7 ошибок компаний при найме разработчиков

Найм разработчиков остаётся одной из самых сложных задач для компаний.

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

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

Очень многие вакансии выглядят примерно так:

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

Перед началом поиска полезно разделить требования на три категории:

Часто оказывается, что действительно критичными являются лишь 2–3 технологии. Остальное можно освоить в процессе работы. Также помогает ответить на простой вопрос:

какие задачи должен решать разработчик в первые 3–6 месяцев?

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

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

нужен backend-разработчик.

Но на интервью выясняется, что задачи включают:

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

Перед началом найма полезно сформулировать:

Иногда помогает короткая внутренняя сессия с командой или техническим лидером, где обсуждаются:

После этого описание вакансии становится гораздо более точным.

Часто процесс выглядит так:

Иногда это растягивается на несколько недель.

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

Во многих случаях процесс можно сократить до 2–3 этапов:

Также помогает заранее определить:

Чёткий и быстрый процесс часто становится конкурентным преимуществом компании.

Резюме разработчика может выглядеть очень убедительно:

Но резюме не всегда отражает реальную глубину опыта.

Например:

Поэтому оценка кандидатов только по CV часто приводит к ложным ожиданиям.

Полезно комбинировать несколько способов оценки:

Особенно эффективным бывает разбор конкретных ситуаций из опыта кандидата:

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

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

В результате вакансия выглядит так:

требования уровня Senior, зарплата уровня Middle.

Такие позиции могут оставаться открытыми очень долго.

Перед запуском поиска полезно изучить текущий рынок:

Иногда компании пересматривают не только зарплату, но и формат работы:

Это может существенно расширить пул кандидатов.

Многие вакансии написаны очень общими словами:

Но кандидаты хотят понимать конкретику:

Чем понятнее вакансия, тем выше шанс получить релевантные отклики.

Хорошее описание вакансии обычно включает:

Это помогает кандидатам быстрее понять, подходит ли им эта роль.

Иногда кандидат успешно проходит несколько этапов интервью, но решение по офферу откладывается.

Причины могут быть разными:

Но на рынке IT скорость играет большую роль. Если решение принимается слишком долго, кандидат может выбрать другую компанию.

Чтобы не терять сильных кандидатов, полезно:

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

Большинство проблем с наймом разработчиков связано не с отсутствием кандидатов, а с процессом найма внутри компании.

Чаще всего ситуацию улучшают несколько простых вещей:

Когда эти элементы выстроены, поиск разработчиков становится заметно быстрее.