Лучший тест React Native для найма: что действительно работает

Почему стандартные JavaScript-тесты не работают для React Native

Многие компании нанимают инженеров React Native, используя JavaScript-оценки или тесты frontend разработчика. Это неправильно. React Native разделяет синтаксис с React, но ограничения, подводные камни и паттерны проектирования совершенно другие.

Кандидат, который пройдет frontend coding test, может не пройти React Native. Не потому что он плохой, а потому что React Native требует других trade-offs.

Что делает наём React Native другим

The bridge problem

В React Native вам нужно думать о границе между JavaScript и нативным кодом. Web-разработчики это никогда не делают. Инженер React Native должен понимать:

• Как вызывать нативные модули из JavaScript
• Что происходит, когда вы блокируете главный поток (мгновенное зависание приложения)
• Как layout работает по-другому (нет CSS, другой box model)
• Отладка через две runtime (Chrome DevTools для JS, Xcode/Android Studio для нативного)

Этот gap между JavaScript и нативным кодом — вот откуда берутся плохие нанимаемые.

Производительность сложнее

Web-разработчики могут быть медленными и уходить с этим. React Native работает на телефонах с половиной памяти ноутбука. Производительность имеет значение:

• Рендеринг FlatList из 1000 элементов медленный без оптимизации
• Кэширование изображений критично
• Размер bundle влияет на время запуска
• Сериализация bridge дорогостоящая (слишком много нативных вызовов = задержка)

Блестящий web-разработчик, который никогда не думал о производительности, напишет медленный React Native.

Тестирование другое

Веб: тестируйте с jsdom, Jest, React Testing Library. React Native: тестирование, зависящее от платформы, сложнее. Многие инженеры React Native едва тестируют. Оценка, которая не проверяет способность тестирования, упускает сигнал.

Идеальная структура оценки React Native

Фаза 1: Screen (30 минут live)

Дайте им полуготовое приложение с определенной ошибкой. Пример:

«Это приложение отображает постраничный список пользователей из API. Когда вы прокручиваете вниз, оно получает следующую страницу. Но список заикается (проседает фреймрейт) при загрузке. Найдите узкое место и объясните, как его исправить».

Что это проверяет

• Могут ли они рассуждать о производительности React Native?
• Знают ли они FlatList, keyExtractor и оптимизацию?
• Понимают ли они bridge и почему нативный код имеет значение?
• Могут ли они диагностировать без запуска кода?

Web-разработчик может предложить memoization. Инженер React Native знает, что оптимизация FlatList — реальный ответ.

Фаза 2: Take-home (90 минут)

«Построить простое приложение заметок. Пользователи могут создавать, редактировать и удалять заметки. Заметки сохраняются в хранилище устройства. Требования:

• Используйте AsyncStorage для сохранения
• Покажите состояние загрузки при загрузке заметок
• Обработайте случай, когда хранилище переполнено
• Навигация между списком и детальными экранами»

Что это проверяет

• Могут ли они построить полную функцию?
• Думают ли они о сохранении?
• Обрабатывают ли они граничные случаи (переполненное хранилище, поврежденные данные)?
• Могут ли они эффективно использовать React Navigation?
• Организован ли код и тестируемо ли?

Rubric оценки:

• Работает ли это? (50%)
• Соответствуют ли требования? (30%)
• Поддерживаемо ли это? (20%)

Не ожидайте совершенства. Ожидайте рабочего, продуманного кода.

Фаза 3: Walk-through (30 минут)

Спросите:

• «Пройдитесь через то, как заметка сохраняется. Каков поток от ввода пользователя к хранилищу?»
• «Что происходит, если пользователь закрывает приложение при сохранении заметки?»
• «Как бы вы это тестировали? Что бы вы тестировали?»
• «Если нам нужно синхронизировать заметки с облаком, что бы вы изменили?»

Это раскрывает:

• Понимают ли они свой собственный код или они скопировали его?
• Думали ли они о режимах отказа?
• Могут ли они рассуждать о trade-offs архитектуры?

The bridge problem более подробно

Это наиболее важный фильтр найма. Задайте этот вопрос в walk-through:

