Какую роль вы занимаете в команде: рядовой разработчик, сеньор или тимлид

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

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

Как отвечать

Назовите роль и сразу раскройте её через ответственность. Удобно идти по четырём осям:

• масштаб: задача, фича, сервис целиком или несколько сервисов. Например, «владею двумя сервисами на Go: API на net/http с роутером chi и воркером, который читает Kafka»;
• решения: что вы решаете сами. Выбор библиотек, структура пакетов, протокол между сервисами (gRPC или REST), схема таблиц и миграций;
• прод: участвуете ли в дежурствах и как разбираете инциденты. Для Go конкретика ценится: pprof для утечек горутин и памяти, трассировка, метрики в Prometheus;
• люди: ревью, наставничество, участие в найме, декомпозиция задач для команды.

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

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

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

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

Отвечают «был и рядовым, и сеньором, и тимлидом, смотря по проекту». Без конкретики это звучит как уклонение.

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

Выдают техническое лидерство за управление командой, а затем не могут рассказать ни про одну встречу один на один или разрешённый конфликт.