> Был ли опыт наставничества в компаниях

Короткий ответ

Да, опыт наставничества был, и я рассматриваю его как часть инженерной работы, а не как отдельную активность. Я вёл onboarding новых разработчиков, проводил регулярные one-on-one, делал code review с обучающим уклоном и помогал коллегам расти до следующего грейда. Формат зависел от контекста: иногда это был менторинг один на один, иногда - внутренние воркшопы и design review для команды.

Подробное объяснение

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

Ключевой trade-off здесь - время. Наставничество конкурирует с delivery, поэтому я явно выделяю бюджет, например 10-20% времени в неделю, и договариваюсь об этом с менеджером. Иначе менторинг незаметно съедается срочными задачами. Ещё один важный момент - не решать задачу за менти, а задавать вопросы и давать инструменты, чтобы человек сам приходил к решению. Это медленнее в моменте, но быстрее в долгую.

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

На практике

В одной из команд я вёл onboarding трёх разработчиков параллельно. Мы завели checklist по неделям: первая неделя - окружение, доступы, чтение архитектурной документации; вторая - первый небольшой PR в production; третья-четвёртая - самостоятельная задача под review. Я проводил ежедневные короткие синки первые две недели, потом переходил на два раза в неделю. Параллельно я делал code review так, чтобы это было обучение: объяснял не только что поменять, но и почему, ссылался на внутренние гайды и паттерны.

Ещё был кейс менторинга middle-разработчика до senior. Мы составили план на полгода: ownership за сервисом, участие в design review, ведение технической документации, менторство стажёра. Я давал feedback по каждой зоне и помогал собирать evidence для promotion-пакета. В итоге человек успешно прошёл review. Отдельно я запускал внутренний воркшоп по тестированию и CI, который потом переиспользовали в других командах.

Как отвечать на собеседовании

Отвечайте конкретно и структурно: кого менторили, в каком формате, сколько времени это занимало, какой был результат. Хорошо работает схема "контекст - действия - измеримый результат". Упомяните, как вы балансировали наставничество с delivery и как договаривались об этом с менеджером. Если опыта формального менторинга мало, честно скажите об этом и приведите смежные примеры: code review, воркшопы, помощь коллегам, документация. Не преувеличивайте - senior-интервьюер легко отличит реальный опыт от общего рассказа.

Что проверяет интервьюер

Интервьюер проверяет, умеете ли вы развивать других, а не только писать код. Ему важно увидеть системность: есть ли у вас подход к onboarding, менторингу и feedback. Также проверяется зрелость в приоритизации - способность выделять время на наставничество без ущерба для delivery. Дополнительно оценивается impact: как вы измеряете рост менти и как это влияет на команду. На senior-уровне ожидается, что вы масштабируете знания через артефакты и процессы, а не только через личное общение.

Типичные ошибки

Частая ошибка - отвечать общими фразами без конкретики: "помогал коллегам", "делал review". Другая крайность - рассказывать только про менти, забывая про свой вклад и результаты. Некоторые кандидаты преувеличивают масштаб наставничества, и это вскрывается на уточняющих вопросах. Ещё одна ошибка - не упоминать trade-off между менторингом и delivery, что выглядит нереалистично. Также плохо, когда кандидат решал задачи за менти вместо обучения, - это сигнал о слабом понимании роли наставника. И наконец, отсутствие измеримых результатов снижает убедительность ответа.