Расскажите про процесс разработки, устройство команд и пайплайн
Что проверяют
Видите ли вы систему вокруг своего кода. От Java-разработчика уровня middle и выше ждут знания пути изменения от задачи до прода, а не только места, куда он коммитит. Заодно интервьюер прикидывает, насколько ваш прошлый процесс похож на здешний: человек из команды без код-ревью и без автотестов адаптируется дольше.
Как отвечать
Три части вопроса, три части ответа.
Процесс: как задача попадает в работу и что происходит дальше. Груминг с аналитиком, оценка, ветка от основной, pull request, ревью хотя бы одного коллеги, прогон тестов, выкат. Называйте то, что было на самом деле, включая шероховатости.
Команда: состав и границы. Сколько разработчиков, есть ли выделенное тестирование, кто владеет требованиями, как сервисы разделены между командами. Если у каждой команды свой набор сервисов с собственным релизным циклом, скажите об этом, для бэкенда это ключевая деталь.
Пайплайн: этапы и что на каком шаге блокирует. Обычно это сборка, юнит-тесты, статический анализ и порог покрытия, сборка образа, автотесты на тестовом контуре, деплой на стенд, отдельное подтверждение выката на прод. Полезно добавить про миграции базы: как они применяются и что вы делаете с обратной совместимостью, когда новая версия какое-то время работает рядом со старой.
Где спотыкаются
Пересказывают Scrum по учебнику: стендапы, ретро, покер планирования. Спрашивали про ваш процесс, а интервьюер получает определение из статьи, и следующий вопрос будет неудобным.
Второе: называют инструменты вместо смысла. Важно не то, какая система сборки стоит, а что именно она проверяет и на каком шаге вас останавливает.
Третье: молчат про откат. Вопрос про пайплайн почти всегда тянет за собой вопрос, что вы делаете, когда на проде сломалось, и слова «откатим релиз» без деталей про базу и совместимость контрактов обычно мало.