Вопросы на собеседовании мобильного разработчика

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

В Android у Activity ключевые точки такие: создание — инициализация разметки и зависимостей, затем экран становится видимым, затем активным для взаимодействия, при уходе в фон — пауза и остановка, при закрытии — освобождение ресурсов. В iOS у ViewController логика похожая: загрузка view, появление на экране, полное отображение, исчезновение, освобождение. Практический смысл в том, что подписки, слушатели и таймеры ставятся на появлении и снимаются на уходе, иначе появляются утечки. Именно так в одном проекте удалось убрать утечку и снизить потребление памяти примерно на 30%. Ещё учитываю пересоздание экрана при смене конфигурации.

• Показано понимание обеих платформ, а не заучивание
• Есть практический вывод про подписки и утечки
• Подтверждено результатом: минус 30% памяти

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

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

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

• Дан прямой ответ на вопрос по существу
• Названы причины выбора, а не только синтаксис
• Есть измеримый эффект от договорённости в команде

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

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

Это способ не блокировать главный поток, пока идёт долгая операция: запрос к сети, чтение файла, обращение к базе. В мобильном приложении интерфейс отрисовывается в главном потоке, поэтому синхронный запрос подвешивает экран и приводит к пропущенным кадрам. На практике использую корутины в Kotlin или async/await в Swift, разделяю слои так, чтобы сеть и база жили вне главного потока, а результат приходил в интерфейс уже готовым. Отдельно продумываю обработку ошибок, отмену задач и состояния загрузки, чтобы пользователь понимал, что происходит. В одном проекте такой подход помог примерно на 40% ускорить холодный старт и убрать жалобы на подвисание списка.

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

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

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

В работе я опираюсь на SOLID как на способ держать код предсказуемым. Single Responsibility — каждый класс отвечает за одно: экран, репозиторий, маппер. Open/Closed — новые типы оплаты добавляю через интерфейс, не трогая существующий код. Liskov — реализации репозитория взаимозаменяемы: сеть и кэш. Interface Segregation — узкие интерфейсы вместо одного большого. Dependency Inversion — бизнес-логика зависит от абстракций, а не от конкретного сетевого клиента. На проекте с более чем 50 экранами такая структура даёт результат: время на добавление нового платёжного метода сократилось с трёх дней до четырёх часов.

• Разбирает все пять принципов с примерами
• Есть метрика: с трёх дней до четырёх часов
• Связывает принципы с реальной задачей

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

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

Для меня безопасность — это несколько слоёв. Секреты и токены храню только в защищённом хранилище платформы: Keychain на iOS и Keystore на Android, без открытых файлов и логов. Весь трафик идёт по HTTPS, дополнительно включаю certificate pinning, чтобы исключить подмену сертификата. Чувствительные данные в покое шифрую, а в интерфейсе показываю только маскированные значения. Отдельно ограничиваю логи: никаких токенов и персональных данных. На проекте с аудиторией больше миллиона пользователей такой подход даёт результат: утечки из логов исчезли, а число инцидентов с перехватом трафика сократилось до нуля за год.

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

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

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

Dependency Injection — это передача зависимостей извне, а не создание их внутри класса. В мобильной разработке это даёт тестируемость и слабую связанность. Я использую DI через контейнер: например, Hilt на Android или Swinject на iOS. Внедряю репозитории, сетевые клиенты и аналитику через конструктор, а не через синглтоны. Это упрощает подмену на моки в тестах. На одном проекте с более чем 200 юнит-тестами переход на DI даёт эффект: время написания теста сокращается с 30 до 5 минут, потому что не приходится поднимать реальную сеть и базу. Отдельно слежу, чтобы граф зависимостей оставался плоским и читаемым.

• Простое объяснение с примерами фреймворков
• Есть метрика: с 30 до 5 минут
• Связано с тестируемостью и читаемостью

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

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

