Одна вакансия — плохой образец для резюме: она отражает лексику конкретной команды, а не всего рынка. Адаптация резюме в IT становится заметно точнее после разбора 20–30 объявлений по нужной роли: такой срез позволяет отличить опыт, который кандидат просто плохо описал, от навыков, которых у него действительно нет.
Эту методику предлагает Habr / Карьера в материале о поиске работы. Идея проста: не начинать с подстановки ключевых слов в CV, а сначала собрать карту требований по вакансиям. Для Senior Java в одном объявлении могут фигурировать Java, Spring Boot, Kafka, PostgreSQL и Kubernetes. Но гораздо полезнее понять, какие формулировки повторяются в десятках позиций и какие задачи стоят за ними.
Автор предлагает фиксировать не только технологии, но и четыре группы признаков: название роли, стек, задачи и уровень ответственности. В вакансиях Java-разработчика рядом с привычными инструментами могут регулярно встречаться микросервисная архитектура, высоконагруженные системы, распределённые системы, производительность, code review, архитектурные решения и менторинг. Это уже не набор случайных слов для ATS, а описание того, каким рынок видит специалиста на конкретном уровне.
Практическое упражнение выглядит почти скучно — а потому работает. Кандидат берёт 20–30 вакансий одной роли и заносит в таблицу формулировку, число упоминаний, наличие навыка в своём опыте и его видимость в резюме. Kafka может встретиться 14 раз и уже быть корректно описана. Микросервисы — 12 раз, при этом опыт есть, но в CV он спрятан под фразой «разработка и поддержка backend-системы». Code review — 10 раз: человек делал его регулярно, однако ни разу не назвал напрямую. А Kubernetes может встречаться в половине выборки, но отсутствовать в реальной практике кандидата.
Последний случай принципиален. Если технология или ответственность не подтверждаются опытом, это не ошибка формулировки и не повод добавить модный термин в резюме. Это пробел, который придётся закрывать обучением, пет-проектом, внутренней задачей или выбором другой группы вакансий. В рекрутинге подобное приукрашивание быстро вскрывается на техническом интервью, а в случае с инфраструктурой, архитектурой или лидерскими задачами — ещё и на первых неделях работы.
При этом простой подсчёт слов тоже может завести не туда. Требование low latency способно встретиться всего несколько раз, но оказаться общим для вакансий в узком направлении, например для команд с задачами производительности. Тогда оно важнее распространённого Spring Boot именно для кандидата, который нацелен на эту специализацию. После разбора объявлений обычно проявляются отдельные кластеры: продуктовый backend, интеграционные роли, highload/performance-позиции и вакансии, где Senior уже выполняет часть функций Tech Lead.
Для разработчика это способ не тратить вечер на косметический ремонт резюме под каждое объявление. Сначала стоит определить, к какому кластеру относится собственный опыт, затем выбрать понятный язык для его описания. Фраза «участвовал в развитии проекта» почти ничего не сообщает ни рекрутеру, ни нанимающему менеджеру. Если инженер проектировал сервисы, строил интеграции через Kafka, проводил code review, участвовал в архитектурных решениях или наставлял коллег, это лучше назвать прямо — но только если за каждым пунктом есть конкретные примеры.
Для продуктовых и инженерных руководителей методика полезна с другой стороны. Повторяющиеся размытые требования в вакансиях часто показывают, что компания сама не договорилась, кого ищет: сильного исполнителя, системного архитектора, владельца интеграций или будущего лида. Кандидатская таблица не заменит интервью, зато позволяет быстро увидеть, какие ожидания рынок считает базовыми, а какие относятся к конкретному типу команды.
ИИ здесь уместнее использовать не как автора готового резюме, а как инструмент первичного разбора текстов вакансий. Ему можно поручить выделить повторяющиеся роли, технологии, задачи и уровни ответственности, показать частоту и сгруппировать объявления по похожим требованиям. Важно ограничить задачу: анализировать только переданные тексты, не добавлять знания о профессии и не переписывать CV. Иначе модель с готовностью заполнит пробелы правдоподобными, но чужими достижениями.
Главный эффект такого подхода — не «совпадение на 93%» с автоматической системой отбора, а более честная адаптация резюме в IT. После двадцати вакансий может выясниться, что менять карьерную историю не нужно: достаточно заменить несколько общих фраз на точное описание уже сделанной работы. А иногда карта рынка честно покажет другое — выбранная роль требует опыта, который ещё только предстоит получить.