Какие метрики и процессы оценки успеха разработчика используются
Что проверяют
Здесь смотрят на зрелость: понимаете ли вы, что работу разработчика нельзя честно измерить одним числом, и как вы сами докажете свою пользу. Следом часто просят пример: по каким результатам вас оценивали на прошлом месте и чем вы гордитесь. Этот же вопрос полезно задать работодателю: как проходит ревью и что влияет на повышение.
Как отвечать
Разделите командные метрики и индивидуальную оценку. Командные метрики поставки описаны в исследованиях DORA:
- частота деплоев: как часто изменения доходят до прода;
- время от коммита до прода: насколько быстро идёт поставка;
- доля неудачных изменений: сколько релизов заканчивается откатом или хотфиксом;
- время восстановления: как быстро сервис возвращается в строй после сбоя.
Это метрики системы, а не человека. Для более широкой картины есть модель SPACE: удовлетворённость, результат, активность, взаимодействие, поток.
Индивидуально оценивают через процессы: регулярные 1:1, performance review раз в полгода или год, отзывы коллег по схеме 360, матрица грейдов с ожиданиями по уровню. Для Python-разработчика в ней обычно есть качество кода и тестов, проектирование сервисов, работа с производительностью, участие в код-ревью, менторство.
Для своего ответа подготовьте два или три примера с результатом: ускорили эндпоинт, сократили время CI, закрыли целый класс инцидентов. Цифры берите свои, реальные. Если формальной оценки на прошлом месте не было, так и скажите и расскажите, как сами понимали, что работаете хорошо.
Где спотыкаются
Называют строки кода, число коммитов или закрытых задач мерой успеха. Это легко накрутить, и по закону Гудхарта метрика перестаёт что-то значить, как только становится целью.
Приносят velocity в сторипоинтах как личный показатель. Сторипоинты нужны команде для планирования, сравнивать по ним людей бессмысленно.
Отвечают теорией без себя. Интервьюеру важнее услышать, как оценивали вас и что вы из этого вынесли, чем пересказ статей о метриках.