Привет, Хабр! С вами Валерия Батон, руководитель направления рекрутмента Flowwow.
Недавно наш СТО Дима Шестернин рассказал о кризисе доверия на рынке IT и наших факапах в найме. Сегодня я подхвачу от него эстафету и поделюсь, как мы модернизировали процесс рекрутинга IT-специалистов во Flowwow, чтобы минимизировать неудачные кейсы.
Единый стандарт: зачем мы унифицировали этапы
Для начала давайте вспомним, с какими кейсами мы столкнулись: это осознанная меркантильность, фантомы на удаленке, цифровые несуществующие профили. Смотря на это, я вижу ключевую проблему: ожидания кандидатов или работодателя не совпадают с реальностью. Именно поэтому, на мой взгляд, рушится и репутация.
IT-рынок изменился и продолжает это делать. Как показывают исследования, он сейчас столкнулся с абсолютно непривычными для себя реалиями. Это больше не классические качели от «рынка кандидата» к «рынку работодателя». Скорее, мы пришли к своеобразному балансу (хотя, на мой взгляд, чаша весов сейчас все-таки немного на стороне работодателя). Эпоха массового найма, когда бизнес активно расширял штат в IT-департаментах, прошла. Сегодня бизнесу (особенно в условиях ограниченных бюджетов) критически важно нанимать по-настоящему эффективных специалистов, которые будут давать результат, а не впустую тратить ресурсы.
Именно эффективных специалистов — тех, чьи навыки на практике будут совпадать с ожиданиями компании, — можно находить только в условиях единой системы координат. Вот почему мы унифицировали систему найма для всего IT-департамента. Раньше каждая команда могла добавлять свои этапы, менять их местами или использовать разные подходы к оценке. Это была та гибкость, которая работала, но на определенной стадии роста компании.
Теперь процесс найма живет в рамках трех фиксированных этапов. Это позволяет нам по одним и тем же принципам оценивать кандидатов для разных юнитов и гарантировать одну воронку для всех.
Наш процесс сейчас выглядит так:
HR-скрининг (30–40 минут) — быстрый мэтч по культуре и первичный технический фильтр.
Технический этап (до 90 минут) — проверка хард-скиллов в контексте наших реальных задач, а не абстрактной теории.
Софт-интервью (60–90 минут) — оценка того, как человек взаимодействует с командой и процессами.
Мы фиксируем эти три точки контакта, чтобы ни один важный аспект не выпал из поля зрения. Рекрутер на HR-скрининге фильтрует входящий поток, техэтап проверяет, как рассуждает кандидат, а софт-этап помогает понять, сможет ли он находить общий язык с будущими коллегами.
Как и во многих процессах — многое решают нюансы. Именно об обновленных деталях найма пойдет речь дальше.
HR-скрининг: первый технический фильтр
Раньше HR-специалист проверял базовые вещи: совпадение по корпоративным ценностям, опыт кандидата, зарплатные ожидания, а также рассказывал о «плюшках» компании. Но в условиях, когда навыки в резюме могут разительно отличаться от реальности, нам нужно было добавить еще и технический фильтр, чтобы не тратить время руководителя и коллег. Теперь это не просто смолл-ток, а проверка «сколько будет 2+2», но на языке IT-специалиста.
Важная ремарка: IT-рекрутер понимает базовые вещи и термины из IT, ведь только так он может работать с этим направлением.
Как работает этот технический фильтр? Техлиды каждого направления сформировали список фундаментальных вопросов. Это базовые вещи, которые, на наш взгляд, разработчик должен знать без долгой рефлексии и помощи поисковых систем. А рекрутеру достаточно услышать четкий и верный ответ.
Для понимания — это вопросы уровня:
В чем разница между интерфейсом и абстрактным классом?
Что такое Dependency Injection (DI) и зачем оно нужно?
Чем отличается JOIN от UNION в SQL?
Если кандидат не может дать ответ на подобную базу, то, по нашему опыту, вероятность того, что он не пройдет техническое собеседование, очень высока.
Кроме того, мы внедрили специальный транскрибатор — инструмент, который переводит аудио-интервью в текст (важно: мы против видеозаписей, это лишний стресс, поэтому программа транскрибирует речь в текст). В любом случае рекрутер фиксировал бы ответы, но теперь за него это сделают технологии. Ему не надо будет искать баланс между записью за соискателем и пониманием сказанного. Он полностью погружен в диалог и оценку софт-скиллов. После этого этапа техлид получает комментарии по кандидатуре, транскрипцию и может сам оценить, стоит ли приглашать соискателя на следующий этап.
Такой подход экономит время и позволяет нам выходить на техническое собеседование только с теми, чьи базовые компетенции не вызывают сомнений.
Технический этап: контекст важнее теории
Если кандидат успешно ответил на базовые вопросы на скрининге и мы понимаем, что он впишется в текущую команду, его ждет техническое интервью. Раньше этот этап часто сопровождался лайвкодингом или глубокими теоретическими вопросами. Однако мы проанализировали воронку и поняли: лайвкодинг часто снижает конверсию. И это вовсе не потому, что кандидаты слабые, а из-за запредельного уровня стресса. Это сопоставимо с тем, как если бы копирайтера попросили написать текст прямо на созвоне, вместо того чтобы дать ему тестовое задание.
Разработчик не обязан выдавать гениальный код в прямом эфире, где он так или иначе ощущает давление. Поэтому всем нанимающим менеджерам мы рекомендовали отказаться от лайвкодинга в пользу форматов, максимально приближенных к реальности.
Что мы внедрили взамен:
Ревью кода: мы даем фрагмент кода, написанный силами конкретной команды. Задача кандидата — провести качественное ревью: найти баги, подсветить узкие места, предложить улучшения. Это показывает не то, как человек помнит синтаксис, а то, как он мыслит и как будет работать с кодом на практике.
Груминг задачи: мы берем реальную задачу из бэклога (возможно, ту, что техлид закрыл буквально вчера) и предлагаем кандидату разобрать ее: обсуждаем архитектурные подходы, варианты реализации, возможные риски.
Почему такой подход работает лучше в реалиях нашей компании? Во-первых, эти задачи тяжело передать нейросетям в ходе интервью: кандидату нужно вникнуть в контекст, проанализировать. Во-вторых, это хорошо показывает соискателю то, с чем он будет иметь дело во время работы у нас. Таким образом, мы в том числе минимизируем те моменты, когда у работника не совпадают ожидания и реальные задачи во время испытательного срока.
Софт-интервью
Если харды подтверждены на реальном контексте, наступает финальный этап — софт-интервью. Его цель — понять, как человек будет работать в команде, брать на себя ответственность и выстраивать коммуникацию.
Здесь мы ввели важное ограничение: на интервью со стороны компании должны присутствовать не более двух человек. Наша позиция проста: кандидаты тоже выбирают нас. Если интервьюеров много, возникает хаос: размывается оценка кандидата, ломается структура беседы, и интервью затягивается.
Теперь мы рекомендуем лидам приглашать на этот этап product-менеджера, если в дальнейшем предполагается активное взаимодействие с ним. Раньше продакта почти не подключали к найму разработчиков, хотя он один из главных внутренних заказчиков. Будущий сотрудник должен понимать, кто будет оценивать результаты работы, а продакт — с кем ему предстоит выпускать фичи. Это еще один шаг к тому, чтобы ожидания совпали с реальностью.
Детали найма: ручной отбор и рекомендации
Чтобы картина была полной, хочу подсветить еще несколько неочевидных деталей нашего процесса найма.
Например, в самом начале воронки все отклики рекрутер отсматривает вручную. Мы принципиально не доверяем первичный фильтр ATS-системам. Робот легко может отсеять сильного специалиста только из-за нестандартного оформления резюме или случайной опечатки.
А вот процесс проверки документов мы, наоборот, автоматизировали на стороне HR (это происходит независимо от проверки СБ). После оффера кандидат загружает документы в сервис для автоматизации найма, который выдает нам готовую аналитику. Мы сверяем трудовую книжку с резюме. Например, если человек скрыл часть своего опыта, для нас это повод задать прямые вопросы. Это в том числе может помочь отсеять «волков».
Кроме того, мы считаем важным брать рекомендации от предыдущих работодателей. Однако мы всегда проговариваем нанимающим менеджерам: опирайтесь на свое мнение, полученное на интервью. Рекомендация лишь расширяет картину, но ничего не гарантирует на 100%, ведь это всегда субъективная оценка.
Вместо вывода
Может показаться, что внедрение технических вопросов на старте и глубокий разбор реальных задач растягивают процесс найма. На деле все ровно наоборот.
Наш процесс стал более информативным для обеих сторон, но не стал занимать больше времени. Все шаги, перечисленные в статье, помогли стандартизировать найм в компании и минимизировать долю неудачных кейсов.
Какие этапы найма вы считаете реально полезными?
