Какие методологии и флоу разработки используются в команде?

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

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

Как отвечать

Расскажите, как было именно у вас, а не что написано в учебнике. Опорные точки:

• ритм: спринты по две недели с планированием и ретро или поток задач по Kanban с лимитом незавершённой работы. Назовите встречи, которые реально проходят, и сколько времени они съедают;
• постановка: откуда приходят задачи, есть ли уточнение требований до старта, участвует ли фронтенд в обсуждении макетов и API, кто пишет критерии приёмки;
• оценка: story points или часы, оценивает команда или один человек, что делаете при срыве срока;
• флоу веток: короткие ветки от main и мерж в тот же день с фича-флагами (trunk-based), GitHub Flow с превью-стендом на пул-реквест или GitFlow с релизными ветками. Важно не название, а почему выбрано так;
• ревью и качество: сколько апрувов нужно, за какое время разбирают пул-реквест, какой размер PR считается нормальным, что гоняет CI и что блокирует мерж;
• готовность: определение готовности задачи, участвует ли QA, где заканчивается ваша ответственность.

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

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

Пересказывают определения Scrum и Kanban. Вопрос был про вашу команду, а не про сертификацию.

Отвечают одним словом «Agile» или «у нас Scrum» и замолкают. Дальше следует уточняющий вопрос, на котором становится ясно, что деталей вы не помните.

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