Как происходит рост сотрудников и перформанс ревью
Что проверяют
Обычно этот вопрос задаёте вы в конце собеседования, и от ответа зависит, понятно ли, как расти из мидла в сеньора в этой команде. Если его задают вам («как у вас проходило ревью»), проверяют отношение к обратной связи и умение рассказать о своих результатах без приукрашивания.
Как отвечать
Задавайте вопросы, на которые нельзя ответить лозунгом:
- критерии: есть ли матрица компетенций для бэкенд-разработчиков и что отличает сеньора от мидла именно здесь. Хороший ответ звучит так: владение сервисом целиком, проектирование, влияние на соседние команды;
- что считается результатом: засчитывают ли работу, которую не видно в фичах: снижение задержек после профилирования через
pprof, переход на новую версию Go, починку нестабильных тестов, дежурства и разбор инцидентов; - процесс: частота ревью, самооценка, отзывы коллег, калибровка, связь с пересмотром зарплаты;
- поддержка между ревью: встречи один на один, индивидуальный план развития, менторство, бюджет на конференции;
- пример: когда и за что повысили последнего человека в команде.
Если вас спрашивают о прошлом опыте, говорите от первого лица и со своими фактами: какие цели ставили, какую обратную связь получили, что изменили. Для Go-разработчика убедительно звучат измеримые вещи: снизили p99 сервиса, вынесли часть монолита в отдельный сервис, начали вести дизайн-ревью. Цифры берите свои, не придумывайте. Если формального ревью не было, скажите прямо и расскажите, как добивались обратной связи сами.
Где спотыкаются
Выдают шаблонную STAR-историю про повышение до ведущего без деталей. Первый же уточняющий вопрос «что конкретно изменилось в вашей работе» её разрушает.
Задают вопрос слишком рано, на первом звонке с рекрутером, и в форме «через сколько меня повысят». Лучше спросить нанимающего менеджера о критериях, а не о сроках.
Не спрашивают про инфраструктурную работу. В Go-командах много незаметной работы над надёжностью, и если её не засчитывают, вы окажетесь тем, кто всё чинит и не растёт.