Какие процессы в команде нравятся

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

Совпадаете ли вы с командой по рабочему ритму и понимаете ли, зачем вообще нужны процессы. Ответ «мне всё равно» или «лишь бы не мешали» настораживает не меньше, чем любовь к бесконечным созвонам. Следом обычно спрашивают, какой процесс вам не нравился и что вы сделали, чтобы его поменять.

Как отвечать

Назовите два-три процесса и к каждому причину из своего опыта, привязанную к iOS-разработке:

• небольшие пул-реквесты и быстрое ревью: изменения на сотню-другую строк и ответ ревьюера в течение дня. Так меньше конфликтов в .xcodeproj и в сторибордах, если они ещё остались;
• CI на каждый пул-реквест: сборка, юнит-тесты и SwiftLint в Xcode Cloud, GitHub Actions или GitLab CI на macOS-раннере. На ревью никто не спорит о пробелах;
• автоматическая сборка в TestFlight: fastlane или Xcode Cloud собирает билд, и QA с продактом видят изменения без просьб «скинь сборку»;
• фича-флаги и релизный поезд: релиз выходит по расписанию, недоделанное закрыто флагом и не держит весь выпуск;
• ранний контакт с дизайном: макеты в Figma обсуждаются до оценки, а не после того, как экран уже сверстан.

Приведите свой пример: что было до, что поменялось, что это дало. Цифры берите свои и реальные, например время от мержа до билда в TestFlight или число возвратов после ревью. Если в прошлой команде процессов почти не было, так и скажите и объясните, чего не хватало: «билды собирал один человек на своём Mac, и когда он уходил в отпуск, релиз вставал».

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

Перечисляют ритуалы без смысла: «нравятся стендапы и ретро». Интервьюер так и не поймёт, что именно помогает вам работать.

Придумывают эффектные проценты вроде «ускорили разработку на 20%». Следующим вопросом спросят, как считали, и честного ответа не будет.

Критикуют прошлую команду. Лучше говорить о том, что вы хотите видеть, а неудачный опыт подавать через вывод, который вы из него сделали.