Многоликость IT-рекрутера: о чем эта профессия и как с этим живется

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

Делимся нашим большим ИМХО и ощущением профессии, основанными на опыте и ценностях GUID, трендах рекрутинга в принципе и не претендуем на истину в последней инстанции:)

В статье вы найдете ответы на следующие вопросы:

• Какие роли сочетает в себе рекрутер?
• Как сорсинг связан с хакатонами?
• Зачем тру-сорсерам дедукция и Python?
• Как общаются с кандидатами рекрутеры, которые не просто рассылают массовый копипаст вакансии? (спойлер: да, такое бывает)
• Как проходят собеседования с рекрутерами?
• Как рекрутер балансирует между всеми сторонами-участниками процесса?
• Почему рекрутинг - это боль?
• И почему рекрутинг - это добро?❤.

Надеемся, эта статья поможет разобраться в вопросе в целом, и составить представление о каждом аспекте работы в отдельности.
Приятного прочтения:)

Вместо предисловия: техническая экспертиза и знание рынка

IT-рекрутер сочетает в себе множество ролей. Мы учимся у разработчиков, Data-аналитиков, менеджеров, Scrum-мастеров, психологов, продавцов, маркетологов, детективов, коучей и всех, у кого есть что перенять и внедрить в практику.

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

На этапе захода вакансии, рекрутер должен быть способен:

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

Техническая экспертиза помогает рекрутеру вдумчиво оценивать релевантность кандидата, а не пользоваться описанием вакансии как списком покупок в магазине. Прежде всего, описания вакансий от инженеров часто включают в себя множество “хотелок”, не обусловленных реальными потребностями проекта. Заявки в духе “О, а пусть он еще 2–3 языка знает, кроме основного, и так, чтобы еще с Big Data работал, а еще Machine Learning хочу — круто же!” при минимальных бюджетах и древних проектах с бардаком в коде (основано на реальных событиях) делают процесс закрытия невозможным, если рекрутер вовремя не вычислит неадекват в требованиях. Или вот еще пример — на наших курсах по IT-рекрутингу есть занятие, посвященное снятию вакансии у заказчика. Мы приглашаем на них СЕО/СТО/Лидов из IT компаний, чтобы студенты могли пройти через реальный рабочий процесс. И на одном таком занятии Лид вообще не узнал вакансию своей компании по описанию с их же работного сайта, настолько много не используемых в реальности технологий там было указано. Потому важно уметь читать вакансии и соотносить требуемое с реальностью. И, конечно, общий технический язык общения с кандидатами позволит куда глубже и подробнее обсудить их опыт на собеседовании.

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

У тру-рекрутера есть друзья в большинстве компаний. Он всегда знает:

• где сократили проект;
• где команда недовольна менеджментом;
• где много овертаймов и маленькие бюджеты;
• кто какие направления планирует развивать;
• кого в скором будущем будут нанимать конкуренты.
• Новостные порталы, форумы IT-специалистов, информация от кандидатов, других рекрутеров и просто обширный нетворк помогают держать руку на пульсе индустрии.

Сорсинг, хакатоны и дедукция

Пассивность IT-рынка привела к развитию сорсинга как ключевого навыка, и даже отдельной отрасли со своим комьюнити и экосистемой, т.к. здесь не кандидаты ищут работу, а работа ищет кандидатов. Существуют даже специальные хакатоны для сорсеров, на которых за 2–5 минут участники должны найти ответы на вопросы в духе: «Этот француз активно контрибьютил в развитие такого-то Open source фреймворка, его жена 49 дней назад лайкнула мой пост, напишите, какую татуировку набила его бабушка». Такие задачи здорово развивают навыки сорсинга, т.к. они требуют умения грамотно составить запрос с учетом того, какую информацию он должен и, что не менее важно, НЕ должен отобразить. Нужно знать, как устроены ресурсы вроде Stackoverflow/Github/и тд., чтобы понимать, как оценивать профили пользователей и какими методами можно достать контактную информацию.

