Как организована разработка в вашей команде
Что проверяют
Понимаете ли вы процесс целиком, а не только свою часть. Вопрос задают и как встречный от кандидата.
Как отвечать
Проведите задачу по всему пути, это самый убедительный формат.
Постановка. Откуда берутся задачи: продукт, поддержка, технический долг. Есть ли уточнение требований, участвуют ли в нём разработчики, кто пишет критерии приёмки.
Планирование. Спринты или непрерывный поток, как оцениваются задачи, кто решает, что берём.
Разработка. Ветвление: короткие ветки с частыми вливаниями или долгие ветки релиза. Договорённости по коду: стиль, линтеры, требования к тестам, что входит в определение готовности.
Ревью. Сколько согласований нужно, какой ожидаемый срок ответа, что проверяет человек, а что автоматика. Здесь стоит сказать, что формальные вещи вроде форматирования отданы инструментам, чтобы люди обсуждали смысл.
Проверка. Есть ли выделенные тестировщики или разработчики проверяют сами, что автоматизировано, есть ли отдельный стенд.
Выкладка. Конвейер сборки, как часто релизы, есть ли флаги функциональности, как делается откат.
Эксплуатация. Кто дежурит, как приходят оповещения, разбираются ли инциденты после, есть ли бюджет времени на технический долг.
Общение. Ежедневные встречи, ретроспективы, документация, где лежат решения по архитектуре.
Если это ваш встречный вопрос, самые информативные уточнения такие: сколько времени от готового кода до прода, кто может остановить релиз, что происходит при падении на проде ночью, и сколько времени команда тратит на поддержку по сравнению с новой разработкой.
Где спотыкаются
Описывают только свою часть работы.
Называют методологию по имени и не могут описать реальный поток.
Не знают, как в их команде происходит выкладка и откат.
Не задают этот вопрос сами, а потом обнаруживают релизы вручную по ночам.