Vacancy intelligence: fit и gap map

1. Вакансия — это тоже спецификация, просто карьерная

Когда вы впервые открываете вакансию, её очень легко читать эмоционально: «О, Python, это я знаю», «Ой, AWS, это страшно», «fast-paced — наверное, они не спят». И почти наверняка вы примете плохое решение. Вакансия — не любовное письмо судьбы и не приговор, а документ с требованиями, ограничениями и сигналами. Разбирается так же, как task spec или issue в модуле про issue-to-PR.

Но так имеет смысл разбирать не каждую найденную вакансию подряд: сперва текст проходит через career/target-roles.md и career/search-boundaries.md, иначе вы дотошно анализируете роли не из своей воронки.

Вспомните, как мы работали с инженерной задачей. Мы не смотрели на неё как на один большой абзац текста — мы вытаскивали цель, scope, constraints, критерии приёмки, риски и неизвестные. Логика та же, направление другое: там вы спрашивали «что нужно сделать?», здесь — «какого человека они на самом деле ищут, какие доказательства у меня уже есть и чего пока нет?».

Полезно держать в голове очень простую схему:

flowchart TD
    A[Текст вакансии] --> B[Структурированный разбор]
    B --> C[Сопоставление с evidence bank]
    C --> D[Fit score]
    D --> E[Gap map]
    E --> F[Решение: apply / build evidence / skip]

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

Посмотрите на очень короткий фрагмент условной вакансии:

Ищем Backend Engineer.
Обязательно: Python, PostgreSQL, REST API, pytest, CI/CD.
Будет плюсом: AWS, опыт менторства.
Нужен человек, который сможет владеть сервисом end-to-end
и комфортно чувствует себя в fast-paced команде.

Если читать это «по-человечески», можно увидеть только знакомые слова и немного испугаться последней строчки. Если читать это «по-инженерному», вы уже замечаете слои. Есть обязательные требования. Есть плюсы. Есть seniority signal про end-to-end ownership. Есть скрытый сигнал о темпе команды. А значит, текст уже можно раскладывать на части.

2. Слои вакансии: от must-have до скрытых сигналов

На этом этапе важно перестать воспринимать вакансию как плоский список технологий. Она многослойная. Причём самые интересные сигналы часто спрятаны не в словах Python и PostgreSQL, а в формулировках между ними. Именно поэтому один и тот же стек может означать очень разную работу в двух разных компаниях.

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

С must-have всё относительно просто: это то, что обычно написано словами «обязательно», requirements, must have, we need. Здесь не надо быть героем и додумывать за работодателя. Если в тексте есть pytest, значит, это факт. Если там написано просто testing mindset, это уже не то же самое, и не надо превращать это в pytest только потому, что вам так удобнее.

Nice-to-have — более мягкий слой. С ним многие делают одну из двух ошибок. Либо полностью его игнорируют и потом удивляются, почему их профиль выглядит слабее других кандидатов. Либо, наоборот, воспринимают каждый nice-to-have как ещё один обязательный пункт и сами себя отсеивают. Правильнее смотреть на него как на усилитель, а не как на шлагбаум.

Responsibilities часто говорят о вакансии больше, чем стек. Допустим, две компании ищут Backend Engineer на Python. Но в одной написано «поддержка API и оптимизация SQL-запросов», а в другой — «own product experiments, communicate with design and analytics, move fast». Во второй роли фронт работы уже намного шире, даже если стек похожий.

Теперь самое интересное — hidden signals, то есть скрытые сигналы. Они не являются фактами в строгом смысле, и именно здесь Claude Code любит уверенно фантазировать. Поэтому правило очень простое: скрытый сигнал — это гипотеза, а не установленный факт. Если вы видите fast-paced team, это может означать маленькую команду, широкую роль, частую смену приоритетов и слабую документацию. Но не надо записывать это как «у них точно хаос». Правильная форма — «вероятен высокий темп и широкий ownership, это стоит проверить на screening».

С red flags ситуация ещё тоньше. Это не «мне не понравилась компания», а конкретные противоречия. Например, вакансия просит senior-level ownership, mentoring и production-scale CI/CD, но зарплата и формулировки уровня похожи на Junior. Или просят одновременно backend, DevOps, data analysis и customer-facing communication «в одном лице». Это уже не эмоция. Это структурный риск.

