Подбор-ИИ-стартап или как мы случайно попали в боль всех ИТ-компаний. Часть 2
ЧАСТЬ 2
Добрый день, уважаемые хабровчане!
В первой части мы рассказали, зачем вообще взялись за автоматизацию технического скрининга и к чему это привело. Теперь пришло время поговорить о том, что происходило дальше.
В этой статье — разбор вопросов, которые компании задавали нашему продукту. Иногда — с интересом, иногда — с подозрением, но всегда по делу. Эти вопросы не просто помогали нам лучше понять рынок — они буквально шлифовали продукт, заставляя его эволюционировать на глазах.
Live coding и аудит репозитория
Практически сразу у нас всплыл резонный вопрос: «А как же навыки кодирования? Мы ведь их не проверяем!» Была даже идея добавить отдельный модуль — заставить писать код, включить лайвкодинг. Плюс — смотрели гитхаб-контрибьюшены, чтобы хоть как-то понять, как человек пишет.
Но очень быстро стало ясно: не тот масштаб проблемы.
Во-первых, если мы говорим о разработчике от двух лет опыта — а мы именно таких и ищем — то он уже умеет писать код. Базовые скиллы давно пройдены: циклы крутятся, REST-эндпоинты шлются, null'ы обрабатываются. Если не умеет — он бы и не выжил в продакшене.
Во-вторых, смотреть чужой репозиторий — история мутная.
Кто его писал? В какой роли? Это его код или кусок корпоративного проекта, аккуратно выдранный перед собесом? А если это пет-проект — он вообще живой или последний коммит был «Initial commit» два года назад?
Ладно, допустим — давайте лайвкодинг.
Но и тут не всё так радужно. Что делает разработчик на лайвкодинге? Он решает задачу «на скорость» — используя накатанные паттерны, популярные подходы, зачастую — шаблоны, которые просто выучены. Это не плохо. Но это не даёт понимания, насколько он осознаёт, что стоит за этими строками кода. Как работают механизмы внутри? Почему именно так, а не иначе? Какие есть альтернативы?
Мы ведь хотим видеть не только, как человек «выложит» решение, но и насколько он гибок в мышлении — может ли предложить три разных варианта, объяснить плюсы-минусы каждого и выбрать уместный в зависимости от контекста. А лайвкодинг такое не вытаскивает: там ты жмёшь на время и интуитивно идёшь по самому популярному пути.
И вот что интересно: мы сравнили результаты, полученные через лайвкодинг, с теми, что дал наш подход в Jumse — и… они оказались практически идентичны. Только в случае с Jumse мы дополнительно получаем глубину понимания, работу в контексте, рефлексию и мышление в рамках системы.
Так что, по факту, Jumse спокойно заменяет лайвкодинг — и делает это даже лучше.
Конфигуратор вакансий
Со временем пришло понимание, что просто «проверить Java» — недостаточно.
Если мы скриним кандидата под реальную вакансию, скажем, на позицию Java-разработчика, то одного знания Java Core и Spring мало. Сегодня разработка — это гораздо более широкий стек.
Нужен человек, который не только разбирается в синтаксисе, но и умеет:
писать под микросервисы,
работать с Docker и Kubernetes,
знает, как живёт БД (Postgres, Mongo и т.д.),
понимает CI/CD пайплайны,
может поднять проект локально,
умеет читать чужую архитектуру и не боится паттернов проектирования.
Короче, один Java-раздел не вытягивает всю картину.
И тут перед нами встал вызов: а как автоматизировать проверку такого широкого набора компетенций, не превратив процесс в адскую анкету на 500 вопросов?
Так родилась идея конфигуратора вакансий.
Это такая штука, с помощью которой мы собираем скрининг как из LEGO. Каждый «кубик» — это отдельная компетенция. Хочешь проверить знание Kafka, Docker, Spring Boot и основы проектирования БД? — пожалуйста. Просто добавь нужные модули, и у тебя готов скрининг, заточенный именно под эту вакансию.
Более того, можно пойти глубже: каждая компетенция разбивается на подтемы. Например, «Docker» — это не просто «умеет запускать контейнер», а и работа с docker-compose, сетями, слоями образов, а иногда даже написание Dockerfile с нуля без копипаста.
Так у нас появился настоящий конструктор вакансий — инструмент, который стал ещё одним важным пивотом в нашем проекте. Теперь мы можем собирать гибкие, точечные, на 100% релевантные скрининги под конкретные задачи бизнеса. И всё это — без боли.
Политика принятия решений
До того как перейти к созданию финальной концепции скрининга, мы сфокусировались на самом главном — объективной оценке знаний. Сначала мы замеряем знания по выбранным компетенциям, потом сопоставляем кандидата с этими знаниями. Всё просто.
Но дальше всплыла важная мысль: сеньор — сеньору рознь.
Java-сеньор в Росбанке и сеньор в Альфа-страховании — это два совершенно разных «сеньора». Где-то больше инфраструктуры, где-то больше продуктовой инженерии, где-то архитектура, а где-то работа с legacy. Компетенции разные — и требования тоже.
Именно эту проблему и решает конфигуратор вакансий — мы кастомизируем скрининг под нужды конкретной компании. Но тут встал следующий вопрос: а как, собственно, правильно понять, кто перед нами? Как объективно оценить уровень разработчика, если у всех свои шкалы?
Для этого мы и придумали отчёт с градацией по грейду.
Выглядит это так:
🔹 Сначала отображается определенный грейд (Junior, Middle, Senior, и т.д.),
🔹 А дальше — метрики, собранные по результатам скрининга:
– какие сегменты знаний проверялись,
– что конкретно в сегменте проверялось (при этом данная информация уникальна, так как обычно тимлиды не уточняют, что спрашивали у кандидата, только список сильных/слабых тем),
– сложность проверяемого материала,
– как успешно кандидат с ними справился.
На каждую компетенцию — своя секция в отчёте.
А после — трактовка этих результатов в конкретный грейд, основанный на нашей политике принятия решений.
Что важно — эта политика не взята с потолка. Мы обкатали её на тысячах кандидатов, и она показала до 98% попадания в правильный грейд. То есть это не просто «нам показалось», а действительно алгоритм, превращающий метрики в решение.
Но при этом мы не забыли о реалиях: грейды в разных компаниях — разные.
Именно поэтому политику можно тонко настраивать под конкретную организацию. В коробке идёт дефолтный рыночный шаблон — как сегодня принято понимать Middle, Senior и прочее. Но при интеграции мы кастомизируем формулу так, чтобы она учитывала внутренние стандарты компании. В результате — почти стопроцентное совпадение с реальностью.
Плюс, мы всё это красиво визуализируем.
Можно смотреть метрики по отдельному кандидату, по компетенциям, по темам — а можно агрегировать данные на уровне отдела, команды или вообще всей компании. Это уже настоящая HR-аналитика, на базе которой можно принимать обоснованные управленческие решения.
Ну и да — такой скрининг можно использовать не только при найме…
(но об этом — дальше 😉)
Кейсы использования
В какой-то момент мы задали себе логичный вопрос: а где именно этот инструмент можно использовать? Ведь мы проверяем только хард-скиллы, без поведенческих интервью, софтов и культурного фита. Значит, наш фокус — именно на технической компетенции. Но и этого, как оказалось, хватает на целый набор сценариев.
📌 Первый кейс — быстрый отбор, или как мы его называем, «причек»
Это лайт-версия, которая помогает из десяти кандидатов за 10–15 минут выцепить 2–3 самых релевантных. Идеально подходит на входном этапе: закинули ссылку, человек прошёл, мы видим, кто реально что-то умеет, и только их уже двигаем дальше по найму. Быстро, бесшовно, без перегрузки команды.
🧰 Второй кейс — полноценный технический скрининг
Здесь мы берём на себя ту работу, которую обычно делает тимлид. Проверяем по тем же метрикам, которые он бы смотрел на собеседовании. Но разница в том, что это автоматизировано — без субъективности, без усталости, без личного настроения интервьюера.
При этом само управленческое решение (брать/не брать) можно оставить за тимлидом. Особенно удобно, когда в компании нет своей экспертизы по какому-то стеку. В таких случаях можно полностью положиться на Jumse: мы оцениваем хард-скиллы, присваиваем грейд, и дальше HR просто смотрит на цифры и принимает решение.
А если экспертиза есть — тимлид может использовать наш отчёт как готовую выжимку, сэкономив часы. Вместо 1.5–2 часов на собеседование, он тратит 10–15 минут: читает отчёт, задаёт пару уточняющих вопросов — и уже даёт финальное заключение. А остальное время может потратить, чтобы продать кандидату компанию, а не ковыряться в нюансах логирования в Spring Boot.
📈 Третий кейс — ассессмент внутри команды
Jumse можно использовать не только при найме, но и внутри команды — для оценки текущих сотрудников. Такая «диагностика» помогает выявить слабые места, понять, у кого какие пробелы, и на базе этого строить персонализированные планы развития. В результате — команда растёт, экспертиза усиливается, а обучение становится точечным, а не «давайте все пройдём курс по Docker, хотя половина и так всё знает».
В итоге, Jumse — это универсальный инструмент:
🔹 для HR — чтобы не звать на интервью «пальцем в небо»,
🔹 для тимлидов — чтобы сэкономить часы и оставить только экспертные финальные решения,
🔹 для компаний — чтобы системно развивать своих разработчиков.
Использование ИИ
В завершение — главное: мы постоянно развиваемся и упрощаем процессы. Активно используем ИИ для генерации контента (на этот счет напишем отдельную статью). Сначала он генерировал либо идеальный код без багов, либо хаотичный набор строк. Пришлось научить его писать как живой разработчик — с ошибками, компромиссами и реализмом.
Сейчас ИИ встроен в систему как полноценный инструмент, а не костыль. И это только начало: впереди — новые роли, языки, глубже контекст. Всё ради одной цели — честного и объективного найма.
Прокторинг
Одна из типичных проблем всех дистанционных скринингов — это, конечно, ChatGPT и “друг на подхвате”. Когда вместо кандидата задачи решает нейросеть или сосед по комнате.
Мы не стали изобретать велосипед и просто добавили прокторинг. У нас есть как свой собственный, так и интеграции с внешними решениями.
Благодаря этому использование ChatGPT и других обходных путей становится сильно затруднено — а чаще всего просто невозможно. Так что скрининг остаётся честным, а результат — релевантным.
Экономический эффект
Чтобы понять реальную пользу от внедрения Jumse, мы сравнили экономику: классический техскрининг против автоматизированного. В начале всё было грубо: интерфейс сырой, контент — сложный и ручной, а скрининг через Jumse занимал до 2–3 часов и стоил в 2–3 раза дороже, чем обычное интервью с техэкспертом.
Но спустя пару лет — после нескольких пивотов, внедрения ИИ и оптимизации процессов — стоимость одного скрининга через Jumse оказалась ниже классического собеседования (в зависимости от компании разница варьируется от 30% до 300%). При этом мы ещё и перестали терять кандидатов, потому что не нужно ждать свободного слота у тимлида.
Объективность выросла, пробелы в знаниях ловим до проекта, а темлиды наконец занялись тем, что у них получается лучше всего — экспертной оценкой, а не рутиной. Jumse делает всю черновую работу, а финальное слово — за людьми.
Продолжаем снижать стоимость скрининга.