Привет, Хабр!

Это моя первая статья!

Хочу поделиться с вами своим мнением и наблюдениями о процессе подбора персонала в разработке. 

Думаю, мои наблюдения также могут быть применены в других направлениях.

Статья будет интересна следующим лицам: программистам,HR, Teamleads, директорам HR, IT. 

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

Предлагаю принять во внимание следующее:

1. В статье делюсь только своими мыслями и опытом. Я не могу никого учить. Делайте выводы сами.

2. Все совпадения случайны.

3. Подбор персонала - крайне сложная и ответственная задача.

4. У нас у всех мало опыта, век живи век учись.

Немного о себе:

Мне 30+ лет, работаю уже почти 10 лет IT менеджером в  компании ( штат более 500 чел ). На текущий момент моя группа занимается улучшением продуктов компании , также разработкой программ для клиентов и сотрудников. За 10 лет мне приходилось нанимать, обучать, руководить большим количеством людей - в общей сумме более 60 человек. Многие из них "выросли" из начинающих инженеров - в серьезных (разработчики, автотестировщики, devops). На данный момент они работают в TOP IT компаниях России.

Тактика:

Итак, начнем.

1) Убедитесь что ваше/кандидата резюме прочитано

Два года назад я решил попробовать себя в роли мобильного разработчика. На тот момент у меня был опыт 1 год разработки мобильного pet-project. Было 1500 скачиваний, 300 активных пользователей.  Я откликнулся на предложение одной из ТОР компаний России.

Читаю описание, вижу что по тех части я подхожу, по руководящим задачам тоже. Отправил отклик и, к моему счастью, меня пригласили! Вау! Я сразу представляю кучу бабок , успех, карьерный рост). Приехал на собеседование, его проводил руководитель IT департамента и какой-то другой руководитель, наверное его зам. Что сказать…старший был ровно из тех типичных менеджеров , каких любят у нас в России. Возрастом от 40+, полненький на вид, напористый, уверенный в себе. Начали беседу, она длилась не долго, минут 30 . По его разговору я понял, что я ему не нравлюсь. Что именно он спрашивал я не помню, но помню что сказал в конце.

Он: "Знаешь чем отличается опытный разработчик от новичка?".

Я: "Нет".

Он: "Опытные указывают в своем резюме крупные, долго-играющие проекты, со сроком реализации 2-5 лет, а новички напишут в своем все подряд, разных терминов наберут…".

Я ушел расстроенный, понял, что мне отказали.

На протяжении где-то полугода я размышлял о его словах и меня,  как менеджера , не покидали размышления:

1. Я указал в своем резюме все как есть, ничего не выдумывал, лишнего не указывал.

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

3. Как так вышло, что  такой опытный руководитель, по времени он явно был больше меня на руководящей должности, у которого ЗП больше меня раз в 5,  штат сотрудников больше раз в 20, такой матерый и уважаемый человек пригласил меня и сказал, что я ему не подхожу по очевидным и банальным вещам и так понятных из резюме?

4. Он потратил минимум 30 минут своего времени и зама, работа HR, я потратил 1 час на дорогу. И это все просто так? А где же профессионализм, свойственный рук. департамента? В чем заключается ТОП менеджмент?

В итоге , где-то через полгода, меня осенило в чем было дело  - просто он не читал мое резюме до встречи, а читали во время. Данный факт подтверждает то, что он озвучил недовольство моим опытом как разработчика, хотя он явно и полностью был описан. Также в разговоре он сослался на глагол "…пишут", то есть ему было важно что у меня именно описано. Ну что ж бывает. Занятой человек, ему наверняка было не до этого, сами поймите тех.дир! Только мне от этого не легче, 1,5 часа впустую.

После данного случая я стараюсь поступать следующим образом:

Если бы я был Team lead: Обязательно,  до назначения встречи, внимательно прочтите опыт кандидата.

Плюсы: Это сэкономит вам время. Если есть странные моменты, попросите HR их уточнить и дать вам обратную связь.

Минусы: Потратите свои силы, время. Соответственно их не хватит на другие задачи.

Если бы я был HR: Убедитесь у Team lead что он действительно внимательно прочел резюме до встречи. Как вариант можете задать ему уточняющие вопросы, например: "Тебя не смущает что у него опыт всего 1,5 года?", "У него указан опыт коммерческой разработки 1 год, но нет ссылок на продукты, что можешь сказать?", "Тебя устраивает как у него описан опыт с RxJS?", "Смотри у него есть опыт с docker, что у него спросить про это?". Может хотя-бы в этот момент Team lead (ЛПР) придет в себя и прочитает хотя-бы пару строк из резюме внимательно.

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

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

