Привычна ли среда с жесткими процессами релизов

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

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

Как отвечать

Отвечайте фактами, а не заявлением о лояльности. Назовите элементы, с которыми работали:

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

Дальше покажите, что понимаете цену ошибки: там, где откат стоит дорого, регламент дешевле инцидента. И что умеете работать внутри процесса, а не вопреки: нарезать задачу так, чтобы она влезала в окно, писать миграции без разрушающих шагов, оставлять совместимость на время выкладки.

Если такого опыта не было, скажите прямо и опишите, что ближе всего: ревью, тесты, стенд. Уместно и спросить самому, как здесь устроены частота релизов, откат и кто принимает решение о выкладке.

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

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

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

Приписывают себе опыт, который видели со стороны. Следующий вопрос будет предметным: что делали при неудачном релизе, как откатывали миграцию, кто принимал решение. Незнание деталей выдаёт пересказ.