ИТ-HR не разбираются в ИТ: кто виноват и что делать

В чем успех IT HR, его эффективность? Формула простая: ты должен быть одинаково хорош и в HR, и в IT.

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

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

Открыта вакансия финансиста, насёчу и покажу резюме бухгалтеров и налоговиков — одна же сфера, какая разница! Разбираться еще в этих терминах — БДДС, БДР, управленческий учет. Маркетолог нужен — держи пиарщика и SMM-щика в придачу. Как не подходят, разве это не маркетинг?

Глупо звучит, правда?

Так почему из года в год я встречаю ИТ-рекрутеров, которые не разбираются в IT? За всю свою практику я просмотрела тысячи резюме ИТ-рекрутеров и IT HR-ов, провела сотни интервью с ними. И каждый раз, когда я ищу человека к себе в команду или своему клиенту, я хочу плакать от горя, разочарования и непонимания.

Вообще у меня есть довольно длинный список компетенций — знания, навыки, soft skills, мотивация, ценности. И один из важных пунктов — это знание и понимание предметной области, т.е. IT, разработки в частности. Это понимание ролей в разработке, процессов, технологий, знание определений — что из чего вытекает, что как к чему относится, классификации, отличия, сходства, параллели. Рекрутер должен уметь отделять «зерна от плевел», знать, чем занимаются IT-специалисты, в чем суть каждого участка работы, ценность, какие технологии и инструменты они при этом применяют. Что критично для одного проекта и абсолютно неважно будет для другого. Понимать, в чем отличия крутого спеца от среднестатистического и слабого. Понимать hard skills на уровне теории. Я ведь даже не говорю про практику, оценивать, чистый ли код у разработчика. Хотя бы теорию. Экспертиза должна быть! Но нет, и здесь тоже всё печально.

Раньше я проводила собеседование так: сначала оценивала профессиональные скиллы в рекрутинге или в HR в целом, потом soft skills, мотивацию — и только потом смотрела на знания в IT. Интервью с IT HR я провожу по 1,5-2 часа, чтобы глубоко оценить весь список важных для меня компетенций. И т.к. процент тех, кто шарил в IT был меньше 10%, я решила перенести проверку ИТ-части в начало разговора. Я называю это тех.блицем. И так у меня сократилось время общения максимум до 20 минут с теми, кто тех.блиц не проходит.

Сейчас у меня в работе очередной рекрутинговый проект — я ищу IT HR в единственном лице в небольшую международную софтверную компанию.

Рекрутеров на рынке больше, чем 6 лет назад, потому что IT-компаний тоже стало больше. Но проблема с их прокачанностью в IT осталась на том же уровне. На тех.блице я не задаю каких-то космически сложных вопросов. Все из реальной жизни в ИТ, требований к кандидатам, их задач, процессов разработки.

Чтобы вы понимали, примеры вопросов:

И так далее.

И вот выдержки из ответов (кроме ответов: «я не знаю») :

Большинство кандидатов понимают, что у них есть пробелы, хотят их восполнить, учиться. Но оправдываются тем, что:

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

Рекрутеры жалуются: так ведь очень много непонятных слов, как же понять, что это такое, что это значит. Как же я сам, у меня нет учителя.

Другие кандидаты раздражаются: зачем мне это все знать, глупости какие-то. Я и так прекрасно справляюсь со своими задачами без этих ваших ООП и Java с JavaScript. Какое это имеет отношение к моим обязанностям задачам? — Детка, самое прямое отношение. И если ты этого не понимаешь, удачи. Значит, нам не по пути.

Или заявляют с высоковздернутым носом: я умный/умная, и если надо будет, я разберусь. — Так что ты еще не разобралась/разобрался за 3-5-7 лет, пока работаешь в IT HR? В чем проблема-то, в чем сложность, раз ты умная/умный?

И мне очень жаль...

Жаль заказчика, что он будет получать нерелевантных кандидатов, когда появятся те самые вакансии джавистов или фронтендеров. Будет тратить свое время и нервы. А бизнес-задачи будут простаивать, потому что рекрутер ищет/показывает не тех, упускает нужных или вообще не понимает, кого и зачем искать.

Жаль работодателей, потому что от некомпетентности рекрутера страдает HR-бренд. Потому что рекрутер — это лицо компании, первый человек, с кем контактирует кандидат на входе. И ошибка первого контакта может дорого обойтись — потерей классного кандидата.

