Скрининг резюме в ИТ: чек-лист

Вместе с рекрутером hh.ru Екатериной Дворник и старшим ИТ-рекрутером Дмитрием Книгой разбираемся, как не упустить подходящего ИТ-специалиста, даже если вы сами не так глубоко разбираетесь в технологиях.

Почему первичный отбор усложнился

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

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

В помощь работодателям у hh.ru есть инструмент — проверка хард-навыков через независимые тесты. Соискатели отвечают на вопросы прямо в личном кабинете. Чтобы вы могли доверять результатам, платформа отслеживает попытки обмана.

На что смотреть в первую очередь

Рассказываем, какие критерии помогают провести первичную оценку резюме и не упустить нужного специалиста.

Структура и читаемость

Грамотно составленное резюме отвечает на базовые вопросы сразу: где кандидат работал, над какими задачами, с какими инструментами и каких результатов достиг.

Резюме может быть неидеальным по оформлению, но должно быстро давать ответы. Если за первую минуту непонятно, чем человек занимался и что умеет, — это уже сигнал

Навыки в связке с задачами

Чтобы понять, какие навыки у кандидата основные, а какие второстепенные, посмотрите, что повторяется из роли в роль и что он описывает подробно. Если инструмент появляется один раз и без деталей — скорее всего, опыт с ним незначительный.

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

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

Релевантность последнего опыта

Особое внимание стоит уделить последним 1–3 годам работы. Этот период показывает актуальный уровень специалиста: с какими технологиями он работает сейчас, какие задачи решает и как изменилась его зона ответственности.

При этом название компании — не главный ориентир. Строчка о работе в крупной корпорации сама по себе мало о чём говорит: внутри таких организаций сотни команд с разным уровнем задач. Важнее контекст — над каким продуктом работал кандидат и за что он отвечал лично.

Отдельно стоит обратить внимание на то, сколько времени человек провёл в компании. Если специалист менял работу чаще, чем раз в год, о причинах стоит спросить на собеседовании.

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

Фокус на конкретной роли

Когда есть фокус на 1–2 направлениях, релевантных вакансии, оценка занимает меньше времени: сразу видно, что человек понимает, какую работу ищет.

Красные флаги: что должно насторожить

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

Нет конкретики

Формулировки вроде «участвовал в разработке», «помогал команде» или «работал над улучшением» не дают понимания, что именно делал кандидат. Какие задачи решал? Какие инструменты использовал? К каким результатам это привело? Из размытых описаний выяснить это невозможно — рекрутеру приходится гадать или возвращаться к кандидату за уточнениями.

Технологии без структуры

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

Структурированный список показывает приоритеты и помогает оценить реальный уровень владения инструментами.

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

Задачи без результата

«Внедрял CI/CD», «работал с Kubernetes» — такие формулировки описывают процесс, но не объясняют, зачем соискатель это делал и что изменилось. Без результата сложно оценить, какой вклад внёс кандидат и насколько глубоко он погружался в задачу.

Фраза «использовал Kafka» мало о чём говорит. А вот «перешли на Kafka для обработки 100 тысяч событий в день, снизили нагрузку на основной сервис» — это уже реалистичнее, с таким кандидатом хочется пообщаться

Как узнать, что соискатель приукрашивает опыт

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

Всё выглядит безупречно

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

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

Технологии есть, решений нет

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

Размытые границы ответственности

Бывает так, что кандидат описывает достижения проекта, но не объясняет свою роль в них. «Запустили продукт с нуля», «увеличили выручку на 40%», «перевели систему на новый стек» — звучит впечатляюще, но неясно, что из этого сделал конкретный человек и на каком этапе подключился.

Как оценить кандидата, если вы не разбираетесь в технологиях

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

Смотрите на логику, а не на термины

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

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

Изучите сведения вне резюме

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

Внедряйте внешние инструменты проверки

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

* На февраль 2026 года работает в тестовом режиме, поэтому доступен ограниченному количеству пользователей.

↩ На главную блога