Если бы я был Кандидат: Уточните у HR, что ваше резюме прочитали, обязательно сделайте это до приезда в офис или собеседования по Skype. Во время собеседования вежливо спросите читали ли все кто принимает решение о найме ваше резюме. Все люди занятые , запросто могут этого не сделать. Если нет, попросите их прочитать, только потом начинайте собеседование. Сошлитесь на то, что это важно для "эффективной" траты времени, как их так и вашего.

Плюсы: Это может сэкономит вам время.

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

P.S У вас может сложиться мнение, что я пишу какую то ерунду, ну не прочитали резюме и что с этого? Мы то всегда читаем. А с чего ты взял что они его не прочитали, может ты им просто не понравился или нагрубил?

Далее я приведу пару конкретных кейсов, где подобная история повторяется).

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

2) Что очевидно мне - очевидно тебе!

Несколько лет назад до этого собеседования, бизнес-тренер моей компании объяснил мне одну вещь: "Что очевидно мне - очевидно тебе". Идея в том что при объяснение какого-либо предмета, постановки задачи мы автоматически, точнее по лени, считаем что у собеседника такое же понимание , опыт и видение задачи, предметной области как и у нас.

 Например, руководитель в первый раз просит своего подчиненного: "Сделай мне отчет о вчерашних продажах", тот говорит: "хорошо!". И тут вуаля, вылезает сюрприз! Дело в том что в русском языке слово "отчет" является очень абстрактным понятием, и каждый из собеседников представляет себе разную структуру, содержание и полноту отчета. Первый считает что отчет будет выглядеть так как он ожидает - с 7 колонками и 5 графиками. Второй представляет себе тот отчет, который он делал вчера - с 2 колонками и без графиков). Оба результата называются словом "отчет". В итоге , после того, как сотрудник сделает отчет, руководитель , посмотрев и не увидев того, что ожидает, скажет, а может даже заорет: "Ты что тут налепил? Как мне в этом разобраться?"

Чтобы избегать этого я следую двум простым правилам:

1. Формализую поставленную мной задачу, описываю ее в деталях, чтобы у ее исполнителя было такое же понимание как и у меня.

2. Уточнять правильность понимания поставленной задачи исполнителем .

Например вот как выглядит "классическая" постановка задачи при поиска кандидата:

Заказчик: Привет HR, у меня уволился разработчик, найди мне, пожалуйста, такого же, только не хуже, можно побыстрее?

HR: Ммм…) Хорошо, а не хуже это как? Опишите его, пожалуйста, подробнее.

 (Как заказчик представляет его себе: Знает rxjs: relaySubject, mergeMap, sheduler, как избегать утечек памяти при подписках, как создать утечку памяти, как применять rx декларативно. может объяснить когда плохо и хорошо логирование клиентских логов на сервере и как это сделать, lazy loading, идеально знает разницу межу mvp/mvc/mvvm. может с нуля на голом js реализовать hello world по mvp/mvc/mvvm) 

Заказчик: Ну от 2 лет коммерческой разработки, javascript, angular, rxjs, git, jira.

HR: Просматривает резюме кандидатов, видит резюме: "Опыт 1 год, javascript,  git, jira. angular."  (Что реально знает кандидат: rxjs: switchMap, map. На angular делал проект уровня hello world)

Т.к. у HR нет подробного описания вакансии и ей не с чем сравнить, у нее срабатывает эффект: вижу то, что хочу и т.к. у нее горят сроки, то.

(HR звонит кандидату)

HR: Здравствуйте, ваше резюме показалось нам очень интересным, вы не хотите пройти у нас собеседования на позицию "разработчик".

Кандидат: ( ууху! Фартуна, лотерея! Куча бабла и тачки.) Да конечно! Я все могу! Куда приезжать?…

Аналогичная ситуация происходит когда кандидат сам делает отклик на вакансию.

Кандидат: Открывает вакансию, видит описание:

"2 года коммерческой разработки, javascript, angular, rxjs, git, jira."

Думает: "Ну я уже 1 год делаю сайты на javascript. Пару сайтов делал на Angular. Знаю пару операторов в rxjs, git, jiar тоже без проблем, давай попробую". Откликается.

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

Применительно к найму, формализацией поставленной задачи, является детальное описание профиля кандидата.

Я думаю, в идеале, это должно выглядеть так:

- Описание минимальных требований:

Тут нужно указать тот минимум которым должен обладать кандидат. При этом нужно описать его так, чтобы у кандидата, желательно и HR,  было бы такое же понимание терминов как и у заказчика. В данном пункте, я считаю, нужно описать,  минимум 15 параметров, чем больше тем лучше. Каждый  параметр должен быть раскрыт минимум в 3х примерах. При этом, на мой взгляд, желательно описывать типовой функционал кандидата. Знания, опыт которые он может получить, найти в интернете за пару часов описывать не имеет смысла. ( поясню подробнее в другой статье).