Способы хранения выбираю под задачу. Небольшие настройки и флаги — UserDefaults на iOS и SharedPreferences или DataStore на Android. Структурированные данные и офлайн-режим — SQLite, Room, Core Data или Realm. Файлы и кэш медиа — файловая система, с шифрованием для чувствительного. Секреты и токены — только Keychain и Keystore. Для больших объёмов и синхронизации между устройствами подходит серверная база, а на клиенте остаётся кэш. На проекте с офлайн-режимом и базой на 50 тысяч записей Room с индексами даёт выборку быстрее, чем прямые SQL-запросы, и это заметно экономит заряд и трафик.

• Перечислены уровни от настроек до базы
• Есть цифра: база на 50 тысяч записей
• Показан критерий выбора под задачу

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

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

В работе с сетью я придерживаюсь слоистой схемы: репозиторий, источник данных, клиент. На Android чаще использую Retrofit с OkHttp, на iOS — URLSession или Alamofire. Для асинхронности — корутины и Flow на Android, async/await на iOS. Обязательно настраиваю таймауты, ретраи с экспоненциальной задержкой и обработку ошибок: различаю сетевые, серверные и бизнес-ошибки. Ответы кэширую, чтобы приложение работало офлайн. На проекте с 30 эндпоинтами единый сетевой слой с интерсепторами даёт результат: дублирование кода сокращается почти вдвое, а добавление нового запроса занимает двадцать минут вместо двух часов.

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

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

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

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

• Есть конкретный результат: минус 40 процентов времени старта
• Показан системный подход: сначала замеры, потом правки
• Названы реальные техники, а не общие слова

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

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

Если коротко, это сообщение, которое приходит на устройство от сервера, даже когда приложение закрыто. Работает так: у приложения есть токен устройства, он отправляется на наш сервер, сервер формирует запрос и через сервис платформы доставляет уведомление — на iOS это APNs, на Android FCM. Дальше система показывает баннер, а приложение обрабатывает данные, когда пользователь открывает его. На практике важны разрешение от пользователя, аккуратная сегментация аудитории и обработка клика. В проекте с базой около миллиона установок сегментация по активности помогла заметно снизить отписки.

• Объяснение от схемы до практики, понятно любому слушателю
• Есть цифра масштаба проекта: около миллиона установок
• Упомянуты подводные камни: разрешения и сегментация

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

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

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

• Чёткая последовательность шагов от билда до релиза
• Названы частые причины отклонения на ревью
• Есть ориентир по срокам, это говорит об опыте

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

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

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

• Показано, что выбор паттерна зависит от контекста
• Упомянуты и простые, и сложные подходы
• Есть результат из практики с масштабом команды

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

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

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

• Показана пирамида тестов от юнитов до ручной проверки
• Есть конкретный результат: багов стало втрое меньше
• Упомянут CI, это важно для командной разработки

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

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

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

• Есть конкретный алгоритм диагностики, а не общие слова
• Показан результат в цифрах: минус 35% падений
• Акцент на профилактике, а не на разовом фиксе

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

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

Это библиотеки локального хранения данных на устройстве: Room в Android, Core Data в iOS, Realm — кроссплатформенный вариант. Они дают объектную модель поверх базы и берут на себя миграции, запросы и реактивные обновления. Мне приходилось сравнивать их на проекте с офлайн-режимом, и выбор был в пользу Room: нативная интеграция с корутинами и Flow, предсказуемые миграции, меньше шаблонного кода — объём слоя доступа к данным сократился примерно на 40%. Отдельно ценю реактивность: интерфейс обновляется самостоятельно при изменении данных, без ручной перезагрузки списков.

• Объяснена суть технологии, а не только название
• Есть критерий выбора под задачу офлайн-режима
• Цифра 40% подтверждает практический опыт

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

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

Базовое правило: интерфейс живёт в главном потоке, вся тяжёлая работа уходит в фон. Для этого использую корутины и Flow, на iOS — async/await, то есть структурированный параллелизм с предсказуемой отменой. Общее изменяемое состояние держу в одном месте, чтобы не ловить гонки, а доступ к нему ограничиваю очередью или актором. В одном проекте распараллеливание загрузки и обработки данных сократило время холодного старта примерно на 30% и убрало подвисания при прокрутке. Моя задача была сделать так, чтобы отмена запроса не оставляла висящих задач и утечек.