3. Claude Code в разборе вакансии без додумывания

Claude Code здесь действительно полезен, потому что умеет быстро превращать сырой текст в структурированный документ. Но есть важный нюанс: вакансия — это не код, который можно проверить grep'ом. Здесь больше неоднозначности, а значит, выше риск, что Claude начнёт «дорисовывать» смысл. В этой теме ваша задача — использовать его как аналитического помощника, а не как карьерного оракула.

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

Например, так:

career/jobs/co1-backend.md

А вся работа по этой вакансии уже живёт в career/applications/co1-backend/: туда складываются VACANCY_ANALYSIS.md и FIT_ANALYSIS.md.

После этого можно попросить Claude Code сделать первый проход анализа. Если в вашей версии доступен неинтерактивный запуск вроде claude -p, можно использовать его. Если нет, просто дайте тот же текст в обычной сессии Claude Code. Сама формулировка важнее, чем конкретный флаг.

Вот хороший пример запроса:

claude -p "Прочитай файл career/jobs/co1-backend.md.
Сделай разбор вакансии в секциях:
must-have, nice-to-have, responsibilities, stack,
seniority signals, hidden signals, red flags, evidence needed.
Используй только факты из текста.
Hidden signals помечай как [гипотеза].
Не выдумывай требования, которых нет."

Почему эта формулировка хорошая? Потому что вы заранее ставите границы. Вы не просите «объясни, подхожу ли я». Вы просите извлечь структуру. Это та же дисциплина, которую вы уже тренировали на task spec: сначала факты, потом интерпретация.

Полезный промежуточный результат может выглядеть так:

## Скрытые сигналы
- [гипотеза] "fast-paced team" может означать широкую зону ответственности
- [гипотеза] "own services end-to-end" указывает на высокий уровень самостоятельности

## Красные флаги
- зарплатная вилка не указана
- seniority signal выше, чем формально заявленный уровень

После этого обязательно пройдитесь по результату глазами. Если Claude записал AWS в must-have, а в тексте оно было только в nice-to-have, это не «мелкая неточность», а ошибка разбора. Если он вывел «в компании нет DevOps», а в тексте такого не было, удаляйте без сожаления. Вакансия не обязана быть идеальной, а ваш анализ должен быть честным.

И ещё один важный практический момент. Ваш career workspace — не публичный проект на GitHub. Не кладите туда чужие приватные письма, recruiter notes с чувствительной информацией, конфиденциальные детали, которые не должны гулять по интернету. Claude Code отлично работает и с локальными markdown-файлами в приватной директории. Этого более чем достаточно.

4. Evidence-based fit scoring по доказательствам

Теперь начинается самая интересная часть. Вы уже разобрали саму вакансию. Но вакансия сама по себе не даёт ответа на вопрос, стоит ли подаваться. Этот ответ появляется только в момент, когда вы накладываете её на свой evidence bank. И вот здесь многие снова скатываются в эмоции: «ну я вроде умею», «кажется, было что-то похожее», «наверное, CI/CD у меня тоже есть». Нет. Нам нужны доказательства.

Ваша задача — для каждого must-have найти конкретный артефакт, который вы можете показать и объяснить. Из этого курса у вас уже есть отличный набор материалов: capstone-репозиторий из модуля 32, README и demo, артефакты issue-to-PR из модулей 17–18, TEST_STRATEGY.md и тесты из модуля 19, CI/CD-материалы из модуля 21, MIGRATION_PLAN.md и RISK_MAP.md из блоков legacy и migration, у кого-то ещё и workflow/governance артефакты вроде AI_CODING_POLICY.md.

Очень полезно делать сопоставление прямо в табличном виде:

Здесь важно не играть в маркетинг. Если у вас есть только учебный pipeline из курса, пишите именно так. Не надо превращать его в «опыт production CI/CD». Но и занижать его не нужно. Учебный pipeline, который вы сами запускали, читали по логам и объясняли на защите, — это всё равно evidence. Просто честно ограниченный по масштабу.

