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

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

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

Как отвечать

Опишите команду так, чтобы собеседник мог её представить:

• размер и роли: сколько Python-разработчиков, есть ли выделенный QA, DevOps, аналитик, кто ставит задачи;
• продукт и стек: над чем работали и на чём. Например, бэкенд на Django или FastAPI, PostgreSQL, Celery для фоновых задач, или команда данных с Airflow и pandas;
• устройство работы: длина итераций, планирование, путь задачи от тикета до прода, кто её тестировал;
• качество кода: обязательное ревью, ruff и mypy в CI, pytest с порогом покрытия или без него, хуки pre-commit;
• ваше место: зона ответственности, решения, которые принимали сами, помощь коллегам, участие в найме или онбординге;
• что вынесли: практику, которую хотите принести на новое место, и то, что сделали бы иначе.

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

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

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

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

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