Собеседование Senior Android разработчика. Проводит Алексей Быков

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

Публичное тренировочное собеседование Android-разработчика: кандидат с примерно тремя годами Android-опыта рассказывает о работе в небольшой команде, релизах, legacy-коде и ошибке, проявившейся только в release-сборке. Техническая часть охватывает Kotlin, архитектуру, MVVM/MVI, Dagger, RxJava и coroutines/Flow, RecyclerView, производительность UI, сеть, кэширование, многопоточность и тестирование. В конце интервьюер разбирает ответы кандидата, отмечая необходимость глубже изучить Dagger, современные реактивные инструменты и практики тестирования; затем участники отвечают на вопросы зрителей.

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

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

• Для рассказа о технической ошибке подготовьте полный кейс: в видео release-сборка падала на экране из-за непроверенной конфигурации зависимостей, а профилактикой названы проверка release-подобной сборки, smoke/UI-тесты и ручной проход ключевых экранов перед поставкой.
• На вопрос о качестве кода недостаточно ответить «писать unit-тесты»: интервьюер ожидает связь между code review, линтерами и статическим анализом, unit-, UI-, интеграционными и screenshot-тестами, а также понятный процесс их запуска в CI и перед релизом.
• При выборе архитектуры нужно объяснять требования и компромиссы: кандидат сопоставляет MVP, MVVM и MVI через управление состоянием, жизненный цикл View и тестируемость, а не объявляет один паттерн универсальным.
• Стоит уверенно знать Dagger на уровне компонентов, subcomponents, scopes, жизненного цикла объектов и влияния code generation на сборку, особенно в многомодульном проекте.
• Для списков нужно уметь объяснить DiffUtil, различие item/content comparison, payloads, ListAdapter/ConcatAdapter и диагностику лагов через профилировщик кадров.
• Для сетевой и реактивной части полезно различать WebSocket, polling и long polling, понимать scheduler’ы RxJava, дублирование подписок/запросов, а также осознанно сравнивать RxJava с coroutines и Flow.
• На обратной части собеседования кандидат предлагает спрашивать о процессе появления и релиза фич, тестировании и CI/CD, размере команды и продукта, обучении, компенсациях и причинах, по которым интервьюер работает в компании.