Катастрофа в найме разработчиков-джунов в цифрах. Как выкрутились мы

Привет, это Лиза из Лиги А.! Последний год отовсюду слышны жалобные стоны эйчаров и тимлидов, которые нанимают джунов. Ходят байки, что на джуновскую вакансию за сутки прилетает тысяча откликов, среди которых единицы адекватных. Это не байки. За деталями добро пожаловать в статью — расскажу с цифрами и примерами, как мы выкрутились из сложной ситуации с наймом.

• У нас «сломался» стандартный процесс найма джунов: трудозатраты на найм одного человека доходили до 100 часов, эйчары и тимлиды выгорали.

• Перевернули процесс на 180 градусов.

• С помощью автоматического тестового задания отсортировали всех кандидатов по уровню технических навыков.

• Пошли по полученному списку сверху вниз.

• И наняли сильного джуна после всего 5 собеседований.
• Трудозатраты на найм снизились в 20 раз — со 100 до 5 часов.

• Достаточный для нас технический уровень был всего у 2.5% откликнувшихся.

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

Спойлер — никак не справляется.

Как работал стандартный процесс:

1. HR размещает вакансию.

2. Затем разбирает отклики и созванивается с кандидатами для проверки на общую адекватность.

3. После этого кандидаты выполняют тестовое задание.
   

4. Готовые тестовые вручную проверяет тимлид (благо они небольшие).

5. Тех, кто хорошо выполнил тестовые, приглашают на техническое собеседование.

Каждый этап — это фильтр. HR эффективно фильтровал по софт-скиллам, тимлиды эффективно оценивали технические навыки. Всё работало отлично, пару лет назад.

Но многое изменилось за последний год:

👉🏻 На размещённую вакансию с галочкой «без опыта» стало прилетать 600 откликов за несколько часов, а потом ещё несколько сотен в течение нескольких дней.

👉🏻 Резюме и тексты в откликах выглядят хорошо, а на первичных созвонах с HR кандидаты поют соловьём. «Спасибо» ИИ и карьерным модулям на онлайн-курсах.

👉🏻 На тимлида сваливаются сотни слабо выполненных тестовых, которые надо проверить вручную.

В итоге все перегружены — время дорогих спецов тратится десятками часов, деньги сгорают, а выхлоп околонулевой. На сотню откликов встречается 2-3 средних кандидата, а сильные встречаются ещё реже.

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

В какой-то момент поняли, что нам важно наличие у кандидата технических навыков. Но их уровень почему-то проверяем в самом конце процесса.

Мы перевернули процесс:

• стали оценивать технические навыки в самом начале,
• сделали оценку автоматической,
  
• подключали HR и дорогого тимлида в самом конце.
  

Но и это не всё.

Можно ведь не просто фильтровать кандидатов по уровню навыков, можно ещё и сортировать — от самых сильных к самым слабым. И сначала собеседовать самых сильных.

В общих чертах стало понятно, как всё должно работать. Но одно дело теоретизировать, а другое — проверять идеи на практике. Нам повезло, так как сошлись все звёзды:

1. Появилась необходимость нанять джуна-верстальщика. На горизонте возник проект с кучей подходящих задач. Тимлиды начали сопротивляться, HR тоже. По-старому нанимать было нельзя.

2. Лига сильно связана с HTML Academy.

3. HTML Academy недавно провела олимпиаду по фронтенду для Яндекса. Поэтому мы смогли переиспользовать сам интерфейс олимпиады и задания.

Мы взяли все наработки и выстроили воронку следующим образом:

1. Есть вакансия на HH.

2. При отклике на вакансию приходит ссылка с автоинвайтом в копию интерфейса олимпиады, заточенную под нас.

3. В интерфейсе студент выполняет серию заданий и загружает их в систему.

4. Задания оцениваются автоматически — мы видим статистику и рейтинг кандидатов.

