Мой путь в индустрии IT через призму найма

1b6bcc2d644f93c8c9088825ae6d704c.png

Предисловие

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

Начало карьеры управленца

Свой путь в найме я начал в 2014 году, в то время я уже частично выполнял обязанности руководителя IT отдела в небольшой томской компании, которая занималась разработкой программно-аппаратных решений.

Все ребята были амбициозными и заряженными на успех и мы быстро начали расти. В начале моей работы IT отдел был 4–5 сотрудников вместе со мной, в самом пике количество сотрудников в отделе составляло 30 человек, это еще нужно учесть что отпочковали от IT отдела: отдел технической поддержки и отдел ОТК, формированием которых изначально занимался я.

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

Так как я был совсем молод и достаточно ЧСВ-шен, то я не воспринял эту задачу как какую-то невыполнимую и сразу же ринулся в бой.

dfa73d481453aa43945254030d7374f3.png

О наличие специалиста по найму — рекрутера на тот момент никто не думал и все делали своими силами.

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

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

  • Прочитал множество статей, на тот момент роликов еще на ютубе по этой тематике почти не было;

  • Немного поспрашивал у более опытных в IT коллег;

  • Подготовил множество вопросов, не помню, штук 30–40;

  • Гордо распечатал их и прикрепил на планшетку.

С энтузиазмом ринулся проводить интервью.

Какой процесс найма у нас был на тот момент:

  1. Я размещал вакансии на HH.

  2. Осматривал всех специалистов.

  3. Приглашал подходящих приехать на интервью в офис (тогда еще никто из нас не думал об удаленке).

  4. QA, ассистентов, Ops-инженеров (тогда мы просто их называли админами) я полностью интервьюировал сам.

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

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

  7. Потом мы принимали решение и я шёл к директору согласовать кандидатов.

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

554e7ed8deb04c226e8b6b91db0cf783.png

Ситуацию не спас найм для меня ассистента, да, рутину удалось с себя сбросить, но задач было очень много.

Прогресс

Мы точно были не опытными, но мы были далеко не глупыми. Мы провели ряд ретро для разбора процессов и что же мы поняли:

  1. Лично я понял что вопросы на планшетке это полная туфта. Типовые вопросы не позволяют в короткий срок (один час интервью очень малое количество времени) быстро выстроить контакт, как сейчас говорится заметчиться с кандидатом. На тот момент я уже провел много интервью и мог спокойно действовать без подсказок. И уже тогда пришло осознание, что на интервью нужно действовать гибко и пытаться подстраиваться под кандидата, чтобы максимально его раскрыть и получить всю информацию, которая поможет принять решение нанимать или нет. И важный момент: кандидату гораздо интересней на интервью, где нетиповые вопросы, а вопросы, которые позволяют кандидату чувствовать себя комфортно и вести интересную беседу. И главное, кандидат с большей вероятностью примет оффер, если на интервью ему было интересно с интервьюером

  2. Необходим рекрутер.

  3. Нужно ассистента быстро обучить до руководителя проектов, если не удасться, то нанять (впоследствии наняли одного РП и одного из разработчиков по его желанию переучили в РП).

Мы наняли рекрутера и наш процесс най, а преобразился (был год 2016):

  1. Наконец-то купили хороший пакет услуг от HH, можно иметь много вакансий)).

  2. Рекрутер совместно со мной и инженерами составлял вакансию.

  3. Рекрутер вел коммуникацию с кандидатами.

  4. Кандидатов, которые потенциально подходили направлял на меня и инженеров.

  5. Приглашал на интервью и вел первую часть интервью минут 30 (назовем это HR интервью).

  6. Если кандидат по мнению рекрутера подходил, то я подключался к интервью и проводил свою часть.

  7. В случае если нужен был инженер сразу звали его.

  8. То есть интервью сразу могло содержать в себе HR+техническая часть+финальная часть.

  9. Потом принимали решение с рекрутером и инженерами.

  10. Я и рекрутер шли согласовывать кандидата с директором.

  11. Рекрутер отправлял оффер кандидату.

146c5993d20772a6c0646bce132c5319.png

Что это дало:

  • Меня разгрузили и я мог заниматься проектами и продуктами;

  • Рекрутер отсеивал сразу не подходящих кандидатов и мне не приходилось тратить на них время;

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

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

Завершение пути длиною в четыре с половиной года

Все не вечно, в том числе и срок жизни сотрудника в компании. К лету 2018 года я принял решение двигаться дальше. С ностальгией и мужской грустью я оглядываюсь на пройденный путь в разрезе найма.

706386bd12792c77213accc317f7af99.png

Описанные этапы найма в предыдущем пункте осталось почти неизменны, что модернизировали:

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

  2. Я обучил одного из коллег руководителей проектов проводить интервью.

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

  4. Все финальные кандидаты согласовывались со мной и не нужно было согласовывать с директором.

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

