Как устроен процесс разработки и релизов в команде

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

Работали ли вы в настроенном процессе или «пушили в мастер». Вопрос открытый, и по ответу видно сразу: размер команды, зрелость релизов и вашу роль в них. Оценивают не методологию, а то, насколько подробно вы помните детали своего процесса.

Как отвечать

Идите по пути задачи от постановки до прода, называя конкретику своей команды:

• постановка: откуда берутся задачи (бэклог, дизайн-макеты, аналитика), кто уточняет требования, участвует ли фронтенд в оценке;
• работа: ветка от main на задачу, договорённость об именовании, размер пул-реквеста, сколько ревьюеров и что смотрят;
• проверки: что гоняет CI на пул-реквесте (линтер, типы, юнит-тесты, сборка, иногда прогон e2e и замер размера бандла), что блокирует мерж;
• выкатка: превью-стенд на ветку, стенд для QA, прод. Регулярный релиз по расписанию или непрерывная выкатка после мержа;
• после релиза: мониторинг ошибок (Sentry и подобное), как откатываете, есть ли фича-флаги, чтобы выключить неудачную функцию без релиза.

Про методологию достаточно одной фразы: двухнедельные спринты со Scrum-ритуалами или поток задач по Kanban. Дальше полезнее рассказать, что делаете при срочной правке на проде: отдельная ветка от релизного тега, укороченное ревью, выкатка вне очереди.

Сильный ответ содержит и оценку: что в процессе работало, что мешало и что вы предложили изменить.

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

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

Обрывают рассказ на мерже. Релиз, откат и мониторинг это как раз то, ради чего вопрос задан.

Говорят «у нас процесса не было». Он есть всегда, даже когда не назван: кто-то же решал, что выкатывать и когда. Опишите, как было на самом деле, это честнее и информативнее.