Вопросы на собеседовании Android-разработчика

Пример сильного ответа

val — это ссылка только для чтения: переприсвоить её нельзя, но объект внутри может меняться, если он мутабельный. var — изменяемая переменная, и злоупотребление ей усложняет рассуждение о коде и мешает многопоточности. const val — константа времени компиляции: подходит для примитивов и строк, объявляется на верхнем уровне или в object и подставляется прямо в байткод, без геттера. В проекте по умолчанию используем val: по статистике линтера таких объявлений около девяноста процентов, а var остаётся только там, где состояние действительно меняется.

• Различает read-only ссылку и неизменяемый объект
• Точно объясняет суть const val
• Подкреплено практикой проекта и цифрой

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

В Android памятью управляет рантайм ART: сборщик мусора стартует от корней — статических полей, локальных переменных, ссылок из нативных слоёв — и освобождает объекты, до которых ссылок больше нет. Реализация поколенческая: молодые объекты собираются часто и быстро, долгоживущие — реже. Паузы короткие, но при большом числе аллокаций сборки идут часто и дают подёргивания интерфейса. Поэтому в работе: не создавать объекты в onDraw и на биндинге списков, переиспользовать вьюхи, профилировать память и следить за утечками через статические ссылки. В одном проекте такие правки снизили джиттер при скролле примерно на треть.

• Верная модель: корни, поколения, паузы
• Сразу переход к практике и профилактике утечек
• Есть измеримый результат оптимизации

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

В работе я держу в голове, что Activity — это точка входа от системы, а Fragment — часть разметки внутри неё, поэтому его жизненный цикл вложен в цикл хоста. У Activity ключевые точки — создание, старт, возобновление, пауза, стоп и уничтожение, плюс сохранение состояния при пересоздании. У Fragment добавляется свой слой: прикрепление к хосту, создание представления и отдельно — уничтожение представления, хотя самостоятельно фрагмент живёт дальше в back stack. Из-за этого ссылки на view приходится обнулять. В одном проекте такие утечки давали около двухсот мегабайт лишней памяти, после правок стало стабильно.

• Показано понимание вложенности жизненных циклов
• Есть конкретика про утечки и мегабайты
• Ответ звучит как опыт, а не заученный текст

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Корутины — это лёгкая надстройка над потоками: код выглядит последовательным, но приостанавливается без блокировки потока. Диспетчер решает, где выполнять работу, structured concurrency связывает дочерние задачи с родительской областью, поэтому отмена и обработка ошибок предсказуемы. Потоки дороже: каждый занимает память под стек, и переключение между ними стоит времени. RxJava даёт мощные операторы и потоки данных, но порог входа выше и стек-трейсы читать сложнее. В своём проекте на корутинах время отклика экрана сократилось примерно на треть, а код стал короче и понятнее.

• Сравнение по трём осям: цена, отмена, операторы
• Есть измеримый результат — треть времени отклика
• Названы диспетчеры и structured concurrency

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

RecyclerView переиспользует представления: он просит адаптер создать столько ViewHolder, сколько помещается на экране, а затем передаёт освободившиеся обратно в пул. ViewHolder хранит ссылки на view, поэтому поиск по разметке не повторяется при скролле. LayoutManager отвечает за раскладку, ItemAnimator — за анимации. DiffUtil сравнивает старый и новый списки и отдаёт точечные операции вставки и удаления, поэтому список не мигает и не теряет позицию скролла. На экране с лентой на несколько тысяч элементов такой подход убрал подлагивания и заметно снизил время обновления списка.

• Объяснён механизм переиспользования, а не только термины
• DiffUtil показан через пользу для интерфейса
• Есть цифра: лента на тысячи элементов

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Смысл всех трёх — развести логику и отображение, разница в направлении связей. В MVP View пассивна, а Presenter напрямую ей управляет через интерфейс, зато связь получается двусторонней и быстро разрастается. В MVVM View наблюдает за состоянием из ViewModel через StateFlow, а ViewModel не знает о view и переживает пересоздание. MVI делает поток однонаправленным: view отправляет intent, редьюсер строит новое неизменяемое состояние, UI просто его рисует, поэтому поведение предсказуемо и легко тестируется. На экране с фильтрами переход на MVVM дал покрытие тестами ViewModel около сорока процентов.

