Как устроена система наставничества и адаптации в команде

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

Для разработчика уровня middle и выше это вопрос о том, умеете ли вы передавать знания и помогали ли новичкам входить в проект. Следом обычно спрашивают: «Через сколько новый разработчик сделал первую задачу сам и что ему мешало?»

Как отвечать

Опишите, как адаптация была устроена в вашей команде, и отдельно свою роль. Удобный каркас по этапам:

• первый день: доступы готовы заранее, проект поднимается по README парой команд, например dotnet restore и docker compose up для зависимостей. Если на это уходит неделя, это первая проблема, которую стоит назвать;
• обзор решения: наставник проводит по .sln, объясняет слои, где лежат миграции EF Core, как устроены конфигурация и логирование;
• первая задача: маленькая, но настоящая, с доходом до прода. Ревью на ней подробное, с объяснением, а не просто «поправь»;
• правила: соглашения записаны не в головах, а в .editorconfig и анализаторах Roslyn, тогда часть замечаний снимается автоматически;
• контрольные точки: еженедельные встречи и план на первые месяцы, после которого новичок ведёт задачи сам.

Скажите, чем мерили результат: время до первого пулл-реквеста, до первой самостоятельной задачи, отзыв самого новичка. Цифры приводите свои. Если наставником вы не были, расскажите, как адаптировали вас, что сработало и что бы вы поменяли: это тоже ответ по существу.

Если этот вопрос задаёте вы работодателю, спрашивайте конкретно: закреплён ли наставник, какие цели на испытательный срок, кто проводит первые ревью.

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

Рассказывают гладкую историю по STAR с круглыми цифрами вроде «адаптировался за две недели». Интервьюер спросит, что было трудно, и без живых деталей история рассыпается.

Путают наставничество с работой за новичка. Наставник объясняет и ревьюит, а не пишет код вместо него.

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