Как устроена коммуникация в команде
Что проверяют
Как вы работаете со смежниками. У мобильной разработки их особенно много: дизайн, бэкенд, QA, аналитика, магазины приложений, и почти каждая задача упирается в чужую готовность.
Как отвечать
Опишите свою команду и точки стыка, они у мобильщика специфичные:
- дизайн: макеты в Figma, проверка состояний (загрузка, ошибка, пустой экран, длинный текст), обсуждение того, что не ложится на нативные компоненты, до старта разработки, а не после;
- бэкенд: контракт API согласуется заранее, иначе вы неделю ждёте ручку. Полезно назвать, как договаривались о версионировании: старое приложение остаётся у пользователей надолго, и ломать формат ответа нельзя;
- QA: сборка на проверку через внутренний канал (Firebase App Distribution, внутреннее тестирование в Google Play), обсуждение того, какие устройства и версии Android входят в проверку;
- релизы: план выкатки, поэтапное раскатывание, откат через фича-флаг, а не через новую сборку, потому что доставка обновления пользователям занимает дни.
Дальше ритуалы: дейли, планирование, ретро, и обязательно письменный след. Договорённость по API или по поведению экрана фиксируется в задаче, потому что через месяц вспомнить, почему сделано так, не сможет никто.
Приведите короткий пример: заметили расхождение макета с реальными данными, пришли к дизайнеру и аналитику до реализации, сэкономили переделку.
Где спотыкаются
Молча реализуют неоднозначный макет по своему пониманию. Это самая частая причина переделок в мобильной разработке.
Не поднимают вопрос об обратной совместимости API, хотя старые версии приложения живут у пользователей месяцами.
Отвечают шаблонно, без деталей своей команды. Здесь ждут конкретику: сколько человек, кто ставил задачи, как согласовывались релизы.