На практике fit score удобно считать по must-have, а nice-to-have выносить отдельно. Самая простая формула выглядит так: берёте количество обязательных требований, по которым у вас есть defendable evidence, и делите на общее количество обязательных требований. Не идеальная наука, но очень рабочая эвристика.

Например, если у вакансии пять обязательных требований, а вы честно можете защитить четыре, у вас получается 4/5, то есть 80%. Это уже предметный разговор. Не «мне кажется, я подхожу», а «я закрываю четыре обязательных пункта из пяти, а пятый у меня пока только в учебном масштабе».

5. Gap map и decision matrix

Очень важно психологически понять одну вещь. Если у вас чего-то нет, это ещё не означает «я не подхожу». Иногда не хватает знаний. Иногда — практики. А иногда знания и практика есть, но нет удобного артефакта, которым это можно доказать. Эти случаи нельзя складывать в одну коробку под названием «я недостаточно хорош».

Именно для этого и нужен gap map. Это не список ваших недостатков. Это карта непокрытых участков между вакансией и evidence bank.

Удобно различать хотя бы три типа gap:

Когда gap map сделан, decision matrix перестаёт быть лотереей. Можно пользоваться очень простой таблицей:

Но здесь есть одно важное уточнение: red flags могут переопределить score. Если у вас формально 80% совпадения, но вакансия одновременно требует senior ownership, on-call, DevOps, mentoring, relocation и при этом не даёт даже понятной компенсации, высокий fit score ещё не означает «надо бежать подаваться». Иногда лучший карьерный навык — спокойно закрыть вкладку.

Вот как может выглядеть честный gap map:

## Пробелы
- CI/CD: есть GitHub Actions в учебном проекте, но нет production-scale примера
- AWS: базовое понимание есть, собственного артефакта нет
- Mentoring: командного опыта нет, не claim'им

Обратите внимание на тон. Здесь нет самоуничижения. Нет фраз «я слабый кандидат». Есть факт: такого evidence пока нет. И с фактом уже можно работать.

6. Артефакты VACANCY_ANALYSIS и FIT_ANALYSIS

После такого разбора в career/applications/co1-backend/ у вас обычно появляются два артефакта.

Первый артефакт — VACANCY_ANALYSIS.md. Он отвечает на вопрос: «что написано в вакансии на самом деле?»

Шаблон может быть очень коротким:

# VACANCY_ANALYSIS.md

## Must-have
## Nice-to-have
## Зоны ответственности
## Стек
## Сигналы seniority
## Скрытые сигналы [гипотезы]
## Красные флаги
## Нужные доказательства

Второй артефакт — FIT_ANALYSIS.md. Он отвечает уже на другой вопрос: «как эта вакансия стыкуется с моим evidence bank?»

Тоже краткий, но предметный шаблон:

# FIT_ANALYSIS.md

## Must-have match
## Nice-to-have match
## Совпавшие доказательства
## Пробелы
## Риски интервью
## Решение
## Заметки

Можно сразу делать и короткую заполненную версию:

# FIT_ANALYSIS.md

## Must-have match
4 / 5

## Совпавшие доказательства
- capstone repo
- TEST_STRATEGY.md
- GitHub Actions sample

## Пробелы
- production-scale CI/CD

## Решение
apply

Заметьте, как сильно меняется ваше состояние, когда вакансия перестаёт быть просто текстом на сайте и становится двумя markdown-файлами. В этот момент у вас появляется управляемость. Вы можете вернуться к анализу через три дня. Можете сравнить две вакансии между собой. Можете объяснить самому себе, почему одну вы берёте в работу, а другую нет. И самое приятное — вы перестаёте тратить силы на бесконечное внутреннее «а может, всё-таки я недотягиваю». У вас уже есть ответ. Он лежит в артефакте.

Когда вы начинаете работать именно так, рынок найма перестаёт быть шумной стеной текста. Он превращается в набор инженерных документов, для которых у вас уже есть знакомый workflow: разобрать, структурировать, сопоставить с evidence, посчитать fit, зафиксировать gaps и принять решение. А это, согласитесь, гораздо спокойнее, чем гадать по настроению и количеству кофе в крови.