Как устроен процесс найма в отдел клиентских приложений RUTUBE
Когда я пришел в компанию, в начале 22-го года, за весь фронтенд отвечали 5 разработчиков. Вчера, мы пересекли отметку 50 человек в отделе и это ощущается, как серьезный рубеж. Когда-то я проводил собеседования, нанимал и онбордил самостоятельно. С ростом команды и запросов на найм, неизбежно пришлось научиться делегировать части процесса, где-то адаптировать и перестраивать процесс целиком. Вот что имеем на текущий момент:
0️⃣ К нам поступает заявка на подбор. Уточняем какие задачи стоят перед командой продукта, определяем вместе с техническим лидом какой грейд специалиста нужен (intern, junior, middle или senior). Обычно, у рекрутеров всегда несколько заявок на подбор.
1️⃣ Отсматриваем резюме. Этот этап не всегда обязателен, потому что есть определенные критерии, которыми должен обладать спец и они известны рекрутеру. Но, иногда, хочется понять на кого ставить собес — у нас несколько собеседующих из разных команд, которые могут сразу проверить конкретные компетенции относительно открытых ставок. Так же, есть рискованные моменты в резюме с точки зрения его оформления и с таким человеком не хочется общаться, потому что его культура с вероятностью выше 50% не совпадет с нашей — опыт говорит, что эта корреляция реально работает. Про резюмешки писал пост выше. 2️⃣ Проводим техническое интервью. Обычно, оно занимает 1,5 часа и включает в себя софтовую секцию, чтобы разговорить кандидата, понять насколько происходит культурный метч и какие вопросы не стоит задавать, а в какие темы наоборот стоит углубиться. Далее, у каждого собеседующего есть ряд своих вопросов, приемов и техник, с помощью которых он проверяет знания кандидата и определяет грейд. Тема грейдов, в принципе, нетривиальна, особенно, когда у нас есть всего час на техническую секцию и широкая выборка компетенций, которую нужно проверить (напишу об этом отдельный пост). Кстати, большой техсобес нужен не всегда. Например, если у нас задача провести стажировку и нанять интернов, достаточно подготовить тестовое с четкими критериями оценки и отсеивать при невыполнении критериев. А тех, кто прошел, собеседовать по тестовому. Ранее писал пост про один из важных вопросов на собесе, ознакомьтесь. 3️⃣ Интервью с командой. Если кандидат удачно прошел технический собес и его грейд нам подходит, мы определяем в какую команду кандидату лучше всего будет выйти относительно его пожеланий и задач в команде. Тут кандидат задает свои вопросы, команда свои и все стараются понять насколько ок будет работать вместе. Бывает так, что этот этап вскрывает софтовые проблемы кандидата (иногда проблемы команды..) и полное непонимание/нежелание работать в тех процессах, в которых мы уже работаем. И это риски, на которые мы либо идем, либо.. нет (скорее всего нет). Либо этап с другой командой.
4️⃣ Обратная связь. Тут два варианта: либо нужно сказать почему кандидат нам не подошел, либо оффер. С оффером все понятно, а вот с тем как и что говорить, если ответ "нет" — далеко не так все прозрачно. Я думаю, что стоит посвятить этой теме отдельный пост и сформулировать что же такое качественная обратная связь (мы сами еще тестируем гипотезы), но точно могу сказать: отписка рекрутера, как на картинке к посту, не прокатит.
5️⃣ Выход и онбординг. Тут точно нужно будет несколько отдельных постов подготовить, очень большие темы. Но что точно скажу: выдавать доступы и технику неделями — это очень плохо! Ответственность руководителя в том, чтобы этот процесс выровнять и как можно сильнее сократить. У нас получилось уложится в день (для сотрудников из оффлайна), но мы работаем над тем, чтобы все было еще лучше автоматизировано и запротоколировано. А что касается онбординга? Его стоит проводить либо в рамках реальных задач команды, либо в формате буткемпа. Как сказал ранее, опишу две эти темы отдельными постами, а пока можно послушать как устроен процесс найма в Яндекс 360. Мы с Ромой затронули тему буткемпа и выяснили почему он возможен не в любых командах и не во всех компаниях.
Think about it 🧠 | @ulyanov_life
