Какой идеальный процесс разработки для вас

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

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

Как отвечать

Описывайте не фазы SDLC, а путь задачи от тикета до прода, и к каждому шагу добавляйте, зачем он:

• задача: понятные критерии приёмки и оценка командой до начала работы, чтобы не переделывать после ревью;
• ветки: короткоживущие ветки или trunk-based, мерж раз в день-два, незаконченное прячется за фича-флагами;
• ревью: небольшие пул-реквесты, ревью в течение дня, стиль проверяет машина (Checkstyle, Spotless, SonarQube), а не человек;
• тесты: JUnit 5 и Mockito на логику, интеграционные тесты на Testcontainers с настоящими PostgreSQL и Kafka, а не на H2;
• CI/CD: сборка Maven или Gradle на каждый пул-реквест, красная сборка блокирует мерж, выкладка автоматическая, миграции через Flyway или Liquibase;
• после релиза: метрики через Micrometer и Prometheus, алерты, разбор инцидентов без поиска виноватых.

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

Хорошо закончить вопросом о том, как устроен процесс у них. Это нормальная часть собеседования, а не дерзость.

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

Пересказывают учебную схему «планирование, проектирование, реализация, тестирование». Вопрос про ваши предпочтения, а не про определения.

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

Ругают прошлого работодателя. Лучше формулировать через то, чего хотите, а не через то, что было плохо.