Была ли в команде система наставничества для онбординга
Что проверяют
Как вы входите в новую команду и помогаете входить другим, а заодно насколько взрослые процессы были на прошлом месте. Следом обычно спрашивают, были ли вы наставником сами и что поменяли бы в онбординге.
Как отвечать
Нужен рассказ из вашего опыта с конкретикой, а не описание идеальной программы. Удобный каркас:
- как было устроено: бадди или ментор на первые недели, план на испытательный срок, чек-лист первого дня;
- что входило для Python-разработчика: окружение, которое поднимается одной командой (
docker compose up, зависимости черезuvилиpoetry, хукиpre-commitсruffиmypy), доступы к репозиториям, CI и мониторингу, обзор архитектуры сервисов; - первые задачи: маленькие, но проходящие весь путь до прода: правка, тест на
pytest, ревью, деплой. Так новичок за неделю видит весь конвейер; - обратная связь: регулярные встречи один на один, разбор замечаний с ревью, понятный критерий, когда человек «вошёл».
Результат лучше мерить наблюдаемыми вещами: через сколько дней первый PR, когда новичок взял задачу без помощи, сколько вопросов закрыла документация. Цифры берите свои, даже скромные: выдуманные проценты интервьюер распознаёт.
Если вы были наставником, расскажите одну историю: что не получалось у новичка и что вы изменили. Например, README по запуску проекта стал живым документом, который каждый новый человек дополняет по ходу своей настройки.
Если системы наставничества не было, скажите честно и покажите, что вы из этого вынесли: как входили сами, что помогло, что бы вы ввели. Это тоже хороший ответ, если в нём есть выводы.
Где спотыкаются
Отвечают «да, была» и замолкают. Вопрос открытый, интервьюер ждёт деталей: кто наставлял, как долго, чем именно помогали.
Ругают прошлую компанию за то, что их «бросили». Лучше описать факт и то, что вы сделали, чтобы разобраться самостоятельно.
Приводят круглые цифры вроде «производительность выросла на 30%». Производительность разработчика так не меряется, и следующий вопрос «как считали?» ставит в тупик.