Какая была команда в проекте

Что проверяют

Как была устроена мобильная разработка на проекте и где в ней были вы. Для Android важно, сколько было разработчиков на платформе, как делили код и кто отвечал за релизы в Google Play. Следом часто спрашивают, как вы синхронизировались с iOS-командой и бэкендом.

Как отвечать

Опишите команду через то, как шла работа над приложением:

• состав: сколько Android-разработчиков, есть ли параллельная iOS-команда, бэкенд, дизайнер, QA, продакт. Если был общий код на Kotlin Multiplatform, скажите, кто за него отвечал;
• разделение кода: многомодульный проект с feature-модулями, владельцы модулей, общий core и дизайн-система. Это показывает, как несколько человек работали без постоянных конфликтов при слиянии;
• связь с дизайном и бэкендом: макеты в Figma, контракт API через OpenAPI или договорённости заранее, моки, пока бэкенд не готов;
• релизы: периодичность, релизная ветка или trunk-based, feature flags, поэтапная раскатка в Play Console, кто следил за Crashlytics и останавливал раскатку;
• качество: ревью, detekt или ktlint, unit- и UI-тесты, CI на каждый пулреквест;
• ваша роль: какие фичи или модули вели, участвовали ли в выборе архитектуры, помогали ли новичкам.

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

Где спотыкаются

Перечисляют людей по должностям и останавливаются. Без того, как команда делила работу и выпускала релизы, ответ не показывает ни процессы, ни ваш уровень.

Не могут объяснить, как шёл релиз: кто собирал подписанный бандл, как раскатывали обновление и что делали при росте падений.

Говорят о команде только хорошее и общими словами. Одна честно описанная проблема, например вечно опаздывающий контракт API, и то, как вы её решили, стоят больше десятка похвал.