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

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

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

Кандидат, который успешно сдаст тест для frontend-разработчика, может не справиться с React Native. Не потому, что он слабый специалист, а потому что React Native требует совершенно других компромиссов.

Что делает найм React Native-разработчиков особенным

Проблема моста между JavaScript и нативным кодом

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

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

Этот разрыв между JavaScript и нативным кодом — именно здесь источник ошибок при найме.

Производительность является большей проблемой

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

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

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

Тестирование кардинально отличается

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

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

Этап 1: Задача на понимание (30 минут live)

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

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

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

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

Веб-разработчик может предложить memoization. Инженер React Native знает, что нужна именно оптимизация FlatList.

Этап 2: Домашнее задание (90 минут)

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

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

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

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

Критерии оценки:

• Работает ли приложение? (50%)
• Выполнены ли все требования? (30%)
• Легко ли поддерживать код? (20%)

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

Этап 3: Обсуждение решения (30 минут)

Спросите:

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

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

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

Проблема моста — глубокий разбор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оценка, которая игнорирует offline-поддержку, сохранение данных или обработку прав доступа, является неполной.

Отсутствуют требования к производительности

«Напишите приложение» без требований к производительности — слишком просто.

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

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

Кандидат A:

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

Кандидат B:

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

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

Оценка React Native-разработчика с фоном веб-React

Если кандидат хорошо знает React для веба, но не имеет опыта с React Native, пересмотрите ожидания:

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

Но они будут испытывать трудности с:

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

Оценка должна по-прежнему проверять весь стек, но вы можете быть мягче в отношении кривой обучения и сосредоточиться на базовых навыках рассуждения, которые будут полезны в новом контексте.

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

Если вы нанимаете мобильных разработчиков в масштабе, учитывайте, что React Native имеет другие инструменты и компромиссы, чем нативная разработка для iOS или Android. Не смешивайте оценки. Инженеры React Native нуждаются в собственном процессе отбора.

Три этапа (задача на понимание, домашнее задание, обсуждение) занимают примерно 2,5 часа времени кандидата и 1,5 часа времени интервьюера. Это приемлемо для должности среднего уровня.

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

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

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

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

• Основах React
• Основах JavaScript
• React Native-специфичных паттернах (FlatList, AsyncStorage, Navigation, мост между JavaScript и нативным кодом)
• Ограничениях устройства и понимании производительности

Используйте этот фреймворк для справедливой интерпретации результатов тестов и согласованного подхода ко всем кандидатам.