Как ответить
Да, я регулярно участвовал в менторстве стажеров и джуниоров. В последней команде (продуктовая разработка, стек Java+Spring) мы брали двух-трёх стажёров каждые полгода. Я отвечал за онбординг нового backend-разработчика и сопровождение его первых спринтов.
Мой подход состоял из трёх этапов:
- Первая неделя — погружение. Я готовил «карту знаний»: какие микросервисы используем, как устроена CI/CD, где лежит документация. Стажёр получал задание разобрать простой сценарий (например, отладка запроса) и описать, что происходит от контроллера до базы. На этом этапе я не давал готовых ответов, а подсказывал, куда смотреть в логах и коде.
- Первые 2–3 спринта — парное код-ревью. Каждую неделю мы выбирали одну его задачу и ревьюили её вместе вживую. Я объяснял не только «что исправить», но и почему мы пишем тесты именно так, почему используем Optional, а не проверки на null. Такие сессии длились час, но они давали больше, чем 10 отдельных комментариев в PR.
- Еженедельные 1-1 (30 минут). Обсуждали прогресс, узкие места. Я записывал, какие темы вызвали трудности, и через неделю возвращался к ним уже на реальном коде.
Пример из практики: стажёр Саша пришёл с базовым знанием Java, без опыта работы с распределёнными системами. Через три месяца он закрыл задачу по интеграции с внешним API — сам спроектировал ретраи, написал тесты и провёл демо. Через шесть месяцев он уже ревьюил задачи других джуниоров.
Я вынес из менторства две вещи. Первая: чтобы объяснить сложное, нужно самому глубже разобраться в теме. Например, когда я рассказывал, почему мы избегаем циклов в Hibernate, я нашёл проблемные места в своём коде. Вторая: менторство снижает количество «пожарных» вопросов — если потратить час на онбординг, потом сэкономишь десять часов на исправлении ошибок.
Сейчас менторство — часть моей рутины. Считаю, что это не дополнительная нагрузка, а способ сделать команду сильнее и освободить время для сложных задач.