Специалисты в области информационных технологий сегодня нарасхват, и потребность в них в ближайшие годы будет только расти. Поиск разработчиков, тестировщиков, аналитиков и администраторов для компаний самых разных профилей — нетривиальная задача даже для опытных рекрутеров. Достойные специалисты требуют особого подхода: рекрутеру нужно ориентироваться в отрасли, обладать базовыми знаниями в IT-сфере, иначе выстраивать коммуникацию. Как научиться говорить с айтишниками на одном языке, пишет Егор Яценко — один из самых авторитетных российских IT-рекрутеров, энтузиаст и популяризатор новой профессии. Он дружелюбно и иронично объясняет, как быстро искать и убеждать кандидатов, рассказывает о секретах эффективного рекрутинга и закономерностях, которые узнал на собственном опыте. Но самое главное — эта книга поможет начинающим и даже опытным рекрутерам сохранить здравомыслие в любых обстоятельствах.
Для кого
Для рекрутеров и эйчаров, специалистов кадровых служб, как уже работающих в найме IT-специалистов, так и еще только планирующих перейти в эту сферу. Заинтересоваться профессией IT-рекрутера могут и выпускники вузов (причем не только технических), и абитуриенты, и представители других профессий, решившие перепрофилироваться.
v 1.0 — создание fb2 — (On84ly)
В книге упоминаются социальные сети Instagram и/или Facebook, принадлежащие компании Meta Platforms Inc., деятельность которой по реализации соответствующих продуктов на территории Российской Федерации запрещена.
Редактор
Главный редактор
Руководитель проекта
Художественное оформление и макет
Корректоры
Компьютерная верстка
Дизайн обложки
© Егор Яценко, 2022
© ООО «Альпина Паблишер», 2022
Последние полтора года стали, пожалуй, самым турбулентным и сложным периодом в IT-рекрутинге. За это время в России были наработаны уникальные практики привлечения, удержания, развития карьерного трека IT-специалистов и самих IT-рекрутеров. В книге Егора Яценко все это отлично систематизировано, переосмыслено и подано оригинальным и доступным языком. Центральное место в своей книге Егор уделил главной мечте IT-рекрутера — «переводчику с языка айтишников». Сегодня сфера IT в нашей стране стоит перед новыми вызовами, книга выходит в свет как нельзя более кстати и вовремя, будет полезна всем IT-рекрутерам в ежедневной битве за айтишника.
Книга, которую вы только что открыли, предназначена как для начинающих, так и для уже активно работающих HR-специалистов IT-рынка.
Человек, занимающийся наймом профессионалов на рынке IT, регулярно сталкивается со многими сложностями, которые зачастую становятся камнем преткновения для всех участников процесса: кандидата, компании и рекру́тера.
Мы пишем и размещаем вакансии — и не получаем на них отклика. Это вынуждает нас идти «в поля» и активно искать кандидатов. В рамках такого поиска мы сталкиваемся с многочисленными препонами: кандидаты устают от наших звонков и писем, прячут свои резюме и отказываются общаться. Знакомая история? И хорошо еще, если просто отказываются, а не посылают в разнообразных направлениях.
Даже если вам удалось дотащить кандидата до собеседования, он может в любой момент исчезнуть, отказаться выполнять тестовое задание, засомневаться, задуматься, испугаться — и всё! Прощай, закрытие вакансии — начинаем всё по новой!
При этом требований к IT-рекрутерам выдвигается все больше и больше, и зачастую желания заказчиков и реальность настолько далеки друг от друга, насколько представления первобытного человека о строении Вселенной расходятся с квантовой теорией.
Я вас очень хорошо понимаю, если в очередной момент, когда снежный ком описанных проблем нарастает, вы искренне недоумеваете: что за профессию я выбрал и за что мне это проклятие?! Чтобы найти хорошего кандидата, я должен устраивать не просто танцы с бубном, а полноценные спиритические сеансы — смотреть в стеклянный шар и выискивать в нем знаки судьбы, которые наведут меня на след хорошего разработчика, сисадмина или еще какого-то специалиста.
В сообществе IT-рекрутеров есть расхожая шутка: «Да где же мне взять этого специалиста — родить, что ли?» И постепенно она перестает быть шуткой, потому что дети нынешних IT-рекрутеров, наблюдая, насколько востребованы хорошие специалисты на рынке и как за ними гоняются, начинают осваивать языки программирования. Это, конечно, хорошо: мы активно участвуем в популяризации IT-профессий среди молодежи. Но и страшновато одновременно: есть риск не дожить до момента, когда на рынке будет наконец-то достаточно хороших девелоперов.
Ну что, вы прониклись трагизмом происходящего? Отлично! Теперь — о хорошем.
За годы существования IT-рынка мы наработали множество различных технологий поиска классных специалистов, а также ведения их от первого контакта к найму и адаптации в компании. Это бесценный опыт, потому что он приобретался через хождение по граблям, боль, ошибки, взлеты и падения.
Как человек, каждый месяц обучающий десятки и сотни начинающих и опытных IT-рекрутеров, я сталкиваюсь с реальными задачами по найму персонала, которые возникают здесь и сейчас и требуют немедленного решения. Более того, чаще всего ко мне приходят не с простенькими вакансиями, а с висяками, которые «саднят» уже не первый месяц. Я общаюсь с коллегами по цеху, развиваю HR-сообщества и благодаря этому аккумулирую сотни различных ходов, которые позволяют рекрутерам решать, казалось бы, невыполнимые задачи.
Собранным материалом я делюсь в сообществах (ссылки на которые вы найдете в этой книге), на конференциях и просто на посиделках за пивом — здесь же вы найдете мою копилку опыта в структурированной форме, где всё изложено кратко и максимально понятно.
Мы рассмотрим различные варианты активного сорсинга — поиска кандидатов на различных площадках — от традиционных приемов до технологий, появившихся буквально вот-вот. Поговорим о строении IT-отрасли в целом: как она меняется, какие новые профессии появляются и каким требованиям должны соответствовать успешные кандидаты. Поговорим о копирайтинге вакансий и затронем тему процессинга кандидата.
В общем, в книге будет описан весь цикл IT-рекрутмента, подводные камни, которые кроются в каждом этапе, и способы выхода из кажущихся безвыходными ситуаций. Я надеюсь, что эта информация будет интересна и начинающим специалистам, и тем, кто уже уверенно занимается наймом: последние найдут здесь знакомые идеи (которые всегда полезно освежить) и совершенно точно — новые техники, приемы и способы работы, которые никогда не теряют своей актуальности. Учитывая перманентное состояние горящих сроков и дедлайнов в нашей профессии не только сейчас, но и всегда, я буду рад, если мои советы и инструменты сделают вашу жизнь немного легче.
Я не буду говорить абсолютно очевидных вещей о том, что IT-рекрутмент появился в общем-то одновременно с IT-сферой, потому что кому-то ведь нужно было искать тех самых IT-специалистов. Гораздо интереснее разобраться в том, что стало причиной текущей ситуации, когда на рынке дефицит кадров, а IT-специалисты не хотят общаться с рекрутерами.
В этой книге мы обсудим не самые приятные вещи, и, если это может вас травмировать, — возможно, не стоит ее читать. Но я сторонник такого подхода: если вы хотите стать специалистами в IT-рекрутменте, то начать придется с себя. И в первую очередь — признать те ошибки, которые уже были совершены.
На мой взгляд, началось все довольно давно. Как только появилась такая отрасль, как IT, рекрутерам пришлось искать специалистов для нее. Чаще всего в работе применялись те же инструменты и средства, что и в обычном рекрутменте, который далеко не всегда был передовым и технологичным. Чего уж там говорить — даже база кандидатов зачастую не велась, и даже такой старинный софт, как E-staff, был не у всех (что еще более странно, он или его более современные конкуренты — «Хантфлоу», Potok, FriendWork и прочие ATS-системы — до сих пор есть не у всех).
Одновременно с этим появлялись всё новые айтишники. На первых порах они были вынуждены проходить через процессы, выстроенные в компаниях изначально. И, несмотря на то что сама целевая аудитория отличалась от прочих специальностей, у них тогда просто не было выбора. Но технологии не стояли на месте (благодаря все тем же айтишникам), и возникали всё новые ресурсы и способы поиска работы, популяризировалась зарубежная профессиональная соцсеть LinkedIn, подтянулись «Хабр», «Мой Круг». В итоге оказалось, что зачастую гораздо комфортнее было найти работу через коллегу на профильном ресурсе, чем через job-борды и рекрутеров. В то же время рекрутеры продолжали работать в штатном режиме и общаться с айтишниками как ни в чем не бывало. Например, плохо разбираясь в вакансиях, просто зачитывали кандидатам описания или по телефону предлагали решить задачки на логику, которые должны были помочь осуществить первичный скрининг.
Рынок же в это время рос и развивался, айтишники становились всё более востребованными. Компаниям срочно понадобились люди, которые искали бы айтишников, и порог входа в профессию IT-рекрутера начал снижаться. В результате в рекрутеры шли люди, которые до конца не определились, чего же они хотят от жизни. Эта профессия стала своеобразным «перевалочным пунктом», что в свою очередь сказывалось на качестве выполняемой работы и, как следствие, на кандидатах. Пропасть между кандидатами и рекрутерами все больше росла.
Надо сказать, на заре своей рекрутерской карьеры я и сам задавал логические загадки для разработчиков по телефону. И, как ни удивительно, кандидаты мне отвечали. Можете ли вы себе представить, что до 2014–2015 годов кандидаты реально, взяв трубку, готовы были ответить на теоретические вопросы и решать какие-то загадки-задачки?
Давайте еще раз восстановим ситуацию:
● Компаниям очень нужны кандидаты, потому на рынке много вакансий.
● Кандидаты могут выбирать среди предложенных вакансий наиболее интересные.
● Рекрутеры плохо разбираются в предметной области и плохо «процессят» кандидатов, то есть взаимодействуют с ними на всех этапах найма — от знакомства до потенциального трудоустройства.
Какой вывод из этого напрашивается? К черту рекрутеров. К черту компании, в которых работают непрофессиональные рекрутеры, путающие Java и JavaScript (да-да, это очень старая шутка, но даже в 2022 году встречаются люди, считающие, что это один и тот же язык программирования).
IT-сообщество начинает раздражаться и негативить в адрес рекрутеров. Рекрутеры начинают бояться и обижаться на айтишников, отчего косячат еще больше. Звучит как-то очень грустно и бесперспективно.
К счастью, в определенный момент компании начали понимать, что профессионализм рекрутера сказывается на их HR-бренде, и уделять этому процессу больше внимания. Появились люди, неплохо разбирающиеся в IT, которым это интересно и которые способны поговорить с айтишником «на одном языке». Эти же рекрутеры стали подсказывать руководителям, что нужно менять процессы найма, убирать из скрининга теоретические вопросы и подстраиваться под кандидата. Кандидаты даже стали считать этих ребят адекватными и нормальными. Но, к сожалению, такая оценка — чуть ли не максимум, который мы можем получить. Кроме того, IT-специалисты компаниям нужны все больше и больше, но еще не все рекрутеры осознали необходимость меняться и учиться. Хотя такая тенденция есть. И учебных материалов, блогов, вебинаров и конференций по этой теме тоже становится все больше. Например, в 2017 году вышел масштабный «путеводитель» по поиску персонала в IT-секторе и развитию личного бренда рекрутера — Full Stack Recruiter Яна Тегзе[1]. А вот книг, посвященных именно IT-рекрутменту, да еще и на русском языке, до сих пор нет очень не хватает.
Вся эта ситуация повлекла за собой нежелание кандидатов выходить на открытый рынок поиска работы, ведь искать ее оказалось довольно больно и неприятно: нужно отвечать на глупые вопросы, большинство собеседований проходят по одному и тому же сценарию, при этом рекрутеры зачастую не понимают, о чем говорят, и задают общие вопросы. И правда, зачем лишний раз страдать?
А это в свою очередь потребовало изменения профиля необходимых компетенций для IT-рекрутера. Теперь ему нужно не просто обрабатывать hh.ru и забивать воронку кандидатов, но еще и уметь их активно искать на различных площадках, то есть, говоря на профессиональном языке, сорсить. Кроме того, он должен научиться грамотно коммуницировать и «продавать» вакансию «холодному» кандидату, писать нормальные тексты, чтобы делать эффективные вакансии. А еще — владеть маркетинговыми инструментами, чтобы привлекать кандидатов через соцсети, лендинги и т. д.
Как я уже писал выше, профиль рекрутера с течением времени очень сильно поменялся, и теперь рекрутеру нужно гораздо больше компетенций, чем раньше. Но даже в этой теме есть несколько спорных моментов.
Когда-то, когда я искал рекрутера к себе в компанию, я решил «по науке» составить профиль кандидата и расписать все качества и умения, которые должны у него быть, пояснив, каким образом я буду оценивать эти качества. Получился список из 43 пунктов. Только вдумайтесь: из 43! И, разумеется, правда была такой, что если в природе и существует человек, который реально будет соответствовать всем 43 параметрам, то, вероятно, его либо не заинтересует моя вакансия, так как он для нее слишком крут, либо я просто не смогу предложить ему достаточно денег.
И что же тогда делать? Сокращать хотелки, друзья. Как бы ни было больно. Так у меня получилось несколько групп навыков.
Во-первых, рекрутеру необходимо разбираться в предметной области, то есть в IT. Насколько глубоко — вопрос спорный. Некоторые считают, что именно это поможет рекрутеру общаться с кандидатом на одном языке. И в этом есть доля правды: если вы знаете IT, вам будет гораздо легче, комфортнее и спокойнее находить общий язык с кандидатами. В конце концов, шансов, что вы протупите и зададите неверный вопрос, меньше! Но есть и обратная сторона. Одних знаний IT недостаточно. На мой взгляд, гораздо важнее обладать необходимыми коммуникативными навыками, уметь слушать кандидата, правильно задавать вопросы и работать с возникающими возражениями. В то время как в само́й предметной области нужно разбираться на уровне человека, не путающего понятия, понимающего, как строится процесс разработки, какие есть этапы и задачи, какой технологический стек существует, какие технологии для каких задач типичны, а какие — нет. Насколько это глубоко? На мой взгляд, не очень. Но даже базовых знаний вам хватит, чтобы не выглядеть глупо и понимать в диалоге, о чем идет речь.
Скажем, когда вы видите в вакансии фронтенд-разработчика такой язык программирования, как C++, у вас должен возникнуть вопрос: а почему этот язык указан, какие конкретно задачи кандидату нужно будет на нем выполнять? Скорее всего, реальных ежедневных задач, связанных с С++, у кандидата не будет, но вам должно быть важно разобраться, почему эта технология указана в вакансии.
Или, например, в случае, если в вакансии фронтенд-разработчика также указаны бэкенд-технологии, важно понять: они указаны, потому что на самом деле нам нужен фуллстек-разработчик, который будет выполнять задачи и на бэкенде, или они просто добавлены в качестве информации о том, на каком технологическом стеке выполнен проект.
А при варианте, что в резюме кандидата присутствует такая технология, как ASP.NET, вы должны понимать, что он работал над веб-, а не десктоп-проектами.
Все это не фундаментальные знания, а довольно поверхностные, но они позволят избежать базовых ошибок.
Во-вторых, как я уже и писал выше, рекрутеру необходимо обладать достаточными коммуникационными навыками. Это огромная тема, которой можно посвятить отдельную книгу. Если попытаться в двух словах рассказать, что же я имею в виду, то подойдут эти: нужно уметь правильно задавать вопросы. А вот цели при этом у рекрутера могут быть разными. Чаще всего ему нужно уметь докапываться до истины. Даже в процессе первой коммуникации с кандидатом рекрутеру важно понять, что именно интересно кандидату, что для него важно на новом месте и почему. А в случае, если кандидат не захочет открываться нам и рекрутер будет сталкиваться, как менеджер по продажам, с возражениями, то, конечно, надо будет с этим работать. И, как и менеджеру по продажам, лучше всего в этом помогут опять-таки вопросы.
Давайте посмотрим на довольно типичный диалог рекрутера (Р) и кандидата (К):
На первый взгляд все довольно логично: кандидат ответил общей фразой, рекрутер решил уточнить. Но что происходит на самом деле? Кандидат почему-то отвечает общей фразой, а рекрутер подбрасывает ему варианты. Вместо открытого вопроса (не предполагающего ответа «да» или «нет») рекрутер начинает помогать кандидату. В итоге мы узнаём не то, чего хочет кандидат, а только то, какой вариант из предложенных он выбрал. Согласитесь, это не одно и то же.
В целом же умение задавать вопросы не означает, что рекрутер должен как заведенный спрашивать-спрашивать-спрашивать и игнорировать все реплики кандидата. Конечно, нет. Рекрутер всегда ведет диалог с кандидатом, а диалог не может состоять исключительно из вопросов одного человека: так не построить доверительных отношений между кандидатом и рекрутером. Еще одна из распространенных ошибок рекрутера — молниеносно работать со всеми возражениями, сразу «вываливать» всю информацию и начинать продавать вакансию. Такой формат коммуникаций приводит к результату гораздо реже. В конечном счете рекрутер должен правильно задавать вопросы, уметь слушать и анализировать полученную информацию. А это все уже тесно связано с его навыками оценки soft skills.
В-третьих, рекрутеру необходимо владеть навыками сорсинга[2], то есть поиска кандидатов. Это важнейшая задача, которая может составлять чуть ли не большую часть рабочего времени рекрутера. По факту это просто эффективный поиск на различных ресурсах, но, как показывает практика, обрабатывать ресурсы умеют не очень многие. В то время как на Западе уже давно существует профессия сорсера.
В России тоже стали появляться сорсеры, но их пока мало. У нас часто рассматривают эту позицию как стартовую перед должностью рекрутера, что в корне неверно, потому что этим двум специалистам нужен разный набор компетенций и soft skills.
Трудно сказать, в какой момент эти позиции действительно массово разделятся и должность сорсера станет уважаемой и более распространенной в нашей стране, но мы к этому идем. Тем не менее рекрутеру важно понимать, как происходит сорсинг и где можно искать кандидатов. Ведь сейчас в российских реалиях эффективный рекрутер должен уметь сам сорсить.
Еще одна часто возникающая путаница: а чем сорсер отличается от ресечера? «У нас эти ресечеры еще с нулевых работали!» Давайте и это обсудим. Ресечер — это зачастую стартовая позиция, его задача — заливать кандидатов в воронку. Чаще всего кандидатов берут на job-бордах и путем элементарного обзвона добавляют в базу, передавая рекрутеру тех, кто готов общаться, и назначая им собеседования. Сорсер вроде как формально делает то же самое: находит кандидатов и назначает им собеседования. Вопрос в глубине знаний. Ресечер делает базовую работу, частично снимая нагрузку с рекрутера и перекладывая на себя рутину. Этакий кол-центр от HR. В то время как сорсер занимается довольно сложным поиском, для чего часто приходится делать аналитику рынка, выстраивать стратегию поиска, использовать сложные инструменты, находить холодных (а не только теплых) кандидатов, выстраивать с ними коммуникацию так, чтобы им хотелось работать в компании и вернуться к рассмотрению вакансии в случае, если в момент первого контакта она для него по какой-то причине оказалась неактуальной. Для выполнения этих задач требуются и определенные навыки работы с инструментами поиска, и знание рынка, и это не может быть базовой позицией, так как выполнение задач требует какого-то опыта. В некоторых компаниях, например в KPI, на сорсера навешивают еще и «пополняемость базы», ее реактивацию.
Ну а зачем рекрутеру навыки сорсера? Конечно, для того, чтобы эффективно закрывать вакансии. Так как функция сорсера в компаниях далеко не часто выделена в отдельную, рекрутеру приходится самому и искать кандидатов, и общаться с ними, и собеседовать их, и вести по всему процессу. Если рекрутер не будет уметь искать холодных кандидатов на рынке IT, ему будет очень сложно.
В-четвертых, рекрутеру важно обладать навыками копирайтинга, то есть работы с текстами. Одна из огромнейших проблем современного рынка труда в том, что все вакансии, размещенные на нем, одинаковы. Ладно, возможно, не все, но большинство. При этом количество информации вокруг нас просто колоссальное. И становится особенно важным уметь грамотно излагать свои мысли и оформлять вакансию во что-то читабельное и привлекающее внимание, лишенное воды и общих фраз, но при этом содержащее какую-то мотивацию и призывы к действию, отражающие ценности компании. В общем, задача не из простых. А если вспомнить про нашу целевую аудиторию, то есть айтишников, то все становится еще сложнее: чаще всего рекрутерам очень сложно описать задачи и проект, поэтому вакансии становятся такими же водянистыми, как диплом четверокурсника.
В-пятых, сейчас рекрутер должен знать и различать базовые маркетинговые понятия и метрики, чтобы не только развивать свой бренд и бренд компании, но и чтобы понимать, как устроено сознание современных людей и как правильно работать с соцсетями и мессенджерами, какие вещи допустимы, а какие — верный путь в бан. Конечно, проще об этом не думать и надеяться на то, что в вашей компании будет маркетолог, способный решать все эти задачи. А если нет? Да ладно, и так постараемся обойтись… Или нет?.. Я полагаю, что да. Вопрос лишь в вашей успешности. Можно и без этих знаний быть успешными; с другой же стороны, обладая ими, вы уменьшаете степень неопределенности и не полагаетесь на удачу.
Кажется, посмотрев на этот список, можно подумать, что таких людей не бывает. Да, таких рекрутеров действительно не очень много, зачастую они обладают всего двумя или даже одним из пяти пунктов. Но те, кто владеет всеми пятью компетенциями, становятся не только суперэффективными сотрудниками, но еще и лидерами мнений в HR-сообществе. А потому… плох тот солдат, который не мечтает стать генералом. В случае же с современным рынком труда… у солдата, кажется, просто не остается выбора, потому что чем дальше, тем больше навыков понадобится рекрутеру и тем сложнее ему будет выполнять свою работу и котироваться на рынке труда.
Кстати, в определенный момент на рынке появилась тенденция учить рекрутеров программированию. Должен сознаться: я не понимаю, зачем это нужно. С одной стороны — да, это поможет рекрутерам чуть лучше понимать предметную область IT. Но в то же время прокачка этих скиллов будет отнимать довольно много времени, в то время как практически применять навыки программирования рекрутеру вряд ли придется. Ведь большинство задач, для реализации которых может понадобиться программирование, на самом деле можно реализовать и с помощью существующих решений: различных сервисов, чат-ботов и расширений для Chrome. Ну и в конце концов, давайте по-честному: да, учиться программированию можно, но это сугубо техническая задача, которая не всем под силу и может вызвать отторжение. А так как прямой острой необходимости в этом нет, то и зачем тогда?
На мой взгляд, обучение рекрутеров программированию — не более чем хайп и желание заработать денег, которое, в общем-то, неплохо удовлетворяется.
Подводя итог этой главы, хочу лишь сказать, что рекрутер — это уже не просто человек, который может позвонить кандидату с hh.ru и пригласить его на собеседование. Рекрутер — сложная профессия, требующая большого количества скиллов. Это, конечно, немного усложняет нашу с вами повседневную жизнь, но в то же время делает ее безумно интересной.
Итак, давайте представим себе ситуацию, что вы уже работаете в компании или в кадровом агентстве, и вот вам прилетает заветная вакансия — та самая, которая покажет, на что вы способны, и позволит вам реализовать себя. Или обратная сторона Луны: вы уже давно занимаетесь IT-рекрутментом, и процесс работы с появившимися вакансиями для вас прост, понятен, а главное — привычен. Что же будет происходить дальше? Дальше чаще всего происходит встреча с заказчиком, на которой вы обсуждаете детали вакансии и пытаетесь прояснить профиль кандидата. На этом моменте хотелось бы остановиться подробнее.
Встреча с заказчиком и определение профиля кандидата, или, как это часто называют, «снятие заявки»,[3] — ответственнейший момент, который во многом будет определять, как работа сложится дальше. Не стоит недооценивать его важность. Облажаться на данном этапе — все равно что споткнуться и упасть в начале забега: догнать остальных еще есть шанс, но усилий для этого придется потратить в разы больше. И самое парадоксальное то, что многие рекрутеры к этому процессу не готовятся. На самом деле для того, чтобы этот этап прошел хорошо, важно обладать теми самыми коммуникативными навыками, о которых мы говорили вначале. Умение вести переговоры — одно из ключевых для рекрутера. Но зачастую их успешность зависит от этапа подготовки к ним. Чем лучше подготовка, тем меньше сюрпризов на самих переговорах. В то же время чем больше информации мы соберем на старте, тем точнее будут наши вопросы, тем правильнее мы составим профиль кандидата и тем лучше будем понимать, кого же мы ищем, а значит, и где нам его искать.
Важно отличать также инхаус-рекрутера, то есть работающего внутри компании и нанимающего для нее персонал, от рекрутера из агентства: первый знает о вакансии и проекте гораздо больше, чем второй. Понятно, что рекрутер из агентства должен перед встречей почитать и погуглить больше информации.
Поэтому, перед тем как идти на встречу с заказчиком, я настоятельно рекомендую вам обратить внимание на следующие нюансы.
● Чем занимается компания. Важно понимать сферу деятельности, потому что она может накладывать определенные «отягчающие обстоятельства» на поиск. Например, если компания работает в сфере беттинга или микрофинансов, большинство кандидатов отказываются от вакансии именно из-за сферы, с которой не хотят связываться. Какие у компании планы? Возможно, они писали об этом в блоге — и вы сможете лучше понимать перспективы позиции.
● О каком проекте идет речь, какой у него сейчас статус. Внутри компании может быть несколько проектов на разных стадиях развития, и в зависимости от проекта могут быть как разные условия труда, так и просто разные задачи. Эта информация также поможет вам лучше понять текущие обстоятельства в компании.
● Посмотреть, где компания уже размещала вакансию. В зависимости от количества обработанных ресурсов вы можете понять, насколько тщательно ведется поиск по вакансии и в какие каналы вам стоит идти в первую очередь. А еще, проверив те же мессенджеры, вы сможете узнать о репутации компании и о том, что о ней говорят в профильном сообществе.
● Узнать немного лучше личность человека, с которым вы будете общаться. Для этого полезно изучить его соцсети, посмотреть, что он пишет и как. Или же не пишет вовсе. Эта информация поможет вам лучше говорить с человеком «на одном языке».
● Изучить текст присланной вакансии. Да, все заявки обычно плюс-минус похожи, и выжать какой-то текст от заказчика тоже бывает непросто. Но очень важно, чтобы он эту предварительную работу проделал. Нет ничего хуже, чем объяснение вакансии в коридоре, между кухней и переговоркой. Поэтому сначала заказчик должен сформулировать свои мысли, а уже потом вы со своей стороны должны прочитать вакансию и подготовить вопросы по ней. А встретившись, вы проверите, насколько ваши «представления о прекрасном» совпадают. Обращайте внимание на все неточности, неясности и прочие нюансы. Особенно если в вакансии указан огромный перечень требуемых технологий. Зачастую реально работать нужно с гораздо более скромным их количеством.
Даже если вы инхаус-рекрутер, полезно освежить в памяти, что сейчас происходит с проектом и с кем вам предстоит общаться. В конце концов, правда заключается в том, что не все заказчики приятные. Иногда это бывают конфликтные, истеричные, инфантильные люди. И очень важно, отправляясь на встречу с кем-то из таких персонажей, понимать, кто перед вами и как с ним строить общение. Одному вопрос в лоб относительно того, что кандидатов с набором всех требований в природе не существует, будет казаться нормальным аргументом. А для другого это будет красной тряпкой, на которую он набросится и сразу скажет: «Мне по барабану. Найди».
Итак, предварительная работа проделана: статус проекта понятен, заказчик изучен, вакансия испещрена комментариями и вопросами. Что дальше? Дальше — сама встреча. Основная ваша задача на ней — понять правильный профиль кандидата, которого вы будете искать. И очень важно, чтобы в этом вопросе заказчик вам помогал и был с вами на одной стороне. Хотя иногда его и нужно возвращать к реальности. Но сначала предлагаю разобраться с тем, какие вопросы по вакансии вы можете задать.
Я бы условно поделил их на несколько групп.
Первая — вопросы о компании. Это те вопросы, на которые вы уже частично могли получить ответы в интернете и задавая которые вы будете сверять соответствие загугленного действительности.
● Чем занимается компания?
● Сколько в ней человек, какая структура и география?
● Какие планы по развитию на текущий год?
● Кто основные конкуренты, есть ли среди них компании-доноры (то есть те, в которых можно будет искать людей на вакансию)?
● Почему сотрудники в принципе выбирают эту компанию?
● Почему клиенты ее выбирают?
Вторая группа — вопросы о проекте. По факту они очень тесно связаны с вопросами о компании и как бы вытекают из них.
● На какой проект ищут человека, на какой стадии сейчас проект?
● Сколько человек на проекте?
● Сколько человек в команде, в которую ищем кандидата?
● Какая методология разработки? Если гибкая, то насколько Scrum[4] (или не Scrum) чистый, какие элементы внедрены?
● От кого поступают задачи?
● Есть ли code review[5] (для разработчиков)?
● Есть ли система контроля версий (СКВ)[6], какая? (Скорее всего, это будет видно в описании вакансии, самые популярные СКВ — Git, SVN, Mercurial, TFS.)
● Как часто бывают релизы[7]?
Третья группа вопросов — самая важная и самая сложная для рекрутеров, потому что это вопросы о задачах. Сложно это для нас потому, что мы далеко не всегда можем реально понять, что означают те или иные задачи. Да и тимлиды, и IT-специалисты не всегда подробно их формулируют и часто ограничиваются довольно сухими примерами. Очень важно понять реальные задачи, чтобы впоследствии включить их в описание вакансии и сделать его наиболее привлекательным для кандидатов.
● Какие задачи будет выполнять кандидат?
● Какие задачи сейчас есть в бэклоге[8] (если по-простому — в пуле)?
● Назовите пример наиболее сложных задач, с которыми кандидату придется столкнуться и которые теоретически могут стать для него вызовом.
● Представим себе ситуацию, что кандидат сегодня вышел на работу. Какие задачи он получил бы прямо сейчас?
● А через месяц/полгода?
● Зачастую полезно узнать, в каком процентном соотношении и какие задачи будут у кандидата. Например, если мы ищем фронтенд-разработчика[9], важно понять, какой процент его времени будет занимать верстка, так как не все фронтенд-разработчики готовы заниматься ею в каком-то существенном объеме.
По факту всеми этими вопросами мы пытаемся разговорить оппонента и собрать по крупицам информацию, которую сможем добавить в вакансию. Но не стоит пугаться: не все IT-специалисты будут сидеть и отмалчиваться. Большинство из них будут рады услышать от вас такие вопросы, рассказать подробнее о задачах и помочь вам накидать такого смыслового «мяса» в вакансию, чтобы кандидаты на старте лучше понимали, с чем им придется столкнуться.
Четвертая группа вопросов — о технологиях. Еще одна очень важная и сложная группа. Потому что она тоже относится к той сфере знаний, которая дается рекрутерам зачастую довольно-таки сложно.
● Какой текущий стек[10]? Какая архитектура проекта?
● Планируются ли какие-то изменения в стеке? Этот вопрос можно конкретизировать. Например, если в вакансии мобильного разработчика указано знание Objective-C, обязательно стоит уточнить, планируется ли переход на Swift, так как Objective-C — устаревающая технология и специалистов с ней искать будет сложнее и дольше.
● Есть ли на проекте legacy-код[11]? Если да, какой процент задач будет составлять поддержка legacy, а какой — разработка нового функционала?
● Какие из указанных знаний наиболее критичны? Зачастую заказчик указывает в вакансии огромное количество технологий, с которыми в реальности кандидату работать придется не так много. Важно сразу понять, какие технологии наиболее критичны, а какие можно даже не вписывать в поиск, чтобы не сужать себе воронку.
● Важно также обратить внимание на сам стек и на мелочи, которые могут быть указаны в стеке, но существенно усложнят поиск или окажутся нелогичными. Так, если продолжить пример с вакансией мобильного разработчика, в ней может быть указан еще и такой язык программирования, как C++. Это язык, который напрямую не относится к мобильной разработке; важно понимать, для чего его добавили, какие задачи на нем будет выполнять кандидат.
Вообще уже на этом этапе можно предложить нанимающему менеджеру из всех указанных технологий выбрать те, которые должны быть у идеального кандидата; те, которые должны быть у не идеального, но подходящего и, соответственно, у третьей группы — у просто подходящих. Так вы сразу сможете для себя проранжировать необходимые навыки и составить более четкий портрет кандидата.
Пятая группа вопросов — о вакансии. Эта группа посвящена текущему статусу поисков и должна помочь вам на старте прикинуть сложность и узкие места будущего поиска. Кроме того, задавая эти вопросы, мы так или иначе узнаем о важных для заказчика soft skills и о его собственных.
● Почему вакансия открылась? Если вакансия на замену, чем не подошел предыдущий сотрудник?
● Как строится наем в компании сейчас, сколько человек на вакансию успели посмотреть, на каком этапе отваливается наибольшее количество кандидатов и по какой причине?
● Какая обратная связь касательно проекта и компании в целом есть на рынке? С одной стороны, мы об этом уже отчасти спрашивали раньше, но тут немного уточняем наш запрос: иногда о самой компании рынок отзывается не очень, но какого-то конкретного тимлида хвалит.
● Есть ли сейчас в компании люди, которые могли бы выполнить эти задачи? Если есть, почему им не предлагают текущую позицию? Если нет, чего не хватает уже работающим сотрудникам?
● Есть ли пример идеального резюме? Это вообще отличный вопрос, который позволяет вам еще раз сверить ваши «хотелки» и четче понять, совпадают ли ваши с заказчиком взгляды на идеальных кандидатов.
Шестая группа вопросов — об условиях вакансии. Это самая простая и понятная часть для нас, и не нужно прикладывать дополнительных усилий, чтобы в чем-то разобраться.
● Какая вилка зарплаты? Готовы ли рассматривать более высокую? Если найдется идеальный кандидат, но на 10/15/20 тысяч дороже, готовы ли будете обсуждать бюджет? Какие навыки должны быть у специалиста, чтобы готовы были предложить ему зарплату по верхнему пределу? Для рекрутера это еще один триггер, ведь то, как заказчик опишет профиль кандидата, ради которого можно будет идти обсуждать бюджет вакансии или которому можно будет дать максимальную зарплату, обозначит рекрутеру еще раз наиболее критичные и важные для заказчика моменты в вакансии. Иногда оказывается так, что после этого вопроса заказчик отвечает, что максимум в вилке получит только кандидат, реально соответствующий
● Белая зарплата или серая? Ой, нельзя мне такое писать в книгах: это ж может оказаться, что у нас в стране есть серые или даже черные компании. А они есть. Только не рассказывайте государству — оно ж не в курсе. И для кандидатов это может быть критичным моментом, не уточнив который вы потратите свое и их время, а еще можете и на негатив нарваться. Так что да, это важный вопрос.
● Какой соцпакет? Есть ли ДМС? Если да, то что включает? Распространяется ли на семью? Компенсация фитнеса, питания, обучения, проезда, телефона?
● Какой график работы? Если гибкий, что это значит: с которого и по который час можно начинать или заканчивать работу?
● Есть ли возможность работать удаленно? Как часто? Кажется, что в ковидную эпоху на удаленке умеют работать все, ан нет. До сих пор есть компании, не готовые к этому и не желающие давать такую возможность своим сотрудникам.
● Есть ли релокационный пакет? Если да, что включает? Готовы ли в принципе смотреть иногородних кандидатов? А иностранных? С каким гражданством?
● Есть ли парковка около офиса? Корпоративный транспорт, если офис далеко от метро?
● Как бы продавал вакансию кандидату сам заказчик? На чем бы делал акцент? Почему он сам работает в компании и на этом проекте?
Седьмая группа вопросов — о личностных качествах кандидата. В последнее время всё чаще обращают внимание на soft skills кандидата, а потому этому вопросу важно уделить особое внимание. Доходит даже до того, что иногда отдают предпочтение кандидату, более слабому технически, но подходящему именно по soft skills. Но ответы на эти вопросы зачастую косвенно мы получаем во время ответов на предыдущие. Например, когда заказчик рассказывает про сложившуюся команду или про режим работы и большое количество переработок. В таком случае, если у нас уже появилась какая-то гипотеза относительно необходимых кандидату личностных качеств, наша задача — проверить, насколько эта гипотеза верна.
● Какие личностные качества важны?
● Какие люди хорошо приживаются в команде? Почему?
● Какие, наоборот, не приживаются никогда?
Также важно спросить, зачем кандидату понадобятся конкретные софты. Порой в вакансию кочуют просто общие требования вроде «коммуникабельный» на должность, для которой это качество совсем не нужно. Потому старайтесь отслеживать логику между задачами, требованиями к хардам и к софтам.
Конечно, перечень этих вопросов не исчерпывающий. Вопросов может быть существенно больше, а в случае, если вы инхаус-рекрутер, то и меньше. Но этого перечня в большинстве ситуаций достаточно, чтобы правильно понять профиль вакансии и определиться, кого же вам надо будет искать.
Давайте попробуем разобраться на реальном тексте вакансии, который я нашел на hh.ru. Он, конечно, очень лаконичный, но даже в нем есть о чем поговорить.
Обязанности:
Разработка нового функционала.
Требования:
Опыт разработки на JavaScript.
React.js.
Понимание концепции REST, HTTP-запросов.
Желательно:
Опыт верстки с использованием css3, постпроцессоров, LESS, SASS.
Знание библиотек работы с состоянием приложения flux, redux (желательно).
Опыт тестирования компонентов.
Опыт работы с TypeScript.
Знание принципов работы сборщиков Webpack, Gulp.
Итак, давайте приблизительно переведем на более понятный язык то, что мы сейчас прочитали:
● JavaScript (JS) — один из наиболее популярных языков программирования, на котором чаще всего делается пользовательский интерфейс (фронтенд-разработка).
● React.js — JavaScript-библиотека с открытым исходным кодом для разработки пользовательских интерфейсов, облегчает программирование на JS (в следующих главах мы подробно поговорим про то, что это такое).
● REST — это стиль архитектуры программного обеспечения для распределенных систем, отвечает за правила работы с URL-адресами страниц.
● HTTP — это протокол, с помощью которого клиент и сервер обмениваются данными. Например, когда мы нажимаем на кнопку «каталог» на сайте интернет-магазина, с клиентской части в серверную идет запрос, который просит показать необходимые данные.
● css3 — язык описания стилей: с его помощью создатель веб-страницы задает цвета, шрифты, расположение блоков и т. д.
● LESS, SASS — языки, созданные на основе css для реализации тех же целей — оформления веб-страницы.
● Flux, redux — это библиотека для управления состоянием приложений.
● TypeScript — расширенная версия JavaScript, которая позволяет упрощать и ускорять разработку крупных JS-приложений за счет добавления типизации, классов и модулей.
● Webpack, Gulp — инструменты, которые собирают разбросанные по модулям файлы проекта, объединяют в единые файлы в правильном порядке и ужимают их в размере.
Казалось бы, описание достаточно детальное. Но все равно вопросы остаются. Вот только некоторые из них:
● Какой новый функционал нужно будет разрабатывать конкретно? В обязанности входит только новый функционал или поддержка старого? В каком соотношении?
● Какого опыта разработки на JS будет достаточно? Задачи какого уровня кандидат должен уметь решать?
● Насколько критичен опыт с React? Готовы ли смотреть с другими фреймворками? А с нативным JS (то есть без использования фреймворков)?
● Насколько хорошо нужно понимать REST? Кажется, если кандидат с опытом, он априори понимает REST. Какого уровня тогда нам нужен специалист?
● Сам ли он будет верстать или есть верстальщики? Какой процент задач по верстке, какой — по разработке?
● Правильно ли понимаю, что flux — обязательное требование, а redux — опциональное? Готовы ли смотреть кандидатов без redux?
● Надо тестами код покрывать или целиком процесс тестирования проводить? Есть ли тестировщик в команде?
● Насколько критичен опыт с TypeScript? В сравнении с остальными технологиями, что из них важнее, без какой точно не будете смотреть кандидатов?
● Опять-таки возникает вопрос о требуемом уровне специалиста. Кажется, что большинство фронтов с Webpack работали.
На самом деле я просто показал вам, что по каждой строчке вакансии у нас могут быть вопросы — и это нормально. В этом нет ничего страшного, для многих заказчиков такой бриф — хороший знак. Хотя, конечно, в этой вакансии самая большая проблема — в тексте самой вакансии: он пустой и неинформативный. Как видите, я неспроста задавал все эти вопросы. По факту ответы на них помогут мне переписать довольно стандартный и пустой текст во что-то более информативное.
Чем больше опыта у вас будет, тем меньше понадобится приставать к каждому пункту вакансии и появится больше возможностей построить беседу так, чтобы одним вопросом охватить сразу несколько тем. Так, например, в данной вакансии основной вопрос — какого уровня специалиста мы ищем, потому что в тексте много базовых требований, а дальше мы уже могли бы переключиться на вопросы о задачах, команде и четче понять, кто нам нужен.
Очень важным шагом в завершении этих (да и любых) переговоров является закрепление договоренностей, то есть согласование профиля кандидата. После того как вы пообщались с заказчиком, можно прямо на месте уточнить: «Давай резюмируем. Правильно ли я понимаю, что нам нужен такой-то и такой-то кандидат, в идеале обладающий тем-то и тем-то. Но мы готовы также смотреть и тех, кто обладает только несколькими из вышеперечисленных пунктов, верно?»
После того как вы обсудите это устно, очень важно письменно закрепить договоренности и написать в мессенджере или письмом всё, что вы обсудили. И если впоследствии у вас возникнут сложности в работе и заказчик решит «переобуться», как это делают некоторые политики и общественные деятели, вы сможете сказать ему, что договаривались о другом и у вас «все ходы записаны». Делать это нужно не для того, чтобы «становиться в позу» и кому-то что-то доказывать, а для того, чтобы в случае возникновения прений вы могли отстоять свои границы, показать заказчику, что требования меняются и, вероятно, вакансия не закрывается не потому, что вы не сумели кого-то найти, а потому, что требования были не до конца сформулированы. (Если, конечно, это действительно было так.)
Но конфликт не обязательно должен возникнуть. Такое закрепление договоренностей полезно для всех еще и по той причине, что после общения вы сможете самостоятельно обдумать профиль кандидата, у вас могут возникнуть какие-то идеи, мысли и будет очень полезно сверять их с тем профилем, который вы обсудили.
Ну и последний нюанс. Наличие профиля позволяет вам еще раз сверить ожидания: ваши — от предстоящей работы и заказчика — от вас. Порой случается так, что, когда вы скидываете финальный вариант профиля или задаете финальный вопрос, выясняется, что вы друг друга недопоняли и заказчик имел в виду что-то совсем другое. И обсуждение профиля начинается заново.
Помните, что чем точнее вы поймете заказчика на данном этапе, тем эффективнее будет ваша работа.
Еще одна ситуация, с которой вы также можете столкнуться, — заказчик и сам не понимает, кого же он хочет найти. Так часто бывает, если вакансия для компании или для рынка в целом — новая. В такой ситуации я сам оказался однажды: у меня была вакансия человека, каких на рынке не существует. Мы запускали стартап, и нам нужен был специалист с комплексным функционалом — набором навыков, которым ни один среднестатистический существующий специалист не обладает. В попытке расписать все детали и сделать нормальное описание вакансии я записывал всё и вся — и так и не мог понять, что за специалист у меня вырисовывается. Ведь профили очень разные: то ли мне нужен уставший от рекрутмента рекрутер, то ли аккаунт-менеджер из онлайн-школы, обучающей IT, то ли просто аккаунт-менеджер, то ли деврел[12].
В конечном итоге я придумал для себя такое решение — построение небольшой скоринговой модели, которая будет учитывать мои субъективные представления о том, кто нам нужен, и считать риски.
Конечно, это очень примитивная скоринговая модель, которая тем не менее может быть полезной для нас. Она на практике помогла мне осознать, кто же именно мне нужен.
Я сделал себе таблицу, в которой было 4 столбца с предполагаемыми профилями нужных мне кандидатов (рекрутер, аккаунт из IT, просто аккаунт, деврел). В строчки я вписывал отдельно задачи, которые этим людям нужно будет выполнять. Дальше для каждой задачи я выделял удельный вес параметра, который мне казался подходящим (абсолютно субъективный). И для каждой обязанности и каждого профиля ставил оценку. В итоге оценка умножалась на удельный вес параметра, а потом все эти показатели суммировались.
Теперь по-человечески. Допустим, я не могу понять, кто мне нужен — менеджер по продажам или менеджер по поддержке клиентов. Я создаю таблицу.
Под обязанностями я составил список рисков, у каждого из которых также был удельный вес и проставлялись оценки. Вес умножался на оценку, показатели рисков суммировались и вычитались из верхней суммы.
Конечно, какой-нибудь аналитик сказал бы мне, что я чего-то не учел, но даже для моего первичного понимания такая табличка оказалась спасительной. Точно так же можно эту табличку переложить на вакансию и предложить заказчику проставить эти оценки и риски, чтобы ему было легче понять, на каком профиле ему лучше остановиться.
Создание вакансии — один из ключевых процессов в рекрутменте. Хотя, поверьте, я так буду говорить о каждом следующем шаге. Но давайте мыслить логически. Размещение вакансии на работных сайтах и прочих ресурсах — одно из простейших и обязательных действий, которые нам с вами необходимо совершить для того, чтобы закрыть вакансию. Не всегда именно размещенная вакансия приводит к ее закрытию, но все равно именно ваше описание становится базовым КП (коммерческим предложением), которое вы, подобно менеджеру по продажам, будете отправлять своим кандидатам. Ваша вакансия — это продукт, который вы будете предлагать рынку кандидатов. И чем лучше ваш продукт будет описан, чем четче будет структурирована вся информация о его функциях и особенностях, тем больше пользователей заинтересуются вашим продуктом.
Представьте, что вы ищете фильм, который хотите посмотреть сегодня вечером. Есть полноценная масштабная двухчасовая работа, но таких работ очень много. Вам, чтобы принять решение о том, какой именно фильм смотреть, нужно обратить внимание на несколько характеристик. Возможно, при выборе кино приоритетным для вас будет имя режиссера. Возможно, вы будете обращать внимание на актерский состав. Также есть вероятность, что вы посмотрите на рейтинг этого фильма или на наличие у него наград. Наверняка в первую очередь вы прочитаете краткую аннотацию или посмотрите трейлер. И если эта информация будет скучной или абсолютно пустой, неинформативной (уж простите за тавтологию), то есть вероятность, что фильм вы так и не захотите смотреть. Вам придется искать косвенные признаки, которые замотивируют вас выбрать именно это кино: может быть, это будут отзывы либо рекомендации друзей или тот самый актерский состав. В общем, вам понадобится дополнительная мотивация. В случае с вакансией ситуация аналогичная: она может быть распрекрасным, глубоким, чувственным и проникновенным «фильмом», который не оставит равнодушным никого, кто его посмотрит, но если трейлер и аннотация к «фильму» унылые, то людям придется искать дополнительные мотиваторы, чтобы принять решение в пользу именно вашего «кино».
Одна из распространенных ошибок рекрутеров — не работать над описанием вакансии, никак его не редактировать и размещать то, что «прилетело» от заказчика. А прилетает порой очень разное. Но прежде чем понять,
Кстати, если вы испытываете трудности с внедрением HR-изменений в работу команды, попробуйте найти единомышленника из бизнеса, с которым вы сможете что-то внедрить. Он станет «засланным казачком» и будет нативно продвигать идеи. Знаю, что даже в больших IT-компаниях успешным HR-бизнес-партнерам зачастую удается внедрить изменения именно так. Возможно, вы найдете хорошего, заинтересованного представителя бизнеса, который будет активно вовлечен в процесс найма и готов к экспериментам. Вот как раз с него и стоит начать внедрение такого анкетирования, если изначально многие этому сопротивлялись. А после успешной реализации кейса вы сможете «раскатать» это решение на всю компанию. Так что вернемся к табличке.
Любопытно, что на одни и те же вопросы вы и нанимающий менеджер можете ответить по-разному. В процессе ответов на эти вопросы очень важно прийти к общему знаменателю, показать результаты тимлиду, чтобы в очередной раз «сверить часы» и понять, правильно ли вы движетесь в своей работе.
Интересно, кстати, что в этой таблице есть вопрос про то, почему люди работают в компании и почему выбирают оффер. И это — два важных, но разных пункта. Например, человек может работать в команде, потому что тут крутые ребята, а оффер принимает, потому что компания быстрее всех с ним коммуницировала. И это реальный кейс. Одна компания, имея абсолютно среднестатистическую вакансию, в ходе подобного опроса узнала, что ее офферы принимаются за оперативную обратную связь и предложение о работе. Узнав, что их скорость — весомый аргумент для кандидатов, ребята вынесли эту информацию прямо в вакансию! Так что подобные анкетирования, при всей своей кажущейся примитивности, могут открыть какие-то новые идеи для вас и в итоге повлиять на результаты найма.
После того как вы проанализировали аудиторию, у вас складывается более правильный профиль кандидата и вы уже можете
Помните, мы уже предлагали вначале разделить профиль кандидата на три уровня: идеальный; не идеальный, но подходящий; подходящий. После определения ЦА сделать это будет еще проще, а главное — эффективнее. Все три профиля, разумеется, нужно согласовать с заказчиком. И под каждый составить отдельное описание вакансии.
Теперь же давайте вкратце обсудим, что обязательно должно быть в описании вакансии, а чего быть не должно.
Сейчас описания вакансий выглядят преимущественно одинаково. Происходит это по разным причинам, но во многом на это повлияли стандартные форматы вакансий на работных сайтах. В результате и рекрутер, и заказчик часто не думают о своем описании как о «продающем тексте», который должен привлекать аудиторию.
Тема копирайтинга вакансий, как я и говорил, заслуживает отдельной книги, но, на мой взгляд, важно уловить несколько основных моментов.
Прежде всего стоит отказаться от стандартного шаблона «обязанности — требования — условия». Если вы откроете hh.ru и посмотрите на все вакансии, через пять минут вы уже не будете вчитываться в них, потому что большая их часть сделана по этому формату и ваш мозг начнет автоматически «отсеивать лишнее».
Чаще всего описание вакансии начинается с информации о том, кого мы ищем и кто же эти «мы». Первый блок, посвященный компании и профилю человека, очень важен, но не стоит формулировать его так же, как это записано в Уставе организации. Исходите из ценностей компании, вашего продукта и тех вещей, о которых вы узнали на предыдущих этапах.
Откажитесь от «мыканий»: «мы — такие-то…», «мы ждем от вас, что…», «нам бы хотелось, чтобы вы…». Это все очень здорово, что есть эти «мы» и им чего-то хочется. Просто распрекрасно. А чего хочется кандидату? Что важно для него? Какой человек «впишется»? С кем ему придется работать? Если попробовать составить описание вакансии с этой точки зрения, получится совсем другой текст. Он будет настоящим и живым. И скорее всего, именно он привлечет больше кандидатов.
О чем еще стоит упомянуть. Обязательно расскажите о технологическом стеке. Расскажите, с какими технологиями придется работать каждый день. Приведите примеры задач, которые команда решает каждый день, и парочку важных задач и целей, к которым она стремится. Но не общее «мы хотим сделать самый лучший сервис», бла-бла-бла. «Ближайшая задача — построить интеграции с …», «В этом году мы планируем зарелизить новый аналитический модуль, который будет …» — согласитесь, это гораздо конкретнее, чем «создать лучший сервис» и «захватить мир чего-нибудь». Конечно, описать задачи сложнее всего: не всегда разработчики вдаются в детали. Да и рекрутерам их понять бывает непросто: мы ведь не «технари». Но чего точно делать не стоит — так это писать задачи в формате «разработка ПО». Ох, сколько же такого… разнообразия… вы найдете на job-бордах. Но не впадайте в искушение. Это всё от лукавого.
Стек, задачи расписали, а дальше будет круто рассказать о том, как строится процесс распределения задач у вас в компании, откуда они прилетают, насколько большая команда, как часто происходят релизы и каким вообще будет процесс найма — сколько этапов и какие. Кандидату зачастую очень важно знать эти моменты, и, если их в вакансии нет, он все равно о них спросит. Обозначив их в тексте, вы не только «сыграете на опережение», но и заинтересуете кандидата детальным и осмысленным, уважительным подходом к составлению описания вакансии.
И, разумеется, в тексте должна быть информация об условиях, но попробуйте обойтись без зыбких и общих формулировок в стиле «гибкий рабочий график». Гибкий — это с какого времени и по какое? А могу я начать работать в 5 утра? А в 5 вечера? Или то самое пресловутое «оформление по ТК». Это, конечно, важно, но, во-первых, по закону возможно либо так, либо через ГПХ, но это уже несколько другое. Зачем про это писать? Но как же, Егор: ты же сам писал, что у нас в стране есть серые и черные компании? Да, писал. Но это не значит, что надо таким образом обращать внимание на свою «белизну». В последнее время белых компаний все больше. Когда-нибудь мы придем к тому, что даже вопрос такой не будет подниматься (ха-ха). Но клише «оформление по ТК» пишется всеми и не значит ничего: по ТК можно оформить минимальный оклад в 18 тысяч — и с радостью убежать в закат. Серый. В общем, тут нужна конкретика, если уж решили писать: «полностью белый фикс (200–300 к) и квартальные бонусы (до 1 оклада)» — не правда ли, понятнее, чем «оформление по ТК»? Хотя и длиннее, согласен.
И еще один важный нюанс — оформление. К сожалению, большинство вакансий сейчас выглядят как набор списков: вот 8 пунктов обязанностей, вот 10 пунктов требований, вот 15 пунктов условий. Проблема в том, что однообразное оформление текста приводит к тому, что люди его не читают. Они пытаются глазами выцепить самую основную информацию, чтобы сократить время. Старайтесь миксовать небольшие абзацы текста со списками, смотрите за тем, чтобы требования по смыслу не дублировали обязанности (чаще всего требования вообще можно убрать), и обращайте внимание не только на текст, но и на оформление. Тексту тоже нужен воздух!
Вы, наверно, уже все извелись, читая этот раздел, и кричите на книгу: ГДЕ ПРИМЕРЫ?! Понимаю вас, вот они.
Это вакансия от Тани Пичёвой, ex-HRD в Rocket Science. Чувствуется дружелюбный тон общения, указаны основные нюансы, стек, информация о компании, рассказано, почему и за что эту компанию выбирают. Есть акцент на кандидата: «Если в тебе это откликается, пиши». Согласитесь, такая подача гораздо интереснее, ярче и живее, чем стандартно-монотонное бубнение про «мы такие-то и такие-то, ищем программиста, задачи: разработка ПО». И даже условия у Тани прописаны с юмором и жизнью.
Привет, у нас открыта вакансия Java-разработчика уровня middle +/- (вообще всегда, но сейчас — в особенности). Даже если нет открытой вакансии, мы всегда рады backend-разработчикам. Даже если просто познакомиться на будущее. Даже если просто поговорить!
Пиши нам, приходи на кофе, всё обсудим.
Наш основной стек:
Java 8+;
Spring Boot;
PostgreSQL;
JUnit;
Maven, Gradle;
Git;
Docker и Kubemetes.
Из фронтенда сейчас в основном Vue и Angular. Еще есть проекты на Kotim, Spring WebFIux, React, можно поиграться с нейросетями, если хочется.
Rocket Science — команда опытных Java back-end разработчиков. Специализируемся на создании сложных программных продуктов, back-end, кастомные ERP и CRM-системы (в основном для финансовой сферы, но не только). Партнеры ценят нас за стабильные команды, выполнение обещаний и человеческое отношение: СДЭК, Совкомбанк, СМС-Финанс, крупные российские банки под NDA. Это работает не только на партнеров, но и внутри: мы стабильны, проводим регулярные фидбэки 1on1, выполняем обещания и олицетворяем человеческое отношение друг к другу:)
5 аутсорс-проектов (API, backend), на каждом проекте 2–5 человек.
Команда 26 классных ребят (21 разработчик, 2 PM, HR, маркетолог, офис-менеджер), половина из них несколько лет работает вместе.
Команда фигачит с 2011 года, до ребрендинга мы были в составе Improve Group и назывались Improve Intelligence.
API покрываем Е2Е тестами, пробуем новое, шарим знания на техсредах (внутренний технический митап).
Технически мы ищем Java-разработчиков middle, тут всё понятно. Но хотелось бы найти своего человека, потому что именно люди делают компанию такой, какая она есть.
Если в тебе это откликается, пиши! Было бы здорово, если бы вместе с откликом ты прислал нам ссылку на Git с примерами твоего кода, чтобы мы смогли подготовиться к встрече.
Да, кстати:
Принимаем условия игры в суровом мире и готовы на удаленное сотрудничество.
Оформляем официально с первого дня работы.
После испытательного — ДМС со стоматологией (Новосибирск, Академ, Бердск).
Окна на северо-запад, летом не жарко (третья башня Технопарка в Академгородке). Да и мы не душные:))
Но есть и другой подход к написанию текста вакансии. Но тоже крутой, живой и настоящий. Это подход глубокого погружения в вакансию, чтобы кандидаты узнали максимальное количество информации из самого описания. Это пример, который используют в компании «Хантфлоу».
Хантфлоу — главный инструмент работы рекрутеров в СНГ. Здесь они ведут базу резюме, историю работы, обсуждают резюме с коллегами, переписываются с кандидатами и делают отчеты. В Хантфлоу ведут подбор крупнейшие компании — Mail.Ru Group, Avito, Leroy Merlin, Selectel и многие другие.
Это, возможно, самый сложный сервис, над которым вам придется работать. У нас 400 b2b-клиентов и более 10 000 пользователей — и при этом всего 2 суппорт-инженера. Мы смогли добиться этого благодаря высоким требованиям к качеству кода.
Уже сейчас в Хантфлоу больше 400 rps. Каждую задачу мы решаем, ориентируясь на производительность: любой запрос на бэкенд должен выполняться менее чем за секунду, поэтому запросы к базе необходимо максимально оптимизировать.
Мы не строим систему на «костылях» — Хантфлоу сделан так, чтобы его справочники, формы и другие возможности было легко кастомизировать под клиента на уровне конфигурации.
Уровень сложности повышает и большое число внешних интеграций: с джоб-сайтами, соцсетями, СМС-операторами, телефонией, почтой, календарями и многим другим.
Мы вкладываем много ресурсов в разработку публичного API и webhooks. Благодаря ему клиенты могут делать любые интеграции на базе Хантфлоу — например, с Телеграмом и Слаком. Мы мечтаем, чтобы со временем Хантфлоу стал использовать наше API в качестве бэкенда.
______
ПРОЦЕСС РАБОТЫ В ХАНТФЛОУ
Оба сооснователя Хантфлоу из разработки (дизайнер и программист), поэтому ежедневная работа, от которой не тошно, — наша высшая ценность.
Наш процесс разработки такой: дизайнеры проектируют и описывают функциональность → разработчики декомпозируют и оценивают задачу → начинают разработку → код-ревью → тестирование на отдельном тест-стенде → мердж → релиз.
Мы делаем 3–5 релизов в неделю: не дожидаемся окончания спринта, а мерджим и релизим клиентам фичи сразу же после разработки, ревью и тестирования.
Мы ведем разработку на Гитхабе, а задачи трекаем в Джире. У нас внедрен Cl (TeamCity/Jenkins), который позволяет прогонять независимые тесты для каждой ветки и поднимать тестовый стенд для каждой фичи, не блокируя тестирование соседних фич.
______
С КАКОЙ АРХИТЕКТУРОЙ ПРЕДСТОИТ РАБОТАТЬ?
Хантфлоу — это SAAS. Но для крупных клиентов мы разворачиваем отдельные инстансы — на выделенных серверах в нашем дата-центре или на серверах клиента (on-premise). При этом кодовая база Хантфлоу — общая, а релизы на все инстансы мы делаем практически день в день.
В Хантфлоу микросервисная архитектура: это позволяет нам экспериментировать и использовать тот язык программирования, который лучше всего подходит для задачи. Например, наш сервис нотификаций в браузер написан на Erlang.
______
ИЗ КОГО СОСТОИТ ОТДЕЛ РАЗРАБОТКИ ХАНТФЛОУ
Дизайнеры интерфейсов
Бэкенд-разработчики
Фронтенд-разработчики
Тестировщики
Девопс
Проджект-менеджер
______
КОГО МЫ ИЩЕМ
Опытного в асинхронном программировании питониста, который работал с микросервисами, ORM (pewee), проектировал HTTP REST API.
Того, кто хочет выбирать, как ему работать: в офисе или удаленно из любой точки мира.
Того, кому надоели компромиссы между тем, чтобы сделать хорошо или сделать быстро, — мы всегда делаем хорошо, а сроки обсуждаем совместно с командой.
______
ЧЕМ ПРЕДСТОИТ ЗАНИМАТЬСЯ В ХАНТФЛОУ
Улучшать имеющийся функционал и разрабатывать новый.
Участвовать в принятии архитектурных решений.
Быть инициативным и предлагать свои идеи, в том числе если это касается использования новых технологий.
Проводить code review.
______
ТЕХНОЛОГИЧЕСКИЙ СТЕК
Python 2.7, 3.5+ (сейчас переезжаем с 2.7 на 3.7), Tornado, Aiohttp, PostgreSQL, Elasticsearch, redis, pewee, docker.
ЧТО МЫ ПРЕДЛАГАЕМ
Формат работы — офис в Москве или удаленно. Каждые полгода мы собираем всех в Москве, чтобы вместе потусить.
Полностью белую зарплату.
Свободу влияния на продукт — мы готовы обсуждать любые ваши идеи.
Основатели — дизайнер и разработчик, так что идиотских требований от «бизнеса» и бессмысленных совещаний не будет. Вместо этого — неформальность общения, уважение и открытость.
Оплачиваем сотрудникам конференции и профессиональную литературу.
______
КАК ПРОХОДИТ СОБЕСЕДОВАНИЕ
Мы не верим в тестовые задания, так что вам не нужно будет тратить вечер на решение задач.
20-минутное собеседование с HR Анастасией Василевской.
Собеседование с техническим директором Виталием Глибиным.
Присылайте ваши резюме на почту или в Телеграм.
К такой вакансии практически не остается вопросов, ведь в ней, по сути, перечислено все, что нужно кандидату.
Напоследок хочу попросить вас о том, о чем всегда прошу рекрутеров на своих тренингах. Когда пишете вакансию, обязательно смотрите на нее глазами человека, которому вы ее адресуете. Просто представьте себе вакансию рекрутера, которая выглядит вот так:
Ну как вам? Не правда ли, исчерпывающее описание? Прямо-таки захотелось откликнуться. Встать и пойти. И еще раз откликнуться. А потом трудоустроиться. И жить долго и счастливо.
Приблизительно так выглядят наши вакансии для разработчиков, когда в них нет никакой конкретики. Давайте не будем сами себя подставлять.
Самое важное, о чем мы должны помнить, — на той стороне такие же люди. Да, это айтишники, да, они чуть лучше разбираются в технической части, и большинство из них — не гуманитарии. Им легче читать простой и понятный, не перегруженный текст. А если он еще и конкретный, то вообще роскошь.
Чтобы быть успешным IT-рекрутером, далеко не обязательно быть программистом, но, как я уже писал раньше, важно обладать базовыми знаниями в IT-сфере. Для этого, по моему мнению, необходимо иметь представление о системе разработки ПО: какие этапы она включает в себя, на каких языках осуществляется программирование и чем языки отличаются друг от друга, что такое тестирование, системное администрирование и другие направления деятельности.
В этом разделе мы рассмотрим основы — базис, на который вы сможете опереться в своей работе. Остальные же знания, я уверен, вы приобретете в процессе поиска кандидатов через общение с работодателем, самими кандидатами и с помощью более специфических справочных пособий (много актуального и полезного, например, можно найти на habr.com), которые будут вам необходимы для закрытия той или иной вакансии.
Важное уточнение! Этот раздел написан рекрутером для рекрутеров, поэтому информация упрощена, и если ее будет читать гик, он непременно найдет неточности. Но наша цель — дать базовое понимание основных процессов и терминов.
Для начала давайте кратко разберем, какие типы компаний существуют на рынке IT, то есть каким именно организациям необходимы хорошие IT-специалисты (которых вы, по результатам прочтения этой книги, будете подбирать еще быстрее, увереннее и качественнее).
IT-компании условно можно разделить по следующим типам деятельности:
● продуктовая разработка;
● заказная разработка.
Также существуют компании-вендоры, IT-консалтинг и IT-отделы в организациях, напрямую не связанных с разработкой ПО.
Мы рассмотрим их деятельность с акцентом на то, как их воспринимают кандидаты: какие плюсы и минусы они видят в трудоустройстве в организацию того или иного типа и вида.
Продуктовая/собственная разработка. Компании, занимающиеся этим видом деятельности, разрабатывают и продают свой продукт. Среди классических примеров — всем известные Microsoft, «Лаборатория Касперского», Google, «Яндекс», Cian, Avito и др. Такие организации или развивают один продукт, или реализуют сразу несколько проектов — главное, что все задачи по разработке, маркетингу, исследованию рынков и ценообразованию фирма решает сама.
Можно выделить два подтипа продуктовых компаний:
● создание главного продукта;
● создание продукта, обеспечивающего жизнедеятельность офлайн-бизнеса.
В первом случае компания производит собственный IT-продукт — некий софт, который продается и является основным источником прибыли: операционные системы, онлайн-бухгалтерия, антивирусы и т. д.
Во втором — компания изначально занимается офлайн-бизнесом, например розничными продажами, доставкой товаров, финансовыми операциями, строительством. Ее программные продукты идут не на продажу, а обеспечивают собственные нужды организации: для розничной продажи, например, нужен интернет-магазин, и т. д.
Какие преимущества видят кандидаты в продуктовых компаниях? В первую очередь стабильность и перспективы роста (пусть не быстрого, но планомерного). Однажды устроившись в «Яндекс», можно провести там всю жизнь, постепенно развиваясь в своей специализации или осваивая смежные профессии.
В крупных продуктовых компаниях есть время и средства, чтобы отлаживать бизнес-процессы, повышать квалификацию персонала, обучать и мотивировать сотрудников. Отсюда — комфорт и устойчивое ощущение, что «в Багдаде все спокойно». Но давайте не будем идеализировать большие продуктовые команды: у них достаточно времени, чтобы выстроить процессы, но вы же не думаете, что все компании реально выстраивают процессы? Нет, разумеется. И среди больших продуктовых компаний есть те, которые так и не внедрили изменения, уже считающиеся условной нормой на рынке. Так что тут все всегда зависит от конкретной компании.
С психологической точки зрения для разработчиков такие компании привлекательны тем, что они видят результат своих трудов, а значит, есть чувство моральной удовлетворенности. Часто программисты уходят из заказной разработки в продуктовые фирмы именно по этой причине: «Я хочу гордиться тем, что делаю».
Кроме того, в продуктовых компаниях у сотрудников часто есть больше возможностей влиять на этот продукт, то есть над ними нет заказчика, который просто диктует условия, а сотрудник становится тупым исполнителем.
Но, бесспорно, есть и весомые минусы. Самый главный из них — скука. Порой работа внутри продуктовой компании не отличается разнообразием: программист может несколько лет заниматься одним и тем же продуктом или модулем. Или работать в поддержке старых продуктов: бесконечно «фиксить баги» — исправлять ошибки, разрабатывать дополнительные внутренние инструменты. Такая монотонная деятельность без дополнительных интересных задач может деморализовывать. Ну и в конце концов, если компания крупная, то она может обрасти бюрократией, от которой будут мухи дохнуть.
Заказная разработка — это аутсорсинговые или сервисные организации, которые, как и следует из их названия, разрабатывают программное обеспечение под заказ для других фирм. Компании передают определенные бизнес-процессы или производственные функции на аутсорс, а фирмы-аутсорсеры «продают» им собственных специалистов в качестве рабочей силы. Примеры таких компаний: ICL, SimbirSoft, «ЛАНИТ», «Ай-Теко» и др.
В каких случаях для бизнеса актуален именно такой вид сотрудничества? Есть несколько характерных ситуаций, при которых, как правило, обращаются к аутсорсерам:
● Проверка бизнес-гипотезы. Когда разработчики ПО не уверены, стоит ли вкладываться в новый проект, его минимальную версию (так называемую MVP[14]) заказывают сторонней организации. Это отлично экономит и бюджет, и время. Если по результатам работ идея оказывается актуальной, компания берется за ее реализацию самостоятельно: нанимает продуктовую команду, выстраивает бизнес-процессы, планирует маркетинговую составляющую.
● Разработка уникального решения. Бывают ситуации, когда коробочные (то есть уже существующие) программные продукты не покрывают все потребности компании. Например, порой компании заказывают разработку ERP-системы, потому что существующий коробочный функционал той же 1С их не устраивает, SAP — это очень дорого, а компания считает, что их процессы уникальны. Тогда она решает обратиться к аутсорсеру.
● Разовые или регулярные доработки и усовершенствования существующего продукта, например «затачивание» 1С под нужды того или иного производства. В таком случае зачастую выгоднее обратиться в специализированную фирму, чем нанимать своих разработчиков, так как собственный штат обойдется существенно дороже.
Какие плюсы существуют в аутсорсинговых компаниях? Здесь потенциального сотрудника ждет большое разнообразие проектов, что позволяет быстро повысить свою квалификацию и стать многопрофильным специалистом. У разработчиков нет необходимости думать о конечном пользователе: они ориентируются на ТЗ заказчика, а не на переменчивые вкусы потенциальных покупателей софта.
В этот вид компаний легче войти при наличии небольшого опыта, и, как уже было сказано выше, есть возможность быстро расти по мере увеличения клиентов компании.
Однако большое количество различных задач имеет обратную сторону: нередко разработчики отзываются об аутсорс-компаниях как о конвейерах. Ты меняешь несколько проектов за год, делаешь какую-то «свою» часть работ — и не видишь конечного результата. Это негативно влияет на мотивацию, и многие решаются по этой причине менять работу.
Кроме того, в аутсорсе очень сложно общаться с заказчиком. Далеко не всегда от лица компании с разработчиками коммуницирует технически грамотный специалист, и тогда общение происходит в прямом смысле слова на разных языках — с соответствующими печальными результатами работ. Или же заказчик бывает таким упертым и негибким (или чересчур гибким), что подрядчикам приходится пилить уже неактуальный, но согласованный в ТЗ функционал или регулярно менять курс, не понимая, с чем это связано.
Плюс к этому есть аутсорсинговые компании, которые работают по ТЗ заказчика, поддерживая legacy-код — то есть систему, которая была написана кем-то раньше (возможно, на устаревшем языке программирования). В обиходе программистов такой вид деятельности называется «работой на галерах». Представьте, вы сталкиваетесь с некоей программной сущностью, которую написал кто-то — возможно, не очень талантливый и одаренный — много лет назад. Это своеобразный программный лабиринт, в котором даже сориентироваться не всегда возможно, не говоря уже о том, чтобы поддерживать его в порядке. Поэтому есть компании, которые полностью отказываются от такой деятельности и берутся за разработку только с нуля. В таком случае уровень «страдания на галерах» можно значительно снизить.
Кстати, по-хорошему разработчики должны покрывать свой код документацией, которая объясняет, что делает тот или иной кусок кода. Тогда новому сотруднику будет понятно, что для чего нужно. Но в случае с legacy такой документации зачастую нет. Вместо нее — костыли, то есть временные решения каких-то проблем: изначально хотели сделать всё хорошо и грамотно, но разработка требовала слишком много времени — и от глобальной переделки отказались. Что-то вроде заклеенного изолентой шлема живущего на Марсе Мэтта Деймона в фильме «Марсианин».
Вендор — это компания, разрабатывающая технологии под собственным брендом. На базе их разработок другие организации могут создавать свои продукты. К такому виду компаний относятся Intel, IBM, Oracle, а наиболее известный российский вендор — фирма «1С».
С точки зрения трудоустройства вендоры очень похожи на продуктовые компании: здесь так же стабильно и спокойно, но иногда скучновато.
IT-консалтинг — эти компании занимаются внедрением уже готового программного обеспечения. Организации, не связанные с разработкой ПО, но нуждающиеся в нем для обеспечения своих нужд, нанимают консалтинговые компании, чтобы те выбрали, предоставили и внедрили им коробочные решения для сопровождения бизнес-процессов.
Работа консалтинговой компании состоит из следующих этапов:
● Консультант собирает информацию о том, какие процессы происходят в организации, анализирует их и предлагает то или иное коробочное решение.
● Если в ходе анализа выясняется, что одного типа софта недостаточно, а нужно, например, объединить несколько систем в одну, то к задаче подключаются разработчики.
● И наконец, новая система внедряется: специалисты проверяют ее работоспособность и обучают сотрудников компании пользоваться новым софтом.
Примеры организаций, которые успешно занимаются консалтингом на российском рынке: «ЛАНИТ», «Ай-Теко», «Компьюлинк», «Террасофт», «ЭкоСофт».
В IT-консалтинге есть несколько неоспоримых преимуществ. В частности, финансовая мотивация в этом секторе порой выше среднего. А удовлетворенность работой высокая: вы чувствуете свою сопричастность к развитию крупных, известных компаний — это настоящая помощь, которая не просто оплачивается. За нее искренне благодарят! При хорошем развитии событий, конечно же.
Что же может пойти не так? Консалтинг — это работа с людьми: представители заказчика могут быть некомпетентны в технологических вопросах. Из-за этого возникают разногласия, требования в процессе работы могут многократно меняться, сроки внедрения — откладываться. Это важный стрессообразующий фактор, который не всегда окупается даже самыми высокими зарплатами.
Наверно, важно также отметить, что консалтинг — понятие чуть более широкое, чем заказная разработка, потому что, помимо непосредственно разработки, консалтеры предоставляют инфраструктурные решения. Но четкого разделения на рынке чаще всего нет.
IT-отделы в компаниях. На сегодняшний день практически не осталось организаций, которым не нужны технологии. Поэтому в компаниях, не связанных с производством ПО, стали появляться IT-отделы, а в некоторых случаях даже дочерние IT-компании. Крупные подразделения разработки есть в банках, страховых фирмах, в организациях, занимающихся строительством и продажей недвижимости.
Преимущества работы в таких структурах обычно измеряются финансовой мотивацией, стабильностью компании и брендом работодателя.
Недостатки же похожи на те, с которыми сталкиваются сотрудники продуктовых компаний: однотипные задачи, постоянная доработка существующего софта, бюрократия, регламенты и фиксированный график (не всегда, разумеется, но бывает).
Чаще всего IT-специалисты хотят работать в продуктовых компаниях. Даже если там есть бюрократия и какие-то куски legacy-кода, все же причастности к продукту и возможностей для развития там зачастую больше. Но, безусловно, важно помнить, что все зависит от каждого конкретного человека. Некоторых, например, драйвит и хороший аутсорсер. А потому не делаем выводы за кандидата и задаем вопросы!
Описать всех специалистов в области IT физически невозможно, потому что каждый день, по мере развития технологий и рынка в целом, появляются новые специальности. В этой главе я опишу основные профессии, с которыми рекрутер может столкнуться чаще всего.
Важно помнить, что теория и практика, к сожалению, совпадают далеко не всегда. И любые теоретические правила на практике могут не выдерживать никакой критики. Описание профессий, которые вы найдете ниже, — теоретическое. На практике аналитик в компании может выполнять роль продакт-менеджера, а тот — заниматься разработкой. Бывает всякое! Однако надо же нам от чего-то отталкиваться. Я предлагаю эту систематизацию как базисную, и по мере развития в профессии вы будете ее для себя уточнять.
Аналитики. В сфере IT мы говорим «аналитик», а подразумеваем — «системный аналитик». Хотя существуют еще бизнес-аналитики и аналитики Big Data (о них позже).
Чем же занимается этот специалист? Он прорабатывает сценарии использования будущего продукта, пишет технические задания для разработчиков, тестирует и принимает готовое ПО.
Подключаясь к проекту, аналитик в первую очередь собирает требования к разрабатываемому продукту: каким он должен быть и какие функции выполнять. Происходит это, как правило, с помощью интервью. Аналитик опрашивает заказчиков со стороны клиента, если это заказная разработка, или потенциальных пользователей продукта, если софт планируется продавать.
На основе того, что выяснилось, аналитик составляет техническое задание для разработчиков. Это масштабная, точная, очень дотошная работа — создать такой документ, в котором подробно описано, как система будет работать. Любой упущенный, не оговоренный в документации фактор может легко увести проект с нужного курса. Как говорил доктор Хаус про девочку-пациентку, «если бы в ее ДНК отклонение было на один процент, она была бы дельфином».
После того как ТЗ начинает воплощаться в жизнь, задача аналитика — участвовать в тестировании и прогнозировать возможные ошибки.
Бизнес-аналитики обычно занимаются более верхнеуровневыми задачами, больше коммуницируют с заказчиком, знают предметную область, но не включаются в процесс написания детального ТЗ.
В своей работе аналитики чаще всего используют нотации — специальный софт для создания различных блок-схем и диаграмм. После того как вы отрисовали с помощью нотаций какой-нибудь пользовательский сценарий (как использовать ваше приложение), можете подгрузить его, например, к Jira (система отслеживания ошибок) — и уже там отмечать существующие баги. Это гораздо удобнее, чем объяснять на пальцах.
Среди популярных нотаций можно выделить UML, BPMN, Visio и т. п.
Общаясь с аналитиком, скорее всего, вам нужно будет попросить его показать пример ТЗ или различных схем, которые он сможет показать, чтобы ваш бизнес-заказчик мог оценить, насколько хорошо проработано ТЗ.
Технический писатель — специалист, который занимается составлением документов в рамках разработки продукта. Он описывает функционал продукта по установленным нормам, руководство по эксплуатации для пользователей и многое другое. В некоторых случаях он может заниматься оформлением этой документации: добавлять иллюстрации, видео, анимацию.
На российском рынке не очень много таких специалистов. Продолжение карьерного роста технического писателя — системная аналитика, и если человек вырос в аналитика из писателя, то он часто сам выполняет всю текстовую работу.
Техническому писателю необходимо уметь объяснять сложные вещи простым языком. Для этого, конечно же, нужен навык понимания этих самых сложных вещей. Его цель — докопаться до сути проекта, понять ее и уже только после этого описать.
Помните все эти убогие инструкции? Так вот, часто их делают технические писатели. Теперь понимаете, почему так важен хороший техпис? Ведь он работает не только с пользовательской инструкцией, но и с внутренней документацией.
Project manager (проджект-менеджер — менеджер проекта) и Product manager (продакт-менеджер — менеджер по продукту). Мы подробно разберем эти позиции в отдельной главе, пока же важно отметить, что Project manager в IT обычно занимается «административной» работой. Его задача — успешная реализация проекта в установленные сроки в рамках запланированного бюджета.
Product manager отвечает за продукт в целом. В его функции входят анализ рынка, общение с потенциальными пользователями, ценообразование, позиционирование продукта и много других деталей. Некоторые функции, как вы заметили, пересекаются с работой аналитика, но менеджер по продукту — это все-таки более управленческая позиция.
UI— (user interface) и UX— (user experience) дизайнеры — несмотря на то, что в реальности эти функции выполняет один человек, разница между ними все-таки есть. Хотя в последние годы ситуация, на мой взгляд, улучшается.
Итак, UI-дизайнер занимается только непосредственно дизайном, а UX-специалист больше погружен в аналитическую сторону создания продукта.
То есть UX-специалист, грубо говоря, «главный». Он отвечает за логику интерфейса, компоновку элементов и принципы подачи контента. Это он принимает решение о том, насколько пользователям удобно наличие кнопки именно в этом месте интерфейса или на пару сантиметров левее. UI-дизайнер же творит свои шедевры на основе того, что придумал UX. Таким образом, получается, что UX-дизайнер — это голова, а UI-дизайнер — руки.
Понимаю, что хожу сейчас по тонкому льду и влезаю туда, где могу получить по голове. Не мне говорить, кто главнее, потому я лишь высказываю свою позицию: логика интерфейса крайне важна, потому что каким бы красивым он ни был, если он неудобен — какой в этом смысл?
Разработчик (junior, middle, senior, teamlead). Если вы откроете hh.ru, то увидите там и программистов, и разработчиков, и developers, и software engineers. Все это — разные названия одной профессии. Детально про разработчиков мы поговорим, когда будем разбирать языки программирования.
Пока же важно понять, что разработчик — это человек, который непосредственно пишет код и реализует поставленное ТЗ. Обычно выделяют четыре уровня (грейда) сотрудников:
● junior (начинающий специалист);
● middle (специалист среднего уровня, но так пишут очень редко: звучит это дико; скорее уж middle, или мидл);
● senior (старший/ведущий специалист);
● тимлид (руководитель команды).
Тимлид — руководитель группы сотрудников (это могут быть как разработчики, так и тестировщики или, например, аналитики). В процессе руководства группой разработчиков тимлид также может участвовать в формировании команды, принимать решения по архитектуре ПО или выполнять роль аналитика. По факту тимлид всегда участвует в найме, ведь именно к себе в команду он ищет людей, и ему важно понять, с кем предстоит работать.
Тестировщик. Главная задача этого специалиста — найти в ПО баги (ошибки). Он анализирует работу продукта, ищет слабые места, документирует их и передает разработчикам, чтобы те всё исправили.
Сисадмин. Когда рекрутер ищет системных администраторов, он должен понимать, что они могут выполнять очень много различных задач. Самое простое — «спасение» пользователей от любых проблем, связанных с состоянием компьютеров. Сисадмин участвует в закупках новой техники, следит за ее состоянием и при необходимости чинит, устанавливает операционную систему и новые программы, создает учетные записи. Это самые очевидные для обычного пользователя задачи.
В IT-компании всё сложнее. Здесь системный администратор может, например, заниматься администрированием физических и виртуальных серверов или управлять базами данных.
Мы детально рассмотрим эту профессию в отдельной главе, пока же я призываю вас запомнить: существующее у нас представление о системных администраторах гораздо проще и примитивнее реальных задач, которые они могут выполнять.
IT-директор & CTO. CTO, или Chief Technology Officer, или технический директор в IT-компании — это человек, отвечающий за разработку и развитие всего ПО, которое выпускается. У него в подчинении находятся все технические отделы.
Тогда как IT-директор (CIO), скажем, в небольшой строительной компании — это специалист, отвечающий за IT-инфраструктуру, и в подчинении у него будут, например, два системных администратора.
Единой терминологии, определяющей, кто такой IT-директор, нет, все зависит от контекста. Единственное, что можно уверенно сказать об этой должности, — она управленческая. Не подумайте, что рынок не определился. Просто СТО небольшого продукта в 30 человек и СТО нескольких бизнес-юнитов в Mail.ru — это разные специалисты. И тот и другой обладают технической экспертизой, но первый порой может и к процессу кодинга подключиться, и продуктовые задачки на себя взять, а второй, вероятно, будет больше менеджером.
Специалист по информационной безопасности — человек, который, как и следует из названия должности, отвечает за обеспечение конфиденциальности данных. Он анализирует информационные риски компании и внедряет мероприятия по их предотвращению. Также в его обязанности входит оформление документации по информационной безопасности (различных соглашений по неразглашению конфиденциальной информации и др.).
Разработку программного обеспечения можно сравнить с постройкой дома: на первом этапе необходимо спроектировать будущую постройку, набрать команду строителей и выбрать материалы, из которых они будут строить.
После этого можно начинать создание дома вашей мечты — проект входит в этап строительства. Закладывается фундамент, строятся стены, проводятся внутренние коммуникации и происходит отделка.
В финале вы тестируете все внутренние системы дома, чтобы они работали исправно. Принимаете помещение, документируете всё, что в нем есть, и подписываете акт приемки.
И наконец, происходит внедрение нового продукта в вашу жизнь: в случае с домом вы въезжаете в него, осваиваетесь в новом пространстве и начинаете там счастливо жить.
Разработка ПО происходит по тому же принципу: от проектирования через создание к внедрению и сопровождению. Давайте детально рассмотрим все этапы, которые возникают на каждой ступени развития событий.
1-й этап. Подготовка: сбор и анализ требований. Чтобы понять, какое ПО нам нужно получить в результате, на первой стадии его необходимо детально описать, а также спланировать этапы работ, сроки, ресурсы и стоимость.
Сбор и обработка требований бывает двух типов: внутренняя — для разработки продукта, который та или иная IT-компания собирается самостоятельно выпустить на рынок, или внешняя — когда IT-компания принимает заказ от сторонней организации, которой требуется какой-то программный продукт.
Какие специалисты будут участвовать в работе на этом этапе?
● Product-/Project-менеджеры, как говорилось выше, это специалисты, которые отвечают за административную часть. Повторюсь: проджект-менеджер отвечает за успешное выполнение проекта в установленные сроки и бюджет, а продакт-менеджер — за продукт в целом, от идеи до потенциального развития после выхода. Подробнее о том, как именно осуществляется управление проектом и кто еще будет в нем задействован, мы поговорим в отдельной главе.
● Системный аналитик формирует стандарты разработки, пишет техническое задание программистам, планирует бизнес-процессы. Это специалист, который достаточно точно видит, что мы должны получить в результате разработки, и может структурированно донести это до всех участников процесса. Всю эту стратегию он выстраивает на основе требований, полученных от заказчика (менеджмента компании, которая заказала ПО, или пользователей).
● Аккаунт-менеджер подключается в том случае, если разработка заказная. Он осуществляет общение с клиентом и зачастую выступает своеобразным «переводчиком» между заказчиком и исполнителем.
2-й этап. Проектирование: разработка архитектуры и выбор технологий. На этом этапе принимаются решения, как именно будет строиться наш дом — какие технологии лягут в основу продукта. Эти задачи могут решаться с помощью системного архитектора, тимлида и разработчиков — при участии заказчика. Мы не будем углубляться в технологические подробности, как именно создается архитектура будущего продукта. Важно понимать, что критериев выбора достаточно много, начиная от самой задачи, заканчивая системными ограничениями, — и выбор важно предоставить хорошим специалистам в этой области.
Кроме того, на данном этапе выбирается методология разработки: каскадная (Waterfall) или Agile (Scrum, Kanban). О том, что это такое, мы также поговорим чуть позже.
3-й этап. Создание продукта. Этот этап, в свою очередь, включает в себя несколько частей: непосредственно разработка, тестирование, поддержка, доработка.
Некоторые из этих этапов могут происходить параллельно, некоторые — один за другим, но важно помнить, что каждый из них влияет на все остальные. Именно поэтому они все объединены в один блок.
Разработка продукта, в зависимости от требований, может происходить с помощью следующих специалистов:
● Full-stack-разработчик — это специалист, который разрабатывает и интерфейсы, и внутреннюю логику продукта. Интерфейс — это, грубо говоря, то, что видит пользователь: например, заходя на веб-сайт, мы будем наблюдать разнообразные элементы, которые реагируют на нажатие, или просто мигают, или выскакивают нам навстречу в неожиданный момент. Внутренняя же логика — это код, который скрывается за этим фасадом и обеспечивает внутреннюю работу всей системы: пользователь эту «подводную утробу парохода» не видит. Например, нажав на эту или иную кнопку, мы видим всплывающую форму, но не видим, как это произошло: как система обратилась к базе данных, нашла нужную информацию и показала ее нам. Чаще всего фронтендом и бэкендом занимаются разные люди, но случается и так, что один или несколько универсальных специалистов делают всё.
● Frontend-разработчики — специалисты, которые создают клиентскую часть продукта, то есть то, что мы, пользователи, видим на веб-странице или в приложении.
● Backend-разработчики, соответственно, работают только над внутренней логикой.
В зависимости от задачи — если, например, надо создать только мобильное приложение без сайта, сервиса и прочих надстроек, — в разработке будут принимать участие исключительно мобильные разработчики. Если же требуется desktop-версия продукта, к его созданию надо будет привлечь еще и тех, кто сможет это сделать.
4-й этап. Тестирование — как и следует из названия, на этом этапе проводится детальная проверка системы на работоспособность и соответствие всем предъявляемым требованиям. Оно может быть ручным или автоматизированным, и в обоих случаях в нем принимают участие тестировщики. (О них мы поговорим в отдельной главе.)
5-й этап. Внедрение. Казалось бы, на этом этапе все должно быть просто: ПО готово — внедряем! Однако этот этап включает в себя несколько нюансов, и в некоторых компаниях для его прохождения даже существуют отдельные специалисты. Например, если софт создан по заказу какой-то компании, которая собирается им пользоваться, то специалисты по внедрению должны интегрировать новое ПО в уже существующую систему и обучить пользователей.
Обычно процесс внедрения происходит следующим образом:
1. Документирование информации о софте — написание инструкций, которые помогут пользователям и другим разработчикам эффективно общаться с этой новой «сущностью».
2. Непосредственно внедрение системы: та самая интеграция нового ПО в уже существующее.
3. Анализ состояния ПО в новой инфраструктуре: вдруг что-то работает не так, как задумано.
4. Если ошибки выявлены, то специалист по внедрению привлекает разработчиков, чтобы те всё исправили.
5. Обучение сотрудников новой системе или объяснение конечным пользователям, какие изменения произошли и как это может улучшить их работу.
Внедрение нового ПО — важнейший и во многом стрессовый этап для пользователей. Без грамотного проводника в новые возможности софта такое обновление может стать шок-контентом для всех сотрудников компании. Просто представьте: к вам приходит некто, сообщает, что теперь вместо 1С у вас установлен, скажем, 2С, который вы никогда в глаза не видели, — и гордо удаляется. Ситуация жуткая! На этом этапе пользователям необходима грамотная помощь и регулярное взаимодействие со специалистом.
Последний этап. Поддержка и доработка (если это необходимо). В них будут задействованы специалисты технической поддержки — те самые ребята, которым мы так любим звонить в экстренной ситуации (и слушать успокаивающую музыку, пока они там, за кадром, делают что-то загадочное). В зависимости от продукта, системы или сервиса служба поддержки может ранжироваться до трех линий:
● Первая линия (или HelpDesk) — решают самые простые задачи пользователей: выключите и включите компьютер — заработало? Поздравляю!
● Вторая линия — здесь в работу включаются системные администраторы. Они решают вопросы управления доступом и могут корректировать настройки системы.
● Третья линия — специалисты, решающие сервисные вопросы. Они могут поправить ошибку в коде.
Команда технической поддержки может быть общей или специально выделенной под заказчика (в некоторых случаях специалисты могут даже постоянно работать на территории клиента).
Я привел «усредненный» вариант этапов разработки, характерный больше для каскадных методологий. В зависимости от задачи, а также от выбранной методологии работы этапы могут меняться местами, некоторые — исключаться или заменяться другими. Но в целом, по классической схеме, события должны развиваться в описанной последовательности.
Работая в сфере IT, невозможно не столкнуться с терминами типа Scrum (скрам) и Agile (аджайл/эджайл). Но именно из-за того, что они постоянно на слуху и вроде бы все знают, что это такое, появляется масса недопониманий. Как говорил Марк Твен, «все проблемы не от незнания, а от уверенности в собственном знании». И к пониманию Agile в среде HR-специалистов это относится в полной мере.
Поэтому я предлагаю кратко разобраться, как именно выглядят гибкие методологии разработки ПО, какие их разновидности существуют и чем они отличаются.
И начнем мы, вопреки ожиданиям, с описания «негибкой» системы разработки: как строился процесс создания ПО еще несколько лет назад? С чего, как говорится, все начиналось?
Waterfall, или «Водопад», — традиционный подход к работе над ПО. Для него характерна последовательная разработка: первый этап, второй, третий и т. д. Каждый следующий начинается только после того, как закончился предыдущий.
Преимущество «Водопада» заключается в том, что мы можем более-менее точно рассчитать стоимость разработки и сроки ее завершения.
Основной же минус — при долгосрочном планировании мы рискуем получить на выходе технически и морально устаревший продукт.
Вот как схематически выглядит Waterfall-методология разработки:
В стародавние времена, когда производственные и бизнес-модели не менялись годами, каскадная разработка была вполне оправданна. Сегодня же бизнес не может отдать в разработку глобальную задачу и вернуться за результатом, скажем, через полгода. За это время бизнес-идея может потерять свою актуальность, технологии — измениться, кризис — грянуть (привет, ковид!), биткоин — упасть. Поэтому на смену «Водопаду» пришли так называемые гибкие методологии.
Они позволяют на лету менять требования к продукту, добавлять новые модули и отказываться от ненужных. У каждого типа методологий есть свои особенности, но объединяет их одно: наличие некоторых непродолжительных циклов, где результат предыдущего цикла (итерации) оказывает влияние на планирование следующего.
Agile — это семейство методик и подходов к управлению, которые фокусируют команду на продукте. Во главе угла — нужды и цели клиента. Для этого необходимо упростить оргструктуру и процессы, работать короткими циклами, активно использовать обратную связь. Для достижения этих целей предполагается повышение полномочий и расширение зон ответственности сотрудника.
В 2001 году 17 представителей различных концепций разработки программного обеспечения собрались на горнолыжном курорте в штате Юта и составили Agile-манифест. Этот документ закрепил основные принципы и ценности гибкой разработки. На http://agilemanifesto.org/ его можно прочитать более чем на 50 языках, а также ознакомиться со списком авторов, которые его составили. На русском манифест выглядит следующим образом:
●
●
●
●
У такого подхода к разработке есть множество плюсов, в частности командная работа на основе обратной связи позволяет быстро и небольшими порциями поставлять разработанный функционал. А постоянный анализ и корреляция с требованиями заказчика обеспечивает безопасность — то есть, грубо говоря, мы делаем то, что с большой долей вероятности осчастливит клиента в данный отрезок времени, и делаем это быстро.
Каковы же недостатки? Главный из них заключается в том, что разработка может вестись бесконечно. И от этого может быть больно в прямом и переносном смысле: сотрудники находятся в состоянии постоянного тонуса. Требуется скорость в принятии решений и реализации задуманного, но конечного результата не предвидится. Хотя важно признать, что большинство современных компаний все-таки стремятся к внедрению гибких методологий, ведь они больше отвечают реалиям современного мира.
Как выглядит Agile:
Гибкие методологии требуют развития soft skills у IT-специалистов. Если при каскадной разработке программист имел возможность длительное время работать в одиночку и никто его не трогал, то в условиях аджайла с регулярными планерами, демо и код-ревью ему необходим навык эффективного общения и работы в команде.
Среди плюсов аджайла также можно упомянуть тот факт, что минимизируется разработка «в стол»: небольшие фичи уходят к пользователю сразу после выпуска. Кроме того, постоянная обратная связь о качестве кода обеспечивает быстрый профессиональный рост специалистов.
Однако все эти плюсы могут стать минусами в случае, если разработчик не привык к динамичной работе, болезненно воспринимает обратную связь на свой код и общение с коллегами дается ему нелегко. В таком случае стоит задуматься, подходит ли ему работа в аджайл-команде.
В семейство Agile входят следующие методологии: Scrum (скрам), Kanban (канбан), XP, Scrumban (скрамбан). Каждая из них имеет некоторые особенности, которые важно знать, если вы нанимаете персонал под проект.
Scrum — гибкая структура процессов для небольших команд (обычно до 10 человек), которые разбивают свою работу на промежуточные цели. Эти цели выполняются в рамках временных итераций (спринтов) продолжительностью от одной до трех недель, стандартный спринт идет две недели. В качестве подготовки к нему сперва выбирается список задач из бэклога — своеобразного журнала проекта, в котором указываются задачи по приоритетам и отмечается этап их выполнения.
Команда разработки проводит ежедневные 5–20-минутные митинги (совещания), которые позволяют отслеживать ход проекта, быстро выявлять возникающие проблемы и оперативно на них реагировать.
Kanban — еще одна гибкая методология. Основные принципы канбан были унаследованы от подхода, разработанного на заводе Toyota в 1950-х годах. Особенности этой методики заключаются в том, что разработка визуализирована: разделена на задачи, этапы их выполнения маркируются специальными отметками. Количество работ, производящихся одновременно, ограничено. Измеряется и оптимизируется время на выполнение одной задачи.
Extreme Programming, XP. Если описанные выше методологии применимы не только в разработке ПО, то XP — это подход, созданный специально для IT-бизнеса. Его идея проста: взять лучшие практики из других гибких подходов и довести их до экстремально высокого уровня. Например, в рамках данной методологии используется парное программирование: два разработчика на одной машине пишут одну фичу и регулярно (раз в несколько минут) меняются местами. Когда один пишет код, второй его анализирует.
Здесь возникает вопрос, как соотносятся Agile и Scrum. Мне очень понравился ответ, который я увидел где-то на просторах Facebook: примерно так же, как газировка и кока-кола.
Важно понимать, что далеко не во всех компаниях внедрен чистый Scrum или Kanban. Зачастую компания пишет, что работает по скраму, когда у них тупо итерационная разработка, а все прочие условия скрама не соблюдены. Кроме того, на рынке появляются всякие гибридные варианты, которые создают компании. Тот же Сберджайл, например (думаю, не стоит объяснять, в какой компании он применяется, да?).
Развитие гибких систем разработки привело к появлению таких специалистов, как, например, Agile Coach (аджайл-коуч) и Scrum Master (скрам-мастер). Они знают, как создавать, запускать и выстраивать процесс гибкой разработки. Причем их функционал в основном не технический: их сильная сторона — soft skills, за счет чего они становятся одновременно и преподавателями (обучают технологии гибкой разработки), и фасилитаторами (облегчают общение внутри команды), и специалистами по устранению системных препятствий на пути к реализации и продвижению продукта, и выполняют много других функций, благодаря чему проект «едет» в соответствии с принципами Scrum или Agile.
Общаясь с кандидатом и спрашивая у него про методологию, вполне логично поинтересоваться, чистый ли скрам, например, был у них в компании и какие его элементы были внедрены, кто был скрам-мастером. Важно понимать, что количество людей в команде скрам-мастера тоже должно быть ограничено (в канонической версии), а значит, если кандидат говорит о том, что у них все канонично, но один скрам-мастер на 300 человек, он не до конца прав.
Итак, мы разобрали методологии, по которым разрабатывается продукт. Есть те, кто будет следить за соблюдением канонического скрама, но есть ведь и те, кто будет непосредственно управлять процессами, да? Давайте рассмотрим тему, которая вызывает много сложностей у рекрутеров: Product— и Project-менеджеры. Чтобы понять суть этих специальностей, давайте определимся с разницей между проектом и продуктом.
Продукт — это конечный результат, который предоставляется пользователям или клиентам. Продуктом может быть готовый софт, сервис, приложение и т. д.
Проект — это конкретный план, состоящий из разных частей. Все активности внутри него имеют определенный результат и фиксированные даты начала и окончания.
Например, продукт — это новое мобильное приложение для инвестиций. Его разработка будет предполагать множество проектов. Один из них, например, — запуск сайта. У этого проекта есть свои начальные и конечные точки исполнения.
При сравнении этих двух понятий становится очевидно, что у менеджеров продукта и проекта абсолютно различные функции и обязанности.
Product manager, или менеджер продукта, отвечает за успех продукта в целом. Определяет стратегию и тактику его создания и доработки. Его основная задача — делать все возможное для постоянного совершенствования продукта на каждой стадии его жизненного цикла.
Соответственно, Product-менеджеру понадобятся такие универсальные навыки, как стратегическое мышление, эффективное управление приоритетами и понимание пользовательских требований.
Именно Product-менеджер собирает требования к продукту (или работает в этом вопросе в паре с аналитиком), распределяет задачи в бэклоге и принимает стратегические решения по продукту (какую фичу мы будем делать, а какую нет).
Для работодателя, который ищет кандидата на эту позицию, может быть важно, чтобы у того был аналогичный опыт работы, например, в b2b— или b2c-сфере. Также Product-менеджер может иметь в «анамнезе» позицию UI/UX-дизайнера или, возможно, даже разработчика (это реже).
Ну и конечно, Product-менеджер часто отвечает за финансовые показатели продукта, за различные финансовые цели: как количество пользователей продукта вырастет на такой-то процент, как увеличить прибыль по тому или иному каналу.
На job-бордах также можно встретить Product marketing manager. Это как раз те, кто занимался маркетинговым позиционированием продукта. Частично функционал с обычными продакт-менеджерами у них может быть схожим, но это все-таки люди, которые заточены на продвижение продуктов.
Project manager, или менеджер проекта (PM — читать «ПиЭм»), — это специалист, который фокусируется на процессе реализации проекта. Он координирует команды и отвечает за сроки. Его задача — разбить проект на задачи, оценить существующие ресурсы и ограничения и, исходя из этих знаний, спланировать все активности по проекту. То есть определить, кто что делает, выставить адекватные сроки и скоординировать команду так, чтобы она работала максимально эффективно.
Его главная цель — воплотить идею заказчика в установленный срок, используя существующие ресурсы.
Как видите, Product-менеджер должен обладать бо́льшим набором навыков, чем Project-менеджер. Первый из них более глубоко погружен в разработку самого продукта, он имеет влияние на его развитие, принимает бизнес-решения и вовлекает маркетинг. А второй отвечает за то, чтобы проект достиг своей цели, и выполняет административные функции.
В российском бизнесе встречаются разные ситуации. Иногда эти позиции смешаны, иногда разделены (в последнее время, к счастью, все чаще).
Кроме того, в гибких подходах к разработке (Agile) чаще всего нет места Project-менеджеру: эта специальность в большей степени относится к каскадной разработке. А как раз роль Product-менеджера характерна для гибких подходов. Хотя, опять-таки, все зависит от каждого конкретного случая. Наш рынок, к сожалению, сложно грести под одну гребенку и жестко структурировать, поэтому на нем порой появляются очень странные детеныши разных подходов.
Product owner, или владелец продукта, — еще одна руководящая должность, пришедшая из скрама. Этот специалист отвечает за продукт на уровне команды. Его цель — донести до нее видение продукта целиком, ответить на все «почему?», «зачем?» и «как?», прописать пользовательские истории, приоритезировать и почистить бэклог.
Это очень важная роль, которая будет исполняться в тесном тандеме с Product-менеджерами с одной стороны и командой разработки — с другой. Владельцу продукта может быть делегировано «представительство продукта» перед разработчиками, в то время как Product-менеджер и его команда сосредоточатся на стратегии и проработке видения продукта.
Общаясь с кандидатами-продактами, нам, конечно, стоит обратить внимание на то, какое видение продукта было определено, какие метрики считались, какие гипотезы выстраивались, что получилось, что нет, каких результатов добились, за какую часть продукта отвечал продакт (или за продукт целиком), на каком этапе пришел, запускал ли продукты с нуля.
А у проджекта полезно спросить про то, как строились процессы, участвовал ли он в найме сотрудников, приходилось ли увольнять, четко ли соблюдались сроки, как решались конфликтные ситуации, отвечал ли он за бюджет, случались ли случаи перебюджета и почему.
Как мы уже определили в предыдущих главах, разработчики (девелоперы, программисты) — это люди, которые пишут код. И делают они это на разных языках. Чтобы заниматься рекрутментом разработчиков, необходимо хотя бы в общих чертах понимать, чем языки отличаются друг от друга и для каких целей используются.
Разные источники утверждают, что сегодня в мире существует от 1000 до 10 000 языков программирования. Такой разброс связан с тем, что пока нет договоренности, какие языки могут считаться самостоятельными, а какие «диалектами», то есть разновидностями других языков. В любом случае мы не будем рассматривать их все, а остановимся на самых востребованных.
Чтобы условно систематизировать языки программирования, давайте вспомним, что существует бэкенд— и фронтенд-разработка. Бэкенд — это программирование внутренней логики продукта, тогда как фронтенд, наоборот, — создание той части софта, которую видит пользователь.
В зависимости от задач самыми популярными языками для бэкенд-разработки можно назвать Java (читать «джава», но разработчики говорят и «жава», и даже «ява»), C++ («си плюс-плюс» или попросту «плюсы»), С# («си шарп»), Python («питон» или «пайтон»), PHP («пэхэпэ» или даже «пыха») — и это, конечно же, далеко не полный список. Для фронтенда же чаще всего используются JavaScript («джава скрипт»). Но есть исключения, когда JS используется на бэке, а именно платформа node.js.
В мою задачу не входит детально разобрать, какой язык для каких целей лучше подходит, — IT-специалисты могут спорить об этом годами и, как вы можете предположить, далеко не всегда приходят к общему мнению. Я опишу языки программирования для того, чтобы у вас было общее представление о том, что это такое, какие внутренние особенности у них есть и как выстроить диалог с кандидатом, чтобы понять, насколько он вам подходит.
Итак, какими языками чаще всего пользуются бэкенд-разработчики? Для начала вспомним, что языки условно разделены на три типа: высокого уровня, среднего и низкого. Высокоуровневые языки созданы с расчетом на то, что их будут понимать люди: например, в некоторых С-подобных языках или на Python команды выглядят как вполне понятные английские фразы. Таким образом, языки высокого уровня более дружественны к программисту — их проще выучить. Тогда как языки среднего и низкого уровня более дружественны машинам, а нам понятны совсем чуть-чуть. Зачем же они нужны?
Среднеуровневые языки служат связующим звеном между аппаратной и программной частью компьютера, а низкоуровневые — это, по сути, инструкции для конкретной архитектуры компьютера, они удовлетворяют нужды «железа». Соответственно, высокоуровневые языки работают, условно говоря, на любом «железе»: в какую бы среду вы ни поместили программу, написанную на языке высокого уровня, она будет работать одинаково. Низкоуровневые же, наоборот, машинозависимы: при переносе с одной архитектуры компьютера на другую код перестает работать.
С («си») и C-подобные языки. По данным TIOBE Index в 2020 году язык C занимал первое место по популярности в мире. В 2022-м же он стоит на 2-й строчке. Его можно назвать родоначальником языков высокого уровня, тогда как сам он является низкоуровневым. Отчасти благодаря ему компьютерные программы перестали быть инструментом ученых, а вышли из университетов к нам, простым пользователям.
Когда появились первые ЭВМ, разработчики писали код не на читабельном языке программирования. До создания языков высокого уровня были перфокарты — картонки с дырочками, позже появился бинарный код — нули и единицы.
По сути, машины и сейчас «понимают» только нули и единицы, но разработчик создает код не в бинарном формате: он пишет конструкции, приближенные к естественной речи, а автоматические компиляторы и интерпретаторы переводят его волеизъявление в машинный код.
Проблема первых программистов была не только в сложности создания бинарного кода, но и в том, что программы были не универсальны. Например, одна и та же игра могла прекрасно работать на одном компьютере, но совершенно не запускаться на ЭВМ с другой архитектурой.
В 1972 году случилось то, что решило обе эти проблемы: американец Деннис Ритчи, работавший в корпорации AT&T, создал язык программирования C. Это был один из первых языков, в котором использовались «человеческие» слова, и при этом программы стало можно переносить с одного компьютера на другой.
Язык С стал основой для высокоуровневых C++, C#, Java, PHP.
Где применяется старый добрый С сейчас? Будучи созданным как язык системного программирования, он по сей день используется в создании операционных систем, драйверов, загрузчиков и утилит. В задачи языка входит написание максимально быстрого и близкого к «железу» кода, поэтому разработчики, работающие на C, должны быть хорошо знакомы с архитектурой ЭВМ.
В С значительно меньше готовых решений, фреймворков и библиотек: многое разработчик делает с нуля. Архаично, но красиво!
Общаясь с разработчиком С, есть смысл спросить его, с каким «железом» он работал. Зачастую они работают с микропроцессорами определенной архитектуры (самые популярные — ARM, AVR). Приходилось ли писать драйвера? Можно спросить, какая операционная система была на устройстве: Linux, или unix-подобные, или какие-то операционные системы реального времени (RTOS).
С++ — язык-наследник, развившийся на базе С, был представлен в 1985 году и развивается по сей день (хотя и не так активно, как Python, Kotlin, Go и др.).
На С++ создают игровые движки, прикладные десктопные программы, драйверы устройств и приложений для встраиваемых систем высокопроизводительных серверов.
Чтобы упростить программирование на C++, существуют специальные библиотеки и фреймворки.
Что сказать о плюсах этого языка? Среди его достоинств — высокая производительность и поддержка самых разных стилей программирования. Однако он настолько сложен, имеет такой объемный синтаксис и множество ответвлений, что даже опытные си-плюс-плюс-разработчики не могут утверждать, что знают этот язык хотя бы на 80 %.
Важно, что эти разработчики могут использовать различные библиотеки (по сути, то же самое, что и фреймворки), которые помогают им писать код. Среди популярных библиотек можно выделить:
●
●
●
●
●
С#
Говоря о C#, чаще всего подразумевается. NET — программная платформа, также выпущенная компанией Microsoft и включающая в себя множество технологий и инструментов для разработки различных программных продуктов, от веб-сервисов до мобильных приложений.
Для рекрутера важно понимать, что если в вакансии написано. NET, то, скорее всего, речь идет о десктопной версии софта. Если же написано ASP.NET, то речь о веб-сервисе.
Кроме того, на шарпе раньше можно было писать только под винду (Windows) — это было существенным ограничением языка, а найти специалистов, которые делали что-то под Linux на C#, было просто нереально. В последние годы ситуация поменялась, и шарп начал двигаться в сторону кросс-платформенности, то есть совместимости с различными операционными системами.
Java — согласно рейтингу TIOBE, третий по популярности язык программирования в 2022 году. Он давно занимает лидирующие позиции, но в последние годы Python его обогнал. Java считается одним из самых безопасных языков программирования, поэтому большинство банковских и страховых систем написаны именно на нем.
Вероятнее всего, вы уже отлично это запомнили, но все же повторю: не стоит путать Java и JavaScript! Невер!
Что же пишут на Java? Можно сказать, всё! Как шутят разработчики, он есть в каждой кофемашине и холодильнике (кстати, изначально он разрабатывался действительно для бытовых приборов).
Вот несколько известных проектов, где велика доля Java-кода: eBay, Amazon, LinkedIn, Google, Twitter, Facebook.
По данным компании Oracle, в мире более 3 млрд устройств работают на Java. На сегодняшний день по миру насчитывается около 12 млн Java-разработчиков, и их число постоянно растет. По данным платформы AmazingHiring, в России на Java программируют 81,5 тысячи специалистов.
Этот язык программирования прочно занял свои позиции в разработке под Android, веб-продуктов и в сфере Enterprise, поэтому спрос на Java-девелоперов на российском рынке сложно переоценить.
Чтобы заниматься рекрутментом в этой сфере, важно помнить, что Java предоставляет разработчикам несколько платформ (фреймворков), которые облегчают разработку и запуск написанных программ. Различные платформы ориентированы на создание разных приложений для разного типа устройств. Вот некоторые из них:
●
●
●
Немного пугающих аббревиатур: в резюме Java SE и EE могут быть написаны как j2se и j2ee соответственно. Выглядит жутковато, но стоит их запомнить. Зная различные способы написания версий Java в запросе при сорсинге, вы сможете за счет таких трюков увеличить выдачу кандидатов.
●
●
Это далеко не полный список фреймворков: например, помимо описанного выше Spring, существует Spring Boot, который немного упрощает работу самого Spring. Для реализации веб-проектов существуют Blade или GWT (Google Web Toolkit). Но я уверен: понимая, что такое фреймворк, чем он полезен разработчику и в чем теоретические отличия разных фреймворков, даже при нахождении незнакомых названий в вакансиях вы сможете быстро их нагуглить и сориентироваться, кто именно вам нужен.
Python — один из немного языков со своей философией «The Zen of Python» и, наверное, с самой обширной областью применения. Кстати, по рейтингу все того же TIOBE Index, как раз Python — самый распространенный язык программирования в мире. Он используется и в анализе данных, и в системном администрировании, и в разработке сайтов, и в машинном обучении, и даже в создании искусственного интеллекта. При этом область его применения постоянно растет. По последним данным, он уступает по популярности только Java, С и С++.
Сообщество разработчиков на Python считается одним из самых активных, именно благодаря их работе язык активно развивается. На сегодня есть две основные ветки: Python 2.x и Python 3.x.
И да, Python назван не в честь пресмыкающегося, а по названию популярной британской юмористической телепередачи Monty Python's Flying Circus (Летающий цирк Монти Пайтона).
В web Python чаще всего используется для клиент-серверных веб-приложений. Наиболее популярные фреймворки:
●
●
●
Системные администраторы часто пишут на Python сервисные приложения, например, чтобы легко осуществлять открытие файлов, поиск по каталогам, запуск сторонних программ и т. д.
Python также полезен для аналитиков и Data Scientist. Один из самых популярных инструментов этого направления — расширение NumPy, содержащее возможности для работы с большими массивами данных, интерфейсами уравнений и т. д.
Go (или Goland) — язык с достаточно низким порогом входа для новичков, разработанный внутри компании Google для решения проблем на высоконагруженных сервисах. По мнению его разработчиков, язык Go — это попытка создать альтернативу постепенно устаревающим С и С++: за последние годы компьютерные технологии изменились, и они требуют новых решений. Язык был впервые представлен общественности в 2009 году и за последнее десятилетие поднялся в рейтинге TIOBE с 65-го места на 13-е.
Зачастую на Go переходят PHP-разработчики. Кстати, о них.
PHP («пэхэпэ») — язык для разработки веб-приложений. Многие старые сайты написаны на PHP. Например, такие проекты, как YouDo или VK. У PHP есть разные версии, поэтому у разработчика стоит спрашивать, с какой версией он работал. А еще у PHP много фреймворков, например Laravel, Zend, Yii, Symfony. О том, писал ли разработчик на нативном PHP или использовал какие-то фреймворки, тоже стоит уточнить.
Еще один из универсальных вопросов для бэкенд-разработчиков — о нагрузке на проект. Так как бэкенд — та часть проекта, которую мы с вами не видим, именно она зачастую обрабатывает все наши запросы и определяет, насколько быстро мы получим то, что нам нужно.
Переходим к фронтенд-разработке — той части работы программиста, которая затрагивает создание пользовательского интерфейса.
Разработка frontend-части состоит из HTML, CSS и JavaScript (естественно, как было сказано выше, могут применяться и другие технологии — мы делаем упор на эти как на наиболее распространенные).
Логически фронтенд-разработку можно разделить на верстку и логику (скрипты).
JavaScript («ДжаваСкрипт») — скриптовый, строго не типизированный язык. С его помощью разработчик может добавлять интерактивные элементы на сайт (например, игры, динамические стили, анимацию). Возможности JavaScript позволяют создавать много интересного, вплоть до серьезной 2D— и 3D-графики.
Как и любой язык программирования, JavaScript меняется и обрастает своими фреймворками, библиотеками и платформами, среди которых можно упомянуть Angular, React|Redux, Vue.js и Node.js.
Всегда стоит обращать внимание на то, какой фреймворк указан в вакансии, и спрашивать у заказчика, насколько критичен опыт работы именно с этим фреймворком. Среди айтишников вообще идет давний холивар о том, как много времени займет переход с одного фреймворка на другой. Одни говорят, что все фреймворки одного языка между собой похожи и освоить новый можно за пару недель. Другие возражают: чтобы разобраться в тонкостях работы каждого фреймворка, пары недель не хватит. Я бы сказал, что это спор, в который нам, рекрутерам, не стоит лезть, пока мы не «набьем руку», хотя мне ближе позиция, что за пару недель хорошо разобраться в инструменте все-таки невозможно.
В общении с JS-разработчиком есть смысл уточнять, насколько сложным был фронт, была ли на него вынесена какая-нибудь логика и какая именно, кто занимался версткой, был ли на проекте отдельный верстальщик.
Верстка. Чаще всего фронтенд-разработчики не хотят заниматься версткой, потому что для них это скучно. Как правило, они проходят этот этап на пути к разработке и в дальнейшем стараются его избегать. Поэтому версткой обычно занимается отдельный человек — верстальщик: он является связующим звеном между дизайнерами и фронтенд— и бэкенд-разработкой. Верстальщик получает макет от дизайнера и:
● с помощью языка HTML размечает элементы на странице;
● через язык CSS (Cascading Style Sheets) придает им внешний вид: задает цвета, шрифты, расположения отдельных блоков и т. д.
После этого работа отправляется фронтенд— и бэкенд-разработчикам, чтобы они прописали системы взаимодействия с сервером и настроили адаптивность сайта к разным браузерам.
Что такое тестирование на бытовом уровне — очевидно: это проверка того, как работает новое программное обеспечение. Однако не все так просто, как кажется. Тестирование каждой программы или системы включает в себя множество разных процессов: от обычного выявления ошибок до проверки поведения программы в специальных «экстремальных» условиях.
За этот этап работы отвечают Quality Assurance Engineer (специалисты/инженеры по качеству, сокращенно QA), или попросту тестировщики.
Процесс тестирования можно классифицировать по множеству разных критериев, но чаще всего его разделяют на ручное и автоматизированное. Соответственно, в ручном тестировании принимает участие живой человек, а при автоматизированном программы тестируют друг друга — и, вероятно, по результатам когда-нибудь договорятся до восстания машин. Но не беспокойтесь: автотесты тоже запускает человек, всё под контролем.
Manual Testing (ручное тестирование) происходит следующим образом: QA-специалист «изображает» поведение пользователя и регистрирует, где и что именно пошло не так.
Как QA узнает, что именно ему делать? С помощью системного аналитика или продакт-менеджера. Как правило, системный аналитик предполагает, как поведет себя пользователь, попав, например, на новый веб-сайт. На основе этого он составляет Use-case — пользовательский сценарий. Двигаясь по этому сценарию, тестировщик «прокликивает» продукт и описывает поведение программы в тест-кейсах и чек-листах.
У ручного тестирования есть неоспоримые плюсы:
● Это сравнительно недорогой способ найти самые грубые ошибки, причем сделать это максимально быстро: разработчики оперативно получат обратную связь и устранят все баги.
● Только с помощью ручного тестирования можно проверить такой параметр, как «юзабилити», то есть удобство софта для пользователя. Этот параметр не может оценить ни один автотест — только мы сами способны почувствовать, насколько нам интуитивно понятен интерфейс, быстро ли мы находим нужные кнопки, понимаем ли логику происходящего в программе.
● С помощью ручного тестирования можно проверять самые непредсказуемые пользовательские сценарии, в то время как писать автотесты под каждый маловероятный сценарий поведения пользователя невозможно или неоправданно дорого.
Несмотря на все перечисленные плюсы, у ручного тестирования есть один большой минус, и имя ему «человеческий фактор». Тестировщик может пропустить ошибку из-за невнимательности, отсутствия опыта или банальной усталости. И тогда нам на помощь приходят машины!
Автоматизированное тестирование. В данном случае новый софт тестируется с помощью специальных программ — автотестов. Естественно, такие тестирующие программы должны быть кем-то написаны. Но однажды созданные автотесты можно использовать неограниченное количество раз, что значительно удешевляет и ускоряет тестинг.
Неоспоримый плюс автоматизированного тестирования заключается в отсутствии человеческого фактора типа усталости или невнимательности. А кроме того, автотесты помогают понять, как будет работать софт в ситуациях, которые сложно воспроизвести вручную, например при высокой нагрузке на сайт.
Казалось бы, есть только что написанная программа, есть программа-тестировщик: напустите их друг на друга — и получите результат. Человеческое участие больше не нужно! Однако без специалистов в данном случае также не обойтись. Причем эксперт по автоматизированному тестированию должен знать и уметь больше, чем ручной тестировщик.
Для работы авто-QA необходимо знать один, а лучше несколько языков программирования: чаще всего это Java и Python. Также они часто используют в своей работе такие инструменты, как PyTest или Selenium для написания тестировочных кодов. И по мере профессионального развития, как правило, становятся разработчиками. А начинают как раз с ручного.
Типы тестирований. Существует огромное разнообразие тестов, которые мы не будем рассматривать детально (мы же не собираемся учиться на тестировщиков — по крайней мере, по этой книге). Упомяну только основные виды тестирования, чтобы вы понимали, насколько масштабна эта сфера деятельности.
●
●
●
●
●
Если вы планируете заниматься наймом тестировщиков, вам также надо знать, какие есть способы тестирования, и свободно оперировать следующими терминами:
●
●
●
Общаясь с тестировщиком, мы всегда спрашиваем, занимался он ручным или автоматизированным тестированием, какие виды тестирования осуществлял, с помощью чего делал автотесты, писал ли скрипты самостоятельно. Если да, то на каком языке программирования.
О том, кто такие системные администраторы, мы уже говорили. Если кратко, то системный администратор берет на себя функции, связанные с поддержкой и эксплуатацией IT-инфраструктуры в компании. Набор обязанностей системного администратора, как правило, зависит от того, какое оснащение есть в компании: пара компьютеров с принтером или сервера и сложные коммуникационные системы.
В современных условиях активно развивается новая философия сервисной деятельности в IT, и называется она DevOps. Что это значит?
Еще в начале 2000-х было принято четко разграничивать специальности, связанные с разработкой и эксплуатацией ПО. То есть были программисты, создававшие софт, и системные администраторы, которые отвечали за то, чтобы этот софт корректно работал на серверах.
По мере того как начали внедряться гибкие технологии разработки (Agile), от системных администраторов стала требоваться более активная обратная связь. Таким образом, стало развиваться более тесное сотрудничество Developer (разработчиков) и Operation (службы эксплуатации).
В 2005 году компания Yahoo! приобрела интернет-сообщество фотографов Flickr, и им понадобилось переместить данные и сервисы из Канады в США. Для этого нужно было разработать новое ПО.
По результатам этой операции был подготовлен доклад «10+ deploy per days: Dev and Ops cooperation at Flickr». В нем было описано, каким образом команде удалось выполнить поставленные задачи максимально быстро и качественно. Основой успеха стали совместные согласованные действия разработки и эксплуатации.
Этот доклад стал фундаментом новой философии — DevOps, которая быстро нашла много сторонников и последователей. Обоснование идеи раскрыто в книге «Философия DevOps» Дженнифер Дэвис и Кэтрин Дэниелс[16]. В ней говорится, что разработчики, зацикленные на пользователях, должны уделять больше внимания поддержке. Ведь кто лучше сисадминов может рассказать о проблемах продукта? В результате появилась отдельная профессия на стыке разработки и эксплуатации, которая носит название DevOps.
DevOps-специалист — это профессионал широкого профиля, который разбирается в принципах разработки и тестирования ПО и понимает, как конкретный код будет работать на «железе», виртуальных серверах или в облаке. Он может выступать в роли консультанта как в момент проектирования ПО, так и после внедрения. DevOps-специалисты «вырастают» либо из системных администраторов, либо из разработчиков (случается значительно реже).
В командах, где практикуется DevOps как подход, также есть так называемый релиз-инженер. Он не только работает с софтом, но и организует общение как внутри команды, так и между командами разработчиков, тестировщиков и сисадминов.
Возвращаясь же к системным администраторам, важно понимать, что они часто делятся на администраторов Linux и администраторов Windows. Первые, соответственно, работают с Linux-подобными операционными системами, а вторые — с виндой.
Глобальная разница между ними в том, что Linux исповедует концепцию открытого программного обеспечения. То есть исходный код этой операционной системы открыт и доступен для доработок. В то время как код винды — закрыт. У Linux есть отдельные дистрибутивы (условно можно назвать их версиями), которые также могут дорабатываться. Вот пара примеров: Debian, Ubuntu.
Кроме того, у сисадминов стоит спрашивать, с физическими или с виртуальными серверами они работали. Если они занимались поддержкой парка компьютеров, то можно спросить, насколько большим был этот парк.
И наконец, администраторы вообще могут больше заниматься сетями. Например, различным сетевым оборудованием: роутерами, маршрутизаторами, коммутаторами. Тогда нужно обращать внимание на то, с какими технологиями и устройствами работал человек.
В рамках трехзвенной архитектуры ПО одно из звеньев — базы данных. С ними имеют дело разработчики и администраторы. Важно понимать, что сами базы данных делятся на реляционные и нереляционные (NoSQL). Реляционные — это те, в которых фигурирует SQL. Примеры нереляционных — MongoDB, Cassandra.
Нереляционные базы данных обычно используются на более сложных и высоконагруженных проектах. Для управления базами данных существуют СУБД (системы управления базами данных). Так, например, одной из самых популярных СУБД является MS SQL Server. Это продукт Microsoft, а значит, он подходит для Windows. Из менее популярных СУБД можно также выделить MySQL, SQLite.
Сами базы данных могут разрабатываться на нескольких языках программирования, но вот основные:
● SQL;
● T-SQL (Transact-SQL) — это расширение самого SQL;
● PL/SQL (ПиЭльЭсКюЭль).
Если вы видите PL/SQL, значит, в качестве СУБД используется Oracle. И наоборот.
Важно понимать, что запросы к базам данных могут быть следующие:
●
●
●
●
Есть два типа специалистов, которые разрабатывают базы данных и управляют ими: соответственно разработчики и администраторы. В современных реалиях эти две позиции часто смешиваются. В идеале разработчики отвечают за создание, отладку и оптимизацию баз данных, а администраторы обеспечивают ее жизнедеятельность, внедряют обновления, отвечают за безопасность. По факту же, особенно в небольших компаниях, разработчики зачастую берут на себя функцию сопровождения базы данных или администраторы делают всё, вплоть до разработки дополнительных модулей (по мере своих сил и возможностей).
Важно также упомянуть о мобильной разработке — без нее нынче никуда. Глобально мобильные разработчики делятся на iOS и Android (шок, правда?). Но бывают и те, кто одновременно разрабатывает приложения под обе платформы. Вообще для таких целей существуют даже специальные кросс-платформенные языки, например React Native. Правда, он считается не самым стабильным языком программирования, поэтому найти таких специалистов довольно сложно, а в компаниях чаще всего пока встречается все-таки деление на iOS и Android.
iOS-разработчики пишут софт для всеми любимых айфонов. Кстати, iOS — это Unix-подобная операционная система, как и, например, Linux. Но ее исходный код в Apple все же закрыли. Изначально под iOS можно было писать на языке программирования Objective-C. Сейчас он устарел, и все больше проектов стараются перевести на Swift. Тем не менее иногда приходится искать разработчиков, которые способны дорабатывать старые приложения на Objective-C.
Android-разработчики пишут софт для различных устройств, использующих ОС Android (она, кстати, тоже Unix-подобная). Представляете, какой большой вклад в развитие современных технологий сделали создатели Unix? Изначально приложения под Android можно было писать на Java, сейчас же все больше проектов написаны на Kotlin.
Общаясь с мобильными разработчиками, всегда можно спрашивать про нагрузку на приложение, количество скачиваний, а еще про отдельные модули, которые могут быть важны для проекта. Частный пример вопроса: приходилось ли разработчику делать интеграции с Google Maps?
Мы с вами уже затрагивали тему сорсинга, но перед тем как переходить к нюансам, важно разобраться, что же это такое. Забавно, но четкого определения сорсинга нет. Чаще всего пишут, что это поиск подходящих специалистов на имеющиеся вакансии. Противники выделения сорсеров в отдельную профессию сразу же начинают говорить: ну а в чем тогда разница по сравнению с ресечерами или с той работой, которую делает рекрутер? И однозначного ответа тут нет, поэтому давайте разберемся немного в историческом контексте. Изначально позиция ресечера была стартовой в рекрутменте. Ресечер нагонял кандидатов на собеседования: обрабатывал отклики с вакансий, возможно, немного сам искал на job-бордах, а потом просто обзванивал людей. Рекрутер же мог выполнить более сложный поиск. Для этого ему нужно было чуть больше разбираться в самой вакансии и в том, как в целом строится поиск. По факту рекрутер мог делать ту самую работу ресечера, но он еще и собеседовал кандидата, и сопровождал его в дальнейшем процессе.
Сорсер обычно фокусируется на детальном, глубоком и сложном поиске нужных специалистов. Зачастую ему приходится работать с большими массивами информации, уметь выгружать данные с различных ресурсов, находить контакты кандидатов, делать рассылки и более персонализированные письма для кандидатов, брать на себя первый контакт с ними. Получается, что сорсинг — это тот же поиск, только без отвлечения на собеседования, оценку и т. д. Рад бы я здесь дать какое-то определение, да ничего толкового не получается. Как я и писал выше, позиция эта довольно молодая для нашего рынка, поэтому не всегда хватает конкретики.
Так или иначе, чтобы искать людей эффективно, нам необходимо разобраться в нескольких принципах сорсинга, которые мне кажутся основополагающими. И именно они позволяют достигать хороших результатов.
Здесь имеется в виду довольно простая и банальная вещь, о которой мы периодически забываем. Но в помощь нам разные детективные сериалы: чтобы найти преступника, нужно думать как преступник. Здесь логика такая же. Если вы понимаете свою целевую аудиторию (ЦА), понимаете ее интересы и поведение, вы сможете написать правильный запрос, пойти на правильный ресурс и написать правильное сообщение, на которое кандидат вам ответит. До тех пор пока вы не понимаете свою ЦА, к сожалению, вы бродите в потемках.
Частая ситуация — рекрутер пишет ключевые слова, которые важны ему, и находит мало кандидатов. Но соль в том, что нужно брать список нужных вам ключевых слов, фильтровать их и думать о том, как об этом мог бы написать кандидат. Давайте разберем на простом примере не из IT. Допустим, вы ищете менеджера по продажам, и вам очень важно, чтобы у него был опыт b2b-продаж[17]. И вы добавляете три заветные буквы в свой запрос — и находите 100 человек. Но ведь кандидат мог заниматься этими продажами, но написал о них совсем по-другому. Например, просто «продажа компаниям» или «корпоративные продажи». По смыслу — то же самое, но если вы пишете в запросе «b2b», вы просто не увидите кандидатов, написавших по-другому.
Потому постоянно задавайте себе вопрос: а как кандидат мог бы сказать о том, что нам нужно? Чтобы понимать это, нужно изучать свою целевую аудиторию и быть очень внимательным. («Спасибо за очевидный совет, Егор, без него мы бы прям не справились!»)
Сказанное выше может показаться очень банальным советом, но все же повторюсь: в сорсинге очень важно анализировать сразу несколько вещей. Начинать нужно с ЦА, продолжать конкурентами и ресурсами поиска, потом переходить к предыдущему опыту закрытия аналогичных вакансий, к текущей воронке кандидатов.
А еще очень полезно обращать внимание на мелочи и на самые рутинные процессы. Поэтому, чтобы написать грамотный X-Ray-запрос для поиска кандидатов на конкретном ресурсе, нужно и на URL посмотреть, и на заголовки, и на типичные фразы. Как бы то ни было, если не включать аналитическую часть мозга, можно ломиться в закрытую дверь и не понимать, что что-то происходит не так.
Не бойтесь пробовать новые ресурсы. Не бойтесь ошибиться. Не бойтесь пробовать старые ресурсы, про которые кто-то сказал, что они не работают. Фишка в том, что все мы ищем кандидатов на одних и тех же ресурсах. Более того: используем одни и те же инструменты и способы обработки этих ресурсов. В итоге мы с вами работаем с одними и теми же кандидатами. И хоть их и много (в целом в мире), они всё больше устают от нас с вами. А потому иногда, если найти не такой распространенный ресурс, выхлоп с него может оказаться выше, чем очевидные job-борды. Так, например, когда появился Telegram, размещение вакансии в нем приносило просто колоссальные результаты. Но когда люди узнавали, что мы ищем кандидатов в Telegram, не все разделяли наш энтузиазм.
Зато спустя полгода-год Telegram стал ломиться от количества эйчаров в айтишных чатах. И кандидаты снова столкнулись с некомпетентным поведением наших с вами коллег, и снова это вызвало негатив, и снова процесс поиска усложнился. Но и до сих пор размещение вакансии в Telegram может быть полезным.
Мысль кажется очевидной, но не всем же мыслям быть гениальными и исключительными. Тем не менее именно тестирование новых идей, новых запросов, новых ресурсов, новых «заходов» к кандидатам может принести вам нужный результат. Но если в предыдущем пункте я говорил об отсутствии страха, то в этом хочу подчеркнуть необходимость проверки своих гипотез. Не доверяйте одному запросу, пробуйте несколько и смотрите, какой из них сработает лучше. Возьмите за практику проверять несколько идей, не одну. Но помните, что очень важно тестировать не всё скопом, а по очереди, в каждый отрезок времени всего лишь по одному изменению. Потому что, если вы разом поменяете и текст вакансии, и текст сообщения для холодного кандидата, и источники поиска, вы потом не сможете понять, какое именно изменение повлияло на результат.
На самом деле этот принцип сильно связан с предыдущим. Нам очень хочется, чтобы все было просто. И иногда действительно лучше не усложнять (я бы это выделил в отдельный принцип даже). Но не всегда все происходит так просто и легко, как нам хочется. Не всегда достаточно просто разместить вакансию. Не всегда достаточно просто написать булев запрос. Не всегда достаточно просто зайти на GitHub.
И важно соблюдать баланс между простотой и сложностью. На мой взгляд, лучше сделать лишние пять шагов, чтобы найти кандидата, понять его, отыскать новый ресурс. В общем, поработать над тем, чтобы действительно найти подходящих кандидатов, а не довольствоваться первыми 10 резюме, которые появились при написании простейшего запроса.
Должен признаться, что эта тема — моя любимая. Она одновременно и очень легкая, и очень сложная. Легкая, потому что преимущественно булев поиск (он же boolean search) — это про внимательность, элементарную логику и эксперименты. Сложная же, представьте, по той же причине: именно невнимательность нас чаще всего и подводит, подталкивая к ложному выводу о том, что булев поиск не работает.
Что же такое boolean search? Термин этот получил свое название от фамилии английского математика Джорджа Буля[18]. И хотя он внес определенный вклад, в частности, и в развитие дифференциальных уравнений, сейчас я это упомянул, просто чтобы вас напугать. По факту булев поиск
У поисковых систем вроде «Яндекса» и Google есть свои базы данных. Для того чтобы к ним обратиться, можно написать обычный словесный запрос: «резюме программистов из Москвы». И поисковики покажут нам определенный результат. Но у каждого из них есть свои логические операторы, которые помогут уточнить поиск и сделать его более управляемым. Казалось бы, зачем нам управлять поисковиком? А затем, что, по моему скромному мнению, поисковики движутся к тому, чтобы предугадывать наши с вами действия и желания. Поисковики зачастую умнее нас. Но иногда их «ум» приносит лишь горе. Например, если мы напишем тот самый словесный запрос — «резюме программистов из Москвы», то, скорее всего, получим выборку карьерных сайтов, так как там содержится наиболее релевантная информация. Поисковики как бы предполагают за нас, что именно эта информация нам и нужна. Но, к сожалению, это не всегда так, ведь в интернете огромное множество резюме хранятся не на job-бордах. К тому же не всегда у нас такой доступ к job-бордам есть. («Ты что же, Егор, хочешь сказать, что не все компании оплачивают доступ к ним?» — «Да-да, дружок, российский бизнес порой суров».)
Но, несмотря на это, нам нужно продолжать использовать поисковики, только делать это с умом. И как раз для этого нам понадобятся те самые булевы операторы. Важно учитывать, что у каждого поисковика эти операторы свои, но в целом они похожи. У каждого поисковика есть своя документация, описывающая, как эти операторы работают. Мы с вами будем рассматривать Google.
Основная проблема статей, написанных на эту тему в интернете, в том, что в них очень много неактуальной информации. Операторы меняются, устаревают, появляются новые, а в статьях об этом не говорят. Сейчас мы рассмотрим операторы, которые будут актуальны на данный момент. И хотя, скорее всего, актуальны они будут еще долгое время, вам важно эту информацию отслеживать. Сделать это можно, например, тут:
● Операторы поиска в Google — https://support.google.com/websearch/answer/2466433?hl=ru.
● Операторы поиска в «Яндексе» — https://yandex.ru/support/search/query-language/search-context.html.
● Операторы поиска в Bing — https://help.bing.microsoft.com/#apex/18/en-us/10002/0.
Важно понимать, что среди операторов поиска есть так называемые
По этой причине ваш булев запрос всегда нужно проверять. Если этого не делать, можно просто прийти к выводу, что булев поиск не работает в принципе, а это будет большим заблуждением.
Теперь же поговорим наконец об основных операторах поиска, которые нам понадобятся в работе.
Давайте попробуем составить простой запрос и напишем в поисковике:
Первое, что я увижу при таком запросе, будут карьерные сайты — и это логично: на них есть все указанные нами слова, они популярны, и Google предполагает, что результат именно на них наиболее удовлетворит нашему запросу.
Но что делать, если мы не хотим смотреть только на job-борды? Несмотря на то, что там действительно находится огромное количество резюме (когда я прихожу в компании обучать их рекрутменту, почти во всех компаниях отвечают, что не меньше 80 % их найма приходится на hh.ru), порой бывают ситуации, когда нам нужно увидеть чуть больше. Например, нам нужен редкий специалист и все job-борды мы уже перерыли. Давайте тогда попробуем исключить их из выдачи. Для начала прямо так и напишем: — hh.ru — superjob.ru — careerist.ru — rabota.ru — trud.com — rabota.ua — farpost.ru — work.ua — domkadrov.ru.
Уже после этого в нашей выдаче начинают появляться новые ресурсы, которых мы не видели раньше.
Давайте попробуем тогда добавить локацию в наш запрос. А еще добавим синоним слова «программист» и напишем заодно на английском «developer». В итоге наш запрос выглядит так: резюме php программист OR developer москва — hh.ru — superjob.ru — careerist.ru — rabota.ru — trud.com — rabota.ua — farpost.ru — work.ua — domkadrov.ru.
Кстати, по поводу синонимов должностей. Сейчас всё чаще говорят, что писать синонимы должностей не надо, Google сам умеет находить их. Я в этом вопросе считаю, что лучше самостоятельно тестировать запросы без синонимов и с ними и смотреть на результат. В каких-то случаях Google действительно справляется лучше, в каких-то нет. Не стоит доверять какой-либо информации на 100 %, даже этой книге, лучше самому проверить и получить свой опыт!
К сожалению, после этого в нашей выдаче наверху появилось большое количество вакансий, что нам не нужно. Попробуем исключить их: резюме php программист OR developer москва — вакансия — вакансии — job — jobs — hh.ru — superjob.ru — careerist.ru — rabota.ru — trud.com — rabota.ua — farpost.ru — work.ua — domkadrov.ru.
Резюме действительно стало больше. Теперь давайте попробуем сделать так, чтобы Google нам находил точную фразу «php программист» или «php developer», а не эти слова по отдельности. Для этого нам придется взять эти фразы в кавычки. В итоге наш запрос будет выглядеть так: резюме «php программист» OR «php developer» москва — вакансия — вакансии — job — jobs — hh.ru — superjob.ru — careerist.ru — rabota.ru — trud.com — rabota.ua — farpost.ru — work.ua — domkadrov.ru.
Обратите внимание, что кавычки я ставлю именно "гвоздики", а не «елочки», так как оператором являются именно "гвоздики"!
Что ж, в этом запросе встречается как минимум три булевых оператора: кавычки, OR и минус. Давайте теперь попросим Google поискать слово «резюме» в заголовках страниц. Для этого так и напишем в начале запроса: intitle: резюме.
Выдача стала еще более точной. Давайте попробуем поискать слово «резюме» не в заголовке, а в URL. Тогда и написать его лучше на английском. Убираем intitle: резюме и вместо этого пишем inurl: cv. Хотя в последнее время Google стал неплохо искать и кириллицу в URL-адресах.
Тоже неплохо. На самом деле мы можем с вами даже оставить оба этих оператора и попросить Google искать в заголовках страниц слово «резюме» (заголовки на данном скриншоте более крупные, на экране они синие), а в URL-адресе искать слово «cv» (URL здесь указан наверху над заголовком, серым цветом и более мелким шрифтом). В итоге наш запрос выглядит так: inurl: cv OR intitle: резюме «php программист» OR «php developer» москва — вакансия — вакансии — job — jobs — hh.ru — superjob.ru — careerist.ru — rabota.ru — trud.com — rabota.ua — farpost.ru — work.ua — domkadrov.ru.
Его можно еще уточнять, но важно помнить, что длина запроса сейчас не может превышать 32 слова. То есть если в нашем запросе слов будет больше, Google так и напишет: «запрос превышает максимальную длину, мы не учитываем ничего после …».
Но у нас еще остались два оператора, которые мы не использовали. Начнем с оператора filetype: он ищет по определенному типу файла. Если взять наш запрос, в котором мы ищем резюме, то нужно подумать о том, какими же могут быть резюме, в каком формате кандидаты могут их выкладывать? Чаще всего кандидаты используют форматы docx и pdf. Так и напишем: filetype: docx OR filetype: pdf OR filetype: doc.
Так мы с вами вышли на новые странички, на которых располагаются файлы с резюме интересующих нас кандидатов. Важно понимать, что мы с вами хотим найти, ведь от этого зависит и наш запрос. Если это какие-то файлы — надо учитывать их формат, если это странички людей в соцсетях — URL-адреса и специфические фразы.
Булев поиск — это кропотливая и въедливая работа, которая может принести потрясающие результаты, которых иначе было бы достичь очень трудно. Главное — не сдаваться.
Существует три наиболее распространенные ошибки при написании запроса, которые приносят неверные результаты. Отсюда и три правила:
● Все операторы с двоеточием пишутся маленькими буквами и без пробелов после операторов.
● Все буквенные операторы без двоеточия пишутся большими буквами и через пробел.
● Минус (дефис) всегда пишется вплотную к слову, которое мы хотим исключить из выдачи, и перед ним.
Остался всего один оператор, который мы с вами не использовали, а следовало бы. Это оператор site:. Он помогает искать на конкретном сайте, то есть мы можем указать Google, где мы хотим найти эту информацию, приказать ему искать на одном конкретном ресурсе, а не во всем интернете. Такие запросы еще часто называют X-Ray. Например, если я напишу: site: facebook.com «системный аналитик» самара, Google покажет мне все страницы Facebook, на которых встречается словосочетание «системный аналитик» и слово «самара». Но там будут не только страницы людей, но и страницы компаний, непосредственно посты, посты в группах — в общем, много личного. Чтобы оставить в выдаче только профили людей, нужно будет постараться, но об этом я расскажу дальше.
Итак, мы с вами выяснили, что булев поиск — это универсальный инструмент (причем не только рекрутмента), который позволяет найти в сети буквально все что угодно.
Мы разобрали, как найти файлы нужного нам типа, страницы с определенными заголовками. И если вы научитесь уточнять запросы и управлять тем, как Google ищет, вы сможете получать в выдаче именно то, что вам нужно.
Во многих ситуациях булев поиск — это спасение рекрутера. В частности, он даже позволяет искать информацию на платных ресурсах бесплатно. Я не призываю вас к пиратству, но иногда такой анализ платных ресурсов наводит на след нужных вам людей, и уже после этого покупка подписки становится объективно оправданной.
Важно помнить: я разобрал, как пишутся запросы, на конкретных примерах. Например, мы минусовали много разных слов — superjob, hh и др. Это только пример, и он не означает, что эти слова надо минусовать каждый раз. Все зависит от задачи. На этом примере важно понять саму логику построения запроса:
● у вас есть определенная потребность, вы идете в Google и пишете запрос;
● на основе выдачи вы начинаете думать, как его сформулировать лучше: какие заголовки актуальны, какие синонимы можно подобрать;
● после этого вы начинаете исключать что-то из выдачи и смотреть на результат.
Одной универсальной рекомендации, как создать правильный запрос, к сожалению, не существует. Существуют подборки запросов, которые вы можете найти в интернете (например, в моем телеграм-канале Boolean Search Hacks[19]), скопировать и вставить в поиск, но для рекрутера намного важнее понять логику, самому научиться писать запросы. И тогда вы сможете искать что угодно и где угодно.
Булев поиск — это инструмент, для которого критически важно быть внимательным, кропотливым и въедливым. Надо сидеть, ковыряться, разбираться и не бояться ошибок. Просто закинуть ключевые слова по принципу «и так сойдет» — не получится. Зато такая кропотливая работа дает отличные результаты.
Например, булев поиск — это на текущий момент единственный способ обработки Facebook и поиска кандидатов в этой соцсети. А для многих позиций, например для поиска специалистов топ-уровня, Facebook — отличный ресурс, и его не следует недооценивать.
Однако булев поиск — это своеобразное «бутылочное горлышко», через которое не проходят многие рекрутеры. И причина тому — синтаксические и логические ошибки. Рекрутеры пробуют, пишут с ошибками, не могут найти эти ошибки — и приходят к выводу, что инструмент бесполезен. «Буду искать по старинке», — решают они. И это то, с чем нужно бороться.
Как я уже говорил ранее, для булева поиска особенно важен правильный синтаксис. Есть три наиболее распространенные синтаксические ошибки, которые делают новички:
● Ставят пробел после двоеточия. Этого делать не надо. Запрос с двоеточием всегда должен писаться без пробела и выглядеть, например, так: inurl: cv.
● Буквенные операторы без двоеточия должны быть указаны большими буквами — иначе Google их не поймет. В данном случае речь идет об операторе OR, он всегда пишется именно так.
● И конечно, минус (дефис), который нужно писать без пробела, когда вы пытаетесь что-то исключить из своей выдачи. Например: — вакансии — job — jobs.
Я об этом уже говорил, но я занимаюсь обучением уже очень давно и со всей ответственностью заявляю: эти ошибки — действительно самые распространенные. Так что лучше повторю!
Какие еще ошибки критичны? Логические.
Очень часто люди, которые только начинают осваивать булевы запросы, грубо говоря, сравнивают теплое с мягким. Мы говорим: «красивый мягкий стул», и в данном случае «красивый» и «мягкий» — это все определения, которые нам необходимы. «Теплый» будет не в тему. При формировании запроса такие определения важно найти и правильно объединить.
Приведу пример. Вы хотите найти URL-адреса, в которых есть слово cv или resume. Вы пишете inurl: cv OR resume. Что понимает из этого запроса Google? Он видит оператор inurl: и говорит: «Хорошо, я ищу в URL-адресе слово cv». А дальше написано OR resume, и он не понимает: а resume где искать? В тексте страницы, в URL, в заголовке? Так как перед словом resume нет специальных операторов, он начинает искать его везде.
Получается, что мы говорим Google: найди мне, пожалуйста, либо в URL-адресе страницы слово cv, либо где-нибудь вообще слово resume. И, естественно, в выдаче мы получаем совсем не то, что ожидали. Какие-нибудь статьи о том, как прокачать резюме, или инструкцию к телевизору, на пульте которого есть кнопка resume. Потому что формально слово resume в них и правда встречается. Но это не совсем то, что нам нужно.
Если мы хотим использовать оператор OR в поиске в заголовках, или в типах файла, или в URL-адресах, мы каждый раз прописываем перед словом необходимый оператор. Например, в предложенном примере правильным будет такой запрос: inurl: cv OR inurl: resume.
На этом этапе обычно происходит большое количество ошибок. Поэтому обязательно запишите это правило, запомните или, не знаю, набейте татуировку! И тогда ключи, которые скрываются в булевых запросах, откроют вам множество потайных дверей.
Ну и в качестве развлечения давайте проверим, какие из этих запросов содержат ошибки, а какие — нет. Имейте в виду: в сносках вы увидите ответы. Лучше сразу закройте их рукой, книгой, котом — лишь бы эксперимент был чистым.
Какой запрос не содержит ошибок?[20]
1. site: vk.com php программист OR php developer москва
2. site: vk.com "php программист" OR "php developer" москва
А тут какой запрос без ошибок?[21]
1. inurl: portfolio OR inurl: портфолио ux-дизайнер казань
2. Inurl: portfolio OR портфолио ux-дизайнер казань
Ну и последний. Где нет ошибок?[22]
1. Site: facebook.com аналитик самара
2. site: facebook.com аналитик самара
Как мы помним, X-Ray — это частный случай Boolean search. Мы создаем X-Ray-запрос с помощью оператора site: и таким образом ищем информацию на каком-то одном ресурсе. X-Ray в переводе с английского означает «рентген», и этот запрос как будто просвечивает рентгеновскими лучами какой-то конкретный сайт.
X-Ray-запросы писать не сложнее, но и не легче, чем обычные. По сути, правила все те же. Но есть несколько нюансов.
Например, если мы начнем использовать X-Ray-запросы для того же Facebook — будем искать, предположим, «аналитик самара», — то мы обнаружим в выдаче и сообщения о вакансиях, и посты в группах или профилях. Это значит, что мы недостаточно уточнили запрос.
Чтобы написать X-Ray-запрос, нам нужно найти какую-то зацепку, уловку, которая позволит найти именно профили людей, которые нам нужны. В соцсетях, на форумах или на других ресурсах, где общаются нужные нам специалисты, мы, как правило, не хотим читать все блоги и обсуждения. Нам нужны именно профили людей, в которых будет указана информация о них.
Для написания X-Ray-запроса надо найти какой-то специфический признак, характерный для выбранной социальной сети, — какое-то слово, которое встречается только в профилях людей. Какие могут быть зацепки? Вот несколько примеров.
● Зацепка в URL-адресе. Пример такой URL-уловки можно найти в LinkedIn. Если вы посмотрите на URL-адрес страницы пользователя LinkedIn, то вы заметите, что там есть окончание /in. Полностью это выглядит так: linkedin.com/in. Это дополнение /in — ссылка на «папку», в которой хранятся все профили людей. Поэтому если вы напишете site: linkedin.com, то будете искать информацию везде: в постах, вакансиях, профилях. А если запрос будет site: linkedin.com/in, то поиск будет происходить только среди профилей.
● Поиск по заголовку. На сайте hexlet.io можно заметить, что часто в профилях пользователей есть заголовок «пользователь hexlet». Соответственно, если вы напишете intitle: «пользователи hexlet», то вы таким образом найдете профили, а не курсы, вакансии и прочее.
● Ключевое слово. Этот тип поиска характерен, например, для Facebook. Если вы посмотрите на страничку человека на Facebook, там есть такое специфическое словосочетание «другие люди с именем», или в английском варианте «others named». Оно может встречаться только на странице пользователя. Поэтому если вы напишете запрос site: facebook «другие люди с именем», то получите ссылки только на страницы пользователей и отсечете ненужные результаты.
Таким образом, в случае с X-Ray-запросом нам надо анализировать эти три основных момента: URL-адрес, заголовок и специфическое ключевое слово. Находя неочевидные особенности, скрытые в актуальных для вас ресурсах, вы сможете писать точные X-Ray-запросы и находить людей, которые вам нужны.
Такие запросы можно делать по любому ресурсу в интернете, если только этот ресурс не скрывает данные от сторонних пользователей. А таких ресурсов немало. Один из примеров — hh.ru. База их резюме — это то, что они продают рынку, поэтому они тщательно скрывают и определенный процент самих резюме, и контакты специалистов. Когда вы пишете запрос по ресурсу hh.ru, то получаете определенное количество резюме, но без контактов, то есть только то, что ресурс позволяет вам увидеть.
Так же скрывается значительная часть резюме, если у вас нет аккаунта на hh.ru. Вы вводите запрос на поиск по сайту, и он выдает, например, 30 резюме — с «оговоркой», что, заведя аккаунт, вы получите еще 330 аналогичных. При булевом поиске действуют такие же ограничения: не залогинившись, вы не сможете искать по всем 330 резюме, а только по тем, которые hh.ru позволяет видеть сторонним пользователям. Так работают многие ресурсы, и это важно помнить, настраивая булев поиск.
Я не открою вам Америку, сказав, что соцсети плотно вошли в нашу жизнь, в том числе и в рабочие будни рекрутера. Здесь можно не только рассказывать, что ты съел на завтрак и какие фильмы посмотрел после ужина, но и находить кандидатов, выстраивать свой личный бренд, получать полезную информацию от коллег и делать много других интересных вещей. Поэтому я уверен, что соцсети — это место, куда рекрутеру обязательно нужно идти.
Конечно же, для многих соцсети — это личное пространство. И кто-то мне возразит: «Дружище, ты слишком много от меня хочешь! Работать надо на работе, а в соцсетях проводить свободное время и получать удовольствие от общения».
Действительно, каждый решает для себя сам, стоит ли ему идти в соцсети и развивать там рабочие страницы, осваивать сорсинг, общаться в профессиональных сообществах. Но так как соцсети — это инструменты, которые отлично работают в рекрутменте, я считаю необходимым про них рассказать.
Можно ли в нашей с вами работе обойтись без соцсетей? Конечно, да! Но будет несколько сложнее. Так же можно было бы обойтись и без job-бордов: объявления на столбах никто еще не отменял. Но…
Если вы согласны с тем, что соцсети — это эффективный рабочий инструмент рекрутера, давайте рассмотрим, где именно и как можно искать кандидатов.
LinkedIn — профессиональная соцсеть, которая предназначена для поиска работы. В ней люди в большинстве своем указывают должности, специальность, навыки, которыми владеют (и подтверждение этих навыков в виде лицензий, сертификатов и т. д.). Конечно же, далеко не все полностью открывают свои данные, и это нормально. Но так как LinkedIn предназначен для развития именно деловых контактов, здесь можно найти значительно больше данных о профессиональной деятельности человека, чем в любых других соцсетях. При этом в LinkedIn редко можно встретить личный контент: на аватарках, в основном, люди в деловых костюмах, в блогах — обмен профессиональными мнениями. Такая сдержанность может несколько мешать установлению личных контактов, но для дела — в самый раз. Это огромная база кандидатов, и с LinkedIn рекрутеру необходимо дружить. Если же вы ищете специалистов за рубежом, то без LinkedIn практически не обойтись.
Однако у этой соцсети, как вы знаете, есть одна негативная особенность: LinkedIn запрещен Роскомнадзором и заблокирован на территории России. Поэтому некоторые рекрутеры считают, что туда нет смысла идти: мол, есть блокировка — нет кандидатов. К счастью, это не так.
Смысл работать в этой сети есть, специалистов там много, особенно айтишников, которым ничего не стоит обойти блокировку. Кроме специалистов IT-рынка, здесь есть топ-менеджеры, производственники, маркетологи, менеджеры по продажам.
Что делать с блокировкой и насколько законно ее обходить? LinkedIn запрещен, потому что у этой соцсети нет серверов в России. Почему их нет, в принципе, понятно: потому что это всемирная сеть. Многие считают, что если Роскомнадзор запретил, то теперь заходить туда незаконно. Однако блокировка сайта — это санкция против LinkedIn, а не против нас, пользователей. Нам это создает определенные неудобства, но законодательно мы не теряем права пользоваться ресурсом. Конечно, из-за этой блокировки у нас возникают ограничения по действиям. Например, если вы работаете в госкорпорации, то на офисные компьютеры никакие дополнительные расширения установить не удастся.
LinkedIn доступна в бесплатной и платной версиях. И, по моему опыту, бесплатной версии вполне достаточно, чтобы делать большое количество работы. Но и платная может быть полезна в ряде случаев. У вас есть возможность протестировать, какие именно плюсы в платной версии: при регистрации в LinkedIn дается месячный триал-доступ к премиум-аккаунту. Не могу сказать, что разница между версиями очень большая, но она, конечно же, есть. Однако намного важнее не купить всего и побольше, а понимать, как именно работать с ресурсом; если этого понимания нет, то никакие деньги не помогут. О способах работы в LinkedIn мы поговорим чуть ниже.
Facebook — мы слегка затронули эту соцсеть в прошлой главе, пришло время рассмотреть ее подробнее. Я уже говорил, что очень люблю Facebook: это универсальная соцсеть и отличное место для поиска контактов — не всех, но многих.
Исходя из исследований, аудитория здесь чуть постарше, чем в остальных сетях: основной возраст, судя по исследованиям Brand Analytics, 35–44 года (33 %). Но важна не столько статистика, сколько отношение и сложившееся мнение. Мне на момент написания книги было 30 лет. В этом возрасте я пошел получать еще одно образование. Все мои однокурсники при знакомстве обменивались данными в Instagram. Когда же я показывал свою раскрученную страничку в FB, у них это вызывало некоторый скепсис — мол, со «старичками» все понятно.
По поводу Facebook есть такое убеждение, что он исключительно для старшего поколения (хотя это не так: третья по активности группа в FB, составляющая 19 %, — это люди 25–34 лет). Кроме того, насколько эта соцсеть актуальная для всех регионов России — это тоже вопрос: есть районы, где FB сильно проигрывает своему российскому аналогу «ВКонтакте». Глобально же для рекрутмента Facebook может быть очень и очень полезен.
Здесь много специалистов, связанных с маркетингом (особенно в digital-сфере), фронтенд— и мобильных разработчиков. Кроме того, в IT есть ряд специальностей, в которых в среднем работают не совсем юные люди, и для их поиска Facebook тоже может быть полезен.
Плюс к этому Facebook — отличное место для выстраивания личного бренда рекрутера (об этой активности мы поговорим позже). Также FB подходит HR-специалистам как площадка для делового общения с коллегами: HR-сообщества довольно сильно развиты, много групп и контента на профессиональную тему. Таким образом, даже если вы не собираетесь искать здесь кандидатов, Facebook может быть как минимум полезен для понимания, чем живет HR-рынок.
Что касается стиля общения, в этой соцсети гораздо чаще можно встретить личный контент, чем в том же LinkedIn. Это помогает как в установлении контакта с кандидатом, так и в понимании своей целевой аудитории: что она любит, что не любит, чем интересуется.
В аккаунтах Facebook не всегда указываются должности и специальности, хотя достаточно часто; может быть указана неактуальная информация по должностям и местам работы, что, в принципе, нормально. Важно помнить, что если мы начинаем искать кого-то в FB исключительно по должности, то найдем только тех, кто эту должность, во-первых, указал, а во-вторых, написал именно так, как нам нужно. То есть человек может делать то, что нам нужно, но называть это не так, как мы ищем. Это, надо заметить, характерно практически для любого поиска: кандидат пишет, что он software developer, а мы ищем программиста. Вроде одно и то же, но не всегда есть возможность прописать все синонимы. Ну и давайте по-честному: software developer может относиться к людям с диаметрально противоположным стеком.
«ВКонтакте», в отличие от FB, который считается ресурсом для людей старшего возраста, наоборот, называют «соцсетью для школоты». Хотя, по статистике Mediascope на середину 2021 года, основная возрастная категория этого ресурса — от 25 до 34 лет. При этом почти у 90 % населения России есть страничка в ВК (пусть и полумертвая). Мало того, для некоторых регионов эта сеть является основной. Поэтому найти кандидатов здесь, очевидно, можно.
Однако мало кто из рекрутеров сюда доходит. И это при том, что во «ВКонтакте» есть очень удобный, элементарный внутренний поиск — инструмент, о котором многие забывают. Возможно, его игнорируют именно из-за этой самой простоты. Ведь считается, что если мы делаем что-то серьезное, — если уж пошел сорсинг! — то надо это делать сложно и мучительно. Тогда как инструмент поиска работает, IT-специалисты в ВК есть, и буквально все двери открыты.
Правда, потенциальные кандидаты далеко не всегда заполняют профиль и указывают свои должности. Даже если это не сделано, мы все равно можем понять, что кандидат нам подходит, например по его интересам. Особенность ВК заключается в том, что здесь зачастую меньше личных постов, чем в FB, зато больше репостов — по ним достаточно легко понять сферу интересов человека; в частности, косвенно выяснить, является ли он разработчиком и подходит ли нам.
Из минусов стоит отметить тот факт, что ВК считается более личным, нежели рабочим, пространством. Поэтому напрямую писать человеку о работе нужно очень аккуратно. Плюс надо помнить, что в ВК есть ограничение на общение с незнакомыми людьми: за день можно отправить не больше 20 сообщений.
Тем не менее ВК является отличным способом поиска IT-специалистов, в частности и потому, что с кандидатами здесь можно связываться напрямую. Не могу сказать, что это очень хороший способ начать общение, потому что, как было сказано ранее, многие считают ВК личным пространством. В то же время, если вы ищете специалиста и нигде найти не получается, то «ВКонтакте» может выручить.
Instagram — соцсеть, которая еще реже используется для поиска специалистов. Хотя и она представляет для рекрутеров определенный интерес. Айтишников здесь меньше, чем в FB и ВК. Но важно помнить, что аудитория сети растет, и если раньше считалось, что здесь сидят исключительно люди, рассказывающие о том, что они едят, то сейчас Instagram есть практически у всех.
Как вы знаете, сеть более визуальная, здесь меньше текстов, чем в том же FB. И по настроению она совершенно не профильная: далеко не все указывают в описании свой род деятельности. Но тем не менее по косвенным признакам IT-спецов найти можно, и ничего плохого в этом нет.
Кстати, кандидаты гораздо менее привычны к тому, что кто-то может написать им по делу в Instagram, поэтому ваше появление может сработать как эффект неожиданности — привлечь внимание.
Вряд ли можно рассматривать Instagram как основной источник поиска, но как дополнительный — вполне.
TikTok. Может быть, я сейчас скажу крамольную вещь, но сюда в любом случае нужно идти! И не только для просмотра видео с танцующими людьми.
Вы уже, вероятно, знаете, что это соцсеть с 15-секундными видео. Построена на клиповом мышлении. Тут пока сложно кого-то искать. Зато ресурс отлично подходит для построения личного бренда: сегодня здесь можно реально быстро вырастить аудиторию и продвинуть себя как адекватного рекрутера. Алгоритмы TikTok работают не так, как в Instagram и других соцсетях, за счет чего можно быстро набирать просмотры.
При этом, вопреки распространенному мнению, здесь проводят время не только школьники: значительный процент аудитории TikTok является вполне платежеспособным.
Кроме того, последнее время в TikTok появляется много не только чисто развлекательного, но и полезного контента. В частности, активизируются специалисты из мира IT, которые делятся, например, лайфхаками по использованию телефонов и компьютеров. И, естественно, начинают появляться рекрутеры, которые имеют возможность очень хорошо выступить на ресурсе, потому что не побоялись прийти сюда первыми.
По моему убеждению, в сторону TikTok стоит смотреть, потому что в заданном им направлении движется весь наш мир. Мы можем до конца отрицать актуальность клипового мышления, да и диджитализацию в целом, но мне кажется, лучше быстрее пройти эту стадию принятия и начать действовать. В конце концов, подтверждение моих слов — смена курса Instagram. Теперь ведь он тоже будет развиваться как соцсеть с короткими видео (reels).
Twitter — популярная среди айтишников соцсеть. Здесь много непрофильного контента: люди редко указывают свою сферу деятельности, мало пишут на профессиональные темы, больше болтают о личном. Мы можем только по косвенным факторам, например по подпискам, догадаться, что тот или иной человек является разработчиком.
С учетом того что соцсеть активно используется, есть смысл в нее заглядывать — например, для создания более персонализированного портрета кандидата.
Для меня лично Twitter — сложная соцсеть, у меня с ней отношения не складываются. Но IT-специалисты здесь есть, а наша задача идти туда, где присутствует наша целевая аудитория. Я бы не рекомендовал проводить активный сорсинг по Twitter, но есть рекрутеры, которые успешно выстраивают здесь свой бренд, и им это обеспечивает приток кандидатов.
Мы с вами поговорили о наиболее актуальных для рекрутера соцсетях и об их особенностях. Теперь я предлагаю рассмотреть, какие есть способы работы в сетях — что именно мы можем там делать и как.
Публикация вакансий — самый очевидный и оптимальный способ. Объявления о найме можно публиковать как у себя в аккаунте, так и на странице компании или в тематическом паблике, где сидит ваша целевая аудитория. Также можно запускать таргетированную рекламу с вакансией (про таргетинг мы говорить практически не будем: все-таки это уже отдельное направление в маркетинге, и не мне этому учить).
Важно понять основной принцип создания вакансии в соцсетях. По сути, это SMM (Social Media Marketing), то есть чтобы создать публикацию и получить адекватный отклик на нее, нам важно:
● знать свою целевую аудиторию — и публиковать вакансии в том формате, который ей близок и понятен;
● быть кратким — в соцсетях слишком много информации, наш мозг ею перегружен, поэтому учится быстро и эффективно ее фильтровать. Если мы начинаем «растекаться мыслию по древу», это сразу заметно и может вызывать отторжение. Поэтому лаконичность превыше всего;
● работать над своими call-to-action — призывами к действию, которыми должны завершаться публикации в соцсетях;
● правильно выбирать визуальное оформление — делать его ярким и небанальным, чтобы привлекать внимание, а не, наоборот, отталкивать.
Постить вакансии можно, в общем-то, в любой соцсети.
Активный поиск с использованием внутренних фильтров соцсетей. К сожалению, далеко не во всех соцсетях такой тип поиска возможен: например, в Facebook внутренний поиск не работает.
Вы можете обнаружить в интернете много старых статей, в которых описывается, как найти людей в Facebook, используя так называемый алгоритм Graph Search. Для этого предлагается использовать сложные формулировки типа «people who live in Moscow and work as software developers and like Python». Так вот, этот алгоритм с 2019 года не работает.
В то же время во «ВКонтакте» внутренний поиск работает на отлично. О нем, как я уже писал, многие забывают, вероятнее всего, именно из-за его простоты: кажется, что это слишком легко — кого я найду таким очевидным способом? Но найти можно!
Считается, что «ВКонтакте» — исключительно личная соцсеть и беспокоить людей там не очень вежливо. Стоит ли туда идти, решать вам. Но мой опыт показывает, что и поиск, и, как результат, рекрутмент здесь возможны.
Как именно искать во «ВКонтакте»? Заходим на нашу личную страничку, в разделе «Друзья» есть вкладка «Поиск друзей». Выставляем нужные параметры: выбираем актуальный для нас регион; если есть предпочтения — указываем пол и возраст. (Только тссс: официально у нас таких ограничений нет. Будем считать, что это просто неудачный пример.) Оставляем галочку «с фотографией», чтобы исключить ботов. В принципе, и без фото есть реальные профили, только отличить их от ботов будет сложно. И в разделе «Работа», в поле «Должность», начинаем писать то, что для нас актуально. Например, «Java-программист».
Важно понимать, что мы не можем написать большое количество вариантов должности сразу. Мы также не можем использовать во «ВКонтакте» булевы операторы — здесь они не работают. Поэтому приходится двигаться медленно и планомерно: писать сначала, например, «Java-программист», потом убирать и писать «Java developer». Потом — «Java-разработчик». А можно просто написать сначала Java, а потом JavaEE. И так потихоньку, работая с синонимами, получать разные результаты выдачи.
Кроме того, если мы вернемся назад и напишем «Java-разработчик» не в поле «Должность», а в разделе «Работа», где должна быть написана компания, то тоже найдем несколько человек. Потому что пользователи иногда путают эти поля и пишут важную для нас информацию не там, где мы ожидаем ее найти. К этому надо быть готовыми и не упускать такой возможности из виду. Да, понимаю, что поиск по ВК кажется уж очень простым, но именно из-за его простоты и очевидности им пренебрегают. Кроме того, важно понимать, что делать с найденным в ВК человеком дальше. Я бы советовал вам искать его контакты и не писать в ВК, оставляя этот канал связи на случай, если найти другие явки-пароли не удается. Кроме того, надо помнить, что написать в ВК можно не больше чем 20 незнакомым людям в день. Так что заспамить кого-то тупо не удастся. Ну и не рекомендуется, в общем-то.
Где еще хорошо работает внутренний поиск? Конечно же, в LinkedIn. Здесь внутренние фильтры позволяют нам выбрать локацию, должность, при желании можно даже указать название компании, в которой сейчас работает человек. Внутренних фильтров много, чтобы сделать поиск достаточно точным.
Как я уже говорил, в Facebook пользоваться внутренним поиском смысла нет. В Twitter он возможен, но не очень удобен, поэтому здесь также не рекомендую эту опцию. По Instagram — та же ситуация: можно, но сложно. Приходится забивать должность, например «Java-разработчик», смотреть аккаунты, возвращаться назад, забивать синоним… Получается такая рутинная и при этом не очень эффективная работа.
Однако в Instagram есть вариант внутреннего поиска по хештегам. Чтобы в них ориентироваться, надо хорошо понимать, какие хештеги могут использовать ваши кандидаты. А для этого, опять же, важно знать свою целевую аудиторию — в данном случае это очень критично! Например, если мы ориентируемся в шутках, характерных для определенной IT-среды, то можем легко найти специфические хештеги и по ним выйти на нужных нам специалистов.
Булевы операторы внутри соцсетей — далеко не все сети их поддерживают (вернее, в большинстве это невозможно). Но их поддерживает важнейшая для нашей деятельности сеть — LinkedIn. Как мы помним, есть платная и бесплатная версии, и за деньги этот функционал в LinkedIn значительно шире. Но и в бесплатной версии есть несколько операторов поиска, которые позволяют уточнить запрос. Их меньше, чем в платном варианте, они работают не так точно, как хотелось бы, но все равно позволяют сократить объем рутинной работы и получить хорошие результаты.
Чтобы понять, какие преимущества дает булев поиск в LinkedIn, сначала я приведу пример обычного внутреннего поиска. В верхней строке ввожу ключевые слова Java developer и настраиваю внутренние фильтры: искать сочетание этих слов среди профилей людей, локация — Москва.
У нас получилось 8500 результатов. Теперь я нажимаю на кнопку «Все фильтры», чтобы получить дополнительные опции.
В частности, как мы уже обсуждали, можно проставить фильтр с компанией, в которой сейчас работает человек. Или попросить LinkedIn найти слова Java developer не просто в профиле, а в поле «Должность». Таким образом мы отсечем тех, кто, например, раньше работал Java-девелопером, а сейчас стал, скажем, архитектором Java или вообще перешел на другой язык программирования.
И вот что мы получаем, если переместить фразу Java developer из строки поиска в поле «Должность»: вместо 8500 человек в выдаче теперь 985, то есть результат стал значительно точнее.
Теперь переходим к операторам поиска: какие есть в арсенале LinkedIn и чем они могут нам помочь?
Операторы поиска в LinkedIn https://www.linkedin.com/help/linkedin/answer/75814/using-boolean-search-on-linkedin?lang=en.
Как я уже говорил, таких операторов немного, и нужны они нам не всегда, но периодически могут быть крайне полезны. Давайте рассмотрим их по порядку:
● " " — оператор, с помощью которого мы можем задать точную фразу. Здесь логика такая же: с помощью кавычек мы можем как будто «склеить» несколько слов, чтобы LinkedIn искал их рядом.
● NOT — этот оператор аналогичен минусу, который мы использовали в Google; он исключает то или иное слово из запроса.
● AND — объединяет слова, но, по сути, LinkedIn априори ставит его автоматом.
● OR — помогает нам найти или одно, или другое слово из запроса.
● () — позволяет группировать запрос.
Важно помнить, что операторы NOT, AND и OR должны быть написаны большими буквами — именно в таком формате их поддерживает LinkedIn.
И тут возникает вопрос: зачем мне все эти изыски, если я могу написать точный запрос в поле «Должность» и получить всю информацию, которая мне нужна? Приведу пример: давайте представим, что у нас, кроме должности, есть куча других актуальных условий найма. Скажем, мы не хотим, чтобы наш Java developer был senior-разработчиком, нам нужен junior. Тогда в нашем булевом запросе будет указано: NOT (senior OR старший OR teamlead OR тимлид OR ведущий).
Все эти детали я могу написать в поисковой строке, которую мы уже использовали. Таким образом я даю сети LinkedIn указание найти:
● среди людей, живущих в Москве;
● среди тех, у кого в должности указано Java developer;
● только тех, у кого в должности нет слов «senior», «старший», «teamlead», «тимлид» или «ведущий».
Причем, обратите внимание, здесь работает математическая логика: мы взяли все эти слова с операторами OR в скобки, а за скобками написали NOT. Получается, что мы хотим исключить или одно, или другое, или третье и т. д. слово. А можно приставить NOT к каждому отдельному слову — и результат будет тот же. LinkedIn нас поймет и в том и в другом случае, благодаря чему мы подчистим себе выдачу и сделаем ее более релевантной.
Прелесть булева поиска в LinkedIn в том, что мы можем еще и еще уточнять запрос, получая все более и более точные результаты. В данном случаем мы еще сократили количество кандидатов — с 985 до 684.
В платной версии LinkedIn булев поиск работает в большем количестве полей, тогда как в бесплатной — только в верхней поисковой строке.
Или вот еще пример. Пишем в поисковой строке: (java AND c++) OR (java AND php) AND (senior OR старший). Что получаем? Все профили, в которых есть одно из слов — senior или «старший» — и сочетание либо Java с C++, либо Java с PHP. И именно благодаря скобкам LinkedIn понял мою логику.
X-Ray-запросы по соцсетям. После того как мы рассмотрели булев поиск, X-Ray-запросы не должны быть проблемой. Как вы помните, X-Ray — это частный случай булева поиска, когда мы ищем информацию на конкретном ресурсе через поисковик.
Как я уже писал ранее, мы можем писать X-Ray-запросы по Facebook, и, на мой взгляд, они являются чуть ли не единственным способом обработки этой соцсети. А я настаиваю на том, что Facebook — необходимый инструмент рекрутера. Значит, и X-Ray нам придется хорошенько освоить.
По какому принципу строятся X-Ray-запросы вообще и в соцсетях в частности? Как мы помним, в каждой сети есть много разных «сущностей»: аккаунты пользователей, группы, паблики, страницы компаний и многое другое. Нам чаще всего нужны именно страницы людей. Как на них выйти?
Если мы начнем писать запрос общего порядка типа site: facebook.com, то увидим все «сущности» вместе: коммерческие профили, мероприятия, группы и кучу всего лишнего. Чтобы ограничить поиск только аккаунтами пользователей, нам нужно знать специфические детали, которые присутствуют только на страницах людей. Где могут скрываться нужные нам ключи, по которым мы можем отсортировать аккаунты от всего остального?
● URL-адреса — в них может быть какая-то особенность, которая встречается только на страницах пользователей. Эта деталь нам поможет в сочетании с оператором inurl:
● заголовки — нам нужно вычленить какое-то специфическое слово в заголовках страниц пользователей, и тогда нам пригодится оператор intitle:
● сочетания слов, которые также встречаются только на страницах людей; в таком случае мы воспользуемся кавычками " ", чтобы объединить их в запросе.
Давайте попробуем написать X-Ray-запрос для каждой соцсети, в которой он может пригодиться. В первую очередь — для Facebook.
Предположим, мы хотим найти того же Java-программиста, но на этот раз в Казани. Мы пишем: site: facebook.com java kazan OR казань "другие люди с именем". Таким образом мы просим поисковик: дорогой Google, пожалуйста, иди на сайт Facebook.com и покажи нам все страницы, где есть слово Java, Kazan или Казань, а также встречается словосочетание «другие люди с именем». Обратите внимание, что я ставлю кавычки-гвоздики — именно они являются булевым оператором. Кавычки-елочки Google просто не поймет (хотя сейчас он автоматом ставит гвоздики даже на русской раскладке).
Откуда взялись эти «другие люди с именем»? Если мы разлогинимся из Facebook и посмотрим на страничку любого пользователя, то увидим там это специфическое словосочетание. Неважно, с какой целью оно там размещено: нам важно, что встречается оно только на странице человека, а не компании или паблика. Поэтому мы можем спокойно использовать его в качестве индикатора того типа «сущностей», которые нам нужны.
Другой вариант: начало запроса то же самое, но в конце вместо "другие люди с именем" я напишу inurl: people. Таким образом я получу дополнительные аккаунты. Важно понимать, что слово people встречается не во всех URL-адресах людей на Facebook. А значит, выборка первого и второго запросов тоже может отличаться.
В данном конкретном случае разница получилась радикальная: 18 000 вместо 40 результатов. Но мы помним, что Google зачастую хитрит, и никакие 18 000 он нам не покажет. Максимум будет 500 страниц, а скорее всего, он ограничится 300.
В Facebook можно найти множество таких ключевых словечек. Важно понимать, где и по какому принципу их искать. К сожалению, просто выучить то, что я вам предлагаю, не получится. Вернее, заучить-то ключевые слова можно, а вот получить стопроцентно релевантные результаты в любой момент времени не получится. Дело в том, что и соцсети, и поисковики регулярно меняют свои алгоритмы. Поэтому в один день вы можете получить больше релевантных результатов, используя inurl: people, а в другой — с помощью фразы "другие люди с именем". А в третий обе эти зацепки внезапно перестанут работать и надо будет подбирать новые. Таким словосочетанием может оказаться, например, англоязычный вариант «других людей» — others named.
Поэтому главное — не заучить ключевые слова и сочетания, а понимать, в чем суть написания X-Ray-запросов и на что нужно обращать внимание. В таком случае, если текущие зацепки перестанут работать, вы с легкостью найдете новые.
Итак, с Facebook мы разобрались, а как работают X-Ray-запросы во «ВКонтакте»? В 2021 году произошли изменения, которые осложнили такой тип поиска по ресурсу.
Принцип составления запроса для «ВКонтакте» точно такой же, как и для любого другого ресурса: сначала пишем site: vk.com и добавляем информацию про нашего любимого Java-специалиста из Казани. Получается: site: vk.com java kazan OR казань. Раньше надо было следом добавить «показать подробную информацию». Это фраза, которая встречалась только на страницах людей. Но, к сожалению, в 2021 году она перестала работать. Так же, как фраза «пожалуйста войдите на сайт или зарегистрируйтесь».
Это тот самый пример смены алгоритмов, о котором я говорил выше: что-то где-то изменилось — и наша уловка потеряла силу. Если бы я не понимал принцип поиска этих фраз, я бы растерялся и признал, что X-Ray во «ВКонтакте» больше не работает. А это не так!
Можно найти множество новых слов для поиска. Один из примеров, которые я подобрал сейчас — но он может перестать работать уже через месяц, — это слово «заходил». Уверен, вы обращали внимание, что на страничках пользователей есть фраза «заходил вчера» или «заходил 15 минут назад».
Тогда наш запрос будет выглядеть так: site: vk.com java kazan OR казань заходил. И — вуаля! — мы попадаем на странички людей.
Будет ли в такой выдаче лишняя информация? Да, будет! Потому что слово «заходил» недостаточно специфичное. Оно может встречаться в посте какой-нибудь компании, которая описывает, например, как «заходил к ним вчера Билл Гейтс», — и они счастливы своему везению. Нам эта информация не нужна, но, когда у нас другого выхода нет, даже такие неспецифичные слова могут быть полезны. Или, например, словосочетание «добавить в друзья» — она ведь тоже достаточно специфична.
Еще одна сеть, для поиска по которой нам может быть полезен X-Ray, — это LinkedIn. Здесь так же, как на предыдущих ресурсах, нам нужны страницы интересующих нас людей. Для этого есть несколько зацепок.
В URL-адресах страниц с профилями людей есть одна важная особенность. На них после адреса ресурса linkedin.com идет сочетание /in — а дальше никнейм или ID человека. Таким образом, это самое /in и поможет нам выйти на профили нужных нам людей.
Тогда запрос будет выглядеть так: site: linkedin.com/in java kazan OR казань. В таком случае я говорю поисковику: многоуважаемый Google, пойди, пожалуйста, на ресурс LinkedIn и загляни в директорию in. По сути, эта директория является папкой, в которой хранятся страницы разных людей. И мы отправляем поисковик покопаться в ней: найти там страницы, на которых есть слова java и kazan или «казань».
Мало того, этот запрос можно еще уточнить. Например, написать site: linkedin.com/in OR site: linkedin.com/pub java kazan OR казань — таким образом мы добавим в поиск старую директорию pub, в которой профили людей хранились раньше. Есть вероятность, что из этой «папки» pub нам выпадет много лишнего. Но если у нас какой-то узкий поиск и кандидаты исчисляются единицами, то мы сможем расширить количество результатов. Чтобы, в частности, убрать лишнее из выдачи, когда мы используем pub, стоит добавить: — inurl: dir. Это как раз те лишние страницы, которые выпадают при таком поиске.
Как обстоят дела с X-Ray-запросами в Instagram? Здесь его использовать намного комфортнее, чем собственный поиск сети. Если вы пробовали использовать внутренний поиск Instagram, то помните, что приходится по многу раз вводить разные запросы, листать, возвращаться; здесь нельзя прописать сразу несколько ключевых слов, да так, чтобы встречалось одно из них, а не все сразу; собственный булев поиск тоже невозможен. А X-Ray — вполне!
Однако если взять пример с нашим многострадальным Java-программистом из Казани, то вряд ли результат X-Ray-запроса окажется полезным: кандидатов будет совсем немного. Потому что Instagram подходит для рекрутмента далеко не всех специальностей и не во всех регионах. И сочетание java — Казань — Instagram можно назвать практически провальным. В то же время сам запрос по инсте будет выглядеть максимально просто: site: instagram.com java казань OR kazan.
Несмотря на это, работать в Instagram и искать людей через X-Ray имеет смысл: писать потенциальным кандидатам, подписываться на них, читать, что их интересует, — и благодаря этому еще лучше узнавать свою целевую аудиторию.
У меня есть несколько историй о том, как я писал в Instagram IT-специалистам, предлагал вакансии. Мы по тем или иным причинам не сходились, однако подписывались друг на друга — так появляется иллюзия знакомства, а это позволяет перейти определенную межличностную границу и построить нетворкинг, который со временем неминуемо дает положительные результаты.
Кстати, по поводу написания города на двух языках. С одной стороны, необходимости в этом нет: Google и сам понимает, что Moscow и Москва — это одно и то же. Тем не менее я рекомендую вам протестировать написание обоих названий через OR и, соответственно, только одного из двух наименований. Тут результат тоже бывает разный, поэтому любопытно посмотреть, что получится.
Я перечислил основные соцсети, в которых регулярно использую X-Ray-запросы. На самом же деле этот список можно продолжать до бесконечности. Вы можете написать X-Ray-запросы и по Twitter. Главное, понять общий принцип, как они строятся, — и действовать.
В этой главе мы кратко, не вдаваясь в детали, поговорим о таргетированной рекламе. Почему я не считаю нужным детально рассматривать настройки таргета? Потому что, как правило, этим направлением работы занимаются отдельные люди — оно не входит в компетенцию рекрутера.
Например, в некоторых компаниях есть так называемые марчары (специалисты по маркетингу и HR), и запуск таргетированной рекламы вакансий входит в их компетенции. В других организациях этим занимаются рекрутеры в связке с отделом маркетинга. И чаще всего нам с вами не надо тщательно осваивать инструменты маркетинга, чтобы самим запускать рекламу.
Но общее представление о том, как работает этот инструмент, нам все-таки необходимо. Итак, таргетированная реклама — это рекламное объявление в той или иной соцсети, которое распространяется на определенную аудиторию. Вы можете выбрать, кому именно вы хотите показать свое объявление, например по географическому признаку или по гендерному, или подобрать аудиторию, у которой есть характерные интересы.
Чаще всего таргетированная реклама настраивается вручную: специалист отбирает факторы, по которым хочет таргетировать (прицельно распространить) свое объявление. Но эта задача, как я уже говорил, редко ложится на плечи рекрутера. Что от вас может потребоваться — это прописать ТЗ подрядчику (сторонней компании или своему отделу маркетинга) и проверить результаты. Если вы захотите детально разобраться, как настраивается таргетированная реклама, вам пригодятся книги по диджитал-маркетингу — там можно найти подробную информацию об этом.
В нашей нише не так много успешных историй о таргетированной рекламе: кейсов, когда вакансия была опубликована таким образом — и все быстро кончилось ее закрытием. Однако бывают и счастливые исключения: например, почитайте кейсы компании Aviasales — они прекрасны! Одна из нашумевших историй — поиск разработчиков с помощью рекламных баннеров со слоганом «Можно смотреть порно на работе». Как показала практика, эта шутка не только вызвала шквал эмоций на рынке, но и отлично зашла целевой аудитории. По результатам грамотно сформированного и настроенного таргетинга с этим и другими аналогичными слоганами компания получила множество откликов от специалистов, которые обладают аналогичным чувством юмора, то есть легко адаптируются к корпоративной культуре, — и быстро закрыла практически незакрываемые вакансии. Поэтому не устану повторять: все зависит от вас. Таргетинг — инструмент рабочий, особенно если им грамотно воспользоваться.
Мне лично ближе другой вариант: использование инструментов таргетинга для ручного поиска кандидатов. Мы можем взять технологии работы маркетологов — и таким образом найти необходимую нам аудиторию. Дальше останется только связаться с потенциальными кандидатами.
Таргетированная реклама имеет множество но: далеко не вся наша аудитория постоянно сидит в соцсетях, поэтому они могут пропустить наше объявление. Далеко не все отреагируют на рекламу: чтобы это случилось, надо поработать над визуалом, над call to action — призывом к действию. Важно, чтобы по ссылке, которую мы публикуем, был конверсионный лендинг, который привлечет внимание и вызовет интерес, а не какой-нибудь убогий сайт-визитка типа «привет из 90-х».
Ручной же поиск, который базируется на инструментах таргетинга, дает возможность непосредственно дотянуться до нужной аудитории. Например, на страничке «ВКонтакте» у человека могут быть не заполнены поля «должность» и «место работы», но по его интересам и подпискам, которые мы выявим с помощью таргетинга, мы можем определить, что он явно является разработчиком и, вероятно, нам подходит.
Я не буду детально рассказывать, как осуществляется такой поиск, — для этого есть учебники по маркетингу. Или вы можете воспользоваться такими общедоступными инструментами, как Pepper.ninja или церебро. рф: они помогают находить необходимые аудитории. На этих сайтах есть бесплатные версии, которые позволяют довольно долго покрывать потребности IT-рекрутера, а также подробные инструкции, как настроить поиск.
Для чего рекрутеру личный бренд? Для того, чтобы у вас был свой поток кандидатов, которые именно вам доверяют и при необходимости обращаются к вам в первую очередь.
Если вспомнить начало этой книги, мы говорили, насколько часто у IT-рекрутеров бывает подпорчена репутация. И наличие сильного личного бренда может радикально облегчить жизнь его владельцу.
Если у кандидата изначально есть к вам доверие, то вам не придется бороться с «минусовой» кармой и пытаться выйти в плюс, борясь с сопротивлением. Мы сразу начинаем работать на равных. Кандидат сам к нам приходит и говорит: «Я подумываю о смене работы — давай пообщаемся».
Собственно, это и есть финальная цель нашего профессионального роста: закрывать вакансии через кандидатов, которые сами к нам пришли. Это довольно долгосрочная работа, но ее результат того стоит.
Где выстраивать свой бренд? Объективно говоря, где угодно. Одна из очевидных площадок — LinkedIn. Довольно много рекрутеров продвигают себя в Facebook, что вполне логично. Во «ВКонтакте» и Instagram специалистов нашего профиля можно встретить реже, но тоже есть. Кто-то уже начинает записывать видео в TikTok, что также актуально: по приросту аудитории можно судить о ее потенциале. Даже в уже почти почившем ClubHouse рекрутеры ходили по тематическим беседам и создавали «комнаты» для общения с кандидатами. Довольно много ребят из нашей с вами профессиональной среды начинают и продолжают работать над личным брендом в самых разных соцсетях.
В зависимости от особенностей соцсети формируется и контент, который вы там размещаете. Если соцсеть визуальная — то меньше текстового контента, больше картинок и видео; если в приоритете тексты — то надо писать.
Где именно строить свой личный бренд, надо решать, отталкиваясь от двух факторов:
● где сидит ваша целевая аудитория;
● где вам комфортно.
С первым фактором мы разобрались в предыдущих разделах. Что же касается второго, то, если вы не идете туда, где вам комфортно, а начинаете ломать себя — вести блог там, где надо, а не там, где удобно, — все это быстро заканчивается.
Например, вы принимаете решение вести аккаунт в Instagram, хотя ненавидите фотографировать. Через месяц принудительных работ терпение, как правило, заканчивается — и блог оказывается заброшенным. В результате происходит негативное закрепление опыта: человек делает вывод, что «вся эта фигня с соцсетями не работает», выстраивание личного бренда — это долго и мучительно, «проживу без него». Только единицы заставляют себя делать посты через не могу. Но тут опять же возникает вопрос: зачем и кому это страдание нужно?
Мне лично довольно комфортно в Facebook — там я и выстраиваю свой личный бренд. У меня достаточно хорошие отношения с текстами, поэтому я с удовольствием пишу посты и мне не приходится себя ломать.
Когда я захожу в Facebook, я не думаю: «Мне надо придумать актуальную идею и правильно раскрыть ее для читателей». Я иду в соцсеть, где мне комфортно, и в удобном для себя формате делюсь мыслями — выдаю какой-то контент. Если бы я каждый раз себя пересиливал, то тратил бы лишний ресурс на создание личного бренда, тогда как в комфортных условиях этого можно достичь, что называется, малой кровью.
При построении личного бренда стоит помнить об общих принципах позиционирования себя, которые актуальны не только в рекрутменте, но и в нашей с вами жизни в целом. Сейчас в тренде искренность. Картонные фоточки в Instagram больше не работают. Именно на волне этой искренности и открытости TikTok так быстро набрал аудиторию: люди на видео — настоящие, они не боятся быть смешными.
Поэтому я призываю вас транслировать в сети то, что вам хочется, и делать это максимально честно, не пытаясь никого копировать. Сколько рекрутеров реально выстроили свой личный бренд в соцсетях? Немного! У нас очень узкая сфера. И если мы начинаем копировать кого-то из коллег по цеху, это сразу становится заметно (и будет выглядеть подозрительно). Важно быть самим собой, не волноваться по поводу осмысленного выстраивания имиджа — и тогда это сработает.
Людям важна искренность, им интересно смотреть на нас настоящих. Поэтому ваш контент не должен быть строго профессиональным. Никому не интересно читать идеально вылизанные странички, на которых есть только «10 советов, как стать успешным» и «топ-5 рекомендаций по поиску работы». Людям интересны люди: пишите про общечеловеческие вещи!
Если у вас что-то «болит» — напишите про свою боль: вы сбились с ног, пока искали какого-то кандидата. Если это правда, то сообщение будет по-настоящему искренним и это вызовет эмоции у читателей. В ком-то это откликнется, потому что он сам попадал в такую историю; кто-то попытается помочь; кто-то проигнорирует — и это тоже нормально.
Если же вы станете делать исключительно профессиональный контент, люди, естественно, поймут, что вы профессионал в какой-то области. Но им не будет видно, какой вы человек. А мы хотим общаться с живыми людьми! Даже огромные b2b-сделки совершаются людьми: это не две огромные компании что-то друг другу продают — это одни люди договорились с другими.
Нам комфортнее работать с теми, кого мы лучше знаем и понимаем. Поэтому задача построения личного бренда — показать, какой ты на самом деле. Многие думают, что, начиная выстраивать личный бренд, необходимо как-то себя ограничивать: личные фотографии теперь якобы запрещены, буду показываться только в рубашке и галстуке. Нет, все разрешено! Естественно, при соблюдении определенного баланса: если вы в течение года запостили 48 рецептов оливье, а тут вдруг заявляете, что вы эксперт в ракетостроении, — сообщество может не понять. Хотя… В этом тоже нет ничего страшного. Возможно, ваша целевая аудитория любит оливье.
Вообще, когда люди только начинают задумываться о личном бренде, у них возникает много страхов (которые впоследствии не оправдываются). Эти опасения заставляют детально планировать свою активность в соцсетях, и очень часто человек исключает из контент-плана себя. Тогда получается, что в сториз вы рассказываете не то, что у вас действительно происходит, а то, что написано в контент-плане. Я настаиваю на том, что вы должны подстраивать план публикаций под себя, а не наоборот.
Если по плану вам сегодня надо подготовить советы кандидатам, как искать работу, вы можете написать серьезную статью, а можете подать ту же самую информацию в формате истории, которая с вами произошла. «Когда я последний раз искал работу, я столкнулся с кучей сложностей. Мне надоело переделывать свое резюме под требования компаний, каждый день откликаться на миллион вакансий, писать сопроводительные письма — а что, черт побери, в них писать?!» Такое искреннее высказывание соберет больше эмоций и отклика, чем сухая история про 10 правил написания сопроводительных писем.
Завершая свой краткий экскурс в создание личного бренда, я еще раз напомню главную идею: людям хочется общаться с людьми, поэтому свой личный бренд надо строить человечным. Не отрекайтесь от личного контента, не отказывайте себе в удовольствии постить шутки, если хочется. Я регулярно публикую шутки, и они собирают больше лайков, чем профессиональные статьи, — ну и что тут поделать? Смеяться приятнее, чем работать. И хорошо, когда для веселья есть лишний повод.
Про какие мессенджеры пойдет речь? В основном про Telegram: когда он появился, значительная часть аудитории, предпочитающая письменный контент, мигрировала именно сюда. Конечно, это не единственный мессенджер, в котором можно искать специалистов, но для наших целей — основной. Большинство IT-специалистов сидят в чатиках Telegram, и с ними здесь можно общаться.
Кроме Telegram, есть еще Slack: здесь так же находится наша целевая аудитория. Особенно если мы говорим про международный поиск, то в Slack он очень и очень актуален. Также можно упомянуть менее популярные мессенджеры типа Gitter, Skype или даже ICQ. Да-да, как ни странно, ICQ еще жив и там можно найти маленькие локальные IT-чатики.
Последнее время все большую популярность приобретает такой мессенджер, как Discord: изначально его активно использовали геймеры. Discord обеспечивает хорошую аудиосвязь для коммуникации во время игры. А во время пандемии, когда начал активно развиваться Zoom, некоторые компании даже перевели корпоративные коммуникации в Discord — это надежно и бесплатно. Поэтому здесь на сегодняшний день встречается все больше международных IT-чатов.
Но это все глобальные международные площадки. Мы же, как я написал, в первую очередь будем говорить про Telegram. Что здесь можно делать? Разумеется, самое очевидное: размещать вакансии.
Что важно помнить про постинг вакансий именно в этом ресурсе? Объявления в Telegram отличаются от вакансий в соцсетях и на job-бордах своей краткостью. В соцсетях необходимо быть лаконичным, а здесь — вдвойне, потому что в мессенджерах очень много коммуникаций и люди не готовы читать лонгриды. По моему опыту, оптимальный пост о найме — это небольшой аккуратный тизер из нескольких предложений, в которых раскрывается самое основное:
● что за компания;
● в чем суть проекта;
● задачи сотрудника;
● стек;
● контакты
● и, в идеале, зарплата.
Далеко не все компании любят сообщать будущую зарплату сотрудника, но здесь это актуально, потому что в мессенджерах про деньги будут спрашивать.
Вообще особенность мессенджеров в том, что вы сразу получаете обратную связь на то, что пишете. Так как в чатах по большей части общаются неформально, обратная связь может прилететь в очень краткой и понятной форме. Если вас никогда в жизни не посылали на три буквы, то добро пожаловать в телегу — и с вами это с большой вероятностью произойдет.
Я всегда предупреждаю рекрутеров о такой возможности и обязательно говорю: в этом нет ничего страшного. Ну, послали! Никто еще от этого не умер. Я не видел ни одного рекрутера, который спрыгнул бы с десятиэтажки из-за того, что ему сказали что-то неприятное. Надо быть готовыми, что в мессенджерах возможно жестковатое общение, и не стоит на этом сильно зацикливаться.
К счастью, мы можем минимизировать риски таких острых реакций — и это несложно. Надо всего-навсего соблюдать правила, о которых мы сейчас подробно поговорим.
Если вы регулярно проводите время в Telegram, то знаете, что там есть чаты (или группы) и каналы. Разница в том, что в каналах есть так называемый фид, в котором администратор размещает контент. Мы, посетители, в канале ничего публиковать не можем. Недавно в каналах добавили возможность комментировать посты, но все равно сами публикации делает только администратор.
Чат (группа) же — это свободное пространство, функционально для нас довольно понятное. Это как чатики из нашего детства, в которых каждый что-то говорит.
Я условно подразделяю IT-чаты в Telegram на три типа:
● Чаты для поиска работы — такие как, скажем, JavaScript Jobs. Они изначально созданы для размещения и обсуждения вакансий.
● Профессиональные чаты, в которых говорят о рабочих моментах, при этом они строго не предназначены для поиска работы. В их названии часто присутствует частица PRO — например, propython, procxx, progo и др. В таких чатах не только нельзя постить вакансии, но рискованно даже поднимать тему поиска работы.
● Чаты, в которых лояльно относятся к постингу вакансий. Изначально они также не про подбор персонала, но в них не запрещается размещать объявления о найме.
Как себя вести, когда вы только пришли в чат? На входе надо представиться — сообщить информацию о себе, как правило, с хештегом #whois. Действует он не во всех чатах, но в довольно большом количестве. И дальше прочитать правила, как именно тут принято общаться. Для этого надо нажать на название чата и посмотреть его описание. Если в описании группы никаких правил нет, смотрим на закрепленное сообщение. Если и там нет, мы нажимаем на значок лупы в правом верхнем углу и вводим слово «правила».
Наша задача при входе в чат — понять, как именно здесь общаются: что можно, а что нет. Если вдруг вы не смогли найти никакой информации, почитайте диалоги или даже спросите участников о нормах общения. Почему это важно?
Звучит очень банально, но, к сожалению, факт есть факт: рекрутеры далеко не всегда читают правила чатов, в которые вступают. У меня есть Telegram-чат для неформального общения рекрутеров, называется BeerHR. И там везде написано, что на входе надо представиться. Это указано в описании группы, в закрепленном сообщении, а также при входе вас встречает бот, который говорит: «Надо представиться!» И как вы понимаете, представляются далеко не все — порой это делают меньше 10 % новичков.
Это грустно, потому что, в частности, из-за такого поведения IT-специалисты смотрят на нас с неприязнью. Игнорируя правила сообщества, мы подтверждаем их догадки о том, что относимся к ним невнимательно. Поэтому я активно призываю вас обращать внимание на детали общения в чатах и не стесняться спрашивать о правилах, если они нигде не прописаны. Да, может быть сотня причин, почему вы этого не сделали, и они будут уважительными или хотя бы понятными, но это не снимает с вас ответственности, а первое впечатление, как известно, невозможно произвести дважды.
Такой, казалось бы, простой шаг понижает вероятность того, что со временем что-то пойдет не так. Хотя, как мы знаем, закон Мерфи гласит: если есть какая-то вероятность, что неприятность может произойти, она случится. Даже если вы соблюдаете правила, всегда может найтись кто-то, кто вбросит нечто малоприятное на вентилятор.
И вы должны быть к этому готовы. Чат — это безличное пространство, в котором находятся люди из разных городов, они все разных возрастов и разного воспитания. И периодически встречаются тролли, которые просто любят издеваться.
Не стоит этого опасаться, а уж тем более принимать близко к сердцу. Кроме того, если вы соблюдаете правила, сообщество это видит, и, вероятнее всего, оно будет на вашей стороне, а не на стороне тролля.
Итак, первая рекомендация очевидна: читаем правила. Вторая: не надо стесняться задавать вопросы. IT-специалисты зачастую рады вам помочь. Единственное условие: эти вопросы не должны быть совсем уж тупыми. Например, «а можно ли постить вакансии?», если везде написано, что нельзя. Хотя, надо признаться, к такому методу иногда приходится прибегать: когда вам очень хочется сообщить о том, что у вас есть вакансии, а размещать их запрещено, приходится таким образом намекать. Но это рискованный вариант, и им явно не стоит злоупотреблять.
Если вы задаете какие-то адекватные вопросы — типа «сколько времени занимает переход с одного фреймворка на другой?», то люди чаще всего готовы поделиться своим опытом.
Кстати, общение в чатах — один из способов выстраивания личного бренда. Вы сидите в каком-то профильном чатике и включаетесь в беседы про HR, регулярно там возникающие. Таким образом вы даете людям понять, что вы адекватны, а значит, можете им быть полезны как специалист в своем деле.
Приходя в IT-чат, не стоит опасаться всего и думать, что там обитают некие «священные коровы», к которым нельзя подходить. Мы все люди, и везде работают одни и те же общечеловеческие принципы. Просто надо по-людски подойти к общению — и все сработает как надо.
Что хорошего мы можем делать в мессенджерах, в частности в актуальном для нас Telegram? Первый очевидный ответ: постить вакансии. Об этой опции мы уже поговорили и на ней останавливаться не будем. Какие еще возможности существуют?
В 2020 году Telegram поменял внутренние алгоритмы работы, и те методы рекрутмента, которые были доступны раньше, перестали работать. Остается не так много инструментов: небольшой набор возможностей по ручному поиску людей.
Одна из наиболее эффективных — выявление потенциальных кандидатов с помощью алгоритма поиска внутри чата. Как это выглядит? Хо-хо, под страшным словом «алгоритм» скрывается максимально простая процедура. Мы заходим в любой IT-чат. Наверху видим значок «лупа». Нажимаем на него и пишем любые ключевые слова, которые нам нужны, — так мы можем найти диалог на интересующую нас тему. Например, сообщение о том, что человек работал с какой-то конкретной технологией. Или разговор о том, кто из какого города: если люди упоминают города, вероятнее всего, они там находятся (или жили, или переезжают). Учитывая, что в чате могут сидеть люди из самых разных мест и это никак и нигде не отражается, такие «географические» беседы помогут нам сориентироваться, кто откуда.
Помимо этого мы можем написать слова, которые намекнут нам на квалификацию человека. Например, указать в поиске «тимлид» или «сеньор» и найти людей, которые писали о себе эти сведения.
Ну и конечно же, мы можем ориентироваться на слова, связанные с поиском работы. Если люди общались между собой о том, что хотят сменить работу или подыскивают новый интересный проект, мы можем это найти и послать им информацию о вакансии. В таком случае в поиске могут присутствовать слова «собеседование», «рекрутер», «тестовое» и многие другие.
Важно помнить, что чат — это обезличенное пространство, где люди чувствуют себя свободно, поэтому могут говорить самым разнообразным языком. В том числе трехэтажным матом, и это не возбраняется.
Мы с вами можем очень хотеть, чтобы к нам в компанию пришел образованнейший, начитаннейший человек, который продолжит любую строчку Афанасия Афанасьевича Фета. Но когда мы находимся в чате, человек, скорее всего, не будет цитировать поэтов XIX века. Люди чувствуют себя в чате намного безопаснее, чем в обычной жизни, говорят на сленге, поэтому нам для поиска надо находить слова, которыми они пользуются в ежедневных онлайн-беседах.
Например, то же самое собеседование в чатах часто называют «собес». Или человек может написать слово «задолбался», если он устал от текущей работы и хочет найти новую. Люди, которые играют онлайн или участвуют в разработке игр, могут использовать слово «ливнуть» (вместо «уволиться»): от английского leave — «уйти с работы». Это намного более вероятное выражение намерений, чем сообщение типа «я планирую прекратить трудовые отношения с моим текущим работодателем».
Поэтому нам важно знать, как общается наша целевая аудитория, и адекватно подбирать слова для поиска. Общаясь на тему рекрутмента, IT-специалисты могут использовать как слово «рекрутер», так и «эйчар», «эйчарша» или даже «хрюша». Это, конечно, грустно слышать, но люди так пишут.
По слову «хрюша» мы можем найти человека, который негативно относится к HR-специалистам, и нам будет с ним сложно. Зачем, спрашивается, он нам нужен? Может быть, именно он и не нужен. Но его слова мог прокомментировать кто-то другой, кто будет более лоялен.
А может быть, именно он и станет идеальным кандидатом. Я не берусь осуждать человека, который пишет неприятные слова в IT-чате, потому что не знаю его опыта взаимодействия с HR и что у него на уме в целом. Может, он погорячился, не подумал, поэтому не стоит моментально делать поверхностные выводы типа «этот человек нам не подходит». Негативное отношение — это не повод не написать специалисту.
Вот несколько примеров, как можно найти ссылки на поиск работы в различных чатах.
И тут возникает вполне логичный вопрос: стоит ли заниматься таким поиском — ходить по чатам, сорсить в них, подбирать слова для поиска? Какова конверсия этого всего? Важно понимать: все зависит от вас.
Много ли кандидатов можно так найти? Конечно, меньше, чем на job-бордах. На ресурсах, предназначенных для поиска работы, кандидатов, естественно, больше. В чатах найти будущих сотрудников сложнее. Но, несмотря на это, такой поиск позволяет выявить тех, до кого иначе просто не дотянуться.
У меня были ситуации, когда люди пробовали этот метод, чтобы закрыть сложные вакансии — «висяки», по которым несколько месяцев никого и нигде не удавалось найти. И по результатам писали мне, что способ сорсинга в чатах настолько же гениален, насколько прост. Многие думают, что это займет много времени и сил, поэтому даже не пробуют. На самом же деле опыт показывает, что метод вполне рабочий.
Еще один немаловажный вопрос: как мы обратимся к кандидату? И это действительно сложная задача. Если мы напишем не очень хорошее сообщение, есть вероятность, что нас проигнорируют или мы даже получим негативную реакцию в ответ. Но, согласитесь, если мы не попробуем, то и не узнаем, каким мог бы быть результат.
Итак, если взять идеальный сценарий рекрутмента в чатах, то последовательность действий будет такой:
● находим чат, а в нем — нужного нам человека;
● ищем информацию об этом человеке, например, по его никнейму. Некоторые рекрутеры используют довольно простые сервисы, такие как namecheckr.com: здесь можно узнать, кто с таким никнеймом регистрировался в разных соцсетях.
Зачем это нужно? Дополнительная информация позволяет нам персонализировать сообщение, которое мы собираемся отправить. То есть сделать его не «холодным» типа «вот у меня есть такая вакансия, интересно — не интересно?», а индивидуальным. «Холодные» сообщения разработчики получают десятками в день. Если же мы собрали информацию о человеке и задали ему вопрос, который затрагивает его интересы, то шансы завязать продуктивный контакт значительно возрастают.
Другая история: у нас не всегда получается собрать полноценное досье или просто нет на это времени. В таком случае нам ничего не мешает персонализировать обращение исходя из той информации, которая у нас уже есть.
Мы же знаем, что этот человек состоит в каком-то конкретном чате, где мы его нашли. Там он писал какое-то конкретное сообщение, например о желании сменить работу или об увольнении. Мы можем почитать другие его переписки. И, прямо ссылаясь на эти конкретные сообщения, написать: «Николай, привет! Я видел, что вы хотели менять работу, а я как раз в поиске специалиста по вашему профилю. Насколько это актуально для вас? Потому что я вижу, что вы писали это полтора месяца назад».
Чаще всего я получаю вполне человеческий отклик типа: «Слушай, ну ты, конечно, заморочился! Вообще особо не ищу, но вакансию пришли». И это здорово, потому что таким образом вы становитесь не просто рекрутером, который нашел резюме и прислал стандартное описание вакансии. Вы становитесь человеком, который искал его по чатам, нашел, вы что-то о нем знаете и задаете адекватные вопросы.
Люди такого, как правило, не ожидают. И этот элемент неожиданности дает отличные результаты. Все уже привыкли к стандартным инструментам рекрутмента, особенно разработчики, которые получают тонны писем и сообщений о вакансиях. Чаще всего такие обращения не персонализированы, а иногда не имеют ничего общего даже с их опытом работы. И тут приходит индивидуальное сообщение, в котором спрашивают, что важно для кандидата на сегодняшний день, что для него актуально с точки зрения поиска работы.
Такой подход сразу дает понять, что вы адекватны и не собираетесь ему ничего впаривать. Вы сразу получаете несколько очков в карму, и вам не надо бороться с негативным отношением, которое есть у многих разработчиков априори. И оно зачастую оправданно, потому что на рынке, к сожалению, достаточно много неадекватных рекрутеров.
Еще один ресурс, которому необходимо уделить особое внимание, — Slack. Это корпоративный мессенджер, изначально созданный для внутренних коммуникаций в компаниях. Он работает в платной и бесплатной версиях.
Slack выглядит немного странно: его структура отличается от привычных нам Telegram, WhatsApp, Viber и др. В Slack есть так называемые воркспейсы. Условно говоря, это пространства, или комьюнити, посвященные какой-то теме. Люди подключаются к воркспейсу, внутри которого есть разные каналы. Например, в воркспейсе JS-девелоперов будут каналы, посвященные различным технологиям, фреймворкам, верстке, и, как правило, в каждом таком большом комьюнити есть отдельный канал по поиску работы. Их названия обычно содержат слова work, hire, job, career и т. д.
Благодаря такой четкой структуре мы имеем возможность использовать для рекрутинга именно те каналы, которые специально для этого предназначены. Как это сделать?
Для начала надо вступить в воркспейс: на входе написать свою почту, получить письмо со ссылкой, пройти по ней и ввести полное имя, краткое имя и пароль. Попав в воркспейс, необходимо пройти двухфакторную идентификацию, добавив свой номер телефона.
Есть воркспейсы, в которые так просто не попадешь: для вступления в них надо дать не только свою почту, но и ответить на ряд вопросов. В частности, рассказать о своем роде деятельности, возможно, даже ответить на теоретические вопросы по той или иной технологии. И только после заполнения этой формы вам придет письмо, по ссылке из которого вы попадете в нужный воркспейс.
Итак, после всех этих испытаний — мы внутри! Что дальше? Находим канал, посвященный поиску работы, и размещаем там вакансию. Основной плюс размещения информации именно здесь заключается в том, что в Slack, в отличие от Telegram, нет такого обширного массива информации. В Telegram любой человек заходит в чат и пишет что-то в общий поток, поэтому вашу вакансию быстро уносит из поля зрения, она теряется. В Slack, благодаря структуризации по каналам, поток информации гораздо меньше. Если люди хотят ответить на сообщение, они начинают отдельную ветку комментариев — так называемый тред. В результате получается довольно структурная беседа, которая не растекается по всему пространству чата.
Поддерживать такой порядок и структуру позволяют достаточно жесткие правила Slack, и о них важно помнить. Если вы размещаете вакансию не в нужном канале, вам сразу же будет выслано предупреждение, а при повторном нарушении — бан.
При условии, что в Slack-воркспейсы не так просто попасть, возникает закономерный вопрос: а нужно ли мне это все? Проходить сложные процедуры, адаптироваться в непонятном пространстве? Кстати, при первом знакомстве Slack вызывает очень много недоумений: кто это придумал и кого он этим хотел наказать?
На самом деле, несмотря на первоначальное отторжение и сложности процедур, этот мессенджер может быть очень полезен для рекрутера. Здесь сидит достаточно много разработчиков, причем высокого уровня — от middle+ и выше. Конечно, можно найти и отдельные чаты для джунов (например, чат какой-нибудь онлайн-школы или отдельного сообщества), но «в среднем по больнице» уровень специалистов достаточно высокий.
Кроме того, в Slack много англоязычных чатов, где вы можете найти как зарубежных специалистов, так и российских разработчиков с хорошим знанием английского. Естественно, если вы постите вакансию в таком канале, то она должна быть на английском: это простые правила приличия, о которых нельзя забывать.
Как я уже сказал, благодаря структуре Slack вакансия может провисеть в канале довольно долго, за счет чего вы получите значительно больший охват целевой аудитории, чем в Telegram.
Можно ли здесь, по аналогии с другими ресурсами, искать людей по ключевым словам в переписке? Глобально — да. Но есть одно важное ограничение. Так как это корпоративный мессенджер, в нем есть платная часть. В частности, хранение истории переписки — это оплачиваемая функция. В бесплатной версии история хранится какое-то определенное время и оно зависит от активности воркспейса. Если это пространство, где люди общаются активно, вы увидите историю только, например, за месяц.
Таким образом, в вашем распоряжении будут сообщения не более чем месячной давности. Насколько это критично? Возможно, для реализации ваших целей и этого достаточно. В любом случае, как и в любых других мессенджерах или соцсетях, важно не бояться использовать все инструменты, которые есть у вас в арсенале. Пробуйте — и даже если сейчас именно этот инструмент не сработает, ничего страшного! Вы наработаете опыт, заведете новые контакты, и рано или поздно этот труд даст результат.
Несмотря на то что Slack — это, объективно говоря, круто и полезно для рекрутера, специалисты нашей профессии сюда доходят редко. В Slack значительно меньше рекрутеров, чем в том же самом Telegram, при этом кандидатов — много! Здесь есть стотысячные профильные чаты, в которых можно провести время с пользой.
Slack отпугивает многих: людям кажется, что он абсолютно не user friendly, и из-за этого они отказываются с ним взаимодействовать, тем самым упуская возможности. Поэтому я призываю вас перед тем, как перелистнуть страницу, скачать это приложение и начать в нем осваиваться. Ничего страшного в нем нет! Вернее, есть: он действительно ужасен, но за этим первоначальным дискомфортом кроются возможности, которые могут привести к отличным результатам.
У IT-специалистов есть несколько ресурсов, где они часто проводят свое время. Эти платформы сложно отнести к соцсетям в полном смысле этого слова, поэтому я решил вынести их в отдельную главу. Что же я подразумеваю под специализированными ресурсами, на которых можно заниматься рекрутментом?
Первое и самое очевидное, что приходит на ум, — это Хабр Карьера и, собственно, сам Хабр. Что это такое?
Хабр (habr.com) — это большой информационный новостной портал по IT-тематике. Здесь специалисты пишут статьи и обсуждают новости индустрии, компании ведут свои блоги; это один из наиболее актуальных источников, по которым можно следить за новостями, историями и мировыми событиями в области технологий. Естественно, многие IT-специалисты его читают, чтобы быть в курсе происходящего в их направлении деятельности. А кроме всего прочего, они заводят здесь свои аккаунты, чтобы участвовать в обсуждениях и публиковать статьи. Так что если хотите «быть в контексте», то советую тоже читать Хабр.
У Хабра есть такое подразделение, как Хабр Карьера. Изначально этот сервис назывался «Мой круг» и принадлежал компании «Яндекс», но в 2015 году его купил Хабр и сделал узкоспециализированным карьерным сайтом для айтишников.
На сегодняшний день этот ресурс выглядит как job-борд, и с поиском специалистов на нем все обстоит просто: здесь можно размещать вакансии или получить доступ к базе резюме — и то и другое, разумеется, за деньги. Бесплатно можно просматривать не больше 20 резюме в день или, как мы уже разобрали, писать X-Ray-запросы. На сегодняшний день они работают всё хуже, но пока еще работают.
В чем достоинства этого ресурса? На Хабр Карьере очень много профилей специалистов, и не использовать этот источник — просто грех. Единственный недостаток — среди аккаунтов много устаревших, заведенных много лет назад и не обновляющихся. Многие специалисты не расписывают свой опыт, а используют ресурс только для того, чтобы просматривать вакансии, отслеживать тенденции на рынке.
Поэтому зачастую рекрутеры считают, что это старый ресурс, он давно позабыт-позаброшен, но это далеко не так. Для многих компаний Хабр Карьера — первый и основной источник поиска специалистов, так что призываю вас ни в коем случае про него не забывать.
Что же касается самого Хабра, здесь также можно искать кандидатов — правда, таких четких и понятных инструментов поиска, как в разделе Карьера, здесь нет. Единственно, что можно рекомендовать, — это X-Ray-запросы для поиска аккаунтов специалистов. На Хабре есть профили людей, в которых могут быть указаны должность, сфера деятельности, локация и другие подробности.
Мы уже разбирали, как писать X-Ray-запросы в целом, давайте посмотрим, что сейчас может сработать на Хабре. Например, я хочу найти разработчика на Python в Москве. Тогда в запросе я пишу: site: habr.com/ru/users/ moscow OR москва python intitle: aka
Соответственно, я прошу Google отправиться на сайт habr.com/ru и зайти в директорию Users — это «папка», где хранятся профили пользователей. Дальше в адресе должен идти никнейм. Так как они все разные и их не угадать, то на этом адрес оканчивается. Следом идет локация на двух языках, упоминание Python, и, чтобы выйти именно на основные страницы пользователей, я добавляю intitle: aka — слово, которое используется в заголовках именно на таких страницах.
Если я не добавлю это уточнение intitle: aka, я могу попасть не на основную страницу пользователя, а, скажем, в раздел, где хранятся его публикации. В таком случае я выйду на человека, у которого в профиле нет ничего про Python, зато он когда-то написал статью, в которой говорил, как он, к примеру, люто ненавидит Python. Вроде бы все правильно сделал: есть упоминания Москвы и Python, но результат не совсем тот, какого хотелось бы.
На всякий случай еще раз напомню: при написании X-Ray-запросов надо быть внимательным и не надеяться на готовые формулы, потому что то, что я только что предложил, уже через месяц может устареть и не работать. Ищите новые зацепки — и все получится!
Еще один специализированный ресурс, на котором можно искать кандидатов, — это сервис GitHub. Он есть у многих айтишников, в основном у разработчиков. Что такое GitHub? Это сервис для хостинга IT-проектов. Как перевести это выражение на понятный язык? Представьте себе, что вы разработчик из Москвы. И у вас есть сервис, куда можно загрузить часть кода, чтобы совместно с другими разработчиками из Норильска, Сан-Франциско и Нью-Дели его дорабатывать. Для вас, команды удаленных разработчиков, это ресурс, обеспечивающий возможность вести совместные проекты.
Многие программисты используют GitHub, чтобы закидывать туда примеры кода и использовать в процессе трудоустройства: можно прислать работодателю ссылку на код в GitHub, и компания оценит, что умеет делать их потенциальный сотрудник.
Также разработчики используют сервис, чтобы вести там свои личные проекты. На работе человек кодит в одном месте, а в свободное время делает что-то для себя и выкладывает это на GitHub.
Соответственно, нас будут интересовать профили пользователей на GitHub. Как выглядят аккаунты на этом ресурсе?
Вы заходите в профиль пользователя, автоматически попадаете во вкладку overview и видите его имя, никнейм, ниже есть информация, сколько у этого человека подписчиков и на скольких подписан он сам. Эти показатели нам отчасти важны: они, как и в соцсетях, сообщают о популярности кандидата. Конечно же, далеко не все программисты ведут GitHub; так же, как совершенно не факт, что востребованный на этом ресурсе программист нам подойдет. Однако такая популярность — один из хороших показателей, на который мы можем теоретически опереться в рекрутменте.
Прямо под вкладкой overview располагаются либо закрепленные (pinned), либо популярные (popular) репозитории автора. Выглядят они как карточки. На них будет указано название, отмечен язык, на котором написан код, иногда есть описание, для чего он предназначен, плюс звездочки и количество форков, о которых мы поговорим чуть позже.
Ниже на этой же странице вы увидите, в частности, зеленые квадратики, которые сообщают о том, насколько активен был человек в течение последнего года (contributions in the last year). Исходя из этого легко сделать вывод, насколько актуален профиль.
Еще ниже во вкладке overview хранится история изменений (contribution activity) — когда и что человек менял в своем репозитории. Например, в июле 2021 года к репозиторию под таким-то названием был добавлен 1 коммит (1 изменение).
Справа от overview есть вкладка repositories (репозитории) — это часть, которая нас интересует больше всего. Что это такое? Говоря простым языком, это папка с проектами.
Именно здесь вы можете найти фрагменты кода, написанные кандидатом. Если вы будете отправлять тимлиду резюме человека, то ему будет интересно взглянуть на примеры работ из репозитория.
Внутри этой виртуальной папки располагаются сами проекты, а под ними часто есть описания и важные значки, которые также предоставят нам полезную информацию. Вот как они выглядят: звездочки (оценки) и так называемые форки (вилки).
Соответственно, чтобы оценить полезность кода, пользователи ставят звездочки. Или они могут взять код себе: говоря языком соцсетей, репостнуть его в свою папку — и там дорабатывать или использовать для своих проектов. Значок, показывающий количество репостов, выглядит как вилка, и на языке программистов забрать себе код называется «форкнуть репозиторий». Если люди часто форкают тот или иной репозиторий, мы можем сделать вывод, что он полезен, важен и, вероятно, написан на хорошем уровне.
Если же мы зайдем в сам репозиторий, сориентироваться в том, что именно и как кодит разработчик, нам помогут файлы readme.
Если вы помните, в юности, переустанавливая те или иные программы на компьютере, мы читали файлы readme, чтобы понять, как, что и в какой последовательности делать. На GitHub эти файлы несут много полезной информации. В них указывается, о чем именно этот проект, что делает код — для чего он нужен; плюс, возможно, какие-то инструкции и детали. Это та часть репозитория, которую мы, рекрутеры, можем понять и оценить. Хотя тоже не всегда. Иногда это техническое описание того, как работает проект, и нам от этого ни горячо ни холодно: запустить-то мы его все равно не можем, если не умеем. Другие файлы и подавно могут привести нас в некоторое смятение, если мы сами не кодим.
Еще одна любопытная история — вкладка pull request: это запросы, которые делает форкнутый репозиторий. Спокойно, без паники! Сейчас разберем, что это значит.
Представьте, вы взяли чей-то репозиторий — форкнули его себе и дописали какой-то кусочек кода. После этого вы отправляете pull request автору репозитория. Вы говорите ему: мол, посмотри, дружище, что интересного я сделал с твоим кодом, — кажется, стало лучше, бодрее, продуктивнее; добавь, пожалуйста, мои старания в основную ветку.
Автор смотрит и думает: да, прикольно — это то, что нужно! Новые фрагменты кода помогают решить задачи, которые были поставлены. И добавляет изменения.
Таким образом ведется командная разработка, и таких продуктов с открытым исходным кодом, который может доработать каждый желающий, очень много. Помните, мы говорили об операционных системах с открытым исходным кодом, например о Linux? В отличие от него, в Windows, скажем, весь код под семью замками.
Итого: вкладка pull request сообщит нам о том, сколько запросов по изменению к данному репозиторию было сделано. А это опять же показывает, насколько код актуален, востребован и важен для людей.
Что еще интересного мы можем посмотреть в репозитории? Нам, например, важна и интересна кнопочка commits (коммиты). Что это такое? Сделать коммит — это, говоря общечеловеческим языком, зафиксировать изменение в любом из файлов. То есть мы что-то поменяли в коде и сохранили это — сделали коммит. Уверен, что у многих из вас, кто прочитал всю эту историю, возникнет резонный вопрос: к чему все эти трудности? Действительно, зачастую можно обойтись без этого. Но все зависит от вакансии, над которой мы работаем, от уровня и направления деятельности людей, которых мы ищем, и, конечно же, от количества таких специалистов на рынке. Разработчикам несвойственно держать свои данные открытыми, поэтому иногда нам приходится прибегать к таким сложным действиям.
Возможно, вам не пригодятся эти знания именно сейчас, но рано или поздно вы можете попасть в ситуацию, когда нет другого выхода, кроме как идти на GitHub и разбираться в этих непростых ручных методах поиска, чтобы закрыть вакансию. Призываю вас начать осваивать эти инструменты уже сейчас!
А теперь хорошие новости: мы разобрали принципы, по которым работает ручной поиск в GitHub, — теперь давайте познакомимся с несколькими способами автоматизации этого процесса. Если они в один прекрасный день перестанут работать, вы всегда сможете найти кандидатов вручную, а пока можно слегка расслабиться, скачав несколько расширений и сервисов, которые сделают всё за вас.
Сначала уточню: наибольшая часть работы рекрутера проходит в браузере Chrome. И расширения, о которых я буду говорить, подходят именно для него. Вот мой топ инструментов для работы в GitHub.
OctoHR — еще один плагин, который может сделать жизнь рекрутера более простой и приятной. Это расширение не только позволяет искать контакты, но и помогает проанализировать профиль человека. Делает оно это не слишком глубоко: благодаря расширению вы получите поверхностное представление о том, какое количество репозиториев и на каком языке у человека имеется в процентном соотношении (то есть какой язык он использует чаще, какой реже). После установки оно работает априори: вы открываете профиль на GitHub, и во всплывающем окне слева у вас появляется информация.
Ссылка на плагин: https://chrome.google.com/webstore/detail/octohr/beiklbdjdmfkgchmiabjejdlpaoicbef
CandyJar — это расширение, которое позволяет чуть глубже проанализировать профиль. Вы сможете узнать, что у человека происходит в аккаунте, с какими технологиями и когда он работал. Сервис очень полезный, но платный. Из бесплатного функционала здесь есть, в частности, полезная фишка — поиск страничек выбранного человека в других соцсетях. Например, если у кандидата есть LinkedIn, то плагин может подгрузить информацию и оттуда.
Ссылка на плагин: https://chrome.google.com/webstore/detail/candyjar/mlelamfpbkmcjighmglfodehbknhmlod
Git-Awards — сервис, который помогает искать топовых пользователей GitHub: вы можете отсортировать самых популярных, активных, востребованных в сообществе разработчиков по городам, странам, по выбранной технологии и другим параметрам.
Ссылка на плагин: http://git-awards.com/
Octohunt — полезный сервис по поиску людей на GitHub, который работает элементарно: вы вводите интересующую вас технологию и город, нажимаете «искать» — и получаете ссылки на необходимых людей. Не могу сказать, что на этот сервис можно стопроцентно рассчитывать, но порой он бывает полезен.
Ссылка на сервис: https://octohunt.com/
После этого списка автоматических способов поиска, я надеюсь, вы пришли к выводу, что GitHub — это не так страшно, как могло показаться вначале. Теперь переходим к различным способам ручного поиска по ресурсу: как и следовало ожидать, на GitHub есть операторы поиска, которые могут быть нам очень и очень полезны. Хотелось бы, конечно, сказать, что это тоже булевы операторы и сейчас будет легко, но нет. Не в этот раз. Изучить их в полном объеме можно здесь: операторы поиска в GitHub https://docs.github.com/en/github/searching-for-information-on-github/searching-code#considerations-for-code-search.
В этой книге мы рассмотрим основные операторы, которые могут быть наиболее актуальны для рекрутера.
location: — в поисковой строке GitHub мы можем ввести этот оператор, поставить двоеточие и без пробела написать город, который нас интересует: location: moscow. Таким образом мы получим в выдаче всех людей, которые указали в аккаунте локацию Moscow. При этом, как вы понимаете, мы не увидим людей, которые указали свое место проживания как «Москва». В отличие от Google, GitHub не распознает такие синонимы. Если мы хотим, чтобы в выдаче оказались и те, кто написал Moscow, и те, кто написал «Москва», мы, по логике вещей, должны поставить между этими двумя локациями оператор OR. И это будет одна из наиболее распространенных ошибок.
Но тут возникает другая проблема: на GitHub далеко не все пользователи указывают свою актуальную локацию, а многие и вовсе ограничиваются указанием Russia. Поэтому узнать, что они живут в нужном вам городе, не так-то просто. Что с этим делать? К сожалению, ничего — придется с этим жить. К счастью, GitHub предоставляет много других возможностей поиска.
language: — этот оператор позволяет находить людей, у которых есть репозитории на определенных языках программирования. Соответственно, мы можем написать language: php или language: java — и найти тех, кто работает с этими технологиями. Здесь действует та же логика, что и с локацией: если мы хотим найти или тех, кто работает на php, или разработчиков java, то пишем эти запросы через пробел.
Но тут возникает следующий вопрос: зачатую есть какие-то языки, которые мы хотим написать в поиске, но в реальности репозиториев на этих языках может не быть. Например, для разработчиков java есть фреймворк sрring — помните, да? Если мы хотим найти специалистов, которые работают со spring, казалось бы логичным написать поисковый запрос language: spring. Но это будет неверно, потому что в данном случае язык все же java, а фреймворк (то есть инструмент, который помогает разработчику кодить на java) — spring. Из-за этого найти людей, у которых есть репозитории на spring, будет не так-то просто.
Что делать? Можно написать language: java и дальше, через пробел, — spring. Таким образом система будет искать репозитории на java, а spring будет ключевым словом, которое система разыскивает в профиле. Если у человека в профиле написано что-то про spring, то мы получим это в выдаче. В данном случае есть риск, что у специалиста есть опыт работы со spring, однако он этого нигде не указал — и мы его упустим. Но с этим, к сожалению, ничего не поделать.
Поисковые операторы можно объединять: например, если вам нужен человек из Москвы, который пишет на java с использованием фреймворка spring, то запрос будет выглядеть так: location: moscow location: москва language: java spring. Выдача будет довольно узкая, но актуальная — для обработки в первую очередь.
followers: — этот оператор позволяет искать репозиторий с определенным количеством подписчиков. То есть вы можете написать followers:10 — и увидеть все репозитории, у которых больше 10 подписчиков. Но не думайте, что здесь всё как в Instagram. Даже у крутых, известных на рынке разработчиков может быть 200–300 подписчиков. Так что это такой фильтр, который выдает очень субъективный результат. Также в поиске можно задать, например, followers:10..20 — в таком случае вы увидите все репозитории, у которых от 10 до 20 подписчиков.
Такой поиск может быть полезен, если вы хотите найти активных пользователей GitHub, которые делают какие-то актуальные проекты.
В данном случае операторы также можно сочетать, создавая более точные поисковые запросы и получая более узкоспециализированную выдачу. Например, вы можете написать: followers:5..9 location: moscow language: php — и увидеть людей, у которых от 5 до 9 подписчиков, они находятся в Москве и у них есть репозиторий на PHP.
filename: — как и следовало ожидать из названия, этот оператор ищет информацию по имени файла. Казалось бы, что с ним делать: файлы могут называться как угодно. Однако он для нас бывает крайне полезен, так как многие разработчики хранят на GitHub свои резюме — и мы можем найти эти файлы по названию. Если написать filename: resume, filename: cv или filename: резюме, мы увидим, сколько всего полезного для наших целей хранится на ресурсе.
Следующий логичный шаг, который напрашивается, — дописать в запрос локацию и язык разработки. То есть приделать к filename: resume наши стандартные запросы типа location: moscow и language: php. Но, к сожалению, так ничего не сработает, потому что, используя оператор filename, мы ищем среди файлов, а те не могут быть привязаны к месту жительства или технологиям.
В данном случае надо написать значительно более простой запрос: filename: cv php moscow. Тогда получается, что мы будем искать эти слова внутри файла под названием cv. А такая информация, вероятнее всего, в резюме будет.
Надо быть готовыми к тому, что при файловом поиске в выдаче будет много неактуальных резюме. Разработчики когда-то их сделали, разместили на GitHub и там забыли. Но в то же время зачастую можно найти вполне актуальные резюме, которые люди специально размещали на GitHub, чтобы их не нашли на job-бордах или каких-то других ресурсах: они предпочли остаться незамеченными. Но, как говорится, не тут-то было! Теперь с усвоенными из этой книги навыками вы их легко и быстро обнаружите.
Еще одна важная особенность резюме на GitHub заключается в том, что они могут выдаваться в разных форматах. Некоторые из них похожи на стандартное резюме, к которому мы привыкли: текст с информацией об образовании, опыте работы и т. д. А некоторые файлы могут выглядеть странно для человека, который не является разработчиком, — в частности, содержать строчки кода. Однако даже в таких резюме можно найти контакты и другую необходимую информацию — главное, не пугаться, а детально рассмотреть, что вы получили.
В процессе поиска важно обращать внимание и тщательно отслеживать, где именно — то есть в каком разделе GitHub — вы ищете информацию. Посмотрите на предыдущий скриншот: когда мы ищем по имени файла, слева появляется черточка рядом с разделом Code (на экране она красная). То есть мы ищем файлы в данном разделе. Предыдущий поиск — по языку и локации — мы осуществляли в разделе Users (пользователи). Если вы будете искать файлы среди пользователей, выдача будет не совсем такая, какую мы хотели бы увидеть.
Кстати, чтобы осуществлять поиск по файлам, надо быть обязательно зарегистрированным на GitHub. Если предыдущие варианты поиска по локации и языку доступны незалогиненным пользователям, то искать среди файлов можно только после создания своего аккаунта.
Независимо от того, собираетесь вы разыскивать на GitHub файлы или нет, я очень рекомендую здесь зарегистрироваться. На сегодняшний день GitHub является одним из основных ресурсов для большинства разработчиков, поэтому для нас, специалистов по рекрутингу в IT-сфере, иметь здесь аккаунт — это, что называется, «золотой стандарт», обязательная составляющая профессии. Даже если вы не умеете и не собираетесь кодить, знать, как устроен GitHub, уметь на нем ориентироваться и через него выходить на специалистов — полезный и важный навык.
Есть операторы, которые используются несколько реже, но также могут быть полезны. Например, extention: — он отвечает за расширение файла, который мы ищем на гитхабе. Это полезно, потому что с его помощью мы можем искать файлы формата json, которые не индексируются Google. То есть если я напишу extension: json filename: cv, я увижу все файлы с расширением json и названием cv. Хотя при поиске, конечно, extension: нужен нам гораздо реже.
Теперь давайте рассмотрим возможности использования X-Ray-запросов на GitHub. С их помощью здесь также можно искать людей, но результат может быть… разным! В 2021 году X-Ray стал работать чуть хуже: в GitHub пытаются защитить свою информацию от такого способа доступа. Однако, как я уже неоднократно писал, если вы понимаете принцип построения запросов, то никакие ограничения вам не страшны: как только устаревает одна «зацепка», вы с легкостью можете найти другую. Ну или без легкости. Иногда, в общем-то, и не найдете ничего — так тоже бывает. Но, по крайней мере, вы сможете обрабатывать этот ресурс «до последнего вздоха».
На текущий момент, то есть по ситуации на начало 2022 года, для GitHub возможно создать не так уж много X-Ray-запросов. Вот несколько вариантов. В первую очередь мы, конечно же, заходим на google.com, в поисковой строке пишем site: github.com, а потом добавляем «block or report» — это то словосочетание, которое встречается только на страницах пользователей. С его помощью мы отсекаем всю лишнюю информацию с сайта.
К нему добавляем ключевые слова, которые нам нужны. Получается что-нибудь типа site: github.com ruby moscow OR москва "block or report" — то есть мы хотим найти разработчика на Ruby из Москвы. И вот как будет выглядеть наша выдача.
Также вместо «block or report» можно использовать словосочетание «contribution activity» — оно располагается над зелеными квадратиками, которые показывают активность пользователя. Содержится она только в профилях людей, поэтому отлично нам подходит.
На всякий случай еще раз напомню: сейчас эта зацепка более-менее работает, однако не факт, что ситуация останется такой же через месяц или даже завтра. Но попробуйте! Не получится — вы знаете принцип, по которому построить новый X-Ray-запрос, чтобы в любой момент найти новые пути решения вашей задачи.
Итак, у нас получится следующий запрос: site: github.com ruby moscow OR москва "contribution activity"
Еще один приятный сюрприз, который подкидывает нам поиск на GitHub через X-Ray: если вы будете писать довольно общие запросы и пытаться найти резюме, то обнаружите, что существует не только GitHub.com, но и GitHub.io. Здесь также можно найти резюме интересных кандидатов. Соответственно, запрос для поиска по нему будет не сильно отличаться от предыдущего. Мы только что искали Ruby-разработчика из Москвы среди профилей людей, теперь можем точно так же поискать его среди страниц: site: github.io резюме OR cv ruby moscow OR москва. И вот какой результат мы получим.
И последний в моем личном списке (но не во всемирной паутине, естественно) ресурс для поиска кандидатов — StackOverflow. Что это такое? StackOverflow — это международная система вопросов и ответов по IT. Любой желающий может создать здесь аккаунт, задать вопрос и получить ответ или, наоборот, выступить в роли эксперта. На этом ресурсе люди с разным опытом и уровнем знаний могут делиться информацией, находить ответы на волнующие их вопросы и получать ценные рекомендации в своей профессиональной области.
То есть, по сути, это большое комьюнити людей с огромной базой знаний, которым не все равно. Мало того что здесь можно найти много специалистов высокого уровня — для нас, рекрутеров, этот ресурс — ценный источник кандидатов с определенным набором soft skills. Если компания хочет видеть в своей команде людей с определенными ценностями — специалистов, которые готовы делиться знаниями, отвечать на вопросы, помогать коллегам в профессиональном развитии, — то ребята со StackOverflow являются той самой целевой аудиторией. Можно предположить, что если они активно делятся знаниями здесь, то будут аналогично вести себя и в компании (хотя, конечно, эту догадку надо будет проверять).
StackOverflow не очень активно используется рекрутерами в России, потому что у нас есть много других ресурсов — и до этого зачастую руки не доходят. Действительно, зачем разбираться с каким-то очередным, не самым простым и понятным ресурсом, если есть привычный LinkedIn? Но я все же настаиваю, что научиться ориентироваться и работать с StackOverflow имеет смысл. Почему?
Сидят ли там какие-то уникальные люди, которых больше нигде не найдешь? Нет, конечно. По большей части на сегодняшний день у каждого отдельно взятого человека есть аккаунты в разных соцсетях, и найти какой-то «волшебный» ресурс, где собрались специалисты, которых больше нигде нет, практически нереально. Наш мир движется к тому, что люди ищут источники информации и единомышленников на самых разных ресурсах, и очень редко можно встретить человека из IT, у которого нет аккаунта в нескольких соцсетях одновременно.
Однако на StackOverflow порой можно найти актуальную информацию о человеке. Он мог десять лет назад зарегистрироваться на Facebook и с тех пор не обновлять информацию, три года назад забыть свое резюме на GitHub, зато на StackOverflow он будет задавать те вопросы, которые для него актуальны здесь и сейчас. По этим самым вопросам и ответам мы можем понять, с какими технологиями человек работает сегодня, в каких вопросах разбирается, а значит, с высоким уровнем уверенности определить, насколько он интересен для закрытия той или иной вакансии.
Профиль в StackOverflow строится по стандартным параметрам: есть никнейм и локация, кто-то указывает свой опыт работы и специализацию, адрес сайта и контактные данные. Чтобы понять, чем именно потенциальный кандидат занимается и интересуется, важно обращать внимание на теги, которые он использует: по каким тегам он задает вопросы или на что отвечает.
Теги могут слегка сбивать с толку, потому что под ними может скрываться разная информация. Самое простое — теги по языку программирования, например Java или PHP, но возможны и более узкие формулировки. Например, человек пишет вопросы с тегом jquery. Зная, что это библиотека для JavaScript, мы поймем, на каком языке программирования он кодит, даже при условии, что сам тег JavaScript у него ни разу не упоминается. Нельзя сказать, что такая ситуация возникает часто, но она возможна.
Поэтому в тегах важно научиться ориентироваться. Если мы знаем, какие теги существуют, какие у них есть синонимы и как они связаны между собой, то никакие узкоспециализированные слова нас с толку не собьют. Мало того, что мы сможем по ним искать людей, — такая работа по изучению взаимосвязей позволит выявить много интересного для себя лично, для повышения своего уровня профессионализма и получения дополнительных идей для поиска.
К счастью, все теги на ресурсе указаны, поэтому страдать, придумывать и фантазировать на тему не нужно — достаточно только внимательно вникнуть в то, что происходит. Найти все теги можно здесь: https://stackoverflow.com/tags.
Эту информацию дальше можно использовать для разных целей: например, для формирования X-Ray-запросов или для работы с автоматизаторами поиска на ресурсе. Про X-Ray-запросы мы уже знаем немало (но ниже все равно рассмотрим примеры), а что касается автоматизаторов поиска — их относительно немного, но найти можно, и работают они хорошо. Автоматизаторы могут добывать самую разную информацию о людях со StackOverflow и даже выкачивать в удобные таблицы. Тут, наверно, мне стоит вас предупредить, что по закону хранение персональных данных могут осуществлять только операторы персональных данных и с согласия тех самых лиц, чьи персональные данные они собираются хранить. При этом сами эти данные — открытые. Если мы просто находим их, то не нарушаем никаких законов, потому что люди сами добровольно заполнили информацию о себе. А вот с хранением надо быть аккуратными.
Итак, давайте рассмотрим подробнее, какие у нас есть инструменты для поиска людей на StackOverflow.
Размещать вакансии — как ни странно, здесь это можно делать! Правда, за деньги, и немалые. Поэтому такой способ массовой популярностью не пользуется. Если ваш заказчик готов тратиться на хантинг «звезды» и для этого готов вкладываться, то вариант вполне рабочий. В других же случаях переходим ко второму пункту.
X-Ray-запрос — идем в Google и просим поисковую систему хорошенько покопаться на интересующем нас сайте. Чтобы это сделать, важно знать, что на StackOverflow есть поддомен careers — грубо говоря, отсек, посвященный трудоустройству. Если мы обратимся туда, то получим список резюме специалистов. Запрос может выглядеть примерно так: site: careers.stackoverflow.com Moscow — и вот они, наши потенциальные кандидаты из Москвы.
Еще один вариант — обращение к директории (папке), в которой хранятся резюме. Пишем запрос: site: stackoverflow.com/cv — и в конце добавляем то, что для нас актуально, например Moscow ios (то есть специалист, живущий в Москве и работающий с технологиями ios). В ответ получаем список резюме людей по заданным параметрам.
Для следующего примера нам понадобится хорошее знание синонимичных тегов. Предположим, нам надо найти разработчика из Москвы, который кодит на PHP. Среди тегов, посвященных PHP, есть следующие варианты: просто php, или php-oop, php5, php-frameworks. Писать в запросе и php, и php-oop нет смысла, потому что второй тег априори нам встретится, так как в его состав входит php. А вот, например, php5 Google воспримет как другое слово, ведь пятерка прилеплена к самому языку программирования. Так запрос с подобным синонимом принесет больше результатов. Получается: site: stackoverflow.com/users php OR php5 moscow. Результат — ссылки на профили с указанными данными.
Автоматизатор Stack Exchange, с помощью которого можно написать специальный SQL-запрос, который сам найдет пользователей вместо нас. Есть два варианта работы с этим инструментом. Первый вариант: проходим по ссылке http://bit.ly/stackoversearch1 и заполняем форму слева — кого именно мы хотим найти. Исходя из наших требований справа будет формироваться SQL-запрос.
Когда все готово, нажимаем кнопку «COPY QUERY AND GO TO DATA.STACKEXCHANGE», попадаем на другую страницу, где вставляем скопированный SQL-запрос и нажимаем «Run Query». Выглядеть это будет пугающе, но нам, к счастью, разбираться в этом коде не надо.
После нажатия получаем систематизированную выдачу нужных профилей.
Есть вариант чуть попроще. Заходим по другой ссылке http://bit.ly/stackoversearch2, вводим тег и локацию внизу, нажимаем «Run Query» и ждем, пока сформируется выдача. Кстати, да, тут нам снова поможет знание тегов на SO.
С одной стороны, параметров здесь меньше — только тег и локация, а значит, и релевантность результатов будет ниже. Но не тут-то было. На мой скромный взгляд, вторая ссылка дает больше результатов, чем первая. Но я всячески призываю вас самостоятельно во всем разбираться и делать выводы. А потому пробуйте, сравнивайте и докручивайте, пока не получите необходимые результаты.
В самом начале этой книги мы говорили о том, что изначально на развивающийся IT-рынок пришли далекие от сферы IT рекрутеры со своими правилами найма. Они начали выстраивать в компаниях традиционные, достаточно сложные его процедуры. Чтобы понять релевантность кандидата, организовывалось много этапов собеседований и тестовых заданий. Но все меняется, и сейчас есть стойкая тенденция к упрощению этого процесса: количество этапов собеседования и тестовых заданий сокращается.
Таким образом, для кандидатов создаются наиболее благоприятные условия: им не надо мучиться, страдать и по десять раз ходить в одну и ту же компанию, чтобы потом узнать, что они не подходят (или даже подходят, но уже не хочется!). Конечно же, продолжительность предварительного общения может варьироваться в зависимости от уровня вакансии и особенностей компании, тем не менее «в среднем по больнице» процесс трудоустройства происходит быстрее и проще.
Хотелось бы сказать, что это мы все так поумнели, но, кажется, у нас просто не осталось выбора. Кандидаты сами теперь решают, куда они хотят идти, а куда нет. И если компании нужны специалисты, ей часто приходится подстраиваться под рынок.
Какие этапы найма обычно проходит кандидат:
1. Телефонный скрининг — короткое общение с рекрутером, дающее ему возможность понять, есть ли у кандидата самые необходимые скиллы, насколько вакансия ему интересна.
2. Первое собеседование — в нем участвуют кандидат и рекрутер. В некоторых компаниях перед техническим интервью внедрено базовое — с рекрутером, позволяющее сориентироваться, насколько кандидат подходит, расспросить подробнее про его опыт, узнать получше про софты, ответить на вопросы. Редко когда такое интервью занимает больше часа. Порой этот этап исключают, что тоже вполне логично: пригласить рекрутера можно и после техинтервью, и на более поздних этапах.
3. Тестовое задание — выдается в процессе первого собеседования или сразу после него. Оно позволяет оценить уровень технических навыков кандидата. Зачастую именно тестового задания хватает тимлиду, чтобы сделать вывод, стоит ли дальше общаться с кандидатом.
4. Техническое интервью — общение с будущим руководителем (тимлидом) и, возможно, знакомство с командой. Здесь руководитель уже более точно может оценить навыки кандидата, получить представление о его опыте, узнать, почему он так или иначе решил тестовое задание. Или спросить, например, каким образом он бы оптимизировал под нагрузки такой-то сервис. Иногда на технических интервью встречаются теоретические вопросы, и они обычно бесят кандидатов, потому что оторваны от реальной жизни. Если вы получаете от рынка после интервью такой фидбэк, для вас это очередной красный флажочек: надо обратить внимание на процесс собеседования внутри компании.
5. Job offer (документ, в котором указаны все условия и бенефиты) — если собеседование прошло успешно, все оканчивается предложением работы.
Какие вероятны отхождения от общих правил? В принципе, любые: например, очередность этапов. Кандидата могут сначала пригласить на техническое собеседование, а завершающим станет общение с рекрутером. Или HR-специалист ограничится общением с кандидатом только по телефону, а все последующее будет происходить внутри IT-отдела. Также, как вариант, рекрутер может присутствовать на одном-единственном собеседовании (техническое + HR в одном флаконе) и задавать вопросы по своей части. Все это обсуждается с нанимателем заранее или меняется в процессе найма специалистов. Последовательность этапов зависит от того, где у вас ломается воронка кандидатов. Например, перед собеседованием тимлид попросил вас отправлять тестовое задание кандидатам. Вы это делаете, но его никто не выполняет. Возможно, в данной ситуации стоит сначала дать кандидату больше возможностей познакомиться с компанией, все-таки сначала пройти интервью — и только потом решать для себя, стоит ли делать тестовое. Либо после телефонного интервью у вас предусмотрено hr-интервью, но многие кандидаты тупо не доходят до него, так как оно им кажется избыточным. Вероятно, в такой ситуации действительно стоит, скажем, после технического интервью предусмотреть 20–30 минут для общения кандидата с рекрутером. Или же вы считаете, что все кандидаты отлично проходят, но на этапе технического интервью случается коллапс: все отваливаются. Надо попробовать разобраться, почему так происходит: кандидаты действительно слабые или требования тимлида завышенные? В зависимости от ответа на этот вопрос и примите решение, как быть.
На прохождение тестового задания далеко не все кандидаты легко соглашаются. И для нас это становится достаточно сложным процессом. Нужно ли тестовое задание или пришло время от него отказаться, если у значительной части кандидатов оно вызывает негативную реакцию?
С моей точки зрения, здесь важно соблюсти определенный баланс — и это достаточно тонкий момент. С одной стороны, тестовое задание дает нам представление, насколько кандидат может выполнять те или иные задачи. А с другой — результат этого испытания во многом зависит от самого тестового задания. Что обычно смущает кандидатов в задании и почему по мере накопления опыта у них может вырабатываться отторжения к таким задачам?
● Слишком теоретическое, то есть человеку предлагается решить задачу, с которой он в реальной жизни никогда не столкнется. Какой-то университетский тест, в котором нет никакого практического толка. Так что, если нам предстоит выдать кандидату тестовое задание, мы должны понимать, насколько оно отражает реальность и проверяет по-настоящему актуальные навыки будущего сотрудника. Кандидаты, как правило, легко определяют такие задачи, но сами мы оценить актуальность тестового задания, к сожалению, не можем. Поэтому перед тем, как его давать, нам необходимо пообщаться на эту тему с заказчиком.
● Плохо составлено. Написать актуальный тест, который не является теоретической задачей и при этом не погружает человека в какие-то тонкости работы компании, — задача не из легких. Создание такого тестового задания, как правило, ложится на плечи тимлида, у которого не так уж много времени на подобные развлечения. У него есть стандартные рабочие задачи: надо кодить самому, управлять командой, и времени на создание тестов не всегда хватает. Поэтому зачастую они пишутся, что называется, на коленке. А задачу, которая плохо составлена, нет мотива хорошо решать.
● Требует слишком много времени. Если мы на старте найма узнаем, что на решение тестового задания требуется, скажем, 6–8 часов рабочего времени, надо быть готовым к тому, что мало кто на это пойдет. На стандартное тестовое у кандидата не должно уходить более полутора-двух часов работы — это средний показатель по рынку на сегодняшний день. В ином случае одно из возможных решений — предложить кандидату оплатить его работу, чтобы он был заинтересован в ее выполнении. (Да-да, в IT кандидатам иногда и за тестовые платят.)
Исходя из всего сказанного выше, в самом начале общения с заказчиком нам важно не только уточнить этапы собеседования, но и детально обсудить тестовое задание: какую именно задачу мы предлагаем, насколько она связана с реальностью, сколько времени займет, как часто предыдущие кандидаты выполняли ее успешно. Таким образом мы узнаем мнение тимлида или руководителя бизнеса об этом тестовом задании и сможем более-менее аргументированно донести до кандидата, почему его необходимо выполнить.
Говорить о тестовом задании лучше в самом начале, чтобы это не было сюрпризом для кандидата. Имеет смысл сразу описать задание, подсказать, сколько времени должно занять его выполнение, и тут же уточнить, когда кандидат сможет приступить к его выполнению. То есть уже с этого момента мы начинаем формировать договоренности: устанавливаем сроки, оговариваем, когда можно послать follow up — напоминание, когда, как и кому кандидат сможет задавать дополнительные вопросы, если они возникнут. Ну и будем присматриваться, как кандидат себя ведет, соблюдает ли сроки и договоренности, как общается, задает ли по ходу дела вопросы. Таким образом, этап тестового задания может быть неплохой проверкой не только технических навыков кандидата, но и его способностей к коммуникации.
Итак, предположим, что беседа прошла как нельзя лучше и вы выслали тестовое задание. Тут начинается самое интересное — обратная связь. Что делать, если большинство признает задание неадекватным и отказывается его выполнять? Исходите из здравого смысла.
Так как мы сами не можем в полной мере оценить качество тестового задания, проясните позиции обеих сторон — кандидата и нанимающего менеджера. Если у нас набирается энное количество негативных отзывов от людей, которые отказываются выполнять тестовое задание, потому что это слишком долго, бессмысленно или сложно, то необходимо воспринять это как маячок. Тут как в старой шутке: если и третий муж бьет… Да, шутка дурацкая, сексистская, но смысл понятен: может, проблема не в кандидатах.
В таком случае разузнайте у недовольных, что именно их не устраивает в задании, чтобы потом аргументированно обсудить проблему с тимлидом. Это наглядно продемонстрирует кандидату, что вам не все равно, покажет вашу заинтересованность и гибкость в принятии решений. Главное — не забыть объяснить, что задаете вопросы не из праздного любопытства, а чтобы обсудить с нанимающей стороной.
Если же в среднем отзывы о тестовом задании нормальные, а недовольны лишь несколько человек, то можно предположить, что дело именно в них, а не в чем-то другом.
Часто кандидат, не желающий выполнять тестовое задание, предлагает нам вместо этого посмотреть примеры его кодов с GitHub и по ним оценить его способность выполнять поставленные задачи.
С одной стороны, это действительно хорошая идея: если у человека в репозитории есть какая-то задачка, которую он реализовал, тимлид может оценить стиль его работы. С другой стороны, мы не можем доподлинно знать, как именно выполнялась эта работа, в какие сроки, самостоятельно или в команде. При этом коммерческие проекты, которые могут быть подтверждением профессионализма человека, порой запрещено разглашать. А именно они представляют для нас наибольший интерес.
Так что, несмотря на наличие у большинства разработчиков кусков кода, которые они могут показать на GitHub, это далеко не всегда является заменой тестовому заданию. Поэтому нам придется его давать. И возникает вопрос: как сделать так, чтобы человек не отказывался его выполнять?
Как я уже говорил в начале книги, нет смысла продавать всем одно и то же, по стандартной схеме. Мы должны исходить из каждого конкретного случая. Поэтому в процессе беседы важно узнать, что для человека важно в работе, почему он ищет новое место, что его устраивает или не устраивает, какие у него мотивы, — и подбирать аргументы, исходя из этой информации.
Если кандидат не хочет выполнять задание, хорошо бы выяснить, что конкретно его смущает. Возможно, у него был какой-то негативный опыт по этой части: например, дали большое сложное тестовое задание, он его выполнил, потратил время, а фидбэка не получил? Мы ищем те причины, которые могут объяснить отказ кандидата от выполнения тестового задания (обычно их от одной до трех) и отдаляют нас от оффера.
У некоторых кандидатов есть определенный страх, что компании могут так решать какие-то свои задачи: просят кандидатов выполнить тестовое задание, а потом используют полученные куски кода. В реальности я ни разу не сталкивался с такой ситуацией, но, если у людей есть подобный страх, можно предположить, что он возник не на пустом месте. Однако в каждой конкретной ситуации важно понять: сомнения кандидата вызваны его личным опытом или опытом коллег, или это просто абстрактный страх? Исходя из этого вы уже сможете выстроить свою «продающую речь» — подобрать те аргументы, которые актуальны именно для этого человека. Не забывая, что немаловажно, про ответственность за сказанное.
Иначе мы можем «продавать» налево и направо, рассказывая, что тестовое задание — это легко, просто формальность, да вы справитесь на раз, и все у нас будет прекрасно! А потом вдруг возникнет ситуация, когда задание не проверили, или проверили очень и очень нескоро, предоставили неадекватную обратную связь или просто молча не взяли.
Вот вполне универсальный аргумент для негативно настроенного кандидата: тестовое задание — это проверка не только для него, но и для компании. Посмотрев на тестовое задание, он сможет оценить сложность задач, которые ему предстоит выполнять, а также адекватность тимлида: как он дает задания и предоставляет обратную связь. Мало кто захочет работать с руководителем, который пишет задачи «на коленке» или набирает команду на основе теоретических задач, не имеющих отношения к реальности. Такой подход задает тренды всего рабочего общения, и об этом кандидату лучше узнать заранее, еще до трудоустройства.
Конечно же, приводя этот аргумент, вы должны быть уверены в своем тестовом задании, иначе своими громкими заявлениями мы сами роем себе яму.
Итак, если обобщить все то, о чем мы говорили, то тестовые задания — это серьезный камень преткновения. У заказчика, как правило, не хватает времени, чтобы полноценно подготовить задачу. У кандидатов наработан большой опыт выполнения заданий «ни о чем», поэтому даже если у вас хорошее тестовое, кандидат может сомневаться, стоит ли его делать. В итоге решение о том, приступать ли к заданию, зачастую принимается по результатам первичного контакта: кандидат смотрит, как строится взаимодействие, и только потом берется или не берется за тестовое задание.
Из-за всех этих сложностей текст могут давать на разных этапах общения с кандидатом. Иногда его присылают перед собеседованием, чтобы человек сразу оценил, стоит ли ему пытаться трудоустроиться именно в эту компанию. Или, наоборот, задание дается в самом конце, после технического собеседования, когда кандидат уже познакомился с командой, понял, с кем и как ему предстоит работать, обсудил важные для него вопросы — и теперь готов показать себя в деле. Варианты развития событий могут быть любыми, и когда именно приступать к тестированию — полностью зависит от ваших реалий.
Что особенно важно для рекрутера во всей этой ситуации? Повторюсь: во-первых, надо заранее обговорить с заказчиком, что именно дается в виде теста. А во-вторых — держать руку на пульсе, то есть давать своевременную обратную связь обеим сторонам, поскольку мы сами не можем ни повлиять на содержание задания, ни проверить качество его выполнения.
Вообще тема обратной связи достаточно болезненна для кандидата, и более детально об общих правилах обратной связи мы поговорим чуть позднее. В контексте же тестового задания нам важно понимать, что кандидату необходимо получить более-менее аргументированный отклик на свою работу. Поэтому, общаясь с тимлидом, нам важно получить побольше «мяса» — фактов о качестве выполнения задания, о том, что конкретно понравилось или не понравилось. Среднестатистический ответ должен строиться по принципу: «Вот эту задачу ты выполнил хорошо, а вот здесь можно было бы использовать другие инструменты, например…» Просите тимлидов написать хотя бы два-три корректных предложения, которые дадут человеку чуть больше конкретики, нежели «вы нам не подходите». Потому что в ответ на такое заявление у человека возникает вполне резонный вопрос:
— А почему?
— Потому что плохо выполнено тестовое.
— А что именно не так?
Возможно, под «плохо выполнено» имеется в виду, что оно выполнялось долго. Или в нем использовались не те инструменты, которые актуальны для тимлида. А может, оно было выполнено нормально, просто у тимлида и кандидата разные подходы к решению задач.
Просите больше конкретики! Хотя это и сложно. Так как мы ничего не понимаем в результатах тестовых заданий, если только не увлекаемся кодингом в свободное от работы время, то наша задача — по возможности свести все возникающие сложности в коммуникации к нулю. Замечание из собственного опыта: бывали неприятные случаи, когда рекрутер просто копировал отзыв тимлида о полученном коде, этот отзыв был не очень корректным — и кандидат обижался.
Поэтому в список наших задач входит работа с тимлидами: мы должны говорить о том, насколько важна обратная связь для кандидатов, обсуждать ее сроки и гарантировать кандидату их соблюдение. Таким образом, наша функция зачастую сводится к административной: сделать все необходимое, чтобы каждый участник процесса выполнил свою задачу вовремя, всем напомнить, всё проверить — и обеспечить продуктивную коммуникацию.
Итак, мы разобрали основные вопросы с тестовым заданием — и, главное, обсудили, на какие моменты мы с вами, рекрутеры, можем повлиять. Пришло время перейти к самому интервью: в нем мы также ограничены по множеству параметров, однако и свободы выбора действий у нас остается немало.
В рамках собеседования, которое проводит компания с кандидатом, рекрутер выполняет две основные функции: 1) административную и 2) оценку soft skills.
1. Административная. Чаще всего мы согласуем время и место проведения собеседования, оповещаем всех участников, ведем определенный регламент мероприятия. В целом мы решаем все организационные вопросы, которые могут возникнуть, и осуществляем связь между всеми участниками: какие задания будут даны, когда и как будет получена обратная связь и т. д.
2. Оценка soft skills — достаточно сложная тема. С одной стороны, софты становятся для работодателя все важнее и важнее. Раньше мы часто слышали от тимлидов идеи типа: «Мне все равно, насколько коммуникабелен специалист, главное, чтобы код умел писать». Сейчас же тенденция обратная: команда может выбрать менее сильного кандидата, который больше подходит им по духу.
Но, как водится, в хороших правилах есть исключения. В процессе подготовки этой книги мы подумали, что есть еще одна функция, которую выполняет хороший IT-рекрутер: мотивационно-коммуникационная. Это означает, что именно рекрутер часто становится тем мостиком и коммуникатором, который помогает двум сторонам договориться, услышать друг друга. И часто именно хороший рекрутер содействует кандидату в принятии решения о переходе. Поэтому было бы несправедливо опустить эту функцию.
В то же время сам процесс оценки — задача не из легких. Об этом написано много книг, есть различные методологии и подходы, и главное — этот процесс требует много времени. Хорошее, подробное интервью, которое раскроет нам сильные и слабые стороны кандидата, например интервью по компетенциям, занимает несколько часов. В реалиях IT-рынка зачастую нет возможности их проводить: во-первых, у всех нас стабильный дефицит времени. Во-вторых, кандидаты не понимают ценности таких интервью. Из-за этого нам приходится чем-то жертвовать — и чаще всего не тестовым заданием или знакомством с командой, а именно этими «упражнениями в прекрасном».
Ну и давайте по-честному. IT-специалисты часто к классическим вопросам из учебников по оценке относятся скептически. Все эти «кем вы видите себя через пять лет в нашей компании» набили оскомину. Есть ситуации и того хуже. Вот, например, вопрос, который призывают задавать на интервью: почему красный цвет в одежде лучше черного? По реакции на этот вопрос мы якобы можем оценить ряд психологических параметров. В других сферах, вероятно, такие классические модели тестирования все еще работают, но если задать такой вопрос айтишнику, скорее всего, он просто посмеется. И это еще в лучшем случае! А в худшем, как это было в случае с описываемой компанией, выложит свои впечатления в виде эмоционального эссе на ebanoe-it.ru — за счет чего имидж компании в среде кандидатов будет загублен. Потому классические подходы нужно переносить на IT-реалии. В частности, вопросы в их первичных формулировках оживлять и «очеловечивать».
Я не считаю себя экспертом в оценке soft skills, несмотря на то, что провел множество собеседований и знаком с методологиями. Я лишь призываю вас не лезть в Тулу со своим самоваром. И если уж собираетесь проводить полноценную оценку, не ограничиваться одной прочитанной книжкой, а постоянно этому обучаться, чтобы проводить эту оценку качественно. Пока же хочу рассказать о самом-самом базовом в проведении интервью.
Что особенно важно на базовом этапе оценки soft skills? В первую очередь, не основываться на своих предположениях. То есть для понимания трех всадников апокалипсиса — стрессоустойчивости, коммуникабельности и ответственности кандидата — нам нужно знать методологию оценки soft skills. И хоть выше я говорю, что классические методики в полном объеме нам не очень подходят, знать их необходимо, чтобы в процессе общения было на что опереться.
О том, как оценивать soft skills, написаны тома: если вы хотите развиваться в этом направлении, в первую очередь необходимо гуглить все, что связано с интервью по компетенциям. Плюс, конечно же, читать классику этого направления, в частности книги Светланы Ивановой («Что скрывает кандидат?», «Как найти своих людей»[23] и др.). Да, эти книги для IT порой устаревают, но, по моему мнению, это нестареющая база, которую необходимо знать. Самое важное — не пытайтесь «впихнуть» эти методы куда ни попадя. Помните про Тулу и самовар, да? Прочитали, взяли на вооружение — и пошли учиться дальше. Причем важно понимать, что одних книжек недостаточно: для полномасштабного интервью по компетенциям равнозначно важны знания, опыт и такие сопутствующие факторы, как наличие времени, готовность кандидата идти на контакт и много-много других. Не пытайтесь сразу же прыгнуть выше головы: такие тонкие процедуры каждый специалист должен отлаживать годами, и рано или поздно при должной тренировке и качественном обучении вы станете классным специалистом — если только вас привлекает и зажигает это направление.
Еще один труд, обязательный к прочтению, — «Кто: Решите вашу проблему номер 1» Джеффа Смарта и Рэнди Стрита[24]. Книга не столько про собеседования, сколько про общие принципы, помогающие заниматься наймом. Плюс ценные рекомендации по новинкам можно найти в
Важно помнить, что недостаточно просто пообщаться с кандидатом и решить на свое усмотрение, дружелюбный он или не очень. Без методологии и структурированного подхода, который можно освоить с помощью различных источников — книг, мастер-классов или, в продвинутом варианте, с помощью более полного образования, — это будет так называемый «вуду-рекрутинг». Другими словами — ситуация, в рамках которой мы гадаем на кофейной гуще и что-то предполагаем, опираясь на собственный опыт и личное мнение. Есть крайние проявления «вуду-рекрутинга», когда к оценке привлекают какие-то странные критерии, например знаки зодиака или human design. Помните знаменитую HR-шутку о том, что начальник некоей компании отказывался работать со Стрельцами или Козерогами? Это не шутка.
Даже если мы с вами не беремся за такой сложный процесс, как психологическая оценка, мы должны уметь провести биографическое интервью — это достаточно простое мероприятие, которое имеет свою структуру и правила проведения.
В рамках такого собеседования мы проводим базовую работу: уточняем у кандидата, насколько данные из резюме соответствуют его реальному опыту. Казалось бы, что тут сложного? По моим наблюдениям, зачастую, когда мы стараемся создать легкую атмосферу для кандидата, уделяем внимание его психологическому состоянию и снижению стресса, с которым неминуемо связано любое собеседование, мы можем отключаться от логики собеседования. А она важна! Структурированный подход позволяет нам увидеть те маячки, которые определяют, куда нам копать дальше в работе с кандидатом. Давайте рассмотрим на примерах.
Логика такого интервью обычно достаточно простая: для начала мы уточняем ФИО кандидата и дату его рождения. Звучит банально, но по факту некоторые люди могут солгать в резюме, и это не редкость: написать не свои имя или фамилию либо занизить свой возраст. В компании, где я работал, был инцидент, когда кандидата, который сменил пол, но еще не поменял документы, не пускали на проходной, потому что заявка была оформлена на женское имя, а пришел мужчина. Такие ситуации тоже бывают, и к этому надо быть готовыми.
Помимо этого, мы проверяем образование: оконченное или нет, название института, факультет, год выпуска.
На сегодняшний день это может показаться излишней формальностью, но я в этом отношении фанат старой школы. В самом начале интервью я, как правило, сообщаю о том, что нам нужно быстро пробежаться по формальным вопросам: насколько верно указаны все данные в резюме. Если не уделять этому моменту особого внимания, то кандидаты обычно реагируют вполне нормально. Если же человек удивляется, можно вполне адекватно, как мы расписали выше, объяснить, зачем я задаю такие очевидные вопросы и почему это важно. Главное, не докапываться до среднего балла в университете и любимого предмета. Обычно можно задать формальные вопросы за 10 секунд и перейти к более интересным вопросам.
Дальше рассматриваем профессиональный опыт. Выбираем, например, три последних места работы и в хронологическом порядке задаем вопросы. Среди них — общие впечатления о компании, когда устроился, какие задачи ставились, за что конкретно отвечал этот человек, что было и не было сделано, почему что-то не получилось, что бы сейчас кандидат изменил, почему уволился. Также можно расспросить о команде и технологиях, с которыми работал. Самое важное, что мы можем понять из этого общения, — логику перемещения кандидата с одного места работы на другое.
Звучит банально, и очень вероятно, что вы уже не раз и слышали, и сами задавали эти вопросы. Однако я регулярно сталкиваюсь с ситуацией, когда рекрутер пренебрегает биографическим интервью, проводит его смазанно или не особо прислушивается к тому, что ему говорят. А ведь даже самое банальное интервью о том, «где вы работали, что делали и почему ушли», дает отличные поводы для дальнейшего «исследования»; начиная с него, можно дойти до очень интересных фактов.
Узнав у человека, на какие задачи он пришел в компанию, что у него получилось, а что нет, мы по большому счету начинаем лучше понимать причины его ухода. Следующий не менее важный вопрос: куда именно он решил уходить и ради чего? Ради абстрактной лучшей жизни или каких-то конкретных целей? Все нужно уточнять.
Довольно-таки часто в ответ на такие банальные вопросы мы получаем нелогичные ответы. Например, кандидат говорит, что ушел из компании, потому что хотел заниматься командной разработкой, а их в техническом отделе было всего двое. Но его следующее место работы — это точно такая же команда из двух человек.
Это один из самых ярких примеров логических нестыковок, позволяющих нам сделать два предположения. Первое — человек нам врет о причинах ухода. В таком случае нужно копать в этом направлении, в частности обратить внимание на рекомендации с того места работы, прямо на интервью подробнее расспросить. Второй — кандидат не врет, но он сам пока не определился в своих приоритетах, что также случается. Он действительно ушел, чтобы найти более крупный проект, но согласился не на то, чего хотел. Почему так случилось? Это не было его истинной мотивацией, или у него не хватило компетенций, или просто жизнь прижала и нужны были деньги? Вариантов множество.
Логика ответов на вопросы — это те самые азы, про которые мы часто забываем, тогда как она помогает нам лучше понять кандидата и, как результат, сделать правильный выбор.
Мы поговорили про базовое биографическое интервью, обсудили тестовое задание и погрустили над тем, как сложно в наше время проверить soft skills: старые методики не работают, длинные интервью не в тренде, и объяснить кандидату, зачем ты мучаешь его многочасовыми вопросами о цвете одежды, невозможно. Тем не менее в современных условиях компании зачастую при выборе опираются именно на эти пресловутые soft skills: пусть кандидат будет не такой уж профессионально подкованный, зато умеющий выстраивать адекватную коммуникацию.
К счастью, на сегодняшний день появляются новые, неформализованные способы понять, впишется ли человек в команду или нет. Мне, например, очень нравится опыт одной из компаний, которая в качестве последнего этапа собеседования приглашает кандидата-финалиста в офис пообедать, чтобы в неформальной обстановке он мог познакомиться с командой. Таким образом и команда, и потенциальный сотрудник сориентируются, насколько им комфортно друг с другом.
Конечно же, эту методику сложно «оцифровать» — вывести какие-то правила и создать рекомендации типа «если вы зовете человека на обед, кормите его щами; если кислые — опасность». Но, по сути, это что-то вроде бета-тестирования кандидата.
Еще одно классное решение, которые внедряют некоторые компании, — тестовый день. Вы приглашаете кандидата поработать в вашем офисе. Он будет выполнять задания, которые ему дадут, и получит оплату за день работы. А мы посмотрим, насколько это понравится всем участникам процесса. По аналогии с личными отношениями, перед тем как жениться, можно же попробовать пожить вместе — чтобы быть уверенными, что обе стороны это устраивает.
Да, такие мероприятия будут усложнять процесс, и его стоимость будет повышаться. Да, не все кандидаты будут соглашаться на такие эксперименты. Но если вашей команде реально важны люди определенного типа, склада характера, обладающие определенным набором коммуникативных навыков, то найдутся место, время и деньги для эксперимента. И да, эти методы хороши, когда нет хорошего специалиста по оценке. Если оценка действительно выстроена на уровне, то такие развлечения могут быть вовсе не обязательными.
Конечно же, подход к отбору должен соответствовать культуре вашей организации. Если команда никогда вместе не обедает — и тут их внезапно собирают на общее мероприятие ради неизвестного человека, это будет выглядеть странно. Если же внутренняя культура подразумевает свободное, неформальное общение и отвечает тенденциям времени, то — никаких границ! Можно пробовать.
Тут, кстати, уместно упомянуть ограничения 2020 года: казалось бы, многие перешли на удаленную работу (и далеко не все из нее вернулись в офисы) — за счет этого мы должны были бы откатиться от экспериментальных методов оценки к классическим. Глупо звать кандидата на обед, если все сидят по домам!
Однако я не могу сказать, что этот откат реально произошел. Тенденция устраивать тестовые дни набирает обороты — они возможны как в удаленном, так и в реальном формате. Кандидатов приглашают на онлайн-тусовки, которые отчасти пришли на смену обедам и вечеринкам. Несмотря на большие перемены в стиле работы и в жизни в целом, альтернативные способы узнать, подойдет вам человек или нет на уровне общения, существуют и развиваются.
Важно понимать, что эти методики не могут заменить полноценную оценку soft skills, но если для нее не хватает компетенций, времени, сил или других факторов успеха, то такие действия намного лучше, чем ничего. Они могут дать общее представление о том, насколько легко и оперативно потенциальный сотрудник впишется в вашу корпоративную культуру, и отчасти застрахуют от ошибок в выборе.
В то же время такие неформальные методы не говорят нам о качествах кандидата, которые ему, вероятно, пригодятся каждый день на работе. То есть оценить его софтовые компетенции таким образом не получится. Это заплатка на случай, если такой возможности нет.
И еще один момент. В некоторых компаниях пытаются внедрить психологическое тестирование в оценку и в процедуру найма. Например, дают кандидату на последнем этапе тестирование из 200 вопросов, в том числе про частоту походов в туалет и чуть ли не про то, кого он больше любит — маму или папу. При всей моей любви к психологии и терапии хочу сказать, что использование этих тестов в найме — идея так себе.
Во-первых, психологическое тестирование должны проводить психологи. Потому что к тестированию нужно правильно подвести, а еще его надо грамотно интерпретировать. Вы психолог? Я — нет. Вот и не лезу.
Во-вторых, подобные тесты зачастую показывают не системное поведение, а продиктованное текущим психологическим состоянием кандидата. Он, например, может быть в стрессе и давать ответы, которые не свойственны ему в реальной жизни. Чтобы понимать, какое тестирование и когда давать, нужно быть психологом. Вы психолог? Я — нет. Вот и…
В-третьих, в IT у многих это правда вызывает скорее негатив. И вы добавите себе дополнительных возражений и сопротивлений на этапе найма, которые скажутся на вашей воронке. В конце концов, если вы в действительности не являетесь психологом и не можете грамотно обработать предыдущие два пункта, то и третий вам ни к чему. Если же вы психолог, можете выбрать подходящий тест, правильно к нему подвести и умело его интерпретировать, то, наверно, вам будет проще не вызвать негатива. Но недоумение все равно может возникнуть.
Мы проделали огромную работу: проработали вакансию, нашли кандидатов, провели собеседования. Что дальше?
Пришло время договориться о следующих этапах. В идеале весь процесс найма для кандидата изначально не является сюрпризом: в описании вакансии должно быть указано, что именно будет происходить. Плюс мы проговорили регламент во время скринингового телефонного общения и дополнительно — на собеседовании.
Предположим, собеседование прошло успешно, и теперь мы обсуждаем с кандидатом дальнейшие шаги. В случае если тестовое задание было вынесено в конец, после интервью нужно будет обсудить его и установить сроки — как выполнения, так и обратной связи. Если задание не предусмотрено или уже было выполнено, то остается обговорить именно обратную связь: когда человек получит информацию о том, одобрена его кандидатура или нет.
Обратная связь — очень щекотливая тема, потому что… Очень часто ее кандидатам просто не дают! Как вы понимаете, кандидаты не любят рекрутеров и компании, которые так поступают. Если вы хотите, чтобы у вашего HR-бренда была хорошая репутация, надо следить, чтобы обратная связь давалась всем, как бы сложно это ни было.
Самый эффективный шаг — выделить один день (условно пятницу), в который все ваши рекрутеры или вы сами даете ответ кандидатам, которых взяли в работу на этой неделе. В таком случае вы точно не ошибетесь, говоря, что ответ будет в пятницу. Конечно же, важно предварительно договориться об этом с бизнесом: предупредить, что в рамках найма мы даем ответ кандидатам по пятницам, поэтому у всех участников процесса есть время на уточнения, сомнения и принятие решений до этого дня. Это один из самых простых способов никого не потерять и не обидеть.
Второй, не менее тонкий, вопрос: что делать, если мы должны сообщить об отрицательном решении? Чаще всего рекрутеры обходятся достаточно формальными фразами-«отбивками», к которым все участники рынка привыкли: сообщением, в котором говорится что-то типа «ваша кандидатура, к сожалению, не подошла; будем оставаться на связи».
Формально, согласно Трудовому кодексу, мы должны указать причины отказа. И согласно той же букве закона, мы не можем отказать по причине несоответствия soft skills: любое требование, не связанное с профессиональными качествами (hard skills), легко трактуется как дискриминация по тому или иному признаку, — ну а дискриминация в сфере труда прямо запрещена Трудовым кодексом (статья 3 ТК РФ). Отказ должен содержать указания на некие hard skills — недостаток опыта, отсутствие навыков работы с необходимыми технологиями и т. д. Именно поэтому обычно берется такая довольно общая формулировка, которая нас ни к чему не обязывает.
Особо дотошные кандидаты могут нас спросить, что именно не устроило работодателя, или попросить написать формальный отказ (в некоторых случаях даже на бумаге). О том, как должен быть составлен запрос на официальный отказ, а также сам отказ, необходимо консультироваться с отделом кадрового делопроизводства. В этом мы разбираться не будем — для нас более актуально, как избежать таких запросов и конфликтов из-за отказа.
Здесь у меня есть одна очевидная, но не всегда простая в выполнении рекомендация: обеспечивать реальную обратную связь, привязывая ее к hard skills, которые были указаны в вакансии и которые действительно важны. Плюс к этому важно делать это человечно.
Давайте представим, какая форма отказа вас бы устроила. Наверное, вам было бы важно понять, что можно сделать лучше, какие свои навыки прокачать. Подсказать, что именно необходимо проработать тому или иному кандидату, сможет тимлид. И если вы получите от него эту информацию, она может оказаться для вас полезным советом. Завершить письмо вы сможете на оптимистичной ноте, типа «к сожалению, мы решили пока не делать тебе предложения; но попробуй прокачать такие-то навыки — и давай с тобой встретимся через какое-то время (полгода-год, смотря как вы оценили кандидата)».
Надо признать, что у нас нет культуры обратной связи. По этой причине многие люди зачастую не знают, почему именно им отказывают. Поэтому очень вероятно, что кандидат будет вам искренне признателен за хороший фидбэк, позволяющий ему развиваться в востребованном направлении. По моему мнению, обратная связь в таком формате — наилучший вариант.
К сожалению, подготовить такое сообщение мы можем далеко не всегда. Во-первых, не всегда удается получить актуальную информацию от тимлида, во-вторых, зачастую отказ связан не столько с hard skills, а дело в особенностях общения и в несовпадении характеров. С одной стороны, мы по закону не имеем права отказать человеку из-за его soft skills, а с другой — разве вы сможете по-честному сказать человеку: мол, на собеседовании ты вел себя неадекватно, поэтому мы не хотим с тобой работать? В таких случаях нам на помощь приходят общие формулировки.
Один из таких компромиссных вариантов — «мы сделали выбор в пользу другого кандидата». Не могу сказать, что эта фраза мне очень нравится, но это решение, которое позволяет, с одной стороны, не сильно обижать кандидатов, а с другой — прикрыться перед законом. Да, звучит так себе, и все понимают, что это отмазка. Но если нет возможности дать честный и одновременно полезный ответ, то это терпимая альтернатива.
Еще один хороший совет — попробуйте перевести беседу в сторону кандидата: в конце можно спросить, как мы можем ему помочь. Но не со всеми кандидатами такой вопрос будет уместным. Для кого-то вы можете реально что-то сделать: отправить его резюме кому-то, дать пару советов по корректировке или форматированию CV, а с кем-то вам не удастся наладить такой контакт. Так что в выборе формата коммуникаций также ориентируйтесь на то, в каких вы отношениях с кандидатом.
И последний, ужасный, совет. В идеале вам все-таки надо поговорить с кандидатом голосом или хотя бы в мессенджере. Чтобы у него не было ощущения формального отказа. Да, это сжирает больше времени и сил. Но и ценится кандидатами дороже. Так что, простите за прагматизм, если кандидат вам интересен — выделите время на звонок ему.
Итак, обобщим сказанное об обратной связи: во-первых, очень желательно сосредоточиться на том, чтобы она была развивающей. А во-вторых, не менее важно соблюдать сроки, то есть дать ответ вовремя. Важно выстроить процесс таким образом, чтобы человек не ждал обратной связи неопределенное время, а понимал сроки, чувствовал себя комфортно и видел, что вы выполняете перед ним свои обязательства в полной мере.
Итак, мы рассмотрели, как выглядит ситуация с отказом кандидату. Это достаточно неприятный момент, но с ним относительно все понятно.
Бывают более скользкие варианты развития событий, когда мы хотели бы сделать оффер, но по какой-то причине его не делаем. Например, заказчик говорит, что хочет посмотреть других кандидатов, или ему нужно дополнительное время подумать, или для закрытия вакансии мы обязаны пройти через какие-то долгие мучительные бюрократические процессы (что достаточно часто случается в госструктурах).
Тут начинается довольно мерзкая история, когда нам приходится хитрить, юлить, изворачиваться и чувствовать себя ужом на сковородке. Получается, мы взяли на себя обязательство перед кандидатом — пообещали обратную связь условно в пятницу, и тут начинаются какие-то мутные торги, в результате которых мы чаще всего перестаем выполнять эти обязательства, потому что «ответ будет только в понедельник», и то в лучшем случае. Что делать?
Если проблема связана с заказчиком, то прежде всего нам необходимо выяснить истинную причину: почему мы не можем сделать оффер прямо сейчас? Коммуникации с заказчиком — это довольно сложная тема, которой можно посвятить отдельную книгу. Но в данном случае мы кратко рассмотрим варианты выхода из ситуации.
Наша задача на этом этапе — по максимуму выжать из заказчика информацию и разобраться, почему ответ не может быть в срок. Этому надо уделить отдельное время. Причины затягивания могут быть разные. Например, заказчику этот кандидат на самом деле не настолько интересен. Другой вариант: заказчик надеется закрыть вакансию внутренними рекомендациями — скажем, знакомый некоего члена команды сейчас выходит на рынок, и заказчик рассчитывает на него. Или заказчик сам до конца не понимает, почему кандидат ему не нравится. Вроде бы все хорошо, но уверенности нет, поэтому заказчик не готов принять решение и хочет потянуть время. Таких вариантов — огромное множество.
В таком случае надо начать с самого простого и важного в нашей профессии вопроса: почему? Готовьтесь: я буду часто задавать его в течение этой главы. Почему же заказчик не готов сделать выбор сейчас? В зависимости от его ответа мы начинаем копать дальше и глубже. В результате диалог может выглядеть приблизительно таким образом:
— Почему не сейчас?
— Я не готов сделать выбор, хочу посмотреть других кандидатов.
— А почему? Чего именно тебе не хватает в этом кандидате?
— Ему не хватает таких-то навыков.
— То есть я правильно понимаю, что эти навыки для нас особо критичны и кандидатов без таких скиллов мы не рассматриваем?
— Да, правильно.
Это распространенная ситуация, в рамках которой мы внезапно понимаем, что изначально профиль вакансии был проработан неправильно — и надо все переделать. Знакомая история? Без паники! Мы копаем дальше:
— Хорошо, тогда мы перепрофилируем наш поиск? В таком случае надо понимать, что мы будем отбирать новых кандидатов и заново запускать их в процесс. Ты готов к следующим трем неделям поиска? Мы будем искать людей по обновленным требованиям, выбирать, собеседовать, отправлять к тебе, ты будешь с ними общаться, давать и проверять тестовые задания.
В случае ответа «да, готов!» мы начинаем поиск заново. А если «нет, не готов» — копаем дальше:
— Насколько критичны эти недостающие навыки? Сможет ли кандидат начать работу — справится ли без них на первых порах? Можно ли обучиться этим навыкам на практике?
И зачастую мы получаем ответ типа:
— Ну да, возможно…
Наша задача — не заниматься прямыми продажами, не навязывать кандидата, а разобраться, в чем причина неготовности заказчика нанять того или иного человека. Если эта причина действительно критична, необходимо выяснить, сколько он готов ждать и участвовать в дальнейшем поиске. Если не критична, то надо понять, что еще мешает выбрать из уже имеющихся кандидатов.
В данном случае мы формируем дополнительные договоренности с заказчиком и работаем с его дальнейшими ожиданиями. Если нам надо искать новых людей, то заказчик должен четко понимать, что он сам себе усложнил жизнь, затянув процесс, — и при изменении требований к вакансии начинается новый поиск, а не все как-то само образуется за недельку, потому что «уже ведь столько времени работали».
Наша главная задача в такой беседе — дойти до сути проблемы. Чтобы это сделать, есть несколько основных принципов построения коммуникации:
● Мы ничего не должны додумывать за оппонента: все факты, идеи, мысли, сомнения выясняем через вопросы.
● Мы задаем как можно больше открытых вопросов без вариантов ответов. Чаще всего мы начинаем предлагать гипотетические ответы, когда нам некомфортно. Выглядит это так: почему ты не хочешь его брать — потому что он плохо себя на собеседовании повел? Важно этого не допускать, чтобы понять истинную причину, по которой человек отказывается сделать оффер кандидату.
Зачастую бывают ситуации, когда заказчик хочет оставить кандидата «про запас», потому что сомневается, что тот ему полностью подходит. В таком случае рекрутеры испокон веков прибегают к классическому приему, который выглядит следующим образом: мы показываем заказчику менее сильного кандидата, чтобы на контрасте заказчик выбрал уже подобранного.
Не могу сказать, что я большой фанат таких манипуляций. Но так как моя задача — не показать вам идеальный мир, а описать то, что бывает на практике, не могу не упомянуть эту технику. Иногда она работает и даже дает хорошие результаты в отдаленной перспективе. Однако я все же призываю вас не прибегать к таким приемам, а разговаривать с заказчиком, выявлять его мотивацию и потребности и находить здравые способы решения задачи.
С заказчиком разобрались, а что делать с кандидатом, если у нас возникла необходимость попросить его подождать? Чаще всего в нашем неидеальном мире мы начинаем врать: мол, заказчик уже готов, но сейчас он уедет, потом вернется, и тогда сразу же все произойдет — пожалуйста-пожалуйста, подождите! На мой взгляд, это не лучшее решение.
Предварительно общаясь с заказчиком и принимая решения «подвесить» кандидата на какое-то время, мы должны договориться о точных сроках: до какой конкретной даты. Конечно же, процесс желательно выстраивать таким образом, чтобы подобных ситуаций не возникало, но если она все же возникла, то здесь должна быть максимальная определенность. Иначе процесс рискует затянуться навечно.
Важно помнить, что из-за каждого такого оттягивания и компания, нанимающая сотрудника, будет терять баллы в глазах кандидатов, и мы сами будем рушить свой имидж. Помните про собственный прямой интерес, который может пострадать, и старайтесь избегать подобных ситуаций.
Тем не менее давайте представим, что мы не смогли подстелить соломку — и ситуация «подождите нас, пожалуйста!» все же возникла. Как пройти через нее наилучшим образом? В первую очередь очень важно вовремя вернуться к кандидату с обратной связью: обещали в пятницу — звоним в пятницу.
Я предлагаю выстраивать беседу следующим образом:
● Важно признать, что это ваш косяк: с вашей стороны произошла задержка, и пока ответа нет.
● Также надо дать понять, что ошибки бывают у всех. Вам это не свойственно, но бывает!
● Необходимо сообщить, что вы делаете всё, что в ваших силах, чтобы ответ был как можно быстрее. Вы помните о кандидате и заботитесь о его комфорте. И лучше сказать, что конкретно вы будете делать, а не просто отделаться общими словами. Например: «Я уже назначил встречу с ребятами, чтобы обсудить решение вопроса и ускорить процесс».
● Вы назначаете точную дату, когда ответ будет, — и это уже железно.
● Переводим разговор на кандидата: а как ему перспектива трудоустройства к вам в целом? А как его поиски? Сможет ли он подождать или уже нас проклял?
Можно все это отправить в письменном виде, но лучше, конечно же, пообщаться голосом. Вообще любые не очень приятные вещи лучше проговаривать по телефону. У нас тогда появляется больше возможностей услышать живую, спонтанную реакцию человека, а у него — меньше шансов разозлиться, написать какую-то гадость или проигнорировать сообщение, ведь быть грубым вживую гораздо сложнее, чем в переписке.
Если кандидат вам интересен, то, пока оффер не сделан и не принят (да и после этого, объективно говоря), важно быть с ним на связи. Желательно делать это не только в какие-то ключевые моменты (например, в понедельник собеседование — в пятницу фидбэк), но и между ними.
Надо признать, что со всеми кандидатами поддерживать отношения не получится: какими бы мы ни были коммуникабельными, если поставим себе задачу общаться со всеми, то только этим нам и придется заниматься. Кем-то придется пожертвовать. Но если вы понимаете, что процесс может прийти к офферу, то есть повод поддерживать общение с кандидатом в течение всего периода ожидания ответа от заказчика.
В таком случае, если вы вдруг будете вынуждены отложить обратную связь, для кандидата это будет не так страшно: вы с ним уже общались, вы не теряетесь, вы на связи — поэтому с большой долей вероятности вам будут готовы простить задержку. Если же вы просто пропали после собеседования, потом внезапно вынырнули и сказали, что ответите не сейчас, а потом, — вот это уже повод для негативной реакции.
Кроме того, всех интересных кандидатов необходимо спрашивать о том, как проходит их поиск, ходили ли они куда-то еще, получили ли какие-то офферы. Если у вас будет актуальная информация, вы сможете вовремя вернуться к заказчику и скорректировать ситуацию.
Как поддерживать эти отношения в течение недели? Если вы будете то и дело спрашивать кандидата о его офферах, не будучи при этом с ним близко знакомым, то такое поведение может выглядеть странно. Кандидат имеет полное право в такой ситуации психануть и отказаться с вами откровенничать: действительно, с чего бы?!
Как я уже неоднократно повторял в этой книге, нам надо создавать человеческие отношения — и для этого очень важна обратная связь. В течение недели вы можете связаться с ним, скажем, по поводу собеседования: сказать, что он молодец, собеседование прошло классно, тимлид ушел думать, «но мне кажется, что все круто». Вы можете расспросить человека о его впечатлениях: «Что тебе понравилось, что нет? Как тебе наш офис? Как поговорили с тимлидом и командой? Что по тестовому заданию — все понятно или есть вопросы?» Напомните кандидату: может быть, он хотел что-то спросить, но волновался и забыл или просто не успел — вы всегда можете передать его вопросы тимлиду.
Еще один вариант общения: встретили в течение недели мемасик, который развеселил команду, тимлида или других сотрудников компании, — отправьте его кандидату. В этом нет ничего сверхъестественного: мы сегодня так общаемся, это общепринятая норма.
Также мы можем предложить кандидату помощь. Например, дать несколько рекомендаций по резюме — это отличное предложение, которое обычно имеет позитивный отклик и в личных коммуникациях, и в общих чатах. Дайте понять человеку, что вы готовы не только брать — скажем, просить у него информацию в стиле: «А теперь ты получил от кого-нибудь оффер? А сейчас? А сегодня?» — но и делиться. Вообще нетворкинг в современном мире выстраивается на основе того, что мы готовы отдавать, ничего не прося взамен. Потом мы, возможно, попросим, но сейчас готовы делиться и помогать.
В общем, вывод этой главы очевиден: в рамках процессинга важно держать руку на пульсе, постоянно оставаться на связи, уделять внимание кандидату — причем не только просить у него информацию, но и давать что-то ценное взамен.
Оффер, казалось бы, самая приятная и простая ситуация. Но здесь тоже есть несколько моментов, которые стоит обсудить.
Во-первых, давайте посмотрим, как выглядит ваш оффер. Если у вас в компании это официальный документ в формате pdf с подписью директора, то ладно, что поделать. Но если вы можете оформить приглашение на работу как-то посимпатичнее, то обязательно сделайте это. Красивый pdf-документ в формате презентации будет еще одним напоминанием кандидату о ваших конкурентных преимуществах. Такая презентация наглядно продемонстрирует, что вы классные, у вас стоит работать и кандидату у вас будет хорошо.
Почему я настаиваю на том, что оффер должен быть красивый? Когда мы думаем, в какой супермаркет пойти, мы выбираем те места, где продукты красиво разложены по полкам, а не те, где в кучу навалены курица, шоколадные конфеты и гречка. Упаковка важна! Поэтому, подготавливая оффер, подумайте, как вы можете сделать его более привлекательным. Сейчас это несложно: например, сервис Canva позволяет создать лаконичную, эффектную и понятную презентацию в pdf с достойным визуалом.
Что обязательно должно быть в таких презентациях? Здесь есть смысл перечислить конкретные задачи, зарплату, условия, важные факты про соцпакет, кратко рассказать про команду и добавить фотографии людей, с которыми кандидату предстоит работать. Сделайте оффер живым, настоящим и человечным, чтобы кандидат понимал, что он идет работать к реальным людям, а не в обезличенную организацию.
Во-вторых, желательно не просто отправить оффер, но и лично сообщить кандидату радостную новость о предложении работы — позвонить или написать в мессенджер. В идеале, как я уже писал выше, это лучше делать голосом. Задача такого звонка — понять реакцию человека на предложение работы: что он думает, как расценивает оффер, есть ли у него другие предложения и рассматривает ли он их наравне с вашим.
В живом диалоге проще уточнить, на каком этапе поисков работы находится ваш собеседник в данный момент, есть ли другие компании, от которых он уже получил или ждет оффера — и на какие суммы. Да, это конфиденциальный вопрос! Но если вы поясните, что это не праздное любопытство, а вы интересуетесь, чтобы понять свою конкурентоспособность, то вполне можете рассчитывать на ответ.
Поинтересуйтесь, по каким критериям он будет выбирать из предложений, и, если мы готовы сделать предложение на бо́льшие деньги, будем ли мы ему интересны? Важно понимать мотивацию кандидата, ведь когда человек выходит на рынок, у него далеко не всегда есть четкое понимание, чего именно он хочет, какие варианты вакансий есть на сегодняшний день, сколько денег ему готовы предложить и т. д. Некоторые люди годами сидят на одном месте и не представляют, что происходит на рынке труда. Необходимо понять, в каком статусе ваш отобранный кандидат сейчас находится и насколько ваше предложение ему интересно, — и исходя из этого действовать дальше.
При идеальном развитии событий кандидат скажет, что принимает наше предложение. В таком случае нам надо уточнить сроки его выхода на работу, а также еще некоторые детали. Например, сказал ли он своему руководству о будущем увольнении? Если да, то сколько ему нужно еще отработать? Если нет, то не будут ли, по его мнению, его стараться удержать на нынешнем месте? А вообще об этом кандидата стоит спрашивать еще на собеседовании, а здесь лишь уточнять, если вдруг до сих пор его нынешнее начальство было не в курсе.
Исходя из его ответов, вы можете записать себе, когда нужно будет снова выйти на связь и уточнить, поговорил ли он с руководством, как оно отреагировало, движемся ли мы дальше — готовим ли велком-пакет?
То есть даже если кандидат говорит, что принимает оффер, это не повод расслабляться и думать, что если согласился — значит, точно выйдет. Ничего подобного! Люди бывают разные: в компаниях, где я работал, бывали ситуации, когда кандидат говорил, что уже входит в здание, а на самом деле даже не собирался у нас работать (и не спрашивайте почему — я не знаю!). Ситуации бывают разные.
Гораздо менее приятная ситуация, когда кандидат говорит, что он пока не готов принять предложение о работе и ему еще нужно подумать.
В данном случае мы снова переходим к нашим любимым вопросам, которые начинаются с «почему». Нам важно понять, почему именно ему нужно подумать. Он что-то узнал о компании или команде, что его смутило? Или он будет выбирать между какими-то вариантами? Или он сам не знает, почему сомневается, — просто хочет подумать. Все эти моменты важно понять, вовремя отследить и среагировать: может, поменять оффер, попросить дополнительных денег, обсудить с тимлидом задачи, изменить условия соцпакета. Всё разнообразие нюансов невозможно просчитать и перечислить, но мы должны быть готовы с ними разбираться.
Если же кандидат говорит, что не принимает наш оффер, то опять-таки важно понять почему. В зависимости от того, какой ответ мы получим, а также зная реальные возможности компании, мы должны прикинуть, насколько можно поменять оффер и подкорректировать условия работы.
При этом важно разделить ответственность: мы со своей стороны попробуем сделать все, что можем, но и кандидат должен пообещать держать нас в курсе. Чтобы не попасть в ситуацию, когда кандидат из нас вьет веревки, важно договориться, чтобы он честно и своевременно сообщил, если примет другое предложение или изменит свое мнение.
Соответственно, по результатам этого общения мы идем к заказчику и разговариваем с ним. Процессинг кандидата, как вы уже поняли, в основном построен на переговорах, на нашем умении докопаться до истины и порой убедить его, что надо идти именно к нам.
На выставлении оффера участие рекрутера в жизни кандидата не заканчивается. Ведь по факту мы являемся для кандидата первым контактным лицом. А очень часто именно первый человек, который привел человека на работу, становится его доверенным лицом.
Развитие общения, конечно же, будет во многом зависеть от структуры и размеров компании: в больших организациях есть несколько сотрудников, которые отвечают за адаптацию нового члена коллектива. В компаниях поменьше есть тимлиды, которые работают над этой адаптацией, — и в таком случае они могут стать доверенными лицами. В совсем небольших фирмах за все процессы может отвечать рекрутер: он здесь и чтец, и жнец, и на дуде игрец — поэтому в его задачу будет входить помощь в адаптации кандидата.
Но вообще, даже в большой компании между рекрутером и сотрудником, которого он принимал на работу, формируется определенный уровень доверия. Поэтому я считаю, что на этапе адаптации кандидата в любой компании рекрутер не должен отключаться. Оставайтесь на связи: например, есть смысл периодически уточнять у кандидата, как проходит его испытательный срок, всем ли он доволен, есть ли вопросы, сомнения, пожелания? Мне кажется хорошей практикой устраивать периодические встречи новичка один на один не только с тимлидом, но и с рекрутером.
Будет очень здорово, если в первый день выхода кандидата на работу — когда он, по сути, окончательно перестает быть кандидатом и становится сотрудником — вы напишете ему, спросите, как дела, предложите сходить на кофе или на обед. Человек, выходя на новое место работы, так или иначе находится в стрессе, и такое внимание будет снимать напряжение. Это не только крайне полезно для поддержания имиджа компании и вашего личного бренда, но и просто человечно. Мы все люди, и все истории про корпорации, этику, бизнес-процессы и прочие абстракции — это прежде всего истории про людей и качество их общения.
Поэтому не поленитесь лишний раз подойти к новому сотруднику, спросить, как прошел его первый день, — станьте для него первым приятелем, которого он заведет в организации. Хотя истории с дружбой на работе с психологической точки зрения порой осуждаются, но по факту в нашей взрослой жизни мы зачастую находим друзей именно на работе. Конечно же, я не предлагаю вам дружить с каждым человеком, который вам приятен, неприятен или безразличен. Такое общение — это не столько про дружбу на всю жизнь, сколько про создание комфортной атмосферы в месте, где вы работаете. Поддерживая других сотрудников, вы создаете для них комфортные условия, за счет чего среда в целом становится антистрессовой, а обстановка — доверительной.
Есть смысл позаботиться о новом сотруднике не только в первый день его работы, но и выходить на связь в течение следующих недель, а со временем поздравить его с прохождением испытательного срока. В современных АТС-системах, в которых вы ведете базу кандидатов, есть информация об этой дате, так что вы можете не запоминать ее, а настроить уведомление. В некоторых компаниях в KPI рекрутера прописывают прохождение его кандидатом испытательного срока — получается, при хорошем раскладе это будет ваш общий праздник.
Помимо таких простых шагов, нам также важно отслеживать прогресс кандидата с его тимлидом: интересоваться, как идет процесс адаптации, прижился новый сотрудник или нет, чего ему не хватает, может быть, есть какие-то вещи, которые тимлиду хотелось бы высказать, но он пока не решается.
Общаться ли с тимлидом и вникать ли в успехи новичков, во многом зависит от выстроенных в компании процессов. Как минимум поинтересуйтесь, проводит ли тимлид встречи с глазу на глаз с сотрудником, насколько регулярно дается фидбэк по его работе, соответствуют ли ожидания реальной работе и т. д. Если такие встречи проводятся, то идет ли процесс performance review (любая попытка перевода этого выражения на русский все же не кажется мне абсолютно адекватной, но это что-то типа обзора результативности), в рамках которого тимлид оценивает профессиональные качества сотрудника и обсуждает выполнение задач. Если нет, то есть повод задуматься о введении этой методики.
Важно знать, по каким принципам будет оцениваться прохождение испытательного срока. Причем понимать это нужно не только вам и тимлиду, но и самому сотруднику. Если параметры его прохождения детально прописаны (желательно еще в оффере), вам будет проще сориентироваться, насколько успешно идет адаптация. И если со временем возникнет необходимость уволить сотрудника, при таких условиях это произойдет проще и спокойнее. У вас будут формальные признаки, на которые можно ссылаться при увольнении, и компании не придется платить человеку три оклада.
К сожалению, все люди разные, и мы всегда рискуем попасть в неприятную историю, когда кандидаты проходят испытательный срок и потом увольняются, делая это достаточно агрессивно, чтобы получить хорошие деньги на выходе. Даже идеальная оценка не дает гарантий, что такого не произойдет, — это нормально. Главное — не пугаться таких ситуаций и продолжать работать.
Это базовые вещи, с которыми вы, возможно, уже сталкивались не раз. Я не могу назвать себя выдающимся экспертом по адаптации — к счастью, на эту тему есть множество другой обучающей литературы. Но как человек, который процессил множество кандидатов, я буду настаивать на том, чтобы у вас был план адаптации каждого нового сотрудника. Если вы IT-рекрутер, вероятнее всего, этот план делаете не вы, а тимлид, но вы должны быть в курсе происходящего. В плане важно прописать, что́ человек должен уметь делать на момент начала работы, какие навыки должен приобрести за первые два-три месяца, какие задачи обязан выполнить, — то есть что от него ожидается.
Важно соотносить ожидания кандидата и руководителя, чтобы у них было точное понимание, чего они друг от друга хотят и ждут в период испытательного срока. Если что-то пойдет не так, у всех участников процесса должно быть точное понимание: да, это не так. В противном случае между людьми будет копиться недопонимание, которое они в конце концов друг другу выскажут.
В данном случае рекрутер может выступать буфером, смягчающим удар, коммуникатором, который находится между заинтересованными сторонами. Он может вовремя получить фидбэк от каждого, что-то подсказать той и другой стороне, обратить внимание на сложившееся недопонимание — и попытаться наладить ситуацию. Если вдруг мы понимаем, что между сотрудником и заказчиком нет внятной коммуникации, они по какой-то причине не находят общий язык и не понимают друг друга, мы можем настоять на том, чтобы они встретились и обговорили детали работы. Или подсказать каждой стороне возможности решения задачи. Или подкорректировать процессы так, чтобы каждый участник получал адекватный фидбэк.
Опять же оговорюсь, что в больших компаниях этими процессами занимаются отдельные специалисты, например HR-бизнес-партнеры, так называемые бади или просто специалисты по адаптации. Но в маленьких зачастую эту задачу выполняет рекрутер.
Таким образом, уже после приема кандидата на работу у нас может быть несколько функций: административная — выстраивание процессов оформления и адаптации; адаптационная — поддержка сотрудника; коммуникационная — менее официальная, но значимая, когда мы оказываемся между заинтересованными сторонами и помогаем им наладить сотрудничество.
Все эти функции так или иначе завязаны на простой человеческой поддержке. Даже если в компании есть HR-бизнес-партнер, мы помним, что между рекрутером и сотрудником уже присутствует определенный уровень доверия, который начал формироваться с первых интервью. Вы становитесь для человека проводником в компанию, а это многое значит! Поставьте себя на его место и попробуйте понять, почему он нервничает, насколько ему хорошо или не очень, и попытайтесь сгладить острые углы, чтобы он смог полноценно реализоваться на новом месте. В конце концов, если вы не чувствуете в себе внутреннего желания это делать, у вас есть внешний фактор — KPI, в который сегодня зачастую прописывают успешную адаптацию кандидата. Если внутреннего позыва помогать нет, найдите его извне — пусть это будет корыстный интерес, но в данном случае есть шанс, что он будет всем на благо.
Надеюсь, прочитав эту книгу, вы почерпнули как минимум несколько новых идей, которые позволят вам развиваться в работе IT-рекрутера.
В завершение я хочу напомнить о главной составляющей нашей профессии. Несмотря на то что наша успешность во многом зависит от разнообразия практических инструментов в нашем арсенале, самым важным остается человеческий фактор.
Нам приходится многому учиться, оттачивать навыки коммуникации, делать много технической работы, но во главе успешности всегда будет стоять наша человечность. С одной стороны, это желание и умение помогать людям, а с другой — способность становиться на их место, «мыслить как преступник».
Как бы круто мы ни выучили матчасть по маркетингу, все равно, чтобы написать хороший текст вакансии, надо встать на место кандидата: как говорят американцы, почувствовать себя в его ботинках. А это значит, что надо включить эмпатию и посмотреть на мир глазами другого человека.
Как бы мы ни отладили процессинг кандидата, нам нужно постараться сделать каждое отдельное интервью человечным — комфортным для всех его участников. А для этого, опять же, надо понимать, кто и как переживает собеседования и чем мы можем помочь в конкретной ситуации.
Сейчас много говорят о том, что со временем рекрутеров могут заменить роботы. И уже существуют, например, системы автоматизированного обзвона для массового поиска. Но для более высокоуровневого поиска — поиска живых людей с хорошими навыками, которым необходимо вписаться в коллектив таких же живых, образованных, интересующихся «хомо сапиенсов», — всегда будем нужны мы, специалисты, способные выстраивать взаимоотношения.
В гонке за успешными показателями достаточно легко забить на человеческую составляющую рекрутмента; я же призываю вас, наоборот, ее культивировать. И, кстати, как всегда, проще всего начать с себя: мы, рекрутеры, тоже живые люди. Поэтому должны давать себе право на ошибку. Переживать, нервничать, ошибаться, потом вставать и действовать дальше — это в нашей человеческой природе. Так что не бойтесь экспериментировать, пробовать новое и двигаться вперед в профессии: без ошибок это еще никому не удавалось, и каждая новая ошибка может стать отличной возможностью дальнейшего роста.
Успехов вам в ваших начинаниях, и пусть все вакансии закрываются именно так, как надо!
Хочется выразить особую благодарность Евгении Либневиц, без которой создание этой книги затянулось бы еще на несколько лет. Ирине Гусинской за ответ на мое «холодное письмо» и готовность работать с никому не знакомым пока еще не автором. Анне Атрошкиной и Язиле Насибуллиной, с кем мы работали над проектом, благодаря которому пришла идея написать эту книгу, и чей вклад неоценим. Елене Ленсу за помощь в борьбе с синдромом самозванца при написании отдельных глав.
Всем моим друзьям, поддерживающим меня даже в таких сумасшедших и масштабных задумках, как книга. И родителям — потому что когда еще возникнет возможность написать им спасибо в книге?:)
Tegze Jan. Full Stack Recruiter: The Modern Recruiter's Guide. CreateSpace, 2017.
Мне тут сказали, что нужно избегать неоправданных англицизмов. И вроде как действительно: сорсинг — это тот же поиск, но мне все же кажется важным использовать термины, принятые в профессиональной среде. Тем более что отличия есть. О них как раз читайте ниже.
Кстати, именно такую формулировку чаще используют в кадровых агентствах.
Scrum — один из фреймворков гибких подходов к разработке. Подробнее мы о нем поговорим далее.
Code review — это практика, когда более опытный разработчик или команда совместно с автором просматривают написанный кусок кода, анализируют и рецензируют его с целью нахождения узких мест, ошибок и выявления наиболее оптимальных решений. В современных IT-компаниях эту практику в большинстве случаев стараются внедрить.
Система контроля версий — это специальное ПО, сохраняющее различные версии проекта, чтобы впоследствии была возможность вернуться к предыдущей версии. Например, если новые доработки оказались «кривыми» и повлекли много ошибок (багов), которые не были замечены при тестировании. Еще важная черта системы контроля версий — это возможность писать проект одновременно нескольким разработчикам и даже командам разработки.
Условно релиз можно назвать анонсом, выпуском нового функционала ПО.
Бэклог — список задач, которые нужно выполнить команде, отсортированный по приоритетности их выполнения. Термин как раз относится к семейству гибких методологий, о которых мы говорили выше.
Фронтенд-разработчики — это разработчики видимой на веб-странице части программного обеспечения, то есть того, что мы с вами можем увидеть как пользователи.
Стек технологий — это набор элементов, языков программирования, фреймворков, библиотек, который используется для разработки проекта.
Legacy-код — устаревший код, который необходимо поддерживать. Обычно, если его много, это означает отсутствие новых интересных задач для разработчика, а значит — сложности в поисках для вас.
Деврел — это довольно новая профессия для РФ, предполагающая человека, который занимается построением взаимоотношений с IT-сообществами: организацией митапов, конференций, развитием личного бренда разработчиков. На Западе деврел больше занимается продажей технологий для разработчиков.
13 Берем реальные задачи.
14 Прописываем важность (по нашему мнению) каждой.
15 Ставим оценку этому параметру: насколько менеджер по продажам сможет выполнять эту задачу.
16 Дальше прописываем риски, которые видим в вакансии.
17 Здесь же наоборот: чем ниже риск, тем ниже балл; чем выше риск, тем выше балл. Вероятность того, что менеджеру по продажам надоест делать то, что он и так делал сто лет, кажется высокой.
18 Из итога оценки по задачам мы вычитаем риски, чтобы получить балл, на который будем опираться в дальнейшем.
MVP (minimum viable product) — минимально жизнеспособный продукт, обладающий минимальными, но достаточными для удовлетворения первых потребителей функциями.
Кстати, на сленге GUI так и называли: гуи. И можно было спросить у кандидата, если он работал с Qt, занимался ли он исключительно «гуями» или и внутренней логикой тоже.
Дэвис Дженнифер, Дэниелс Кэтрин. Философия DevOps. Искусство управления IT. — СПб.: Питер, 2017.
B2B продажи — business to business (бизнес для бизнеса). Это означает, что компания или ее подразделение продают свой товар/услуги корпоративным клиентам, то есть другим компаниям.
Именно потому, что термин boolean search образован от фамилии ученого, его правильная передача на русский язык — «булев поиск». Так что придется писать именно так, хотя в Рунете часто встречается и «булевый», и «булевой».
Второй, ага. В нем и правило про двоеточие не нарушено, и логика верная: мы же ищем либо фразу «php программист», либо «php developer», правда?
А тут как раз первый. В нем и регистр букв верный, и логика не нарушена.
Муахаха, касатики. Всё обман. Это был вопрос с заковыркой. Оба запроса — неправильные. В первом оператор site: написан с большой буквы, а во втором после него стоит пробел.
Иванова Светлана. Что скрывает кандидат? 41 опросник для оценки факторов риска при проведении интервью. — М.: Альпина Паблишер, 2019; Она же. Как найти своих людей: Искусство подбора и оценки персонала для руководителя. — М.: Альпина Паблишер, 2021.
Смарт Джефф, Стрит Рэнди. Кто: Решите вашу проблему номер 1. — М.: Манн, Иванов и Фербер, 2017.