Как построен производственный процесс от получения задачи до внедрения
Что проверяют
Понимаете ли вы весь путь задачи и участвуете ли в нём, или получаете макет и отдаёте код дальше.
Как отвечать
Опишите цепочку и свою роль на каждом шаге:
- постановка: задача приходит от продукта с целью и критериями приёмки. Здесь разработчик задаёт вопросы про крайние случаи и предлагает более дешёвое решение, если оно есть;
- оценка и декомпозиция: разбивка на части, оценка диапазоном, выявление зависимостей от бэкенда и дизайна;
- разработка: ветка, небольшие коммиты, тесты на логику, проверка на разных размерах экрана и версиях системы;
- ревью: обсуждение решения, а не только стиля. Хорошая практика это самопроверка перед отправкой на ревью;
- тестирование: сборка уходит тестировщику через систему распространения (TestFlight или аналог), разбор замечаний;
- релиз: сборка на проверку в магазин, поэтапная раскатка, признаки функций для того, что можно включить или выключить с сервера;
- после выката: наблюдение за падениями и метриками, разбор отзывов, оперативное исправление при необходимости.
Специфика мобильной разработки, которую стоит подчеркнуть: релиз проходит проверку магазина и занимает время, откатить версию у пользователей нельзя, а старые версии живут месяцами, поэтому серверная часть обязана оставаться совместимой.
Хорошо, если добавите, что улучшали в процессе сами: автоматизацию сборок, ускорение конвейера, шаблон описания задачи, договорённость о признаках функций.
Где спотыкаются
Описывают только этап написания кода, будто задача появляется и исчезает сама.
Не упоминают проверку магазина и поэтапную раскатку, хотя это ключевые отличия мобильного релиза.
Не могут назвать, что изменили бы в процессе, из чего видно отсутствие интереса к нему.