Какие критерии хорошей команды для вас

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

Совпадёте ли вы с командой по способу работы и умеете ли формулировать ожидания без общих слов. Следом почти всегда просят пример: «Расскажите про лучшую команду, где вы работали» или «Что вы делали, когда в команде было плохо».

Как отвечать

Назовите три-четыре критерия и к каждому приложите, как это выглядело у вас на практике. Для команды Java-разработки хорошо работают такие:

• код-ревью по делу: пулл-реквесты смотрят в течение дня и спорят о дизайне и именах, а не о пробелах, потому что форматирование и простые ошибки ловят Checkstyle, SpotBugs или SonarQube в CI;
• зелёная сборка как норма: тесты на JUnit 5 и Testcontainers гоняются на каждый мердж, упавший main чинят раньше новых задач;
• общее знание о системе: сервис не держится на одном человеке, есть ADR или хотя бы README, новичок поднимает проект локально за день;
• честная работа с техдолгом: переход на новую LTS-версию Java или Spring Boot планируют заранее, а не откладывают до конца поддержки;
• безопасность ошибаться: инцидент разбирают без поиска виноватого, по итогам меняют процесс.

Затем свяжите критерии с собой: что вы сами делали, чтобы так было. Например, завели шаблон пулл-реквеста или договорились об ограничении на размер ревью. Примеры и цифры берите только из своего опыта. Если такой команды у вас ещё не было, скажите прямо и опишите, чего не хватало на прошлом месте и что вы пробовали изменить: это звучит сильнее выдуманной истории.

Вопрос работает в обе стороны. Спросите в ответ, как у них устроены ревью и релизы, это покажет, что критерии у вас настоящие.

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

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

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

Ругают прошлую команду. Даже если там было плохо, говорите о фактах и выводах, а не о людях.