- Описание максимальных требований (идеальный кандидат)

Тут нужно описать идеального кандидата. Кандидату показывать это не нужно. Это должно быть только у HR и заказчика. Данный профиль нужен чтобы заказчику было легче выбрать между несколькими кандидатами, например если они не плохие между собой по технической части, но разные по другим показателям, например интерес к исследованию новых библиотек, фреймворков, общительность, стрессоустойчивость, ответственность.

- Расписать почему идеальный кандидат выберет именно вашу компанию.

Лучше понимать по какой причине, идеальный кандидат, выберет именно вас, а не более известную, крупную компанию с большим бюджетом на "HR рекламу". Например ТОР IT компаний России. Почему кандидат на позицию "React developer" пойдет в "Ромашка и КО" вместо "Яндекса","Mail","Avito" etc если у них открыты такие же вакансии с аналогичными требованиями? Возможно в этом случаем вам стоит снизить требования как к идеальному, так и к минимальному кандидатам.

Иначе будет классический лозунг: "Мы ищем кандидата, да такого… такого…. чтобы все и сразу, да с опытом 2 года. А почему ? Да потому что мы классные и у нас открыта вакансия!".

Приведу примеры:

Не правильный профиль идеального кандидата: 

Идеальный кандидат - Билл Гейтс

Задачи: Править верстку в лендинге.

У нас есть конкуренты? - полно.

Мы ему интересны? - нет, т.к он миллиардер и у него куча денег, зачем ему наши 80 000 руб. в месяц?. 

Правильный профиль идеального кандидата: 

Идеальный кандидат - Билл Гейтс

Задачи: Встать во главе нашего сервиса, на стеке компьютерных и биотехнологий.

У нас есть конкуренты? - нет, т.к. в нашей команде есть уникальные специалисты мирового уровня.

Мы ему интересны? - скорее да, т.к он интересуется данной сферой, его наверняка заинтересует наша команда и потенциал роста в мировом масштабе.

Как бы я поступил если бы я был:

Team lead: Расписал бы подробно минимальные, максимальные требования к кандидату.

Тут стоит отметить что именно можно указывать в минимальных требованиях, например:

1. Перечисление библиотек, модулей, подходов  хотя бы 15 штук.

2. Погружение в каждую библиотеку,  модуль, подход  перечислить хотя бы 3-4 функции

3. Перечислить какие архитектурные задачи нужно решать с каждой из библиотеки,  модулем, подходом

4. Перечислить какие бизнес задачи нужно уметь решать на базе данной архитектуры.

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

Например:

RxJs:

а) Уметь применять на практике - sheduler, forkJoin, catchError, takeUntil, retryWhen.

б) Уметь подписаться на http запрос , отписаться от него по событию,  в случае HTTP ошибок подписаться  повторно.

в) Уметь делать автоматическую авторизацию пользователя , если сессия сохранена в браузере.

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

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

Минусы: Нужно потратить время, силы чтобы описать это. Держать в актуальном состоянии. Есть шанс разругаться с HR или его руководителем, т.к. придется погружать их в формализацию, а это труд, нервы. Мы всегда занятые и нам подобное это не интересно.

HR: Требуйте от тим-лида (заказчика) подробного описания минимальных требований, минимум 15 строк по 3 пункта на каждую строку.

Плюсы: Это поможет вам быстро отсеять не релевантных кандидатов, повысит конверсию. за счет того что помогает вообще понять кто именно вам нужен. Например при отклике, если из резюме кандидата не понятно подходит он или нет, вы можете запросить у него перечислить что он знает / делал из минимальных требований предоставленных заказчиком. Если кандидат не проходит какой-то минимум ему отказ. В этом случае не придется даже звонить ему для уточнения чего либо. Вы экономите свои силы.

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

Кандидат: Уточняйте что именно подразумевает работодатель указываю ту или иную технологию, библиотеку, задачи и тд.

Плюсы: Экономия времени, вы можете не обладать какими-либо критичными знаниями, зачем это узнавать на собеседовании?

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

Теперь давайте посмотрим немного примеров описанных мною проблем:

Недавно я поймал себя на мысли, что для того развиваться далее как руководитель в разработке, например стать тим-лидом, мне не хватает опыта коммерческой разработки. Я решил попробовать себя в роли full-stak разработчика, вывесил резюме, сделал несколько откликов.

