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