Детские ошибки HR во взрослом мире ИТ

Меня зовут Павел Новиков. Мой путь в HR начался восемь лет назад, пять из которых я работаю в ИТ. На момент написания этой статьи я тружусь на благо компании ZeBrains. А это веб-разработка, mobile и много других страшных, нет, скорее страшно интересных, вещей.

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

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

Начнем.

Коллега, прежде всего научись отличать Java от JavaScript, библиотеку от фреймворка и далее по списку. Осознай, что DevOps — это DevOps, а не супермен c навыками автоматизированного тестирования и опытом семантической верстки. Не нужно все это искать в одном человеке.

Как проще это осознать?! Приведу простой пример. Топ-менеджер компании и менеджер по клинингу, несмотря на наличие «менеджера» в названиях позиций, являют собой разные роли. Я прекрасно понимаю, что бизнесу очень хочется и требуется... Но ты как профессионал своего дела должен объяснить реальное положение дел.

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

Если же ты считаешь, что ценности компании и корпоративная культура не так уж важны, то это тоже ошибочное мнение.

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

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

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

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

Чтобы качественно вести подбор, нужно понимать, о чем говорит с тобой программист. К примеру, при поиске англоговорящего сотрудника мы явно не станем обращаться к кандидату на иврите. Ведь так?! С программистами такая же история.

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

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

Есть такая проблема — «российский менеджмент». Страшный и ужасный. Речь идет о нерадивых начальниках, чрезмерных системах контроля, невыполнимых KPI, крайне низких зарплатах, бесконечных совещаниях, о ролях тестировщика, проджекта и уборщицы в одном лице.

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

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

Признай, что компания, в которой ты работаешь, не лишена недостатков. Например, в ZeBrains нет устоявшегося рабочего графика. Среди моих коллег, есть те, кто начинает свой трудовой день в 6:00 утра, а есть и те, кто появляется после 10:00. У нас никогда не было и не будет таких вещей, как объяснительная за опоздание.

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

Точно такая же картина происходит и в других отделах. К примеру, я могу провести собеседование и в 23:00, потому что достойный кандидат просто не может в другое время. Если меня спрашивают на собеседовании, бывают ли у нас переработки, я честно отвечаю, что бывают. При этом, конечно, объясняю, с чем это связано.

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

Большинство разработчиков достаточно занятые люди. Именно поэтому многие просят связываться с ними через электронную почту, а не по телефону. Положа руку на сердце, я эту просьбу выполняю, но все-таки частично. Я связываюсь с кандидатами через мессенджеры. Оправдываю себя тем, что это так или иначе решает основную проблему.

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

Популярная хохма гласит:

— Папа, а мы сегодня будем кушать?

— Нет, потому что я работаю в дружном коллективе над интересным проектом.

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

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

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

Похоже на вредный совет, но уточню, что я имею ввиду.

Коллега, всем сердцем прошу тебя забыть о вопросах вроде «кем вы себя видите через пять лет», «назовите три сильные и слабые стороны» и подобных им. Это уже даже не смешно. После этих вопросов на HR непроизвольно вешается ярлык «рекрутёрша-отличница».

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

Собеседование вполне может проходить в формате комфортной беседы. Узнай, чем человек занимался, где работал, что умеет и к чему стремится. Расскажи, чем занимаетесь вы и кого вы ищите. На фоне двух этих рассказов можно постараться найти точки соприкосновения

За этим тезисом кроется сразу два важных момента. Во-первых, если кандидат пять лет отработал с Bitrix, последний год на PHP и в желаемой должности указал «PHP-разработчик»,девять из десяти, что в Bitrix человек не хочет.

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

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