Что важно в команде

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

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

Как отвечать

Назовите три или четыре вещи, и за каждой поставьте практику, по которой её видно.

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

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

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

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

Второе: весь ответ про комфорт и доброжелательность, ни одной рабочей практики. Это ничего не говорит о том, как вы себя поведёте, когда двое в команде не согласны друг с другом.

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