5. Идём по рейтингу сверху вниз и собеседуем самых сильных. 5 приятных собеседований с отличными кандидатами и выбираем самого подходящего. И почему так нельзя было сразу?

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

Механизм оценки технических навыков — самая важная часть найма разработчиков. Кандидаты научились хакать его с помощью ИИ. Как быть?

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

С классическими тестовыми всё интереснее. Обычно в них реализуются задачи, максимально похожие на задачи заказчиков. Если кандидат хорошо выполняет тестовое с помощью ИИ и может так же хорошо выполнять задачи заказчика с помощью ИИ, то это хорошо или плохо? Мы в раздумьях, склоняемся к «хорошо, но с дополнительным контролем качества».

Мы искали джуна-верстальщика на зарплату 40 000 рублей. Нам нужно, чтобы он:

• умел делать адаптивную вёрстку по макету с учётом переполнения,
• был способен делать строгий пиксельпёрфект (когда требуется),
  

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

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

Итоговый перечень навыков, который автоматически оценивается после выполнения тестового:

• использование готовых сборок,
• использование готовых инструментов автоматического тестирования,
  
• адаптивная вёрстка по макету, без точного попадания в макет,
  
• адаптивная вёрстка по макету, с точным попаданием в макет,
  
• вёрстка с учётом переполнения,
  

• навыки взаимодействия с дом API (модификация дом и работа с событиями),

• базовые навыки работы со структурами данных,

• базовые навыки работы с датами,

• навыки написания сложных условных конструкций.

Задания по вёрстке

Задания по вёрстке устроены следующим образом:

• Кандидат получает несколько макетов компонентов в Figma и набор автотестов.

• Для каждого компонента отрисованы три версии (мобильная, планшетная и десктопная) и несколько состояний при переполнении.
• Автотесты проверяют вёрстку кандидата на пиксельпёрфект для адаптивных состояний и состояний переполнения.

• Есть два режима проверки — с более мягким пиксельпёрфектом, и с более строгим.

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

Задания по JS

Задания по JS устроены похожим образом:

• Кандидат получает готовую вёрстку, техническое задание и набор автотестов для нескольких компонентов.

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

• Как и в автотестах по вёрстке, используется метод регрессионного тестирования: серия взаимодействий с компонентом → скриншот полученного состояния → сравнение с эталоном.

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

Вот пример публичных протоколов, которыми сами кандидаты могут делиться по уникальным ссылкам. В этих протоколах первые 10 мест указываются диапазоном, а точное распределение видит только работодатель.

— Откликов на вакансию — 1580 (100%)

— Зарегистрировалось в системе скоринга навыков — 1013 (64%)

— Начали выполнять тестовые задания — 445 (26%)

— Заработали хотя бы один балл за выполнение тестовых — 93 (6%)

— Выполнили тестовое задание хорошо — 40 (2.5%)

👉🏻 Максимально возможное количество баллов — 42, кстати, его набрали 3 человека.

👉🏻 Хорошее тестовое — от 35 баллов включительно.

👉🏻 Мы провели собеседования с 5 лучшими кандидатами и выбрали из них того, кто нам оказался ближе по софт-скиллам.

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

Технический уровень кандидатов катастрофически низкий. Несколько сотен человек срезалось на этапе установки инструментов автоматизации. Где нужно было по инструкции установить ноду, а потом набрать команду npm i.

Больше 400 человек справилось с настройкой окружения, что уже неплохо. Но меньше четверти из них смогли выполнить хотя бы одно задание по вёрстке или по JS. А показали адекватный уровень скиллов только 40 человек.

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

Если вы тоже страдаете с наймом джунов и хотите попробовать сделать похожую автоматизацию, пишите на почту HTML Academy. Ребята помогут настроить процессы и сэкономить время дорогих тимлидов и HR.

А мы уже отмучались с наймом и теперь в нашей команде работают опытные специалисты, которые готовы подключаться к вашим проектам. Пишите нам на почту или мне в телеграм — @gingerliza.

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