Приходится прибегать к разным хитростям поиска — например, исключать из запроса ключевую технологию типа Java и составлять запрос из всех Java-related технологий/библиотек/фреймворков, которые отобразят профили ребят с низкой выдачей. В общем, придумать все возможные аналоги ключевого запроса в духе «темный лорд», «Тот-кого-нельзя-называть» вместо Волан-де-Морта. И подобных методов — уйма. Особо продвинутые ребята вообще учат Python и используют его для построения запросов, и даже пишут сами себе тулзы, облегчающие процесс поиска.

Работа интересная, требует фантазии и дедукции. И главный вопрос, с которым живут тру-сорсеры: «Что еще можно спросить у Гугла, чтобы увидеть тех, кто не попал в выдачу?». Ведь миссия сорсера — найти все, что скрыто;)

Установление контакта: стучим в закрытые двери

Рекрутерам приходится работать с пассивным рынком, а значит стучать во все закрытые двери, а значит оказывать IT-специалистам внимания больше, чем им нужно. Весь этот замкнутый круг приводит к тому, что мессенджеры ребят завалены одинаковыми сообщениями, большая часть которых вообще “мимо кассы”. Масштаб этой беды мы осознали тогда, когда сами начали получать предложения рассмотреть инженерные вакансии (например, Python разработчика). Это финиш, конечно.

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

Эпистолярный пинг-понг — общение с кандидатами

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

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

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

Главное, что нужно понять — с фразы «Нет, спасибо, мне не интересно» работа рекрутера только начинается.

Собеседование

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

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

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

Каста передастов VS Организатор/медиатор/фасилитатор

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

Задача рекрутера:

• сделать так, чтобы все стороны явились и были в добром здравии и хорошем настроении;
• узнать впечатления обеих сторон по итогу общения;
• транслировать фидбеки;
• сглаживать углы;
• улучшать candidate’s experience с каждым новым опытом собеседования.

Эквилибристика в переговорах

Здесь просто приведу вам зарисовку из типичного процесса для полной иллюстрации градуса накаленности работы:)

Итак, пробиваешь ты сотни стен, слышишь долгожданное «Ну ок» от кандидата после долгих и старательных ритуальных танцев с бубном вокруг него, несешь на всех крыльях его резюме hiring менеджерам, и слышишь после фидбек: «Чёт подозрительно, а чего он хочет сменить работу? А он точно достаточно мотивирован?»

Затем ты объясняешь техническим собеседующим, что кандидат не рвётся ничего менять, и его откровенно “схантили”. И в целом из 10–15 человек по стране, которые ему подошли бы, многие счастливы и не хотят ничего менять, ничего не знали о компании до знакомства с вами, а согласие кандидата на собеседование стоило многих усилий. Если повезет, назначаешь с надцатой попытки собеседование, после которого упорно и требовательно собираешь обратную связь.

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

Затем личные вопросы как-то решаются (или нет) и начинаются финансовые торги. И тут внезапно всплывают еще и контр-офферы. И большое счастье, если кандидат тебе сказал об этом, тогда еще есть шанс что-то предпринять. И, когда (точнее «если») сквозь все тернии таки видны уже звезды, компания и кандидат начинают долгожданное сотрудничество, наступает рекрутерское счастье. Хотя, если быть точнее, то в конце испытательного срока, когда компания и кандидат уже точно решили продолжать работать вместе.

Выдохнули?:) Вот так и живем. Подобные переговоры — это те еще американские горки. И требуют сильных медиаторских способностей, умения быстро реагировать на обстоятельства, гибкости, терпения и спокойствия.

Кода: о боли и радости IT-рекрутера

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

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

Но все окупается, когда собранная твоими руками/ушами/нервами команда начинает работу. И не только команда, а и каждый отдельно взятый человек. И воцаряется, пусть и на пару минут и в твоем воображении, благодать. ПМ выдергивает седой волос и чуть спокойнее реагирует на дедлайны. Лид наконец-то снимает с себя кусок работы, теперь не настолько в мыле и может пораньше уйти домой к семье. Клиенты довольны. Менеджмент счастлив. Бизнес движется к своим целям.

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

Уровни технической подготовки IT-рекрутеров

Хочется рассказать о том, что именно мы вкладываем в термины Speaking Developish и “техническая грамотность” IT-рекрутеров.

