Как оценить Hard Skills разработчика, если вы не технарь

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

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

С чего начать, чтобы оценка Hard Skills была объективной

Любая объективная оценка начинается не с кандидата, а с роли. Пока не зафиксировано, зачем именно вам нужен разработчик и какой результат от него ожидается, обсуждать навыки бессмысленно. Формулировка «нужен backend-разработчик» не несёт в себе никакой практической ценности, она не объясняет ни масштаб ответственности, ни сложность задач, ни уровень автономности.

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

После этого становится возможным определить действительно обязательные навыки. Не те, которые «желательны», и не те, которые все пишут в вакансиях, а те, без которых задача в вашем бизнесе в принципе не будет решена. Обычно таких навыков немного, как правило, их число редко превышает 6-7 пунктов. Всё остальное относится к зоне развития и не должно влиять на решение о найме (стоит только заранее подумать о возможном взращивании этих навыков в сотруднике).

Наконец, до начала собеседований важно определить, кто именно принимает финальное решение и на основании каких критериев.

Как быстро понять уровень по резюме и короткому созвону

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

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

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

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

Хорошее резюме отличается конкретикой. В нём чётко описаны:

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

Слабая самопрезентация по-прежнему строится вокруг участия, а не результата. В таких резюме много общих слов и почти нет действий, например:

• «участвовал»;
• «работал с командой»;
• «мы сделали»;
• «нам пришлось»;
• «использовал современные технологии».

Именно такие формулировки сложнее всего интерпретировать на этапе первичного скрининга и именно они чаще всего требуют дополнительной проверки уже во время звонка.

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

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

Какие форматы проверки hard skills работают без технического директора

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

• Кейс

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

• Технический скрининг

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

• Тестирование

Тестовое задание рекомендуем давать только в том случае, если оно реально отражает актуальные задачи бизнеса и не требует существенных временных и ресурсных затрат. Если же оно требует достаточных усилий и временных ресурсов, будьте готовы оплатить эту работу.

Хороший результат в этом формате — не безупречный код, а внятная структура и осмысленные компромиссы.

• Кадровое агентство

Да, можно просто довериться в этом вопросе профессионалам, которые не только займутся поиском и подбором IT-специалиста, но и проведут комплексную оценку его hard skills.

В «Ритейл Персонал» мы готовы взять эту задачу на себя, мы приглашаем внешнего эксперта, чтобы вы были уверенны в том, что кандидат сможет выполнить вашу задачу на 100%. Помимо технических навыков мы оцениваем и soft skills. Они важны не меньше, ведь все хотят, что сотрудник вписался в коллектив и оставался в компании как можно дольше.

Оставить заявку на подбор! 

Как провести интервью, чтобы увидеть реальный уровень

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

1. Зафиксировать формат интервью в начале разговора

В начале интервью важно обозначить, что цель встречи — понять стиль мышления кандидата, а не проверить знание терминов или теории. Стоит сразу сказать, что допустимы уточняющие вопросы, паузы для размышлений и рассуждения вслух.

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

2. Использовать вопросы о прошлом опыте

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

Важно уточнять:

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

Такие вопросы позволяют увидеть, насколько кандидат понимает причины своих действий, а не просто воспроизводит результат.

3. Проверять глубину понимания через уточнения

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

4. Задавать вопросы о принятии решений и ответственности

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

5. Обсуждать критерии качества результата

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

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

6. Завершать интервью вопросами на рефлексию

В конце интервью полезно задать вопросы, которые требуют самооценки. Например, о слабых сторонах, особенностях, личностных характеристиках, интересах, зонах роста или ошибках, из которых кандидат сделал выводы. Кто-то теряется, кто-то шутит, а кто-то даёт осознанный, взрослый ответ.

Когда нужен внешний эксперт для оценки Hard Skills

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

• В каких ситуациях без эксперта не обойтись

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

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

Бывает и проще — внутри компании просто некому оценивать. Такое часто случается на этапе роста, при запуске нового продукта или тогда, когда нанимают первого специалиста в новой роли. Формально интервью проводят, вопросы задают, но глубокой проверки не происходит, и не из-за небрежности, а из-за отсутствия нужной экспертизы.

• Какие задачи решает внешний эксперт

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

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

• Как выбрать подходящего эксперта

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

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

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

Как не потерять сильного кандидата из-за процесса: чего стоит избегать

Сильные кандидаты уходят не только из-за денег. Гораздо чаще — из-за самого процесса найма, долгого, запутанного и неуважительного к их времени. Для опытных разработчиков это особенно чувствительно: альтернатив у них, как правило, хватает.

Одна из самых частых причин отказов — избыточное количество этапов без понятной логики. Интервью повторяются, вопросы звучат одни и те же, решения откладываются без объяснений. В какой-то момент у кандидата возникает ощущение хаоса. А дальше логика простая: если процесс найма выглядит так, какова вероятность, что и внутренняя работа устроена не лучше?

Еще одна распространённая ошибка — размытый диалог, из-за которого остаются размытые ожидания. Так бывает, когда на разных этапах или от разных людей озвучиваются разные требования или меняется фокус роли.

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

Чек-лист подготовки к интервью

1. Определена цель найма

• Понятно, какую бизнес-проблему должен решить новый сотрудник.
• Зафиксирован ожидаемый результат его работы (изменения в продукте / процессах).
• Обозначены примерные сроки достижения этого результата.

2. Описан контекст проекта

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

3. Сформирован список критически важных компетенций

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

4. Назначены правила принятия решения

• Понятно, кто и на каком этапе влияет на итоговый выбор.
• Определены критерии, по которым будет оцениваться кандидат.
• Решения не принимаются «по ощущениям», а опираются на факты.

5. Резюме проанализировано на конкретику

• В опыте кандидата описаны действия, а не абстрактное участие.
• Указан масштаб задач, уровень ответственности и последствия решений.
• Понятно, что именно делал кандидат лично.

6. Подготовлен сценарий вводного созвона

• Запланирован разбор одного реального проекта кандидата.
• Есть вопросы про ограничения, выбор решений и сложности.
• Цель созвона — проверить достоверность опыта, а не произвести впечатление.

7. Выбран формат проверки профессионального уровня

• Определено, будет ли разбор кейса, тестовое задание или экспертный скрининг.
• Формат проверки максимально близок к реальным рабочим задачам.
• Время кандидата уважается (а сложная работа — компенсируется).

8. Структура интервью продумана заранее

• В начале озвучена логика встречи и её формат.
• Основные вопросы опираются на прошлый практический опыт.
• Подготовлены уточняющие вопросы для проверки глубины понимания.

9. Проверяется мышление, а не знание терминов

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

10. Обсуждаются критерии качества работы

• Понятно, как кандидат определяет, что задача выполнена хорошо.
• Уточняется отношение к поддержке, тестированию и доработкам.
• Оценивается взаимодействие с командой и смежными ролями.

11. Запланирована финальная рефлексия

• Есть вопросы о слабых сторонах и точках роста.
• Кандидату дают возможность осмысленно оценить себя.
• Итоговое впечатление формируется по ходу диалога, а не по резюме.

12. Процесс найма прозрачен

• Количество этапов обосновано и понятно кандидату.
• Требования не меняются по ходу процесса.
• Кандидат получает обратную связь и понимает дальнейшие шаги.

Когда процесс выстроен системно, интервью перестаёт быть субъективным и хаотичным. Вы понимаете, за что именно делаете оффер и какие ожидания закладываете на старте.

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