Всем привет! Меня зовут Олег Смоляков, в Яндексе я больше 15 лет занимался разработкой, а теперь отвечаю за улучшение процесса найма разработчиков.

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

TLDR: мы решили обновить процесс найма, вместо порой хаотичных собеседований в каждом отдельном сервисе внедряем единую систему оценки по профессии и уровню (например, «Senior C++ Developer»), кандидат, успешно прошедший оценку навыков, теперь сможет претендовать на аналогичные вакансии в любом из 90+ сервисов компании, а всё это вместе делает процесс найма прозрачным, понятным, без дублирования технических интервью и в целом эффективным для всех участников.

А теперь подробнее о том, почему мы на это пошли и как всё устроено.

Наша цель — нанимать сильных и воодушевлять тех, кто хочет ими стать

Сначала расскажу о себе. Будучи студентом Бауманки в 2005 году, я искал работу и кликнул на объявление, где Яндекс искал разработчика. Там была домашка. До сих пор помню, как два вечера кайфовал, делая её. Потом были собесы, на которых я решал задачи, не похожие ни на что, чем я занимался до этого. Впрочем, ещё на домашке я влюбился в это ощущение «сложного и моего», поэтому итог был предопределён. А через несколько лет я уже сам собеседовал и нанимал новых ребят, и до сих пор регулярно радуюсь, когда кто-то из них становится следующим СТО или СЕО в Яндексе (Валера Стромов, привет!). Однажды мне пришлось отказать кандидату, но я постарался подробно объяснить, что ему стоит почитать и какие проекты поделать для роста.

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

Годы спустя я сходил в саббатикал, вернулся, а у компании как раз назрел запрос на обновление процессов в найме. Так я взялся за реализацию этой давней цели.

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

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

Что было не так: разбор старых проблем

1. Процесс найма очень долгий, а этапов и дублей очень много

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

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

• «Мне провели несколько технических секций про одно и то же».

• «Я умею управлять людьми, а меня три раза просили написать код на позицию IC».

• «Я прошел технические секции, а на финалах с командами меня снова начали гонять по технике».

• «Меня прособеседовали в один сервис, мы не договорились. Попробовался в другой — сказали проходить все технические секции заново».

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

Мы хотим эффективно тратить время всех участников, уметь выявлять сильных инженеров и делать им достойные предложения — для этого важно понимать сильные стороны кандидатов и не проводить при этом лишние ненужные этапы.

2. Процесс не всегда прозрачный

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

Причины снова разные:

• насколько корректно определили на старте профиль кандидата: если плохо, то через пару секций станет понятно, что, оказывается, это не бэкендер, а аналитик, и не на джаве, а на питоне;

• насколько хорошо регламентирован дальнейший путь кандидата: все этапы явно заданы исходя из профиля или каждая следующая секция определяется только после прохождения текущей;

• насколько отлажена коммуникация: всё держится на обученных рекрутерах или автоматизировано.

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

3. Плохая обратная связь после секций

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

Сложная, но долгосрочно важная для нас задача, и мы хотим её решать.

4. На секциях решаем задачи, которые не встречаются в работе

Это вечный холивар. Если рассмотреть хардовые навыки (пока отложим в сторону софты), то их условно можно поделить на фундаментальные навыки и знания и на специальные знания конкретного инструмента, языка или фреймворка. Как правило, получение фундаментальных знаний — это дорого по времени и силам, требует как изучения теории, так и практики, и почти невозможно наверстать за условный месяц. Специальные знания зависят от области и могут либо требовать определённых фундаментальных навыков и в этом случае легко обретаются поверх, либо бывают сами по себе тоже дорогими и требуют многолетнего опыта.

Но самое интересное другое — за час технической секции интервьюер должен оценить уровень того или иного навыка кандидата. Вовсе не решить задачу, а оценить уровень. Желательно таким средством, которое будет обеспечивать стабильное качество результата, например, один из маркеров хорошо спроектированной секции — её результат зависит от кандидата, а не от интервьюера. Отсюда и получается, что часто на секциях используют такие задачи и вопросы, которые по статистике дают лучшее приближение оценки к реальному уровню навыка. Если бы по скану сетчатки можно было бы определять навык программирования, никто бы не удивлялся сканированию на секции :) Так и с задачами: насмотренность интервьюеров, стабильность путей решения задачи, хорошая скоррелированность оценок задачи с реальным уровнем навыка бывают важнее того, насколько задача реальна.

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

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

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

Как мы это всё решаем

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

Поэтому начали мы не с того, чтобы кидаться всё сразу улучшать, а с перехода к системе, в которой процесс найма разработчика начинает зависеть не от того места компании, в которое он нанимается, а от профессии и профиля, которым он соответствует. Senior-разработчик инфраструктуры на С++, middle-разработчик мобильных приложений, эксперт в области компьютерного зрения, тимлид команды девопсов – вот наша новая правильная карта найма, а не «разработчик в Такси» или «инженер по тестированию в Алису». Вакансии и конкретные сервисы — это то, что может привлечь кандидатов на старте, и то, куда кандидаты будут приземляться, пройдя этап оценки.

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

Причём профилей должно быть конечное количество, буквально десятки на всю компанию. По сути, все профессии разработки, отчасти разделённые на специфичные стеки или области (например, инфраструктура/продукт, язык программирования или ML-направление).

В нашем текущем решении мы уже выделили следующие профессии (и профили внутри профессий): 

• бэкендеры: С++, Java, Python, Go;

• фронтендеры;

• мобильщики;

• ML-щики;

• инженеры по тестированию;

• аналитики и аналитики-разработчики;

• девопсы и SRE-специалисты;

• разработчики под Oracle.

Внутри они делятся по уровню, как правило, на два или три: junior/middle и senior. И сквозь эти профессии есть ещё два признака:

• TechLead — тот, кто не только сам решает задачи на работе, но и принимает технические решения на уровне команды (например, отвечает за архитектуру сервиса или валидирует работу других разработчиков);

• TeamLead — руководитель других разработчиков.

На каждое сочетание профессии, уровня и признаков лидерства мы разработали свой набор секций. Часть из них, например секция для тимлидов, общая для всех. Другая часть, например любимая АА, общая для всех бэкендеров. В каждой профессии, кроме проверки фундаментальных навыков, появились секции, специфичные для области: программирование на конкретном языке, архитектура построения мобильных приложений или архитектура сервисов для DevOps с разными ответвлениями, например в управление трафиком. Секция про опыт позволяет провалидировать навыки техлида, которые сложно проверить только кодовой или архитектурной задачкой.

За каждой секцией закреплен пул интервьюеров. Они проходят обучение, калибруются между собой, с СТО и с дальнейшими оценками нанятых сотрудников. Это позволяет повысить доверие к результатам секций со стороны разных подразделений и не дублировать их, если кандидат подаётся на вакансии в разные направления, а на финалах наконец рассказывать про команду, а не продолжать пытать кандидата техническими задачками (хотя, признаюсь, пока у нас бывают накладки, нанимающие менеджеры где-то по инерции, а где-то в попытках определить cultural fit переходят на привычный им способ — спросить что-нибудь техническое).

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

Для тех профессий и профилей, которые мы уже поддержали в новом процессе, мы больше не проводим для одного кандидата однотипные технические секции. И не проводим лишние технические секции. Junior- и middle-разработчики в большинстве профессий проходят 2-3 секции, а senior-разработчики — 4-5.

Что уже работает, а что появится позже

Нет такого рубильника, который мог бы в один момент переключить старый процесс на новый — в Яндексе в среднем за день проходит собеседование 200 кандидатов. Мы постепенно растим долю кандидатов и число профессий, которые живут по-новому. Где-то это зависит от скорости обучения новых интервьюеров, где-то — от необходимости автоматизации.

За последние несколько месяцев больше половины кандидатов Яндекса прошли по новому процессу найма, и эта доля постоянно растёт. В профессиях бэкенда, фронтенда, мобильной разработки и DevOps/SRE таких большинство, и в этом году доведём долю до целевых 95%. Оставшиеся 5% — это разные кастомные роли, требующие либо очень специфичных навыков, либо знания редких для Яндекса языков (например, Scala). Продолжим растить долю в остальных профессиях разработки и в 26 году переведём на новый процесс все профессии, в которых у нас большой найм: ML, аналитики и аналитики-разработчики, инженеры по тестированию.

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

И, конечно, продолжим экспериментировать с сокращением длительности процесса. Одна из главных причин долгого найма — логистика секций и, прежде всего, перерывы между ними.

Моя мечта — отладить механизм до такого состояния, при котором кандидат (если он, конечно, готов) проходит все технические секции за 1 неделю и ещё неделю выбирает себе команду. А все остальные свойства, описанные выше, при этом сохраняются. Это сложно, но верю, что такого состояния добиться можно.

Буду рад вашим вопросам и комментариям.