Інтелект вакансії: 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 як ще один обов’язковий пункт і сам себе відсіює. Правильніше дивитися на нього як на підсилювач, а не як на шлагбаум.

Обов’язки часто говорять про вакансію більше, ніж стек. Припустімо, дві компанії шукають Backend Engineer на Python. Але в одній написано «підтримка API та оптимізація SQL-запитів», а в іншій — «own product experiments, communicate with design and analytics, move fast». У другій ролі фронт роботи вже набагато ширший, навіть якщо стек схожий.

Тепер найцікавіше — приховані сигнали, тобто приховані сигнали. Вони не є фактами в строгому сенсі, і саме тут Claude Code любить упевнено фантазувати. Тому правило дуже просте: прихований сигнал — це гіпотеза, а не встановлений факт. Якщо ви бачите fast-paced team, це може означати маленьку команду, широку роль, часту зміну пріоритетів і слабку документацію. Але не треба записувати це як «у них точно хаос». Правильна форма — «ймовірний високий темп і широкий ownership, це варто перевірити на screening».

Із червоними прапорцями ситуація ще тонша. Це не «мені не сподобалась компанія», а конкретні протиріччя. Наприклад, вакансія просить 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" указує на високий рівень самостійності

## Червоні прапорці
- зарплатну вилку не вказано
- сигнал рівня вищий, ніж формально заявлений рівень

Після цього обов’язково пройдіться по результату очима. Якщо 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: командного досвіду немає, не приписуємо собі

Зверніть увагу на тон. Тут немає самоприниження. Немає фраз «я слабкий кандидат». Є факт: такого evidence поки немає. І з фактом уже можна працювати.

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

Після такого розбору в career/applications/co1-backend/ у вас зазвичай зʼявляються два артефакти.

Перший артефакт — VACANCY_ANALYSIS.md. Він відповідає на запитання: «що написано у вакансії насправді?»

Шаблон може бути дуже коротким:

# VACANCY_ANALYSIS.md

## Обов’язкові вимоги
## Бажані вимоги
## Зони відповідальності
## Стек
## Сигнали рівня
## Приховані сигнали [гіпотези]
## Червоні прапорці
## Потрібні докази

Другий артефакт — FIT_ANALYSIS.md. Він відповідає вже на інше запитання: «як ця вакансія стикується з моїм evidence bank?»

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

# FIT_ANALYSIS.md

## Збіг за must-have
## Збіг за nice-to-have
## Докази, що збігаються
## Прогалини
## Ризики інтерв'ю
## Рішення
## Нотатки

Можна одразу робити й коротку заповнену версію:

# FIT_ANALYSIS.md

## Збіг за must-have
4 / 5

## Докази, що збігаються
- capstone repo
- TEST_STRATEGY.md
- GitHub Actions sample

## Прогалини
- production-scale CI/CD

## Рішення
подаватися

Зверніть увагу, як сильно змінюється ваш стан, коли вакансія перестає бути просто текстом на сайті й стає двома markdown-файлами. У цей момент у вас зʼявляється керованість. Ви можете повернутися до аналізу через три дні. Можете порівняти дві вакансії між собою. Можете пояснити самому собі, чому одну ви берете в роботу, а іншу ні. І найприємніше — ви перестаєте витрачати сили на нескінченне внутрішнє «а може, все-таки я не дотягую». У вас уже є відповідь. Вона лежить в артефакті.

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