Мы давали наше определение Speaking Developish здесь:

Speaking Developish — … способность рекрутера читать резюме и вакансии, понимать разработчика и говорить с ним на одном языке. По нашему глубокому убеждению, для этого необходима как техническая подкованность, так и понимание специфики IT-бизнеса и IT-индустрии (мировых и региональных рынков).

То есть этим термином мы обозначили широкий спектр “IT-знаний”, относящийся к разным областям IT-индустрии. Мы попытались обобщить наши наблюдения и опыт технической подготовки IT-рекрутеров и обозначили этапы изучения Developish в виде пирамиды:

1 уровень — Elementary: базовая IT-лексика, которая естественным образом осваивается новичками, попадающими в эту среду (как правило, за первые месяцы работы). А именно:

большое количество англицизмов (“почекать”, “засинкапиться”, “таска”, “дедлайн”, “реджектнуть”, “заапрувить” и т.п.);

профессиональная лексика (“сивишка”, “ревью/скрининг” резюме, “лонг-листы”, “оффер” и т.п.);

термины и понятия, связанные с функционированием IT-бизнеса и IT-индустрии (типы компаний, технические и нетехнические роли и должности, уровни должностей и т.п.);

В этот период рекрутер встречается с первыми “порциями” незнакомых технических терминов в резюме и описаниях вакансий. Однако, так как основной фокус внимания направлен на базовую IT-лексику и адаптацию, освоение технической лексики ограничивается запоминанием новых слов. При этом, произношение технических терминов может даваться сложно, а их написание и вовсе непосильно:

Найдено на просторах Интернета

2 уровень — Pre-Intermediate. На этом уровне добавляется понимание того, как именно создаются программные продукты. С этой стороны IT-бизнеса сходит дымовая завеса, рекрутер потихоньку проясняет для себя, из каких этапов состоит процесс разработки ПО и какова роль каждого “винтика” в этом процессе. Формируется отдельный пласт знаний, характеризующих IT-проекты (предметная область, методология разработки, стадия проекта, понятие технического стека, менеджмент, структура команды, специфика разработки продукта и аутсорс проектов и т.д.).

Рекрутер работает с различными вакансиями и сталкивается с бОльшим количеством технических терминов. Ключевые термины и их связки запоминаются и рекрутер, как может, классифицирует их: определяет к какому направлению разработки термин относится и держит в голове простенькие схемы взаимосвязи технологий из одной области. Рекрутер знает, что web и mobile — это разные области разработки. Что если есть web, то должен быть front end и back end. От рекрутера на этом этапе можно услышать: “У нас классический фронт — CSS, HTML, JavaScript” и он уверенно оперирует терминами типа библиотека, фреймворк, CMS, движок. Правда, не всегда действительно понимая, чем они отличаются. И, как правило, вообще не задаваясь вопросом, как работают front end и back end, что именно скрывается за этими абстракциями (большинство рекрутеров на этом этапе неспособны объяснить, например, что такое http сервер, REST и API).

Также из-за поверхностного подхода на этом этапе отсутствует “синонимическая база” технических терминов — рекрутер не видит более глубокой взаимосвязи терминов чем “язык программирования-фреймворк”. Он может упорно искать в резюме Unix админа свидетельства того, что он сталкивался с Linux, спрашивать про наличие web-опыта у кандидата с глубокой экспертизой в ASP.NET и расстроится, что у кандидата в резюме есть какое-то LAMP, а опыта с РНР и MySQL нет.

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

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

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

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

По нашему убеждению рекрутеры Middle-Senior уровня способны освоить большой пласт технической лексики на уровне понимания “Для чего это нужно” и “С какими технологиями связано”. И этого вполне достаточно для достижения главной цели speaking developish: единообразно толковать с технарями (кандидатами, заказчиками, тим лидами, проектными командами) и понимать технические понятия, термины и их взаимосвязи. Именно единообразно, единым образом, в рамках одной системы координат. Это позволяет рекрутерам качественно коммуницировать с кандидатами и внутренними заказчиками, а также поддерживать рекрутинг-процессы на высоком уровне.