• Сформулировано чёткое правило разделения потоков
• Названы инструменты под обе платформы
• Есть метрика: холодный старт быстрее на 30%

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

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

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

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

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

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

Предлагаю модульную архитектуру по фичам: поездка, оплата, карта, профиль и общие слои — около десяти модулей. Внутри каждого модуля — presentation, domain и data: интерфейс на MVVM с реактивными потоками, бизнес-логика в сценариях, репозитории скрывают источники данных — сеть, локальную базу, кэш. Позиции водителей и статусы заказа идут по веб-сокету, остальное — по REST, а заказы, сделанные без сети, встают в очередь. Плюс DI, навигация, аналитика и push. В похожем проекте такой каркас дал запуск новых экранов примерно на треть быстрее и меньше регрессий.

• Архитектура разложена на понятные слои и модули
• Учтены офлайн-режим и обновления в реальном времени
• Есть подтверждение подходом на похожем проекте

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

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

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

• Показан архитектурный принцип — единый источник правды
• Есть измеримый результат: скорость и снижение жалоб
• Учтён UX: пометка об устаревших данных и обновление

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

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

На одном из проектов приложение стало заметно падать при открытии раздела с лентой: доля сбоев выросла примерно до восьми процентов сессий. Моя задача была не залатать симптом, а найти причину. Я поднимаю сбор краш-отчётов с контекстом и разбиваю выборку по версиям системы, моделям устройств и сценарию входа. Причина оказалась в работе с памятью при загрузке крупных изображений. Переписываю загрузку на постраничную с ограничением кэша, добавляю тесты на регресс. В итоге доля сбоев упала ниже одного процента, а холодный старт ускорился примерно на четверть. Отдельно фиксирую в отчёте шаги воспроизведения, чтобы команда не искала это заново.

• Есть структура: проблема, диагностика, решение, результат
• Названы конкретные метрики до и после
• Видна работа с причиной, а не с симптомом

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

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

К обратной связи отношусь как к бесплатной проверке кода чужими глазами: чем раньше замечание, тем дешевле исправление. Мой подход — сначала уточнить, что именно смущает, и попросить пример, потом либо согласиться, либо аргументировать данными, а не эмоциями. Если замечание по делу — правлю в том же merge request и добавляю тест, чтобы ситуация не повторилась. Если аргументы кажутся мне слабее моих, объясняю логику решения и предлагаю альтернативу. На ревью стараюсь приносить небольшие изменения: до 400 строк. По статистике команды такие merge request проходят ревью примерно в два раза быстрее, а число возвратов на доработку сократилось на треть.

• Спокойный взрослый тон без обидчивости
• Есть правило и метрика: маленькие MR, скорость ревью
• Показано умение аргументировать данными, а не эмоциями

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

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

Горжусь проектом, где я отвечаю за мобильное приложение с аудиторией около 200 тысяч активных пользователей в месяц. Моя роль — ключевой разработчик: архитектура, оффлайн-режим, релизный цикл. Задача была снизить отток пользователей после падений и ускорить выпуск версий. Я перевожу экраны на единую библиотеку компонентов, настраиваю автоматические сборки и тесты, ввожу метрики сбоев и скорости запуска. Результат: доля сбоев снизилась примерно втрое, запуск ускорился на треть, релизы стали выходить раз в две недели вместо раза в месяц. Отдельно ценю, что команда начала пользоваться этими метриками в планировании.

• Есть масштаб проекта и понятная личная роль
• Результат подкреплён тремя измеримыми метриками
• Финал показывает влияние на команду, а не только на код

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

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

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

• Показана система, а не разовые усилия
• Упомянуты официальные источники и проверка практикой
• Есть подтверждение пользы: инструменты в продакшене

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