Как устроен процесс от запроса функционала до релиза фичи
Что проверяют
Видите ли вы путь фичи целиком, а не только свой кусок кода, и понимаете ли мобильную специфику: релиз приложения и включение функции для пользователей это разные события. Следом часто спрашивают, как вы договариваетесь с бэкендом о контракте и что делаете, если он не успевает.
Как отвечать
Пройдите по этапам и в каждом назовите, что делаете вы как Android-разработчик:
- требования: продакт описывает задачу и метрику успеха, дизайнер готовит макеты в Figma. Ваша часть: вопросы про пустые состояния, ошибки сети, офлайн, разрешения, старые версии Android и разные размеры экрана;
- проектирование: контракт API с бэкендом (OpenAPI), разбивка на задачи, оценка, решение, нужен ли фича-флаг;
- разработка: короткие ветки или trunk-based, код за флагом из Firebase Remote Config или своего сервиса конфигурации. Пока бэкенд не готов, работаете на моках;
- тесты: unit-тесты на ViewModel и use case (JUnit, MockK, Turbine для Flow), UI-тесты на Espresso или Compose testing, скриншотные тесты, если они есть в проекте;
- проверка: сборка уходит QA через Firebase App Distribution или внутренний трек Play;
- релиз: фича попадает в очередной релизный поезд и выходит поэтапной раскаткой, а флаг включают отдельно, сначала на небольшую долю пользователей;
- после релиза: Crashlytics, события аналитики, A/B-тест, если он планировался, и удаление флага, когда фича включена всем.
Если рассказываете про свою прошлую команду, называйте реальные сроки: длину релизного цикла, сколько обычно проходило от макета до прода.
Где спотыкаются
Рассказывают универсальный водопад «требования, разработка, тестирование, релиз» без единой детали про мобайл: сторы, ревью, старые версии у пользователей.
Не упоминают фича-флаги. Без них любая недоделка ждёт следующего релиза, а выкаченную сборку не отозвать.
Забывают про аналитику. Фича без событий выходит, но никто не может сказать, сработала ли она.