50% было отказ, 50% были приглашения. И что же я видел в приглашениях?

Компания №1:

Это было мое самое первое предложение на позицию Tem Lead. К сожалению я не сохранил описание их вакансии.

Суть что у них совершенно другой стек технологий, нежели тот, которым я обладал на тот момент. У них был React/Vue/Nest/ , я знал Angular/Node.js. 

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

Видите! Меня уже приглашают на встречу с "тех.диром". Старая добрая традиция - прийти на собеседование и узнать что ты не подходишь т.к. не хватает знаний!

Я запрашиваю у них минимальные требования.

Мне отвечают

В итоге я получаю на почту тот же текст что и в описании вакансии.

Если бы они написали что им на frontend достаточно опыта с одним из  фреймворков например: Angular, React,Vue и на backend: Node.js, Nest.js я бы пошел. Но этого не было. Тратить время в пустую у меня не было желания. И я им не стал отвечать. 

Компания №2

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

Например:

1)  JavaScript и TypeScript, CSS (Flexbox и Grid) - какие библиотеки, подходы нужно уметь применять?

2) Какие архитектурные задачи нужно уметь решать?

3) Какие бизнес задачи нужно уметь решать?

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

Я надеялся получить развернутый ответ, но в итоге получил:

Честно я был в недоумении. Как так выходит что компания готова оформлять сотрудника официально, платить ему оклад, ДМС, пенсионные выплаты,  прочие расходы и при этом не представлять кто именно им нужен, и каким образом их HR хотя бы поверхностно отличить релевантного кандидата от не релевантного?

1. Где подробное описание минимальных тех. знаний?

2. На основе чего HR поймет что кандидат ей подходит, не подходит?

3. Что HR спрашивать у кандидата?

4. Как HR или заказчик поймут сможет ли потенциально ли кандидат решать их бизнес задачи или нет?

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

Компания №3

Поступило еще одно приложение на позицию разработчика.

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

Непонятно, каким минимум должен обладать разработчик.

1. Реактивные формы нужно уметь использовать?

2. RxJS какие операторы нужно уметь применять?

3. Какие стейт менеджеры уметь применять Ngrx, MobX, Ngxs?

4. Какие библиотеки уметь применять?

5. Как быть unit, e2e тестированием, уровня hello world хватит?

6. Что нужно уметь тестировать - компоненты, сервисы, верстку, e2e тесты?

Я решил попросить у HR подробное описание.

Получил ответ:

Отлично! Ни кандидат, ни HR не понимают кто кому подходит и единственный шанс это выяснить  - прийти на собеседование!

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

В итоге выходит классическая схема:

1. HR приглашает всех у кого в резюме есть слова похожие на те, что им предоставил заказчик (Тимлид). 

2. Тимлид не внимательно читает резюме которое HR приносит ему на согласование. Либо также как HR смотрит на наличие "ключевых" фраз, например: "Опыт разработки backend на NodeJs 1 год". И ему кажется, что это релевантный кандидат, при этом он не перепроверяет, что именно кандидат подразумевает под данным понятием.

3. В итоге кандидата приглашают

4. Задают ему проверочные вопросы и оказывается что он им не подходит т.к. не обладает необходимым техническим минимумом, например unit тесты писал всего пару раз.

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

Компания №4

Вот еще один пример описания вакансии разработчика одной очень известной компании

Что я могу сказать - отличное описание условий, передается дух компании, аж самому хочется окунуться в такой креатив).

А что на счет минимальных тех. знаний? 

1. Typescript 4

2. React 17

И все!

• А если я знаю  Typescript  и React  на уровне hello world я подхожу?

• Если я не знаю оператор "keyof" в Typescript это критично?

• Что значит "middle/senior"? Ведь у каждого кандидата и работодателя разное понимание "middle/senior". Есть ссылка на руководящий документ однозначно их описывающий, например ссылка на RFC?

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

Заключение

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

Я думаю, что по аналогии с военными, нам - заказчикам, также страшно при поиске нового персонала. Нам закрадывается мысль: "Если я возьму плохого, кто отвечать будет?" И в следствии защитной реакции мы придумываем себе волшебные слова "серебряные пули" в надежде что они сами по себе решат все наши проблемы. Кандидаты сами будут понимать подходят они или нет и откликаться будут только действительно классные и нужные ребята.  И подобно тем военным, мы выстреливаем в интернет слова: Middle, Senior, 2 года коммерческой разработки, Spring Boot, Nodejs, Angular, Kubernates. 

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

В конечном счете я предлагаю вам попробовать приложить 20% усилий, чтобы получить 80% результата.

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

P.S.

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

Пишите ваши комментарии - буду рад обратной связи от всех!