• Сравнение через направление связей, а не список определений
• Названы слабые места каждого подхода
• Есть метрика покрытия тестами

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Dependency Injection — это способ не создавать зависимости внутри класса, а получать их снаружи, чтобы код было проще подменять и тестировать. Dagger 2 генерирует граф на этапе компиляции: модули и компоненты описывают, что и как предоставлять, поэтому ошибки видны до запуска, а не в рантайме. Hilt — надстройка над Dagger с готовыми компонентами под приложение, экраны и вьюмодели, поэтому boilerplate кода заметно меньше. В проекте переход на Hilt убрал несколько десятков строк ручной настройки графа и ускорил сборку модулей.

• Разделены DI как принцип и фреймворки как инструмент
• Подчёркнут плюс Dagger: ошибки на компиляции
• Есть результат — меньше ручного кода

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

В моей практике безопасность строится на нескольких слоях. Токены и ключи никогда не лежат в открытом виде: для них — Android Keystore, а поверх — EncryptedSharedPreferences или DataStore с шифрованием. Пароли не храню вообще, только короткоживущие токены с обновлением. Логи и аналитика чистятся от чувствительных полей на уровне сборки, сеть — только HTTPS с pinning. Плюс блокировка экрана приложения и биометрия для критичных операций. На последнем проекте после аудита число замечаний по безопасности сократилось с 14 до 2 за один спринт — в основном за счёт выноса секретов в Keystore и чистки логов.

• Показан системный подход: Keystore, шифрование, сеть, логи
• Есть конкретный измеримый результат аудита
• Названы практики, а не общая теория

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Сборка — это Gradle: конфигурация модулей, product flavors и build types, управление зависимостями. Отдельно настраиваю minifyEnabled и shrinkResources, правила R8/ProGuard для моделей, рефлексии и сериализации, иначе релиз ломается в рантайме. Важны кэш и CI: полная релизная сборка занимает около шести минут, а за счёт кэша Gradle и параллельных задач время сократилось почти вдвое. R8 не только обфусцирует, но и вырезает неиспользуемый код, поэтому размер APK уменьшился примерно на 25%. Перед релизом обязательно прогоняю тесты именно на release-сборке.

• Разобран весь путь от конфигурации до артефакта
• Названы грабли R8 и способы их обойти
• Есть цифры по времени сборки и размеру APK

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Утечки ищу системно: сначала Memory Profiler в Android Studio, снимаю heap dump и смотрю, какие объекты живут после закрытия экрана. Дальше LeakCanary в debug-сборке — он показывает цепочку ссылок до GC root. Типичные причины — статические ссылки на Activity, незакрытые слушатели, корутины без отмены, Context в синглтоне. Лечение: lifecycle-aware компоненты, слабые ссылки, отписки в onDestroy. На последнем проекте после такой чистки падения по OutOfMemory в проде ушли полностью, а потребление памяти в долгих сессиях снизилось примерно на 30%.

• Назван конкретный инструментарий и порядок действий
• Перечислены реальные причины утечек
• Подтверждено результатом в продакшене

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Compose — это декларативный UI-фреймворк: экран описывается как функция от состояния, а не как императивное дерево View. Отсюда главные плюсы: меньше шаблонного кода, нет разметки и findViewById, удобные переиспользуемые компоненты и живой preview. Состояние держу через remember и StateFlow, рекомпозиция перерисовывает только изменившиеся части. Ещё проще анимации и UI-тесты. Минус — кривая обучения и совместимость с legacy-экранами, поэтому переход обычно постепенный. На последнем проекте новый экран на Compose получилось сделать примерно на 40% быстрее, чем аналогичный на XML.