Жаль кандидатов, которые продолжают страдать и беситься от рекрутерской тупости. Но кандидаты-разработчики пытаются помочь, наладить ситуацию — пишут гневные посты на Хабре и в ФБ про то, как не надо делать, как не надо им писать, как не надо с ними общаться и с какими предложениями обращаться. Они это пишут для нас, рекрутеров. А рекрутеры не читают, потому что думают, что у них и так все просто отлично.

Жаль других рекрутеров, профессиональных и компетентных. Потому что им отголоском достается негатив кандидатов и нежелание с ними общаться, потому что они обобщают некомпетентность рекрутеров. Если я 30 раз столкнулся с тупым эйчаром, почему я тебе должен довериться? О чем с тобой говорить вообще, если ты не шаришь, двух слов в ИТ-терминологии не можешь связать и все равно не поймешь, о чем я тебе говорю. И тут мы кричим (точнее доказываем делом): я не такая, поговори со мной, и ты убедишься (удивишься). И они убеждаются (удивляются) и говорят: «Хэй, а ведь ты шаришь». Обсуждают с нами рабочие проекты, с запалом рассказывают о задачах, проблемах и тонкостях. Еще и друзей нам потом рекомендуют, потому что остались довольны, как с ними пообщались.

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

С первой категорией все понятно, т.е. безнадеждно, т.к. без мотивации никуда. А со второй категорией можно работать. Но здесь важно, чтобы, кроме «хочу», было еще и «могу», т.е. мозг, способность обучаться новому — особенно технической информации. И вот вы жалуетесь, что учителя нет, разобраться сложно. Если непонятно — гугли! Ты сам себе учитель. Что-то прочитал, и все равно непонятно — гугли еще, спрашивай у своих заказчиков и кандидатов, что это и зачем. Если все равно непонятно, может быть тебе не место в IT HR? Подбирай персонал попроще — продажников, например. Хотя и там нужно, чтобы у тебя отскакивали от зубов этапы продаж, и ты должен уметь оценить навыки выявления потребностей, работы с возражениями и вот это вот всё.

В интернете множество статей, презентаций, видео, докладов на тему IT. В течение года запросто можно попасть на онлайн-конференции IT HR или найти старые записи докладов. HR API, например. Или канал Amazing hiring на Youtube. Запишитесь на оффлайн-курс по ИТ-рекрутменту. Они проходят в основном в Москве. Но съездите, потратьте деньги — оно того стоит. Ведь это инвестиции в вашу собственную экспертизу, профессиональное развитие.

Снимаете заявку у заказчика, загуглите каждое непонятное слово, разберитесь, для чего это и что это значит. Если не смогли разобраться, попросите нанимающего менеджера объяснить на пальцах какие-то понятия, простыми словами. Например, он вам говорит, что для разработчика важно знание и применение ООП или алгоритмическая подготовка. Очевидно, что без этих скиллов заказчик не будет рассматривать кандидатов. Ваша задача показывать релевантных кандидатов. Значит, вам необходимо понять, что это такое, как применяется в задачах на практике, и как вы это можете оценить на своем уровне. Или другой пример: CTO хочет найти React разработчика. Значит, вам остается сложить 2 и 2 — понять, что это front-end разработчик на самом деле, и узнать, а подойдут ли/будут ли интересны кандидаты со знанием других фреймворков? Допустим, да, подойдут. А какие есть другие, опять же вам предстоит выяснить. Vue, Angular — возможно. jQuery — пожалуй, слишком древний. А может быть, менее популярные Backbone и Knockout тоже подойдут? Тогда и NodeJS туда же? — Нет, это для бэкенда.

Все еще считаете, что вам не нужны ИТ-знания?

Да-да. В конце концов, кто берет на работу горе-эйчаров и закрывает потом глаза на их некомпетентность? Да, именно вы — собственники, HRD, руководители подбора (возможно, такие же некомпетентные?). Помните я писала, что все ошибки эйчара влияют на HR-бренд компании. А еще на бизнес-показатели из-за простоя рекрутинга и внутренних ошибок в HR из-за незнания отрасли и ее специфики, процессов, людей итд.

Если вам нужны опытные специалисты, проверяйте на входе у кандидатов в HR/рекрутинг их ИТ-прокачанность.

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

Хочет ли.

Узнайте прямым вопросом: «Почему ты хочешь в IT? Какие риски и пллюсы ты видишь при переходе? Почему думаешь, что получится? Что делаешь уже в этом направлении?»

Может ли.

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

