Собеседование Android-разработчика крутится вокруг идиом Kotlin, корутин и жизненного цикла платформы — большинство senior-вопросов на самом деле проверяют, понимаете ли вы, что процесс могут убить в любой момент. Ниже — вопросы, которые задают чаще всего, каждый с эталонным ответом. Junior: базовая теория, определения и простые практические кейсы.
Kotlin делит каждый тип на nullable (String?) и non-nullable (String), и компилятор не даёт обратиться к nullable-значению без проверки, поэтому NullPointerException в основном исчезает. Platform types появляются на границе с Java: Kotlin не знает, может ли Java-метод вернуть null, и доверяет вам. Именно оттуда NPE и приходят — аннотируйте Java-API или считайте их результат nullable в месте вызова.
Data class генерирует equals, hashCode, toString, copy и деструктуризацию по первичному конструктору, поэтому это правильный инструмент для значений, которые сравнивают и копируют, — модели API, состояние UI. Sealed class ограничивает набор наследников известным списком, поэтому when по нему исчерпывающий и компилятор укажет на забытую ветку. Вместе они чисто моделируют состояние экрана: sealed-интерфейс Loading, Content, Error, а данные несут data class.
Структурная конкурентность означает, что каждая корутина принадлежит скоупу и родительской задаче, поэтому отмена родителя отменяет всех детей, а родитель не завершится, пока не завершатся они. Именно это спасает от утёкшей фоновой работы, характерной для голых потоков. В Android viewModelScope отменяется при очистке ViewModel, а lifecycleScope — при завершении жизненного цикла, так что работа останавливается, когда её результат уже некуда применить.
Dispatchers.Main работает на UI-потоке, там трогают вью. Dispatchers.IO — большой эластичный пул для блокирующей работы: диск, сеть, база, — потому что такие потоки в основном ждут. Dispatchers.Default размером с число ядер и предназначен для настоящих вычислений вроде парсинга или сортировки. Блокирующий вызов на Default выедает пул — это самая частая ошибка с диспетчерами.
Flow — холодный асинхронный поток: он начинает производить значения при подписке, и у каждого подписчика своё выполнение. StateFlow горячий и всегда хранит ровно одно текущее значение, что делает его естественным для состояния UI — новый подписчик сразу получает актуальное состояние. LiveData — более старый lifecycle-aware держатель; StateFlow вместе с repeatOnLifecycle закрывает ту же задачу остальным инструментарием корутин, поэтому новый код обычно выбирает его.
Поворот, тёмная тема, смена языка и размера окна уничтожают и пересоздают Activity, чтобы она подгрузила ресурсы под новую конфигурацию. Состояние, которое должно выжить, живёт во ViewModel — она переживает пересоздание. Состояние, которое должно пережить ещё и смерть процесса, идёт в SavedStateHandle, потому что систему никто не обязывает держать ваш процесс в фоне. Проверка этого пути через «Не сохранять активности» отличает надёжное приложение от того, что теряет введённые пользователем данные.
Compose перезапускает composable, когда меняется прочитанный им State, и пропускает те, у кого параметры равны и стабильны. Тормоза идут от нестабильных параметров — обычный List или лямбда, захватившая меняющееся значение, — они ломают пропуск и перезапускают большие поддеревья. Лечится подъёмом состояния к ближайшему общему владельцу, неизменяемыми коллекциями или аннотацией @Immutable, а также отложенным чтением через лямбды, чтобы перезапускалась только фаза layout или draw.
DI избавляет класс от знания о том, как собрать свои зависимости, что делает его тестируемым и держит проводку в одном месте вместо разбросанных синглтонов. Hilt генерирует граф Dagger и привязывает время жизни компонентов к андроидным: @Singleton живёт с приложением, @ViewModelScoped — с ViewModel. Практическая выгода — подменить настоящий репозиторий фейком в тестах, не трогая продакшен-код.
Слой UI держит Compose или View плюс ViewModel, которая отдаёт неизменяемое состояние и принимает события. Слой домена держит юзкейсы и чистые бизнес-правила без импортов Android — именно поэтому он тестируется обычным JUnit. Слой данных держит репозитории, которые выбирают между Room и Retrofit и мапят DTO в доменные модели. Важно тут направление зависимостей: домен ничего не знает ни о данных, ни об UI.
На собеседовании ты говоришь вслух под давлением. Кем задаст эти же вопросы, оценит каждый ответ и покажет, что именно подтянуть.
Пройти интервью Junior Android (Kotlin) →