Какая была команда

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

Как вы работаете с людьми и подойдёт ли вам команда, в которую вас зовут. Интервьюеру важен ваш масштаб: сколько было человек, какая у вас была зона ответственности, кто принимал технические решения. Следом часто спрашивают, как проходило код-ревью и как вы решали разногласия.

Как отвечать

Короткий каркас, минуты на две:

• состав: сколько человек и какие роли. Например, четыре Go-разработчика, тимлид, QA и аналитик, фронтенд в соседней команде;
• зона ответственности: какими сервисами владела команда, от разработки до дежурств. Для Go-команды это обычно несколько микросервисов, gRPC или REST между ними, свои очереди и базы;
• процессы: Scrum с двухнедельными спринтами или Kanban, как планировали, кто оценивал задачи;
• инженерная культура: обязательное ревью, golangci-lint и тесты в CI, договорённости о стиле, ADR или RFC для архитектурных решений;
• ваша роль: что делали именно вы. Вели сервис, менторили новичка, отвечали за релизы или дежурства;
• итог: что получилось у команды и чему вы там научились.

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

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

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

Рассказывают только «мы» и не отвечают, что делали сами. Нанимают вас, а не команду, и интервьюер начнёт вытягивать вашу роль вопросами.

Приносят заготовку по STAR с круглыми процентами: «отклик сократился на 30%, баги на 50%». Первый же вопрос «как мерили» разрушает историю.

Жалуются на бывших коллег или руководителя. Даже если было тяжело, говорите о фактах и выводах, без оценок людей.