Итак, на этом этапе “расколдовываются” все базовые понятия и принципы разработки ПО, универсальные для программирования в целом и конкретных его областей (web, mobile, desktop, embedded). Задача рекрутера пересобрать свою картину процесса разработки ПО исходя из нового понимания и основываясь на новых, более фундаментальных принципах классификации технических терминов. Грубо говоря, раньше у рекрутера было 2 плоскости понимания: ИМЯ термина и ИМЯ области разработки, к которой он относится. Соответственно, и перспектива была двумерная.

Например, термины nginx и Tomcat раньше лежали у рекрутера на разных полках, потому что всегда идут “в комплекте” с разными языками программирования. А Mongo и PostgreSQL, наоборот, на одной — и то, и то база данных.

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

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

Хотя со стороны, при мимолетном знакомстве, разработчик может и не отличить рекрутеров 2 и 3 уровней (ведь и на втором уровне рекрутер может уверенно декламировать технические детали проекта).

Стоит ли напрягаться? Стоит. Для самого рекрутера, это пройденный рубеж, от Казаться к Быть. От “делать вид”, что ты понимаешь, к “Понимать” (пусть и упрощенно). И, помимо уже упомянутых качественных коммуникаций и процессов, рекрутер приобретает уверенность в себе и иммунитет от синдрома самозванца.

4 уровень — Upper-Intermediate, уровень технической эрудированности. Это когда на четкую, в каком-то смысле фундаментальную базу третьего уровня вы накладываете:

языковое и инструментальное многообразие (добавляя знания о новых платформах и языках программирования с сопутствующими технологиями, а также различных инструментальных средствах разработки и DevOps практиках);

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

знание хайповых технологий и трендов разработки — AI, ML, BigData, Microservices, и т.п.

понимание, что такое технически сложный проект, для чего нужны алгоритмы, в каких областях необходим математический бэкграунд, а в каких не обойтись без PhD по Computer Vision; 

На этом этапе возможно нормальное HR-собеседование с разработчиком, в русле естественной беседы, расспросов о проектах, опыте, предпочтениях, оценках кандидатом его прошлых задач и планов на будущее. На этом этапе можно говорить об “одном языке”. На этом уровне подготовки кандидату с вами не скучно, он не относится к собеседованию как к потере времени. И видит вашу ценность: вы способны понять, почему тот проект был скучен и тормозил развитие, что действительно увлекает кандидата, какими проектами он хотел бы заниматься и в каком окружении развиваться. И, в идеале, вы сразу сможете “развернуть” ваш проект для кандидата в его перспективе — здесь вот такого не будет, а вот тут зато — идеально, а в будущем еще планируют то-то, …

Собеседование становится предметным диалогом, в котором рекрутер не пытается отделить опыт кандидата от его личности и прособеседовать человека “по софт скиллам”, старательно обходя стороной его опыт.

И, наконец, заключительный, 5 уровень нашей классификации — Advanced. Единственным логичным венцом владения Developish нам кажется практика кодинга. Это еще более глубокий уровень погружения, который откроет для вас программирование в новом свете. А заодно добавит еще одну плоскость понимания — понимания того, КАК это работает. Это, пожалуй, лучшее закрепление теоретических знаний о программировании. Ведь, если вы не работаете ежедневно со всеми теми понятиями и конструкциями, которые выстраивались в процессе вашей технической прокачки, они упрощаются, “утончаются”, теряют системность и примитивизируются. Как и с любым другим языком. Для его поддержки необходима постоянная практика. Или в прямом смысле — кодить, или в переносном — поддерживать знания в актуальном состоянии, не переставая наращивать свою техническую “мощь”.

Итак, когда мы говорим о минимальном техническом базисе, мы подразумеваем, что человек овладел знаниями первых двух уровней нашей пирамиды. Считаем ли мы, что этих знаний достаточно для IT-рекрутера, стремящегося к профессионализму и имеющего тайтл от Middle и выше? Нет, этого недостаточно. Мы считаем, что можно говорить о технической грамотности и подкованности рекрутера, если его понимание технической лексики не ниже третьего уровня (Intermediate). Если к такому пониманию будет стремиться каждый, качество рекрутинга в Украине может улучшиться уже в этом столетии. Ну ладно, в этом десятилетии :).