Чем закончилась моя деятельность в этой организации:

  • Сформирован IT отдел, который разделен по секторам бизнеса компании, годовая ссч ~30 сотрудников в отделе.

  • Сформирован отдел тех. поддержки, годовая ссч 3 человека.

  • Сформирован отдел ОТК, тут один человек постоянно)).

Простыми словами имеется боевой отдел с пост-релизной поддержкой и ОТК продукции на выходе к заказчику.

Новое начало

Летом 2018 я начал работать в сервисной компании (разработка программного обеспечения под заказ) на должности руководитель проектов (РП). Компания уже была больше предыдущей и занималась только разработкой ПО без разработки аппаратных комплексов.

127abe9de4d41cbd319484b568ddd0d9.png

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

Как выглядел процесс найма:

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

  2. Рекрутер ведет всю поисковую работу не только по HH, но и по всем популярным ресурсам.

  3. Рекрутер запрашивает скрининг у нанимающих экспертов.

  4. Рекрутер проводит HR часть с кандидатом и с применением скрининга.

  5. Вся деятельность ведется в системе HF (huntflow).

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

  7. Заапрувленным экспертом кандидатам назначается техническое интервью (ТИ).

  8. Эксперт проводит ТИ, зачастую онлайн, так как уже в этой компании была повсеместно удаленка. Оставляет обратную связь в HF.

  9. Кандидат отправляет на валидацию Руководителю проектного офиса (РПО) и СТО.

  10. Один из них проводит финальную часть интервью, также оставляет обратную связь в HF.

  11. После всех интервью рекрутер пишет письмо на согласование оффера на СТО и РПО.

  12. После согласования рекрутер делает оффер кандидату.

Новая должность

Летом 2020 года все изменилось. Было принято волевое решение пойти по прогрессивному пути развития IT компании и проектный офис, как единица перестал существовать. РП были выведены в отдел разработки и стали частью производственного персонала. Меня, как специалиста, который гибко может перестраиваться работе назначили на должность Ресурсного Менеджера (РМ).

1227c6fa5cc3a778a347f7983227f67e.png

В мои обязанности стало входить:

  1. Проведение всех финальных частей интервью.

  2. Распределение инженеров по проектам в зависимости от желаний и способностей.

  3. Совместно с HR и РП решать проблемы инженеров на проектах.

  4. Принимать решение по найму кандидатов.

  5. Проведение онбордингов в отдел разработки.

  6. Увольнение сотрудников.

  7. Подготовка инженеров к новым проектам.

Интервью стало много, помню что точно было в одну неделю 12–14 интервью. Важно, не допускайте чтобы интервью в один день шли подряд, делайте между ними паузы, а то вы не сможете написать обратную связь по кандидату и придется переслушивать запись.

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

В этой должности я проработал еще полтора года, но как я писал ранее все не вечно.

Финальная часть моего пути

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

А я куда? А у меня новая должность и по сей день 14.12.24 я HofSM — Руководитель Стек Менеджеров (ведущие инженеры специализаций).

ee02a22b6022e4468da722375d9b5bdd.png

Мои основные задачи:

  1. Организация части найма со стороны отдела разработки: актуальные скрининги, актуальные опросники и лайфкодинги по всем стекам (у нас их 10), формализация обратной связи как технической, так и общей для принятия решения и присвоения грейда кандидату. Контроль за качеством написания обратной связи.

  2. Организация обучающих мероприятий и ИПР для сотрудников стеков совместно с Центром профессиональных компетенций.

  3. Организация технической движухи в каждом стеке: проведение и организация встреч стеков совместно стек менеджерами (СМ).

  4. Организация проведения 1 на 1 инженеров с СМ.

  5. Помощь ДМам в подборе персонала на проекты.

  6. Совместно с HR, СМ и РП решать проблемы производства.

  7. Была введена должность Бенч-Менеджер (БМ), моя задача быть руководителем БМа.

  8. Участие в увольнении сотрудников.

  9. Интервьюирование РП, так как у меня большой опыт.

Что тут важного отметить в части найма:

  1. Скрининг постоянно модернизируем, сейчас для найма джунов и миддлов- проводим в ряде стеков онлайн технический опрос на 10 минут, с установленным проходным балом. В ряде стеков сейчас этот подход успешно себя зарекомендовал.

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

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

  4. Что касается моего проведения интервью, сейчас я шагнул еще дальше и для найма РП я придумал/взял из своего опыта несколько сложных кейсов, которые позволяют понять гибкость, адаптивность кандидата. Всеми я не могу поделиться, но для начала опубликую те, которые простые и можно их смело использовать для формирования общей картины:

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

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

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

Кому понравились мои мысли залетайте в пой ТГ канал: https://t.me/Lazzy_IT

a9d1e5be7e82b025ac861029088f0f9e.png

© Habrahabr.ru