Тест мобильного разработчика: примеры вопросов. Что спрашивать
Почему примеры вопросов имеют значение
Большинство оценок мобильных разработчиков построены неправильно. Они либо опираются на мелочь (какое имя метода жизненного цикла в Android 11?), либо они так открыты, что рушатся под собственным весом. Правильные примеры вопросов находятся в середине: специфичные достаточно для оценки, достаточно широкие для выявления суждения.
Если вы строите оценку мобильного разработчика с нуля, знание того, какие типы вопросов работают, — половина боя. Вот паттерны, которые действительно предсказывают производительность работы.
Вопросы, специфичные для iOS
1. Жизненный цикл контроллера представления с состоянием
«Экран входа загружается. При первом рендере он получает сеанс аутентификации из брелока. Если сеанс недействителен, он обновляет токен с сервера. Напишите код для viewDidLoad и viewWillAppear, который это обрабатывает без дублирующихся API вызовов.»
Это проверяет: понимание жизненного цикла ViewController, управление состоянием, сетевые функции и оборонительное программирование. Это не мелочь. Младший пишет это по-другому, чем старший, и обе версии обучаемы.
2. Утечка памяти в делегировании
«Вот контроллер представления, который держит сильную ссылку на объект делегата. Делегат (объект менеджера) держит сильную ссылку обратно на контроллер представления. Напишите тест, который ловит этот цикл сохранения.»
Это выходит за пределы статических знаний. Требуется понимание проблемы, дизайн теста и исправление. Реальная работа.
3. SwiftUI + async-await навигация
«У вас есть стек навигации. Когда кнопка нажата, нужно получить данные, показать состояние загрузки, затем перейти на экран деталей. Напишите код, используя async-await и @State.»
Это современно. Это исключает кандидатов, которые не поддерживают и приоритизирует людей, которые понимают современные паттерны совместного использования.
Вопросы, специфичные для Android
1. Жизненный цикл фрагмента с сохранённым состоянием
«Фрагмент отображает список элементов. Список получается из сети. Если пользователь вращает устройство, список должен сохраниться без повторного получения. Напишите код, используя ViewModel и SavedInstanceState.»
Проверяет: жизненный цикл, сохранение состояния и современные паттерны архитектуры. Не тривиально, не невозможно.
2. Внедрение зависимостей при тестировании
«У вас есть репозиторий, который зависит от сервиса API. Напишите код установки теста, который мокирует сервис и обеспечивает, что репозиторий правильно обрабатывает ошибку 500.»
Это выявляет, думают ли они о тестируемости при проектировании.
3. Пользовательские разрешения с обратным вызовом
«Запросите разрешение камеры при runtime. Если отклонено, покажите диалог, объясняющий почему. Если одобрено, откройте камеру. Напишите код.»
Практичный, современный Android. Кандидат либо знает проблему, либо нет.
React Native (кросс-платформа)
1. Утечка состояния навигации
«У вас есть два экрана в стеке навигации. Экран A получает данные при монтировании. Когда пользователь переходит на экран B и обратно на A, данные должны быть переполучены, не кэшированы. Напишите код, используя React Navigation и hooks.»
Это проверяет понимание жизненного цикла состояния и распространённого источника ошибок.
2. Производительность: FlatList с изображениями
«У вас есть FlatList, отображающий 1000 элементов изображения. Это медленно. Напишите код, который исправляет это (keyExtractor, getItemLayout или изменение размера изображения).»
Практичное отладки. Кандидат либо знает проблему, либо нет.
3. Мост к нативному модулю
«Нужно вызвать нативную функцию из JavaScript. Напишите код моста для iOS или Android, включая обработку ошибок.»
Это проверяет, понимают ли они границу и могут ли работать через неё.
Общие вопросы мобильной разработки (все платформы)
1. Версионирование API компромисс
«Ваш API изменил схему ответа. Старые клиенты всё ещё в использовании. Напишите код в мобильном клиенте, который обрабатывает обе версии.»
Проверяет: прагматизм, оборонительное программирование и мышление об обратной совместимости.
2. Синхронизация состояния в offline-first
«Пользователь редактирует элемент в offline. Как вы ставите в очередь это редактирование и синхронизируете, когда соединение возвращается? Напишите псевдокод.»
Это архитектурный уровень. Ответ выявляет зрелость дизайна.
3. Производительность запуска приложения
«Ваше приложение загружается в течение 4 секунд. Какие три вещи вы бы проверили и почему? Напишите код для одного из них.»
Достаточно открыто для выявления мышления. Достаточно специфично для заземления.
Как оценивать эти вопросы
Не оценивайте по полировке. Оценивайте по:
- Это работает? Делает ли код то, что был просит?
- Развернули бы вы его? Есть ли необработанные граничные случаи?
- Могут ли они это объяснить? При прохождении, могут ли они рассуждать о своих выборах?
Для мобильной работы специфично, live coding интервью с этими типами вопросов выявляет больше, чем только артефакт, потому что кандидат должен навигировать инструменты и их собственную неуверенность в реальном времени.
Чего избегать
Не спрашивайте:
- «Какова разница между Strong и Weak ссылками?» (мелочь)
- «Реализуйте целое приложение для чата» (слишком широко, неоцениваемо)
- «Что делает этот неясный флаг?» (бессмысленно)
Спрашивайте:
- Проблемы с ясными критериями успеха
- Проблемы, которые показывают суждение (компромиссы, не просто правильность)
- Проблемы, которые выглядят как работа
Эти примеры вопросов якорируют вашу оценку к работе. Начните с них, добавьте собственные варианты, специфичные для домена, и валидируйте оценку один раз вы запущены.
Следующие шаги
Если вы оцениваете мобильных разработчиков в масштабе, наличие согласованного набора примеров в вашей команде предотвращает смещение. Используйте их как шаблон, кастомизируйте для вашего стека и повторяйте на основе того, что вы узнаёте от нанятых кандидатов.