Как устроена иерархия в команде

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

Понимаете ли вы, как в команде принимаются решения и где в этой схеме вы сами. Интервьюеру нужна не оргструктура, а ответы на вопросы: кто ставит задачи, кто решает технические споры и кому вы подотчётны. Следом часто спрашивают: «Бывало ли, что вы не соглашались с решением тимлида?»

Как отвечать

Опишите свою последнюю команду по трём линиям, у каждой свой владелец:

• продуктовая: продакт решает, что делать и в каком порядке, приоритеты живут в бэклоге;
• техническая: техлид отвечает за архитектуру сервисов на Go, общие стандарты (конфиг golangci-lint, подход к ошибкам и context), спорные изменения проходят через design doc;
• людская: тимлид или engineering manager ведёт найм, one-to-one, ревью результатов и рост по грейдам.

В небольших командах техлида и тимлида совмещает один человек, это нормально, так и скажите.

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

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

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

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

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

Говорят «у нас не было иерархии, все равны». Решения всё равно кто-то принимал, и неумение это описать выглядит как непонимание процессов.