«Вам нужно сохранить большой файл на устройство. Вы пишете нативный модуль (Objective-C или Kotlin), который это эффективно делает. Ваш JavaScript код вызывает этот модуль. Пройдитесь через структурирование этого. Что происходит, если файл слишком большой? Как вы обрабатываете прогресс?»

Ответ раскрывает, понимают ли они:

• Структура нативного модуля
• Лимиты сериализации bridge
• Асинхронные паттерны через две runtime
• Обработка ошибок в кросс-языковом коде

Web-разработчик об этом не думает. Инженер React Native думает.

Дисциплина тестирования

Инженеры React Native, которые не могут тестировать, — это риск найма. Они пишут код, который сложно рефакторить. Добавьте это в оценку:

«Как вы напишете тест для логики сохранения заметок? Что вы будете тестировать? Что сложно тестировать?»

Хороший ответ: тесты проверяли бы, что AsyncStorage вызывается, что ошибки обрабатываются, что UI обновляется. Сложная часть: тестирование действительного поведения хранилища устройства.

Слабый ответ: «Jest тесты? Я просто мокирую все и проверяю, что функции вызываются».

Красные флаги в оценке React Native

Слишком много нативного кода

Если оценка требует написания Kotlin или Swift, вы тестируете expertise платформы, не инженерию React Native. Инженеры React Native должны быть способны использовать нативные модули, не обязательно писать их.

Слишком много web-подобных функций

«Построить полную систему аутентификации с OAuth» не проверяет навыки React Native. Это проверяет, делали ли они OAuth раньше.

Отсутствующие граничные случаи

Оценка, которая игнорирует offline support, сохранение данных или обработку permissions, неполна.

Нет constraints производительности

«Сделать приложение» без рассмотрения производительности слишком легко.

Сравнение решений кандидатов

Два решения могут оба работать. Как вы различаете?

Кандидат A:

• Использует FlatList с keyExtractor
• AsyncStorage, завернутый в service layer
• Обрабатывает ошибки (переполненное хранилище, denied permission)
• Нет написанных тестов
• Код организован, но defensive

Кандидат B:

• Использует FlatList правильно
• AsyncStorage с wrapper, который обрабатывает JSON сериализацию
• Обрабатывает ошибки и граничные случаи
• Включает тесты (Jest + mock AsyncStorage)
• Код чистый, маленький и тестируемый

Кандидат B лучше. Не потому что приложение работает (оба работают), а потому что они думали о поддерживаемости и тестировании.

Оценка React Native с React web background

Если кандидат имеет сильный React background, но нет React Native опыта, отрегулируйте ожидания:

• Синтаксис и мышление компонента переносятся немедленно
• Паттерны управления состоянием (Redux, Zustand) переносятся
• Паттерны тестирования (Jest, mocking) в основном переносятся

Но они будут бороться с:

• Навигацией (React Router отличается от React Navigation)
• Туннингом производительности
• Интеграцией нативного модуля
• Мышлением в терминах constraints памяти устройства

Оценка все еще должна проверять полный стек, но вы можете быть мягче на кривой обучения и сосредоточиться на core reasoning skills, которые будут переноситься.

Реализация оценки

Если вы оцениваете mobile разработчиков в масштабе, учтите, что React Native имеет другие инструменты и trade-offs, чем native iOS или Android. Не смешивайте оценки. Инженеры React Native нуждаются в собственном pipeline.

Три фазы (live screen, take-home, walk-through) занимают около 2,5 часов времени кандидата и 1,5 часов времени интервьюера. Это приемлемо для role среднего уровня.

Для старших инженеров React Native добавьте 30-минутное обсуждение архитектуры: «Вы строите приложение, которое получает данные из API, кэширует их локально и синхронизирует в офлайне. Как вы это структурируете? Какие библиотеки вы бы использовали?»

Распространенные ошибки, которых нужно избежать

• Не тестируйте web фреймворки (React DOM, Next.js, и т.д.)
• Не требуйте знания определенной library управления состоянием
• Не делайте оценку про CSS или styling
• Не предполагайте, что они использовали каждую платформу (Android, iOS, Web)

Сосредоточьтесь на:

• React основах
• JavaScript основах
• React Native-specific паттернах (FlatList, AsyncStorage, Navigation, Bridge)
• Device constraints и thinking производительности

Используйте этот framework для интерпретации результатов тестов справедливо и последовательно через кандидатов.