Кстати, мы подготовили тест на 10 коротких вопросов, соответствующий Intermediate уровню в нашей интерпретации. Для желающих проверить свои знания — ссылка на тест здесь.

Верим в вас ❤

Тренинги по технологиям для нетехнических специалистов Speaking Developish

Друзья!
С огромной радостью делимся с вами видеороликом первого тренинга по технологиям для нетехнических специалистов Speaking Developish: JavaScript Ecosystem.

Давайте вспомним, как это было.
Признаемся честно, мы пересмотрели его уже миллион раз и не можем перестать улыбаться.
Вспоминая, сколько сил и труда было вложено и как долго мы готовились к реализации нового проекта, хотим поблагодарить всех, кто был к этому причастен. ❤️
А для тех, у кого не получилось прийти - не расстраивайтесь, видеозапись лекции Speaking Developish на тему JavaScript Ecosystem уже доступна к покупке.

Напомним, что в рамках тренинга спикер раскрыл такие темы:

● Brief web history

● How does browser work

● Preprocessors(SASS, LESS, JADE..)

● JS-based languages(TypeScript, CoffeeScript, ClojureScript)

● JQuery

● ES2015

● SPA - React/Angular/Vue

● BE JS (Node.js)

● JS in Mobile development (React Native, Electron, Cordova..)

● JS Developers

● Gotchas in hiring JS developer.

Чтобы приобрести запись, обращайтесь - pr@guid.com.ua

До встречи на следующих Speaking Developish. ❤️

Speaking Developish. О технической грамотности IT-рекрутеров

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

В IT-рекрутинг приходят разные люди и по разным причинам. Моя причина  –  IT... информационные технологии...ну понимаете, вся вот эта история, про то, что компьютеры преобразуют электрический ток в документы, игры, видео,  –  все то, что мы можем увидеть на своих экранах. И могут передавать этот контент на расстоянии. По проводам или без них. Вы когда-то задумывались каким образом это происходит? Для меня это было и остается магией, в которой очень хочется разобраться. А началось это 15 лет назад. Когда под звуки модема, «дозванивающегося до Интернета», я завороженно слушала рассказы мужа, о том, как все устроено: клиент, сервер, http, базы данных, компиляция, байт-код и куча всего другого от Торвальдса и GNU до квантовых компьютеров, AI, и 3 законов робототехники :).

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

И сейчас, 7 лет спустя, я могу сказать, что мой живой интерес к IT-индустрии положительно повлиял не только на мой личный рекрутинг-опыт, но и определил фокус моей компании на техническую подкованность рекрутеров. Я убеждена в том, что это одна из ключевых вещей, определяющих профессионализм и экспертность IT-рекрутера (для иллюстрации, в нашей программе подготовки рекрутеров половина занятий посвящены понимаю IT-экосистемы и технологиям разработки ПО). И цель этого лонгрида еще раз заявить: владение IT-лексикой и понимание того, что стоит за конкретными понятиями и терминами  –  мастхэв для технического рекрутера. А заодно и показать, к чему приводит игнорирование этой компетенции. Буду опираться на опыт моей компании, добавляя цитаты IT-специалистов из недавно проведенного нами опроса*.

1. Ежедневные коммуникации
Итак, почему же это мастхев? Мы любим приводить следующую аналогию: ни у кого не вызывает сомнения, что переезжая жить в другую страну, первое, что необходимо сделать  –  выучить язык этой страны. Так же и в IT-рекрутинге  – овладевая технической базой и пониманием специфики IT-бизнеса, рекрутер овладевает языком индустрии (со всеми смыслами и содержаниями, которые стоят за отдельными словами). И только после этого рекрутер в принципе способен адекватно представлять компанию и проекты на рынке, понимать, о чем говорит кандидат на собеседовании, и пытаться увидеть за совокупностью фактов об опыте личность кандидата.

Мне до сих пор кажется дикостью, когда HR, путающийся в показаниях по поводу того, что такое front end и back end, делает категоричные заключения о каких-то предпочтениях технического кандидата и паттернах его поведения. Я допускаю, что в теории это возможно. Но когда я представляю, как может строиться диалог такого специалиста и кандидата, у меня волосы встают дыбом. Со стороны кандидата это скорее выглядит как допрос или беседа с пациентом (который пытается убедить доктора, что он не сумасшедший).

