Speaking Developish. О технической грамотности IT-рекрутеров
Speaking Developish — термин, который придумала команда GUID (www.guid.com.ua). Он обозначает способность рекрутера читать резюме и вакансии, понимать разработчика и говорить с ним на одном языке. Мы убеждены, что для этого необходима как техническая подкованность, так и понимание специфики IT-бизнеса и IT-индустрии (мировых и региональных рынков).
В IT-рекрутинг приходят разные люди и по разным причинам. Моя причина — IT, информационные технологии. И на сегодняшний день я могу сказать, что мой живой интерес к IT-индустрии положительно повлиял не только на мой личный рекрутинг-опыт, но и определил фокус моей компании на техническую подкованность рекрутеров. Я убеждена, что это одна из ключевых вещей, которые определяют профессионализм и экспертность IT-рекрутера. Для иллюстрации, в программе GUID по подготовке рекрутеров половина занятий посвящена IT-экосистеме и технологиям разработки ПО.
Поэтому цель этого лонгрида — заявить: владение IT-лексикой и понимание, что стоит за конкретными понятиями и терминами — мастхэв для технического рекрутера. А заодно и показать, к чему приводит игнорирование этой компетенции на различных этапах рекрутинг-процесса. Буду опираться на опыт моей компании, добавляя цитаты IT-специалистов из недавно проведенного нами опроса*.
1. Ежедневные коммуникации
Мы любим приводить аналогию: при переезде в другую страну, первый шаг — изучение языка этой страны. Так же в IT-рекрутинге — когда рекрутер осваивает техническую базу и специфику IT-бизнеса, он овладевает языком индустрии (со всеми смыслами и мемами, которые стоят за отдельными словами). И только после этого рекрутер способен адекватно представлять компанию и проекты на рынке, понимать, о чем говорит кандидат, и видеть за совокупностью фактов об опыте его личность.
Расхожий мотив старта карьеры в рекрутинге и HR — любовь к людям, желание побольше с ними коммуницировать, получше их узнавать, помогать им направо и налево и делать безмерно счастливыми. Но как реализовать «искренний интерес к человеку», когда из его рассказа о себе ты понимаешь 20% слов? Довольствоваться двадцатипроцентным пониманием, сопереживанием и участием? Абсурд.
А уж если в задачи эйчара входит оценка технарей... И при этом он не видит ничего зазорного в том, что «не шарит в технической кухне»... Простите, но это просто аморально. Верх цинизма — отвечать за удовлетворенность и мотивацию людей, не пытаясь понять, чем они живут и дышат каждый день.
Если ты в IT и не speak Developish, разговоры о том, что у тебя к каждому любовь и индивидуальный подход — лукавство. Уважаешь себя, уважаешь и восхищаешься людьми в IT— учи их язык.
2. Требования к кандидатам
Техническая неграмотность — причина одной из наиболее распространенных рекрутинг-ошибок: пропускать этап обсуждения с заказчиком описания вакансии и требований к кандидатам. Рекрутер всегда должен сомневаться. И подозревать заказчика в а) перфекционизме и б) лени гипер-занятости. В первом случае, заказчик добавит в вакансию что-нибудь «про запас». Во втором — не проверит описание и там может оказаться что угодно.
Только если вы интересуетесь техническими деталями и хорошо знакомы с областью разработки, по которой ищете кандидата, — вы способны увидеть нестыковки в требованиях. И предотвратить недели, а то и месяцы нецелевого поиска.
3. Сорсинг
Не первая, но самая очевидная проблема, с которой сталкиваются не шарящие в Developish рекрутеры, — неспособность понять резюме/профиль кандидата и верно оценить его «подходящесть» под вакансию. К чему это приводит? В лучшем случае, к свайпу релевантного профиля в LinkedIn. В худшем — к самовольному реджекту резюме, потому что «опыт не тот».
Это проблема очевидная и решаемая: рано или поздно можно выучить все технологии проекта и их взаимосвязи, аналогичные технические решения, маркеры похожей предметной области и т.п.
Но Developish — не только про способность скринить профили на релевантность техническим требованиям. Технологии — важная, но не единственная переменная в работе инженера. Например, проект имеет еще с десяток характеристик, которые качественно дополняют общую картину вакансии («возраст», масштаб проекта, качественный и количественный состав команды, темпы разработки, типичные задачи, подходы к проектированию и тп.).
Если рекрутер оперирует всеми этими переменными и, главное, понимает, что по каждой из них может быть у потенциального кандидата на текущем месте (специфика его проекта), — тогда и лонг-листы получаются релевантнее, и стратегия общения выстраивается осознанно. Это и есть одна из сторон понимания рынка: когда рекрутер ориентируется не только в типах и предметной области компаний-конкурентов, но и понимает внутреннюю специфику проектной разработки.
4. Работа с возражениями и продажа вакансии
Все знают, что «рынок перегрет», что это «рынок кандидата» и вакансии закрываются тяжело. Для рекрутера это значит, что он не надеется только на отклики с работных сайтов, а большую часть времени занимается активным поиском — ищет кандидатов и пытается их «переманить». В теории звучит логично. На практике есть нестыковочка.
Если понаблюдать за рекрутерами, всегда можно заметить прямую зависимость между их запалом идти «в поле» и тем количеством и качеством информации о проекте, которая у них есть. Наивно ожидать, что рекрутеры будут чувствовать себя свободно в коммуникации с кандидатами, если у них вообще нет информации о проекте. Или этой информации мало. Прямо скажем, непонимание куда ты ищешь и почему твое предложение должно быть интересно, обрекает всю затею с переманиванием на провал. А это и есть Speaking Developish: быть глубоко в теме своего продукта, в теме рынка и обладать техническим кругозором, чтобы читать резюме и говорить с кандидатами об их опыте и текущем проекте.
Абсурдность ситуации — в том, что чаще всего рекрутеры могут получить исчерпывающую информацию о проекте, но не пользуются этой возможностью. Просто потому, что у заказчика и рекрутера отсутствует установка, что рекрутер способен эту информацию понять и обязан это сделать. Закономерно, что и кандидаты все чаще не ожидают от рекрутера содержательного описания проекта и искренне удивляются, когда он способен это сделать.
5. Собеседования
Я не буду слишком подробно останавливаться на собеседованиях рекрутеров с техническими специалистами. Без обсуждаемого базиса это разговор глухого со слепым. Да и цифры* говорят о том, что кандидатам далеко не всегда удается услышать от рекрутеров о потенциальных задачах и технических аспектах вакансии.
Хотя и полной информацией о проекте и компании кандидатов также не балуют.
Возможно, отсутствие в компаниях этапа собеседования с рекрутером — хорошее решение. Для выживания технарей как вида. Но это не оптимальное решение для компаний, которые стремятся экономить время своих собеседующих и заботиться о своей репутации.
6.Одноразовый рекрутинг
В заключение я хочу показать, к чему приводят все вышеописанные проблемы и факапы:
Как сказала наша СОО Настя Геллер при обсуждении этого слайда на рекрутерской конфе: «Какой-то одноразовый рекрутинг получается». Соглашусь. Проблем везде понемногу и вроде не критичные, жить можно...вот и живем.
В итоге, ценность и роль рекрутера в процессе найма нивелируется, а образ малополезного звена прочно укореняется в сознании. Это не только мешает сотням других, правильных рекрутеров выполнять ежедневные задачи, но и препятствует развитию хороших команд и компаний. В итоге именно они недо-нанимают людей..
Что делать?
Начать со своего окружения.
1. Слушать, записывать, мотать на ус и систематизировать всю техническую и около-техническую информацию, которую слышите.
2. Доставать своих технарей вопросами, не зная меры. Хороший рекрутер — очень неудобный человек для собеседующих технарей. Он нудный, дотошный и как банный лист — не отцепится, пока не вникнет во все детали. Зато для кандидата этот же рекрутер — верх компетентности. И компания этого рекрутера в глазах кандидата — соответствующая.
3. Не стесняйтесь просить ваших кандидатов объяснять какие-то технические вещи. Большая часть из них это сделает с удовольствием (проверено тысячу раз). В идеале — уже обладать базой и задавать вопросы по конкретным деталям и тонкостям.
Про гуглеж и систематизацию информации — вообще молчу.
Какие минимальные знания необходимы?
Информация о вакансии, с которой рекрутер может выходить к кандидату, должна охватывать следующие пункты:
— Подробная информация о проекте (его суть, предметная область, «возраст», масштаб, стадия разработки, планы по развитию и т.п.)
— Тип приложения (web, mobile, desktop, embedded) и технический стек проекта (языки программирования, фреймворки, библиотеки, базы данных, вспомогательные тулзы и технологии)
— Как построен процесс разработки
— Качественный и количественный состав команды
— Задачи искомого специалиста (как минимум, в терминах «саппорт/разработка новой функциональности»).
Нетрудно получить эту информацию у заказчика (внутреннего или внешнего). Главное — приложить усилия, чтобы понять новые термины и нанести их на свою «карту информационных технологий». Карта эта будет сильно упрощенная и местами далекая от реальности. Но и такой вариант лучше, чем полное отсутствие каких-либо ориентиров.
И под конец хочу предостеречь вас от еще одной ошибки.
Если вы не программист-рекрутер, и однажды вам покажется, что вы просто супер шарите... Скорее всего, вам покажется. Печальнее технической безграмотности рекрутеров может быть только их техническая самоуверенность. Когда человек с очень умным видом делает какие-то псевдо-логичные заключения, связывая в одну цепочку несочетаемые вещи. Крайность такой самоуверенности — в принятии направо и налево самостоятельных решений о технической релевантности кандидатов.
И в заключение:
Так что желаю всем наряду с неутолимой жаждой познания окружающей IT-реальности, скромности и адекватной самооценки ❤
_______________________________________________________
*Речь идет об исследовании кандидатского опыта и мнения IT-специалистов по поводу рекрутинг-процессов — Candidate Experience Research 2018 (guid.com.ua/...te-experience-research-2). Опрос проводился с 5 по 19 сентября 2018 г., было собрано 437 анкет.
17 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів