Как мы полностью поменяли собеседования

Меня зовут Саша, и я руковожу backend-разработкой в Tutu.ru. Сегодня я расскажу, почему и как мы полностью поменяли процесс собеседования кандидатов за прошедший 2018 год.

Итак, диспозиция на начало года

• Мы быстро растем – нам нужно набирать новых сотрудников
• Сообщество разработчиков о нас думает примерно «Ну это сайт с расписанием электричек – там наверно 3 человека работает в подвале». На самом деле у нас сейчас 7 бизнес-направлений и два десятка команд, которые над ними трудятся.
  Кстати, немного об электричках

  Кстати, в команде Электричек 7 разработчиков, а еще там высоконагруженные микросервисы, которые мы начали переписывать на go
• На собеседовании мы задаем логические задачи, задачи по синтаксису php, ООП и базам данных

Честно говоря, подбор шел медленно. Забегая вперед, скажу, что к концу года мы увеличили скорость набора в 4 раза, при этом не потеряв в качестве кандидатов. Надеюсь, я вас заинтересовал. Читатель, если ты совсем суровый технарь и хочешь почитать только о техническом собеседовании, то тебе в этап 2 :)

Наш подбор состоял из трех этапов:

• собеседование с HR;
• техническое собеседование;
• собеседование с руководителем отдела (мной).

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

Этап 0: привлечение кандидата

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

Мы увидели две проблемы:

• о нас мало кто знает, как о технологичной компании (количество откликов близко к нулю);
• вакансия написана «примерно как у всех».

Что же делать?

А давайте перепишем вакансию

Переписали более модно-молодежно. Но продуктовая разработка нас научила все проверять на данных. Решили проверить двумя АВ-тестами:

• создали две одинаковых вакансии на hh.ru сначала с разным названием должности;
• поставили в этих вакансиях еще и разный текст.

Оба АВ-теста показали 0. «Просто» решить проблему не получилось, нужно решать системно. Это мы тоже любим. Какие гипотезы мы выдвинули из этого эксперимента: похоже, что текст вакансии мало влияет на желание людей у нас работать (значит нужно качать HR-бренд) и что люди хотят прочитать что-то другое.

Повышаем узнаваемость

Мы решили начать с малого и, кажется, не прогадали. Мы не стали придумывать мега-докладов или ставить стендов на огромной конференции, а решили проводить свои митапы. Но вот проблема: из живых php-сообществ в Москве есть только Symfoniacs, а мы как-то ну совсем не про Symfony. Решили сделать свой: искали спикеров, рисовали бейджики, гоняли доклады по 7 раз. И таки получилось, и получилось два раза: раз, два. Будет и третий, и дальше.

По прошествии времени можно сказать определенно: митапы не дают мгновенного эффекта (вам не пришлют сразу десятки резюме), но они заметно повышают узнаваемость. Я все чаще слышу: «О, а я у вас был».

Экономим время кандидата

Все знают, что рынок разработчиков сейчас – это рынок соискателя. Хорошие специалисты чуть ли не каждый день получают сообщения с предложением работы или приглашением на интервью. А теперь попробуем представить, сколько нужно ездить на очные встречи (да еще и в каждую компанию по несколько раз). Поиск работы мечты может превратиться в «о, Господи, хватит уже». Как мы, как потенциальный работодатель, можем помочь с этим кандидату?

Например:

• разумно уменьшить время, которое нужно потратить на общение;
• пробовать что-то узнавать о кандидатах удаленно.

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

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

Этап 1: HR

На этом этапе мы нашли две проблемы:

• У нас были логические задачки, оторванные от реальности (привет шарам в самолете и канализационным люкам), которые, как показывает практика, не всегда могут раскрыть потенциал кандидата, а вот создают негатив довольно часто. Хуже того, бывало, что кандидат уходил домой только из-за того, что не решил задачки, – это создает плохую репутацию. В общем, логических задач из учебника у нас на собеседовании больше нет: системное мышление и умение нестандартно мыслить мы проверяем на техническом собеседовании задачами, возникающими в реальной жизни.
• Мы вообще не собирали обратную связь кандидата о прохождении собеседования у нас. Теперь собираем, строим метрики и работаем с тем, чтобы candidate experience был хорош.

Этап 2: техническое собеседование

Задачи

Что из себя представляло наше техническое собеседование год назад: вы попадаете в переговорку на 1-1.5 часа с одним из тех. лидов, решаете задачки по php, ООП, mysql. Дальше все – на усмотрение каждого отдельного собеседующего. Согласитесь: если вы senior, странно отвечать на вопрос «чем отличается isset от empty?». А нам еще страннее на основании этих вопросов принимать решение, что кандидат сможет выполнять наши задачи и делать это классно.

Мы подумали: «А что же на самом деле должен знать кандидат, чтобы делать у нас задачи и развиваться?». Ответов было несколько:

• Чтобы просто делать задачи:
  • ООП и рефакторинг (Мы за красивые поддерживаемые решения, а еще у нас все еще есть монолит)
  • Проектирование API (Тот самый монолит нужно бить на микросервисы, новые задачи мы решаем только на микросервисах. Проектирование хорошего API в сегодняшнем мире – самое важное умение backend-разработчика)
  • Уметь работать с внешним API (У нас много разных партнеров с разным уровнем качества API)
  • Должен понимать в БД в широком смысле (SQL и разные NoSQL решения)
  • Хорошо бы, чтобы что-то знал о unit-тестах (если что, научим) и пользовался правильными инструментами для разработки
• Чтобы классно выполнять свою работу и развиваться:
  • Обладать глубокими теоретическими знаниями в своей области
  • Уметь эффективно применять теорию на практике

Оказывается, нам не нужно целенаправленно спрашивать ничего о знании языка, и это интересно. Но и это не все! Мы хотим проверить по сути две вещи: обладает ли кандидат нужными нам hard-skills и проверить, есть ли у него потенциал к дальнейшему развитию. Значит, нужно как можно лучше понимать его карьерный путь: с какими ситуациями кандидат уже сталкивался в своих проектах и как их решал. Поэтому в первую очередь мы узнаем о том, что кандидат сделал на предыдущих местах работы. После собеседующий дает задачи из нашей реальной предметной области и проверяет, как кандидат будет с ними справляться. В итоге у нас получился формализованный сценарий технического собеседования, где собеседующий должен дать ответ на определенные вопросы. Интересно, что время собеседования с новыми задачами практически не изменилось – мы по-прежнему тратим в среднем 1.5 часа.

Процесс

В ходе исследования обратной связи оказалось, что сегодня кандидат от собеседующего его технического специалиста уже не ждет простого диалога «задача-ответ» и разговоров только на технические темы. Рынок меняется: кандидатам интересно знать, какие конкретно они будут решать задачи, в какой команде, какие используются технологии и подходы в смежных областях. Теперь у нас каждый собеседующий обязан знать, какие бизнес-задачи решаются в разных командах, примерные планы и текущее состояние технологий, причем не только backend, но и всех остальных ролей команды.

Вишенка на торте

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

Этап 3: финал

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

Этап 4: адаптация

Казалось бы: ну вот же, сотрудник уже в компании, зачем дальше париться? У нас со времени основания компании существует институт наставничества: каждый новый сотрудник получает наставника в своей команде. Но и здесь было, что улучшать. В разных командах разный уровень сложности предметной области, и есть соблазн отправить сотрудника на многодневное обучение прежде, чем он начнет выполнять свою первую задачу. Как показала наша практика, после такого обучения человек обычно практически ничего не запоминает, грустит, и время потрачено зря. Поэтому мы ввели правило: «Сотрудник на третий день обязательно должен взять задачу из спринта». Правило отлично работает в связке с системой обучения, где новичок может почерпнуть нужные знания именно в тот момент, когда они ему нужны.

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

Заключение

Что же мы имеем на выходе? Результаты такие:

• Количество откликов на вакансию изменилось с «почти никогда» до «каждый месяц несколько откликов»
• Скорость подбора увеличилась в 4 раза при том же качестве
• Мы имеем стандартный фреймворк технической оценки технических специалистов, который позволяет хорошо понимать, как будущий сотрудник справится с работой
• Оптимизировали свое время и время кандидата
• Нащупали, как лучше проводить адаптацию внутри

Автор: Александр Миненок

Источник