Собеседование Senior Android разработчика

Коротко о видео

Это запись учебного стрима Android Broadcast: Кирилл Розов проводит нескриптованное мок-собеседование Senior Android-разработчика с Михаилом Горюновым, прямо уточняя, что реального оффера не будет. Основная часть охватывает Kotlin, компоненты Android, сервисы и приоритеты процессов, проектирование RSS-агрегатора, миграцию на Jetpack Compose, CI/CD и стратегию тестирования legacy-проекта. В финале ведущий положительно оценивает технические ответы кандидата, но отмечает недостаток уточняющих вопросов при проектировании и ожидает от senior-уровня более уверенного понимания инфраструктуры; это его субъективная оценка, а не результат найма.

Затронутые темы

Что взять на заметку

• На system-design задаче сначала уточняйте бизнес-ограничения: нужен ли фоновый запуск, допустима ли задержка обновления, как показывать ошибки и какие данные должны видеть пользователи.
• Для локального RSS-агрегатора обсуждались периодический опрос по сетевым ограничениям, условные HTTP-запросы с ETag/If-Modified-Since и обработка 304, а также отдельные таблицы источников и новостей с внешними идентификаторами и составным индексом.
• Нужно уметь объяснить Kotlin inline, reified и crossinline: inline может раздувать бинарник, reified даёт доступ к фактическому generic-типу в месте вызова, а crossinline запрещает нелокальный return.
• Для Android важно понимать роль Activity, Service, BroadcastReceiver и ContentProvider как точек входа, назначение AndroidManifest, а также различие foreground service и PendingIntent.
• Миграцию на Jetpack Compose предлагается начинать с инвентаризации UI и зависимостей, пилотных разнородных экранов и новых небольших экранов, а затем постепенно переносить затронутые части приложения.
• Автоматизацию стоит выбирать по соотношению стоимости и пользы: как базовый шаг обсуждались сборка тестовых APK, доставка их тестировщикам, проверки PR тестами и статическим анализом до merge.
• Для legacy-кода предложено не снижать покрытие в новых PR, добавлять тесты при изменениях, покрывать бизнес-логику и ViewModel unit-тестами, интеграции проверять с поддельными источниками данных, а UI-регрессии — screenshot-тестами.