Оценка ИТ-специалистов и команд: что добавить к проверке hard skills

Что показывает код-ревью и где его не хватает?

Hard skills проверяются быстро: тестовое задание, лайв-кодинг, разбор пет-проекта. Это необходимый фильтр, но моментальный срез. Код не покажет, как человек ведёт дискуссию о техническом долге, воспринимает критику продакта и адаптируется к новому фреймворку за две недели. HR-директору важно понимать: техническая часть отвечает на вопрос «умеет ли», но молчит о «как работает», «зачем приходит в офис» и «как поведёт себя при релизе в пятницу». Поэтому в батарею оценки добавляются инструменты, которые измеряют потенциал, поведенческий стиль и мотивы. Они не заменяют собеседование разработчика, а делают выбор предсказуемым и снижают риск ошибки найма. Без этого слой «совместимость с командой» остаётся на интуиции технического директора, а интуиция плохо масштабируется при найме десятка человек в квартал.

Как оценить мышление и обучаемость разработчика?

Технологии устаревают быстрее, чем заканчивается проект. Стек, актуальный сегодня, через год может смениться, поэтому важнее не список известных библиотек, а способность к переобучению. Инструмент ACI (оценка способностей и мышления) измеряет абстрактное мышление, скорость обработки информации и learning agility — именно то, что определяет, вытянет ли разработчик задачу, которой не учили в университете. Для архитектора критично видение системы, для аналитика — работа с неполными данными, для backend-разработчика в agile — скорость переключения между контекстами. ACI помогает отличить «знает Kotlin» от «освоит Kotlin за месяц, если понадобится». При удалённом найме это особенно ценно: вы не видите, как кандидат решает задачу в реальном времени, но получаете объективную метрику потенциала.

Как понять, подходит ли кандидат в конкретную ИТ-команду?

Команда разработки — не сборник индивидуальных звёзд, а система взаимодействия. Один и тот же разработчик в одной команде выглядит гениально, а в другой — блокирует процесс. DISC показывает поведенческий стиль: как человек принимает решения, реагирует на правила, ведёт переговоры с бизнесом. На практике высокий C-стиль часто встречается у аналитиков и бэкенд-разработчиков, которым важна точность и детализация. Стиль I помогает тимлидам и фронтенд-разработчикам договариваться с заказчиком и вовлекать команду. Комбинация D и S у продакт-менеджеров даёт драйв запуска и терпимость к рутине. DISC не говорит «плохой» или «хороший» — он показывает, где человек даст максимум, а где потребует поддержки. Это снижает конфликтность в agile-командах и ускоряет онбординг.

Почему уходят сильные разработчики и как это предотвратить?

В ИТ текучесть — хроническая проблема. Часто причина не в деньгах, а в том, что задачи разошлись с внутренними драйверами. Один разработчик горит от поиска новых знаний и исследований, другому важна практическая польза и видимый результат для клиента, третий стремится к автономии и влиянию на архитектуру. Если R&D-инженера посадить на потоковую коммерческую разработку без пространства для эксперимента, он начнёт искать выход. Инструмент движущих сил (DF) выявляет, что именно мотивирует человека: знания, гармония, помощь людям, система и порядок или власть и влияние. HR получает язык для разговора о развитии, а руководитель — точки удержания. Согласование мотивов с содержанием работы снижает выгорание и увеличивает срок жизни сотрудника в проекте.

Как собрать батарею оценки под разные ИТ-роли?

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

Эта сборка не отменяет технического собеседования. Она даёт HR и руководителю общий язык и снижает вероятность, что кандидат провалится из-за несоответствия команде, а не из-за навыка.

Какие ошибки найма в ИТ встречаются чаще всего?

Первая ошибка — оценка только по стеку. Компания нанимает «Senior Java» и удивляется, что человек не может объяснить бизнесу простыми словами, почему фича займёт две недели. Вторая — игнорирование культуры команды. «Звезда» с агрессивным стилем работы разрушает процессы в спокойной команде быстрее, чем поднимает производительность. Третья — отсутствие чёткого профиля роли. Оценка всегда относительно чего-то — эталона роли. Когда HR и технический директор заранее не договорились, какие софт-скиллы и мотивы важны, решение принимается на эмоциях после собеседования. Четвёртая ошибка — продвижение сильного разработчика в тимлиды без проверки управленческого потенциала. Результат: потерянный лидер и потерянный разработчик.

Зачем тимлиду и техдиректору оценка эмоционального интеллекта и 360°?

Технический руководитель без эмоционального интеллекта становится узким местом всей команды. EQ показывает, как человек управляет конфликтами в распределённых командах, выдерживает дедлайн-прессинг и переводит язык бизнеса в технические требования. Особенно это важно при росте из эксперта в управленцы: умение читать эмоции команды, снижать тревожность при неясных требованиях и давать обратную связь без демотивации решает больше, чем глубина знаний в конкретном фреймворке. Оценка 360° выявляет разрыв между «экспертом» и «управленцем»: как руководитель делегирует, строит процессы, договаривается о ресурсах и развивает людей. Если техдиректор остаётся главным кодером, стратегия страдает, а команда не получает обратной связи. Совместное применение EQ и 360° позволяет вырастить руководителя, который держит и продукт, и людей.

Как внедрить оценку в процесс подбора ИТ-специалистов?

Встраивайте инструменты на этапе, когда технический скрининг уже отсеял явных аутсайдеров. После проверки hard skills HR направляет кандидата на оценку DISC, DF и ACI — это занимает 20–30 минут онлайн. Результаты обсуждаются совместно с техническим руководителем: поведенческий стиль совместим с командой? Мотивы совпадают с содержанием задач? Мышление достаточно для уровня сложности проекта? Для позиций тимлида и выше добавляется блок EQ и при необходимости 360° для внутренних кандидатов. Главное правило: инструменты не дают «да/нет», а структурируют обсуждение. Они снижают влияние первого впечатления и помогают нанимать не «понравившегося кандидата», а наиболее подходящего под эталон роли. Внедрение не требует перестройки всего HR-процесса — достаточно добавить один-два блока между скринингом и оффером.