Собеседование Android-разработчика крутится вокруг идиом Kotlin, корутин и жизненного цикла платформы — большинство senior-вопросов на самом деле проверяют, понимаете ли вы, что процесс могут убить в любой момент. Ниже — вопросы, которые задают чаще всего, каждый с эталонным ответом. Senior: архитектуру, трейд-оффы, менторство и принятие решений.
По границе, которая меняется вместе, и по времени сборки. Фича-модуль, который собирается и тестируется без остальных, окупается скоростью компиляции и тем, что делает направление зависимостей явным. Деление по слоям — модуль из всех вью-моделей — обычно даёт модули, которые всегда меняются вместе, то есть цену без выигрыша.
Сделать локальную базу источником истины, а сеть — синхронизатором, чтобы интерфейс никогда не ждал связи. Дальше начинается сложное: конфликты и порядок — очередь отложенных операций, переживающая перезапуск, идемпотентные запросы, чтобы повтор был безопасен, и явное правило, кто выигрывает, если изменились обе стороны. Прикрутить это потом означает переписать слой данных.
Начать с группировки крешей: какие устройства и какие экраны, потому что на слабых устройствах вылезает то, что остальные терпят. Обычный ответ — картинки: изображение в полном разрешении, раскодированное ради миниатюры, стоит мегабайты каждое. LeakCanary в отладочной сборке называет удержанные объекты, а профайлер памяти показывает, растёт ли куча и возвращается ли она.
WorkManager: он сохраняет запрос и соблюдает ограничения, которые навязывает система, — сеть, зарядку, Doze. Корутина в области умирает вместе с процессом, а будильник — не планировщик. Сама задача обязана быть идемпотентной, потому что система её повторит, и неидемпотентная выполнится дважды.
Постепенно и в обе стороны: Compose внутри фрагмента, ComposeView в существующей вёрстке и интероп, позволяющий переводить по экрану за раз. Переводить экран тогда, когда его всё равно правят, а не отдельным проектом: переписывание без продуктового изменения — первое, что режут при смене приоритетов.
Бизнес-логику и сведение состояния обычными юнит-тестами — они идут секунды и ловят настоящие дефекты. Поведение репозитория и базы с базой в памяти, потому что допущения ORM — ровно то, что скрывают моки. И горстку инструментальных тестов на потоки, которые не должны ломаться никогда, с пониманием, что они достаточно медленные, чтобы большой их набор перестали запускать.
На собеседовании ты говоришь вслух под давлением. Кем задаст эти же вопросы, оценит каждый ответ и покажет, что именно подтянуть.
Пройти интервью Senior Android (Kotlin) →