Или вот еще. До сих пор не возьму в толк, как можно проявлять «искренний интерес к человеку», когда ты из его рассказа или резюме понимаешь 20% слов? Вы просто на разных полюсах, в разных вселенных. Это как встретить одноклассника через 20 лет, в поезде, узнать, что он геодезист и еще 20 минут мучительно придумывать, о чем его спрашивать (спрыгивать с поезда раньше своей остановки точно не альтернатива).

Так что мне кажется, если ты не speak Developish, то разговоры о том, что у тебя к каждому любовь и индивидуальный подход  – лукавство. Уважаешь и восхищаешься людьми в IT, учи их язык.

2. Описание вакансии 
Если рекрутер не силен в speaking Developish, на стадии утверждения/составления вакансии (в частности, технических требований) он может допускать ошибки, влекущие за собой проблемы с нецелевым поиском и, соответственно, со сроками закрытия вакансий.

О каких ошибках идет речь?

— Рекрутер соглашается сам составить вакансию после слов типа: «Ну, нам Java Dev нужен, типа со спрингом. Остальное погугли, возьми какое-то стандартное описание».
— Рекрутер не утверждает у технарей вакансии своего же авторства.
— Рекрутер не настаивает на перепроверке требований к кандидатам после постановки задачи на поиск в духе: «нам нужен еще один фронт, описание вакансии можно взять старое, которое мы писали накануне позапрошлого новогоднего корпоратива».
— Получая таки «свеженькую» вакансию от технарей, рекрутер не пытается в ней разобраться и оценить на предмет соответствия требований и реального технического стека (прошлого, текущего и планируемого).

3. Сорсинг
Это не первая проблема, с которой может столкнуться рекрутер, но, пожалуй, самая очевидная  –  неспособность понять и интерпретировать резюме/профиль кандидата и, соответственно, верно оценить степень его «подходящести» под вакансию. К чему это приводит? В лучшем случае, к свайпу релевантного профиля в LinkedIn. В худшем  –  самовольно зареджектить присланное резюме, потому что «опыт не тот».

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

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

4. Работа с возражениями и продажа вакансии
Все знают, что у нас «рынок перегрет», что это «рынок кандидата» и вакансии закрываются тяжело. Что это значит для рекрутера? Что он не может надеяться только на отклики с работных сайтов, а большую часть своего времени занимается активным поиском. То есть ищет кандидатов и пытается их «переманить». В теории звучит логично. Но на практике есть нестыковочка.

Если понаблюдать за рекрутерами, всегда можно заметить прямую зависимость между их «запалом» идти «в поле» и тем количеством и качеством информации о проекте, которая у них есть. Наивно ожидать, что рекрутеры будут чувствовать себя свободно в коммуникации с кандидатами и строить какие-то «стратегии общения», если у них вообще нет никакой информации о проекте. Или этой информации просто мало. Прямо скажем, непонимание куда ты ищешь и почему твое предложение должно быть интересно кандидату, обрекает всю затею с переманиванием на провал. А это и есть тот самый speaking Developish: быть глубоко в теме своего продукта, в теме рынка и обладать минимальным техническим кругозором, чтобы «читать» опыт кандидатов.

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

5. Собеседования
Я, пожалуй, не буду слишком подробно останавливаться на собеседованиях рекрутеров с техническими специалистами. Очевидно, что без обсуждаемого базиса это разговор глухого со слепым. Да и цифры** говорят о том, что кандидатам далеко не всегда удается услышать от рекрутеров о потенциальных задачах и технических аспектах вакансии. Хотя и полной информацией о проекте и компании кандидатов также не балуют.

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

Каким в вашем понимании должен быть профессиональный НЕ технический собеседующий (рекрутер/HR)? В чем его ценность?
Он должен разбираться в предметной области кандидата (правильно произносить технологии, знать назначение того или иного элемента, которое требуется в вакансии), знать о проекте, базово разбираться в технической части, очень хорошо знать саму суть проекта (лучше должен знать только sales и owner)
Candidate Experience Research 2018*

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

