Есть ли у вас опыт менторства, код-ревью, наставничества и адаптации

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

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

Как отвечать

Это вопрос про личный опыт, каркас такой:

• масштаб: скольких людей вели, какого уровня, как долго. «Стажёр на три месяца» и «два джуна в команде из шести» звучат по-разному;
• адаптация: что было на первой неделе. Документ по онбордингу, окружение, которое поднимается одной командой через docker compose, первая маленькая задача, доходящая до прода, наставник для вопросов;
• код-ревью: на что вы смотрите. Корректность, тесты на pytest, читаемость, границы модулей, обработка ошибок. Форматирование и мелкий стиль вынесены в автоматику: ruff, mypy или pyright, pre-commit и проверки в CI, чтобы ревью не тратилось на пробелы и импорты;
• правила ревью: небольшие MR, пометка, какой комментарий блокирующий, а какой пожелание, объяснение причины вместо короткого «переделай»;
• результат: через сколько новичок сделал первый самостоятельный MR, начал ли сам ревьюить, что вы поменяли в процессе по итогам.

Цифры берите только свои и такие, которые сможете объяснить. Если формального менторства не было, говорите честно и расскажите, что было: регулярно ревьюили код коллег, помогли новому человеку разобраться в модуле, написали README к сервису. Это тоже опыт, его нужно просто правильно назвать.

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

Приводят красивые, но непроверяемые проценты вроде «качество кода выросло на 30%». Первый же вопрос «как вы это мерили» ставит в тупик.

Описывают ревью как поиск опечаток и нарушений PEP 8. Интервьюер делает вывод, что до архитектуры и тестов ваше ревью не доходит.

Путают менторство с тем, чтобы сделать задачу за новичка. Сильнее прозвучит, как вы задавали наводящие вопросы и оставляли решение ему.