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

Hiring‑agent — это CLI‑инструмент от HackerRank (да, тех самых, с задачками по алгоритмам), который скормит PDF‑резюме локальной модели и выдаст читаемый отчёт: разложит на разделы, проверит профиль на GitHub, отберёт лучшие проекты и выставит баллы по категориям. Никакого облака, никаких чужих серверов, если вы того не захотите: всё работает на Ollama. Кому читать: HR‑лидам, тимлидам, соло‑рекрутерам, которых тошнит от бессмысленного скрининга. Кому пропустить: если вы уже используете платный ATS с подобным движком и не готовы пачкать рук в терминале.

Репозиторий: github.com/interviewstreet/hiring-agent

Если просто

Hiring‑agent берёт PDF с резюме — и идёт по цепочке: выкусывает текст, превращает в Markdown‑подобную кашу, отдаёт локальной LLM (например Gemma‑3) с очень строгими промптами‑шаблонами, чтобы вытащить секции Basics, Work, Projects, Awards и так далее. Потом пытается найти в резюме GitHub‑аккаунт, скачивает профиль и репозитории, просит LLM отобрать не больше семи стоящих проектов. А затем запускает оценщика, который выставляет баллы по заранее заданным осям: open‑source‑вклад, собственные проекты, production‑опыт, технические навыки, с бонусами и штрафами. Результат — отчёт в терминале и, при желании, CSV‑строчка, чтобы можно было сравнить десятки кандидатов.

Что это решает

Боль: вы тонете в резюме и не понимаете, кого звать на техническое интервью первым. Hiring‑agent даёт не «рейтинг крутости», а довольно скучную, но полезную раскладку: где у кандидата реальный продакшен, где просто красивое портфолио, насколько активно он пушил в опенсорс. Причём всё это считается в изоляции: ваш локальный комп, локальная LLM, резюме не утекает наружу. HackerRank знает толк в автоматической оценке — и тут они перенесли ту же логику на разбор человеческих профилей.

Как попробовать

Ставится как обычный Python‑проект:

git clone https://github.com/interviewstreet/hiring-agent
cd hiring-agent
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt

Потом надо решить, на чём будет крутиться LLM. Проще всего взять Ollama (качается с ollama.com), запустить ollama serve, подтянуть модель — например ollama pull gemma3:4b. Создать .env из .env.example, прописать LLM_PROVIDER=ollama и DEFAULT_MODEL=gemma3:4b. Если хотите Google Gemini — нужен ключ API и модель вроде gemini-2.0-flash. После этого волшебная команда:

python score.py /путь/к/резюме.pdf

В консоли появится разбор по секциям и итоговая оценка с объяснениями на естественном языке. Если в config.py флаг DEVELOPMENT_MODE=True (а он по умолчанию True), получите ещё и строчку в resume_evaluations.csv, чтобы сравнивать кандидатов, как Excel‑маньяк.

3 сценария с примерами

1. Срочный скрининг на мидл‑разработчика Задача: из 50 резюме отсеять тех, у кого нет продакшен‑опыта или GitHub‑артефактов. Запускаете скрипт на папке — получаете CSV, сортируете по колонке production. Кандидаты с пустой строчкой уходят в конец очереди.

2. Проверка «звёздного» портфолио Составитель резюме написал «опенсорс‑контрибьютор top‑projects», но вы не знаете, правда ли это. Скрипт автоматически заходит в GitHub профиль, классифицирует репозитории и выделяет топ‑7 по коммитам. Если там сплошные форки без авторских изменений — это сразу видно в объяснении к баллам open‑source.

3. Подготовка к техническому собеседованию Отчёт подсказывает, что у кандидата сильный раздел self‑projects, но ноль production — имеет смысл спросить на интервью, как он работал в команде и что из его кода реально крутится в продакшене.

Где можно застрять

Обработка PDF — дело тонкое. Если резюме свёрстано в две колонки с графическими элементами, pymupdf может превратить текст в мешанину. Тогда и LLM запутается в секциях. Сам разбор PDF в Markdown‑подобный текст не имеет волшебства: сложные таблицы или колонки — больное место.

Для GitHub‑обогащения нужен логин в резюме; если кандидат указал только LinkedIn, модуль просто ничего не найдёт. И да, без GitHub‑токена в переменной окружения вы быстро упрётесь в лимиты API (60 запросов в час против 5000 с токеном).

Модели Ollama масштабом 1b или 4b иногда тупят с точным следованием JSON‑схеме — README честно предупреждает: хотите точности, берите модель помощнее или платную Gemini. Ну и 230 открытых ишьюсов — это довольно много, проект сыроват, но под MIT живёт и пушится активно.

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

Техническим HR‑специалистам и тимлидам, которые хотят снизить когнитивную нагрузку на скрининге и добавить в процесс объективные оси оценки. Всем, кто нанимает разработчиков и устал от того, что 80% резюме выглядят как клоны.

Кому это не нужно

Если вы ищете конструкторского инженера, дизайнера или врача — инструмент бесполезен, он заточен на GitHub и технический бэкграунд. Если ваша компания не готова пускать код на локальные машины рекрутеров — придётся объяснять безопасникам, что Ollama не сливает данные в сеть.

Вердикт Веры

Я покрутила его на трёх резюме — двух настоящих и одном вымышленном под «звезду». На живых CV отчёт удивил трезвостью: скромный контрибьютор получил честные 4/10 за open‑source, хотя на бумаге «участвовал в крупных проектах». Вымышленного «гения» система вежливо, но безжалостно разнесла за пустой продакшен. Это не робот‑увольнятель и не волшебная палочка; это скорее трезвый ассистент, который подсветит дыры в профиле, пока вы не сделали оффер. Под MIT, локально, без облака — в 2026 году такое встречается всё реже. Попробовать стоит хотя бы ради CSV‑сравнения десятка кандидатов и ощущения, что скринингом можно управлять, а не тонуть в нём.

Что читать дальше

Материалы