Рубрика: Аудит талантов · Блок: Архитектура талантов

Оценка разработчиков: что проверяет тест кода, а что — нет

Технические задания и проверка кода хорошо показывают, умеет ли разработчик решать задачи. Но команды чаще страдают от другого: человек не договаривается, не просит помощи, теряет интерес или конфликтует. Поэтому оценка разработчика складывается из двух частей — проверки навыков и оценки того, как он работает с людьми и что его мотивирует.

Решение: ИТ-команды, Оценка персонала

Зачем оценивать разработчиков системно

Разработчиков оценивают в нескольких ситуациях: при найме, при решении о повышении грейда (уровня в сетке должностей), при назначении тимлидом, при формировании новой команды. В каждой из них ошибка стоит дорого: слабый найм замедляет команду на месяцы, неудачное назначение может стоить компании сильного специалиста.

Чаще всего оценка сводится к проверке технических навыков. Это необходимо, но недостаточно. В ИТ-командах проекты нередко срываются не из-за того, что кто-то не умеет писать код, а из-за проблем во взаимодействии — недоговорённостей, скрытых конфликтов, потери мотивации.

Как устроена оценка ИТ-специалистов и команд в целом, — на странице оценки ИТ-специалистов. Здесь — что именно проверять и чем.

Что проверяют технические задания и код-ревью

Технические навыки разработчика — hard skills — проверяют несколькими способами:

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

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

Чего не покажет тест кода

Тестовое задание выполняется в одиночку, в спокойных условиях, без коллег и заказчика. Поэтому оно почти ничего не говорит о том, что часто решает успех в реальной команде:

• как человек реагирует, когда задача сформулирована нечётко;
• просит ли он помощи или неделю сидит над проблемой молча;
• как принимает замечания на ревью своего кода;
• умеет ли объяснить своё решение коллегам без технического бэкграунда;
• что будет его мотивировать через год, когда новизна пройдёт;
• как он ведёт себя в конфликте о технических решениях.

Именно эти вопросы закрывает оценка soft skills — гибких навыков, связанных с поведением и мотивацией.

Хороший способ закрыть часть этих вопросов на собеседовании — поведенческие вопросы о прошлом опыте. Не «как бы вы поступили», а «расскажите о случае, когда требования к задаче поменялись в середине работы», «когда вы не соглашались с решением тимлида и что сделали», «когда ваш код серьёзно раскритиковали на ревью». Ответы на такие вопросы показывают реальное поведение, а не представление кандидата о правильном ответе.

Работа в команде: стиль поведения

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

• Разработчик с выраженным Соответствием часто ценит качество, стандарты и предсказуемость; ему комфортно в задачах, где нужна точность, но может быть труднее с размытыми требованиями.
• С выраженным Постоянством — надёжен, поддерживает команду, но может не сообщать о проблемах, чтобы не создавать напряжения.
• С выраженным Доминированием — берёт ответственность и двигает задачи, но может спорить резко и не учитывать мнение других.
• С выраженным Влиянием — легко общается с заказчиками и коллегами, но может терять интерес к рутинным задачам.

Знание стиля помогает тимлиду распределять задачи и предупреждать конфликты, а кандидату — понять, какая команда ему подходит.

Мотивация: что держит разработчика

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

Если для человека главное — новые знания, а его на год ставят на поддержку старой системы, вероятность ухода растёт, даже если всё остальное в порядке. Подробнее — в статье «Мотивация программистов: что работает, кроме денег».

Эмоциональный интеллект в разработке

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

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

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

Диагностика стилей мышления ACI показывает, на что человек обращает внимание в первую очередь: на людей, на практическую пользу или на системы и правила. Многие разработчики в первую очередь видят систему — структуру, логику, правила. Это помогает в архитектуре, но может означать, что человек меньше замечает, как решение скажется на пользователях или команде.

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

Как собрать оценку разработчика

Удобная схема для найма или решения о повышении:

Результаты сравнивают с профилем роли: какие качества нужны именно в этой команде и на этой позиции. Пример такого профиля — профиль должности программиста.

Отдельный случай — оценка уже работающих разработчиков, например при пересмотре грейдов или подготовке к роли тимлида. Здесь есть преимущество: поведение человека в команде уже видно. Полезно собрать оценку 360 от коллег, тимлида и смежников, сравнить её с результатами диагностики и обсудить с самим разработчиком. Такая оценка помогает увидеть не только технический рост, но и то, как человек делится знаниями, помогает новичкам, участвует в обсуждениях. Для решения о повышении эти качества часто важнее, чем очередная освоенная технология. А для самого разработчика это понятная картина: что у него уже получается и что нужно, чтобы перейти на следующий уровень.

Типичные ошибки при оценке разработчиков

• только технический этап — сильный программист, который не умеет работать в команде, может тормозить её сильнее, чем менее опытный, но командный разработчик;
• слишком тяжёлое тестовое — сильные кандидаты отказываются тратить на него выходные;
• одинаковые требования ко всем — разработчику в стартапе и в банке нужны разные качества;
• оценка «на глаз» на собеседовании — впечатление о человеке за час плохо предсказывает, как он будет работать;
• забывать о мотивации — найм человека, которому неинтересны ваши задачи, почти всегда заканчивается ранним уходом.

Частые вопросы

Как оценить разработчика при найме?

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

Что не покажет тестовое задание разработчика?

Тестовое выполняется в одиночку, без сроков и коллег. Оно почти ничего не говорит о том, как человек реагирует на нечёткие задачи, просит ли помощи, как принимает замечания на ревью, умеет ли объяснять решения и что будет его мотивировать через год.

Нужен ли разработчику эмоциональный интеллект?

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

Как понять, что будет удерживать разработчика в компании?

Модель 12 движущих сил показывает, что человеку важно, кроме денег: новые знания, практическая польза, влияние на решения, команда или понятные правила. Если задачи не совпадают с ведущими мотивами, вероятность ухода растёт, даже при хорошей зарплате.

Какие ошибки чаще всего допускают при оценке разработчиков?

Ограничиваются техническим этапом, дают слишком тяжёлые тестовые, применяют одинаковые требования ко всем командам, полагаются на впечатление от собеседования и не проверяют мотивацию. Итог — сильные технически люди, которые не приживаются в команде.