HackerRank открыл ИИ-резюме, но оно переменчиво как погода: один документ получает оценки от 66 до 99

HackerRank недавно выложил на GitHub открытый исходный код своего ATS (система управления кандидатами) с ИИ-скрингом резюме. Инструмент вызывает LLM шесть раз: для извлечения информации о базовых данных, рабочей истории, образовании, навыках, проектах и наградах. Затем парсит GitHub-профиль кандидата, сканирует его репозитории и отправляет всё в LLM для оценки из 100 баллов (до 20 бонусных).

Инженер тестировал инструмент на своем резюме. Первый запуск: 90/100. Второй запуск (после удаления отладочных print-выражений из кода): 74/100. То же резюме, то же резюме, одна разница, удаленные строки. Запустив 100 раз подряд, автор получил распределение от 66 до 99 баллов.

Проблема не в настройке температуры (использовалась 0.1). Когда инженер проверил отдельные категории, выявилась жесткая разница: технические навыки набирали 8/10 в 98 из 100 запусков, идеальная консистентность, потому что это простой чеклист (знаешь React или нет). Проекты же варьировались дико. В одном запуске они получали отзыв «недостаточно архитектурной сложности», в другом, «демонстрируют реальное применение». LLM не может надежно судить такое.

Даже если снизить температуру до 0, проблема не исчезает, это фундаментальный изъян дизайна. Если компания использует 85-балльный порог, кандидат с одним и тем же резюме будет отвергнут в 65% запусков просто из-за случайности.

Вторая проблема, система весов. Открытый исходник (Open Source contributions) дает 35 баллов, проекты, 30, опыт, 25, навыки, 10. На Open Source + Projects приходится 65% от всех баллов. При этом опыт оценивается по двум строчкам промпта без примеров и якорей, junior с одним стажировкой получает 25/25, principal engineer с десятилетием опыта тоже 25/25. Проекты имеют детальный критерий, но именно в них максимальная дисперсия.

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

Ключевые факты

Одно резюме получает оценки от 66 до 99 баллов при 100 запусках, даже при температуре 0.1, что обуляет его как инструмент скрининга
LLM хорошо справляются с объективными чеклистами (технические навыки), но непредсказуемо судят субъективное (качество проектов, архитектурная сложность)
Категория опыта всегда дает максимальные 25 баллов из-за ненадежного критерия в два строки без примеров, junior и principal engineer неразличимы
65% веса приходится на open-source + проекты, что недооценивает разработчиков без публичного GitHub, но переоценивает side-projects
Даже снижение температуры до 0 не решает проблему, это фундаментальный изъян попытки использовать LLM для субъективных суждений

Почему это важно

HackerRank открыл популярный инструмент (сотни и тысячи лайков в LinkedIn), и он привлек внимание как рациональный способ скрингировать резюме на масштабе. Но выявленная нестабильность показывает, что такие инструменты превращают найм в лотерею: один кандидат с одним резюме имеет 65% шанс быть отвергнутым просто из-за случайности LLM, если установлен 85-балльный порог. Это проблема не отдельного tools, а фундаментального ограничения LLM в задачах, требующих надежного субъективного суждения.

Кому это важно

Компаниям, использующим ИИ-инструменты для скрининга резюме (найм на основе ATS). Кандидатам, которые подают резюме через такие фильтры. Инженерам, имеющим голос в том, как компания отбирает кандидатов. Разработчикам ATS и HR-систем, которые полагаются на LLM.

Как это применить

Если в компании используется такой инструмент, проверьте его на вашем собственном резюме несколько раз, будут ли оценки разными? Если да, это красный флаг. Избегайте абсолютного доверия к ИИ-скрингу для качественных суждений: используйте LLM только для парсинга и объективных чеклистов (знание технологий), а субъективные оценки (качество опыта, сложность проекта) оставляйте людям. Если вы строите ATS, учитывайте, что температура 0 не решает проблему, нужны иные подходы (детальные критерии, примеры, человеческая проверка).

Можно ли доверять

Источник, личный тест инженера с полным открытым исходным кодом HackerRank на GitHub. Методология чистая: сотня запусков, логирование оценок, проверка отдельных категорий. Проблема воспроизводима. Корректировка от автора (28 июня) уточняет, что даже явный prompt про Senior SWE дает те же результаты, система действительно положена на спецификацию, а не на позицию. Нечего не доверять методикой, результаты реальны.

Риски и подводные камни

Главный риск, внедрение такого инструмента как единственного фильтра найма отсеет хорошо квалифицированных кандидатов случайно. Второй риск, смещение критериев в сторону кандидатов с visible open-source работой, оставляя вне поля зрения разработчиков, чей лучший код лежит в приватных проектах компаний. Третий, изображение объективности инструмента (100-балльная оценка) скрывает случайность, делая процесс найма менее справедливым, чем случайная выборка. Также игровой элемент: кандидаты могут начать искусственно раздувать свои side-projects и GitHub, чтобы пройти фильтр, вместо того чтобы показать реальный опыт.

«Если ваша компания имеет пороговую оценку 85, я буду отвергнут в 65% случаев. То же самое резюме, разная удача.»

— автор, danunparsed.com