• Дан корректный контраст декларативного и императивного подхода
• Отмечены и плюсы, и ограничения технологии
• Есть сравнение по скорости разработки

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Intent — это сообщение-описание действия, которое система доставляет компоненту: активити, сервису или получателю. Явный Intent указывает конкретный класс или компонент — так запускаю свои экраны, тут всё предсказуемо. Неявный описывает только действие, категорию и данные, а подходящее приложение выбирает система: например, поделиться ссылкой или открыть точку на карте. Важно проверять resolveActivity, иначе возможен ActivityNotFoundException, и не класть чувствительные данные в extras — их видят другие приложения. Плюс ограничиваю exported-компоненты и валидирую всё входящее.

• Чётко разделены явные и неявные интенты
• Названы практические риски и способы защиты
• Ответ звучит как опыт, а не пересказ документации

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Обычно я разделяю приложение на слои: UI с ViewModel, домен с use-case и моделями, data с репозиториями и источниками данных. Repository скрывает от домена, откуда приходят данные — сеть, кэш или локальная база, — и отдаёт единый поток. В одном проекте такое разделение помогло вынести всю работу с сетью в отдельный модуль: тесты бизнес-логики идут без Android-зависимостей и прогоняются за секунды, а замена источника данных на другую библиотеку заняла около двух дней вместо переписывания всего приложения. Границы слоёв провожу по тестируемости: если логику легко проверить без эмулятора, слой выделен верно.

• Показывает понимание слоёв и их границ
• Есть конкретный результат, а не только теория
• Объясняет критерий выделения слоя — тестируемость

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Сначала замеряю, а не угадываю: смотрю профайлер, Layout Inspector и трейсы кадров, ищу, где теряются миллисекунды. Чаще причина в изображениях: декодирование в главном потоке, отсутствие ресайза под размер вью, лишние перерисовки, глубокая вложенность layout'ов. Дальше подключаю библиотеку загрузки с кэшем и ресайзом, задаю фиксированный размер ImageView, упрощаю вложенность, выношу парсинг и подготовку данных из main-потока, добавляю пагинацию. В похожем случае после этих правок частота кадров выросла примерно с 30 до 58, а время холодного открытия ленты сократилось на треть.

• Сначала диагностика, потом правки — зрелый подход
• Называет реальные причины просадки кадров
• Есть измеримый результат до и после

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Строю single source of truth: лента читается из локальной базы, а сеть только обновляет её. Слой данных — репозиторий, который отдаёт Flow из Room; при старте показываю кэшированные новости, параллельно запрашиваю свежие и складываю в базу. Отдельно держу состояние синхронизации: время последнего обновления, флаги «прочитано» и «сохранено», очередь неотправленных действий. Есть ручной pull-to-refresh и понятная плашка про отсутствие соединения. В проекте с лентой на несколько тысяч материалов такой подход дал мгновенный холодный старт — порядка 300 миллисекунд — и полную работоспособность в метро без сети.

• Озвучивает принцип single source of truth
• Покрывает состояния синхронизации и оффлайна
• Есть конкретная метрика холодного старта

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Первым делом смотрю статистику в системе отчётности об ошибках: фильтрую по версии, устройству и вендору, ищу закономерность — фоновая работа, push или геолокация. Дальше воспроизвожу сценарий на реальных устройствах, в том числе с агрессивной экономией батареи, и изучаю логи. Типичные причины: работа после убийства процесса, отсутствие проверки разрешения в момент выполнения, гонки при обращении к базе из нескольких потоков. Найденное закрываю тестом и защитной обработкой. В одном релизе такой разбор снизил долю падений в фоне примерно на 40 процентов.

