Описание вакансии не соответствует действительности

Приходилось ли вам узнавать об этом на интервью?

В нашем пилотном исследовании, которое предшествовало опросу Candidate Experience Research, был открытый вопрос «Что вас чаще всего НЕ устраивает в том, как проходят технические интервью?».

Один из ответов звучал так:

«Описание вакансии не соответствует позиции в команде и это выясняется на техническом собеседовании,…»

Мы в GUID решили, что будет интересно узнать, насколько распространены такие кейсы и спросили об этом кандидатов:

Описание вакансии не соответствует действительности

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

«Полное соответствие — недостижимый идеал, не требуется. О частичном несоответствии можно узнать только после начала работы, не на стадии собеседований.»

Было бы интересно разобраться, это баг или норма? Уважаемые IT-специалисты, как вы считаете? И хотели бы вы, чтоб вас всегда собеседовали в соответствии с теми требованиями и задачами, которые вы видели в описании вакансии?

Я могу судить об этом только с точки зрения рекрутинг-процессов. И мне кажется, что задача рекрутера свести к минимуму такие случаи. Осмелюсь предположить, что наряду с какими-то сугубо проектными причинами, нерелевантные описания вакансий – следствие двух бичей украинского IT-рекрутинга:

  • Отсутствие понимания, что техническая грамотность — базовая компетенция IT-рекрутера. Подробно об этом я писала здесь. Добавлю только, что в процессе общения с десятками HR и рекрутеров и во время подготовки рекрутинг специалистов, я много раз наблюдала, как именно это работает. Если отсутствует элементарный технический базис, если знания о проекте, – это заученный (в лучшем случае) список терминов, невозможно обсуждать с технарями требования к кандидатам. И, как следствие, распространенный паттерн принятия требований по вакансии — молча взять их и уйти «в поле».
  • Отсутствие осознания, что рекрутер ответственен за ВЕСЬ процесс найма кандидатов. И, соответственно, может и должен следить за качеством всех этапов. Качеством как со стороны процессинга кандидатов, так и со стороны достижения конечного результата для компании.

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

Что конкретно необходимо делать/не делать рекрутеру, чтобы свести к минимуму разбег между описанием вакансии и нуждами команды?

1. Если рекрутер не уверен, что он на 100% знает:

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

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

2. Если требования таки описывал рекрутер (или любой другой человек, не являющийся участником команды, в которой открыта вакансия), он обязан утвердить описание вакансии с командой. Желательно и с рядовым членом команды (который погружен в проект на 100%), и с лидом или даже СТО (который держит в голове перспективы развития проекта, а заодно и общую картину по всем проектам компании).

3. Если рекрутер берет (рекрутеру дают) «старое» описание вакансии, он обязан настоять на перепроверке требований к кандидатам и перечне потенциальных задач. Под «старым» описанием я понимаю вакансии, которые перечитывались командой проекта более чем 2 недели назад. Для некоторых проектов, тексты вакансий месячной, квартальной и полугодичной давности не просто старые, а очень древние. Идти с такими на поиск кандидатов — смертельный грех.

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

5. Получая таки «свеженькую» вакансию от технарей, рекрутеру необходимо в ней разобраться и попытаться оценить на предмет соответствия требований и реального технического стека (прошлого, текущего и планируемого). Технические команды не являются профессиональными составителями вакансий, так что по разным субъективным причинам в описании могут закрасться некоторые «неточности». Задача рекрутера, по каждому из требований спросить команду или будущего интервьюера:

  • Это обязательное требование?
  • Какой именно опыт необходим/какого опыта достаточно по этому требованию?
  • Мы сейчас это используем? Если да — планируем ли использовать и дальше? Если нет — почему это в требованиях.

6. Рекрутер должен однозначно понимать, какие требования являются критичными. Обычно, это 2–3 пункта, без которых команда даже не будет собеседовать кандидатов. Их выделение поможет рекрутеру сделать правильные акценты в поиске и коммуникации с кандидатами.

7. Если все вышеперечисленное соблюдено, а вакансия не закрывается (кандидаты не идут, или идут, но собеседование не проходят), я рекомендую взять:

  • Описание вакансии и фидбеки кандидатов но нему
  • Собеседующего и/или лида из команды проекта и их фидбеки по прособеседованным кандидатам
  • Авторитетного лида из другой команды или СТО

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

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

Юлия Венгер
Founder и Managing Partner в GUID