Как устроена иерархия в команде
Что проверяют
Как вы устроены внутри рабочей структуры: к кому идёте с техническим вопросом, к кому с проблемой сроков, кто вам ставит задачи. Заодно смотрят, не конфликтный ли человек и есть ли опыт работы в команде нужного размера.
Как отвечать
Опишите свою реальную команду, а не схему из статьи. Достаточно перечислить роли и то, что каждая решает:
- тимлид: люди, распределение задач, рост и оценка. С ним обсуждаются загрузка, отпуска, конфликты;
- техлид или архитектор: технические решения, ревью подходов, ответственность за целостность системы. Иногда это тот же человек, что и тимлид, так и скажите;
- продакт или аналитик: что делаем и зачем, приоритеты, требования;
- разработчики по грейдам: джуниор работает с наставником, мидл ведёт задачу сам, сеньор берёт проектирование и помогает остальным;
- смежники: QA, дизайн, DevOps, поддержка.
Дальше самое важное: как принимаются решения. Хороший ответ звучит примерно так: мелкое техническое решение принимает исполнитель, спорное выносится на обсуждение с техлидом или на дизайн-ревью, продуктовое остаётся за продактом. Скажите, как эскалируете: сначала напрямую с человеком, потом с лидом, а не сразу через голову.
Обязательно назовите свою позицию в этой структуре и зону ответственности. Если опыт был в маленькой команде без выраженной иерархии, так и говорите: пять человек, один лид, решения обсуждаем на дейли. Это нормальный ответ.
Где спотыкаются
Рисуют идеальную схему, а на уточняющий вопрос («кто у вас утверждал архитектуру?») ответить не могут.
Жалуются на бывшего руководителя. Вопрос про устройство работы, а не про претензии, и негатив в ответе запоминается сильнее содержания.
Отвечают односложно, «обычная иерархия». Интервьюер ждёт конкретики: сколько людей, кто за что отвечал, как это влияло на вашу работу.