Как сказала наша СОО Настя Геллер при обсуждении этого слайда на рекрутерской конфе: «Какой-то одноразовый рекрутинг получается». Не могу не согласиться. Проблем везде понемногу и вроде не критичные, жить можно...вот и живем. А в итоге, ценность и роль рекрутера в процессе найма нивелируется, а образ малополезного звена прочно укореняется в сознании. И мешает это не только выполнять ежедневные задачи сотням других рекрутеров. Это мешает расти и развиваться хорошим командам и компаниям.

Что делать?
Начать со своего окружения.

Слушать, записывать, мотать на ус и систематизировать всю техническую и около-техническую информацию, которую вы слышите.
Доставать своих технарей вопросами, не зная меры. Хороший рекрутер  –  это вообще очень неудобный человек для собеседующих технарей. Он нудный, дотошный и как банный лист  –  не отцепится, пока не добьется своего. Зато для кандидата этот же рекрутер –  верх компетентности. И компания этого рекрутера в глазах кандидата, значит, соответствующая.

Не стесняйтесь просить ваших кандидатов объяснить вам какие-то вещи. Большая часть из них сделает это с удовольствием (проверено тысячу раз). В идеале (эффективнее)  –  имея какую-то базу, задавать вопросы по конкретным деталям и тонкостям.

Про гуглеж и системное обучение вообще молчу.

Какие минимальные знания необходимы?

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

— Какие операционные системы (Linux/Windows/MacOS/...);
— Какие языки программирования (Java, JavaScript, С#, Python, C++,...);
— Какие фреймворки и библиотеки (Spring MVC, AngularJS, Django, Zend, ...Hibernate, jQuery, React.JS, STL, ...);
— Какие базы данных (MySQL, PostgreSQL, MongoDB, Cassandra, ...);

А в целом, информация о вакансии, с которой рекрутер может выходить к кандидату, должна охватывать следующие пункты:

— Подробная информация о проекте (суть проекта, предметная область, «возраст», масштаб, стадия разработки, планы по развитию и т.п.)
— Тип приложения (web, mobile, desktop, embedded) и технический стек проекта
— Команда проекта
— Методология разработки и процессы коммуникации (с командой и клиентом)
— Задачи специалиста (как минимум, в терминах «саппорт/разработка новой функциональности»).

Обычно, не составляет труда получить эту информацию у заказчика (внутреннего или внешнего). Главное  – приложить усилия, чтобы понять все новые термины и попытаться нанести их на свою «карту IT-мира». Карта эта, скорее всего, будет упрощенная, не детализированная, местами далекая от реальности (а если сравнивать с «картами» технических специалистов –  и вовсе карта другой реальности). Но и такой ее вариант лучше, чем полное отсутствие каких-либо ориентиров.

И под конец хочу предостеречь вас от еще одной ошибки.

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

О НЕтехнических собеседованиях
Был случай когда «HR» задавала мне три-четыре вопроса типа «оцените от 1 до 10 ваши знания такого то фреймворка» и назвала это «конкурсом», который я «не прошел».
Candidate Experience Research 2018*

И в заключение: 

О НЕтехнических собеседованиях
Я часто сталкиваюсь с тем, что рекрутер описывает проект/оценивает мою подготовленность к нему/то, насколько мы с компанией подходим друг другу с большим позитивом и воодушевлением.Однако стадия технического собеседования и тестового задания как-будто открывает глаза на совсем другую реальность.
Хотелось бы пожелать рекрутерам не слишком увлекаться оценкой вещей, выходящих за рамки их компетенции. Ведь знакомство непосредственно с проектом расставляет все на свои места.
Candidate Experience Research 2018*

Так что желаю всем наряду с неутолимой жаждой познания окружающей IT-реальности, скромности и адекватной самооценки ❤.

___________________________________________________________________

*Речь идет об исследовании кандидатского опыта и мнения IT-специалистов по поводу рекрутинг-процессов — Candidate experience research 2018 . Опрос проводился с 5 по 19 сентября 2018 г., было собрано 437 анкет. Полный обзор результатов запланирован на январь 2019 г.