• Начинает с данных, а не с догадок
• Учитывает агрессивную экономию батареи
• Заканчивает метрикой и защитой от повтора

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Корзина живёт в доменном слое как отдельная сущность с идентификатором пользователя и позициями, а данные храню в локальной базе за репозиторием. Источник правды — сервер, локально держу кэш и очередь изменений. Правки применяю оптимистично и складываю в очередь; при появлении сети отправляю их на сервер и получаю актуальное состояние. Конфликты разрешаю по времени изменения и версии записи, для удаления использую tombstone, чтобы позиция не «воскресала». Изменения стекают через Flow, поэтому другое устройство видит корзину почти сразу — задержка в пределах пары секунд.

• Чётко определяет источник правды
• Продуманы конфликты и удаление позиций
• Есть понятная реакция интерфейса на синхронизацию

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Пример свежий: дизайнер настаивает на тяжёлой анимации перехода между экранами, а по моей оценке это лишний риск для слабых устройств и плюс неделя работы. Вместо спора я собираю прототип и показываю на реальном телефоне, как проседают кадры, и приношу два варианта: упрощённый переход сейчас или полный позже. Договариваемся на компромисс — простая версия в релиз, анимацию выношу в отдельную задачу. В итоге релиз вышел по плану, жалобы на плавность в отзывах снизились с 6% до 2%, и спор не перерос в конфликт.

• Показывает проверку гипотезы прототипом, а не спор
• Найден компромисс, а не победа одной стороны
• Результат подтверждён метриками отзывов

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

После одного релиза у части пользователей при открытии истории заказов приложение падало. Причина — в коде не оказалось обработки пустого списка, в тестах данные всегда были. Ночью с коллегой смотрю крашлитикс: вижу всплеск, примерно 4% сессий на новой версии. Сначала выкатываю хотфикс с безопасным пустым состоянием, затем добавляю юнит- и UI-тесты на этот сценарий и пункт в чек-лист ревью. Падения уходят за несколько часов, метрика стабильности возвращается к обычной, а похожих инцидентов больше не было.

• Ошибка признана прямо, без оправданий
• Показана диагностика в сжатые сроки
• Есть системная мера против повторения

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Технический долг веду открыто, а не «когда-нибудь потом»: держу список задач с оценкой влияния на скорость и стабильность. В жёсткие сроки договариваюсь о бюджете — примерно 15% времени спринта на самое болезненное, остальное в бэклог. Если дедлайн совсем плотный, предлагаю продуктовые варианты: упростить функциональность сейчас, а рефакторинг сделать на следующей итерации. Так за пару кварталов удалось закрыть больше 20 задач долга, время сборки сократилось примерно на треть, а число срочных хотфиксов заметно снизилось.

• Долг не игнорируется, а управляется списком
• Есть фиксированный бюджет времени на важное
• Учитывает продуктовые ограничения и компромиссы

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Самый тяжёлый баг — редкое падение при возврате на главный экран: воспроизводилось примерно один раз из двадцати, только на части устройств. Логи ничего не давали, поэтому я иду от профайлера: снимаю трассировку, сравниваю сценарии на разных версиях, проверяю гипотезы по одной и сужаю круг до утечки из-за подписки, которая не отписывалась. Исправление оказалось небольшим, но важным. Падения по этой причине ушли с 0,9% до 0,05% сессий, а время открытия экрана сократилось примерно с 2,5 до 0,8 секунды.

• Показана методичная работа с редким багом
• Названы конкретные инструменты профилирования
• Результат измерен в цифрах

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Оцениваю по декомпозиции: разбиваю задачу на подзадачи по полдня-день, сверяюсь с историей похожих работ и добавляю буфер около 20% на неизвестное. Оценку проговариваю с командой — коллективная проверка убирает большинство промахов. Если вижу, что не успеваю, говорю сразу, а не в день сдачи: приношу варианты — уменьшить объём, сдвинуть срок или подключить коллегу. В одном из спринтов так удалось сохранить дату релиза, вынеся второстепенную часть в следующий спринт.

• Оценка опирается на декомпозицию и историю
• Буфер и коллективная проверка снижают риск
• Проблема озвучивается рано и с вариантами решения

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.