В моей практике было много успешных примеров, когда я брала в команду эйчаров с опытом из других сфер — подбор ИТР (это кстати, наиболее близкая сфера к ИТ), узких специалистов бэк-офиса и даже из массподбора. Но были и неудачные примеры, когда у эйчара в итоге ломался мозг, было отторжение информации про IT. И либо они сами уходили, либо я с ними прощалась. Они были нормальными рекрутерами, только не для IT.

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

Если вы только сейчас задумались, а «шарит» ли ваш эйчар в IT. Позадавайте те же самые вопросы на понимание терминологии, процессов, ролей. При обсуждении заявки на подбор, проверьте пару контрольных моментов: вот я тебе сейчас про CI/CD рассказываю, а ты знаешь что это такое? Объясни, как понимаешь. Или: нам нужен разработчик с опытом на высоконагруженных проектах — а что в твоем понимании высокие нагрузки? Или: нам важно, чтобы аналитик применял практики user story и use case — а что это такое и как ты будешь проверять?

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

Если вам вообще неважно, шарит ли он. Или даже, наоборот, вы считаете, что для эйчара вся техническая информация лишняя, и вы специально ей не делитесь. Или ленитесь. Или думаете, что эйчар слишком тупой, чтобы разобраться, и даже не хотите пытаться. Некоторые кандидаты мне жалуются по другому поводу: «Я спрашиваю своего заказчика/тимлида/CTO, пристаю к нему с расспросами: а это что, а как это работает, зачем это? А он лишь отмахивается, на мои вопросы не отвечает, почему тот или иной скилл важен не говорит. На технические интервью меня не пускают, говорят, эйчарам там быть не положено или ты все равно ничего не поймешь». Ребята, помогите своим эйчарам! Дайте им шанс разобраться. Побудьте техническим наставником. Теперь вы знаете, почему это важно и чем чревато отсутствие прокачки в ИТ. В первую очередь пострадаете именно вы как нанимающий менеджер.

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

Помню, как мне пришла заявка от клиента на ABAP разработчика. Сперва я подумала, что SAP — это самописная программа. Но как только я загуглила, мне самой стало стыдно про себя. Ведь SAP — это крупнейшая ERP-система в мире. И он содержит десятки разных модулей — стала читать и разбираться, чем они отличаются, и что за ABAP такой язык непонятный. Потом была заявка SQL-разработчика с тестовым заданием. И я стала раскапывать ответы на каждый вопрос в тестовом, что такое процедуры, триггеры, запросы в БД, чтобы говорить про это с кандидатами, понимать их ответы и фильтровать. Затем все компании стали требовать от разработчиков знать ООП — значит, и мне надо разобраться, что это такое и в чем заключаются принципы. И так у меня просто стал расширяться кругозор и углубляться знания.

Когда я пришла в СКБ Контур, то мне очень хотелось увидеть на практике то, что я знала в теории. Я просила разработчиков помочь мне и моей команде, показать. Я приходила к ним в комнату, садилась рядом и смотрела, как они пишут код. Мы с рекрутерами увидели, как выглядит Cassandra внутри, а как — Visual Studio, как выглядит код написанный в стиле ООП и функционально, какой синтаксис у JavaScript и C #. Мы читали только что разработанные гайды по UX/UI. Я ничего не знала про ACM и CTF, а такие ребята нам были очень интересны как кандидаты. И Миша Рубинчик, тренер УрФУ по ACM вводил меня в курс дела. Паша Егоров, препод в Контуре и на матмехе, приходил к нашей команде IT HR, показывал нам инструменты, мы обсуждали технические темы, задавали вопросы.

Это было бесценно. И я очень благодарна ребятам за помощь.

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

Я тогда нанимала много ИТ-рекрутеров, команда росла сумасшедшими темпами. Мне хотелось передать свои знания, хотелось, чтобы им было легче погружаться, чем мне в свое время. И у меня родилась база знаний и программа адаптации по IT на 3 месяца. В конце срез знаний на 150 вопросов различной тематики. Так я была уверена, что знания у всех равны, и никто не ударит в грязь лицом ни перед кандидатами, ни перед заказчиками. Я с ней живу уже 5 лет и обновляю время от времени.

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

Часто и я, и мои рекрутеры знают больше самих разработчиков. Например, про ООП. Кто-то из кандидатов не называет ни одного принципа, кто-то только 3, а кто-то из них не может объяснить, что же такое инкапсуляция. Это, конечно, тоже печаль, но уже оборотная сторона — про кандидатов-разработчиков. Но таких кандидатов мы фильтруем, не отправляем заказчикам. Потому что нам нетрудно это оценить, а выигрывают все.

Послесловие

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

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