Tailoring без вигаданого досвіду

1. Tailoring людською мовою

Коли кажуть «адаптуйте резюме під вакансію», у багатьох у голові вмикається небезпечний режим: витягнути з тексту вакансії красиві слова, вставити їх у профіль, сподіватися, що ніхто не помітить. Спокуса зрозуміла, але довіру вона ламає миттєво. Tailoring влаштований інакше: ви не вигадуєте новий досвід, а переупаковуєте вже наявний, щоб роботодавець швидше побачив релевантні докази.

Але робити це для кожної знайденої вакансії — дорогий і марний спорт. Сенс з’являється тільки після career/applications/[slug]/FIT_ANALYSIS.md, коли рішення ухвалено: «цю заявку доводимо». До цього ви не адаптуєте — ви перевіряєте fit.

Якщо перекласти це мовою розробки, то базове резюме — це ваш main, а версія під вакансію — окрема гілка. Жодного force push поверх історії. Берете потрібні шматки, прибираєте шум, змінюєте порядок акцентів і стежите, щоб жоден «коміт» не містив вигаданих фактів. Резюме, лист і повідомлення рекрутеру посилаються на ті самі артефакти, а не живуть трьома життями, як три мікросервіси без API-контракту.

Зручно думати про сьогоднішній процес як про короткий конвеєр.

Найчастіша помилка тут — намагатися адаптувати текст без адаптації змісту. Тобто слова вже «під вакансію», а доказів за ними немає. Таке резюме читається бадьоро, але розсипається на першому ж дзвінку. Тому ваш головний інваріант на всю лекцію звучить так:

2. Резюме: одна база, багато чесних версій

Із резюме особливо хочеться схитрувати, бо саме воно першим потрапляє до рекрутера. Виникає спокуса зробити «солідніше», але вона приваблива рівно до першої технічної розмови. Працює протилежне: кожне помітне твердження можна показати пальцем на репозиторій, README або тести.

Практично це означає одну базову версію, наприклад у career/RESUME_VARIANTS.md, і окрему під вакансію в career/applications/[slug]/TAILORED_RESUME.md. Базовий файл не перезаписується — інакше за три ітерації самі не зрозумієте, де правда, а де сліди відчайдушного вівторка.

Хороший шлях для адаптації виглядає так: поруч кладете must-have з FIT_ANALYSIS.md і PROOF_OF_WORK.md та обираєте не «все, що вмію», а ті докази, що показують збіг. Роль просить REST API, тести й CI — не починайте з passion for innovation. Мапінг «вимога → артефакт → безпечне формулювання»:

Зверніть увагу на важливу деталь: формулювання сильні, але не роздуті. У багатьох студентів проблема навіть не в перебільшенні, а в заниженні власних артефактів: reproducible demo, smoke checks, migration plan і зрозумілий workflow — серйозний матеріал, тільки не називайте його «керував enterprise-трансформацією».

Дуже корисно мати перед очима таблицю небезпечних і безпечних формулювань — вона швидко остуджує фантазію.

Якщо хочеться короткого правила, тримайте його перед очима: замінюйте гучний масштаб на точний масштаб. Точність майже завжди виглядає доросліше за завищення.

Невеликий фрагмент адаптованого резюме може виглядати так:

## Досвід і проєкти

- Зібрав demo-ready backend-сервіс на Python/PostgreSQL з REST API,
  README із запуску та smoke-перевірками основного сценарію.
- Використовував Claude Code для codebase analysis, test scaffolding і docs,
  залишаючи за собою diff review і фінальні рішення.
- Підготував pilot migration plan для навчального legacy-модуля:
  compatibility analysis, rollback path, validation checklist.

Такий фрагмент можна захищати голосом. А це, як не дивно, найкращий тест на якість bullet-пункту.

3. Супровідний лист як міст до доказів

Супровідний лист часто перетворюють або на роман про любов до технологій із дитинства, або на ввічливу копію резюме, яку ніхто не дочитує. На практиці він корисний лише тоді, коли робить одну річ: швидко пояснює, чому ця роль поєднується саме з вашими доказами. Не більше.

Хороша структура дуже проста: роль і причина подачі, дві-три зв’язки «вимога → мій артефакт», чесно закритий gap або готовність розібрати workflow на дзвінку. Лист на п’ять екранів — уже не лист, а спроба взяти інтерв’ю у рекрутера у відповідь.

Робочий шаблон може бути таким:

Вітаю!

Мене зацікавила позиція Backend Engineer, тому що в ній збігаються
мій поточний стек і тип завдань, з якими я вже працював у capstone та
навчальних issue-to-PR сценаріях.

З вашою вакансією особливо добре збігаються три пункти: REST API і
PostgreSQL у моєму capstone-проєкті, risk-based testing і verification
trail у README, а також migration planning на навчальному legacy-сервісі.

У мене немає production-scale досвіду з великим AWS-контуром, але є
відтворюваний pipeline і чітке розуміння, як я перевіряю зміни
та де саме Claude Code пришвидшує роботу.

Буду радий показати репозиторій і коротко пройтися по workflow на дзвінку.

Зверніть увагу на третій абзац: він не ховає gap, а називає його прямо. Рекрутер і hiring manager чудово відчувають, коли ви відводите розмову від слабкого місця, і спокійно приймають чесний масштаб.

Є ще одна корисна тонкість: лист не зобов’язаний бути однаково довгим. Іноді це поле “why are you a fit?” на 600 символів, іноді форма на два абзаци. Логіка та сама — скорочуйте до ядра.

І не починайте з «Із дитинства я мріяв стати розробником». Зворушливо, але вакансії не виділяють на це бюджет уваги.

4. Повідомлення рекрутеру та запит на рекомендацію

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

Різницю зручно тримати в маленькій таблиці.

Хороше повідомлення рекрутеру не має бути довгим, але має бути конкретним. Йому не потрібен весь ваш шлях від першого проєкту — потрібна відповідь на одне питання: «Чому відкрити саме цей профіль, а не наступний із двадцяти?» Дві-три зв’язки з вакансією плюс чесна межа вашого досвіду. Наприклад так:

Вітаю, [Ім'я]!

Побачив у вас вакансію Backend Engineer. За вимогами у мене добре
збігаються три речі: стек Python/PostgreSQL у capstone-проєкті,
tests + verification workflow, а також досвід підготовки migration plan
для навчального legacy-сервісу.

Працюю з Claude Code як із частиною інженерного процесу, а не як із
генератором коду: можу показати, що саме робив сам, як перевіряв diff
і якими тестами закривав основний сценарій.

Якщо роль ще актуальна, буду радий надіслати репозиторій і короткий walkthrough.

Це коротко, ненав’язливо й одразу пояснює, чим ви відрізняєтеся від звичайного «додаю CV». Важлива деталь — фраза про Claude Code: вона не ховає AI, а заздалегідь ставить розмову в чесні рамки. Для частини ролей це плюс.

Із запитом на рекомендацію тон має бути ще акуратнішим. Людині має бути легко сказати і «так», і «ні», не відчуваючи, що її заганяють у кут, — тим більше якщо знайомі ви слабко. Набагато краще дати контекст, конкретну роль і коротке пояснення fit, щоб не змушувати її здогадуватися.

Невеликий приклад:

Привіт, [Ім'я]!

Побачив, що у вас у компанії відкрита роль Backend Engineer. Я подаюся на неї,
тому що за стеком і форматом завдань вона добре збігається з моїм capstone і
AI-assisted workflow із курсу: REST API, verification, README/demo, migration awareness.

Якщо вам комфортно, буду вдячний, якщо подивитеся мій профіль і скажете,
чи є сенс просити referral. Якщо ні — все ок, я зрозумію.

Таке повідомлення поважає час і репутацію людини та сильніше за сухе «можеш зарефералити?»: воно зменшує навантаження на адресата, а не збільшує.

Є ще одне правило, яке дуже допомагає: не перетворюйте outreach на атаку посиланнями. Одного посилання на GitHub і, якщо доречно, одного на demo — достатньо. Чотири репозиторії, відео, PDF і десять bullet-пунктів у короткому повідомленні — і людина не вивчить нічого.

5. Claude Code як редактор, а не біограф-фантаст

На цій темі Claude Code може бути неймовірно корисним, але тільки якщо ви від самого початку ставите йому правильну роль. Попросите «зроби резюме сильнішим» — він і зробить: додасть масштаб, лідерство і production там, де їх не було. Не злий намір, а мовне згладжування. Найкращий режим — не «напиши за мене», а «перевір, скороти, уточни та знайди непідтверджені claims».

Найкорисніший патерн — давати Claude Code одночасно три входи: текст вакансії, ваш PROOF_OF_WORK.md і поточні bullet-пункти, та просити не писати з нуля, а порівняти й позначити розбіжності:

Порівняй цю версію резюме з моїм PROOF_OF_WORK.md і FIT_ANALYSIS.md.
Для кожного сильного твердження познач:
[підтверджено] — якщо є явний артефакт,
[слабо підтверджено] — якщо артефакт непрямий,
[немає артефакту] — якщо формулювання звучить сильніше, ніж мої докази.
Нічого не дописуй від себе, тільки ревʼю.

Це дуже хороший режим, бо Claude тут — внутрішній reviewer: не «вигадує кар’єру», а показує, де ви самі почали прикрашати. А це, чесно кажучи, частіше, ніж здається: навіть без свідомої брехні слово на кшталт production, led, owned platform, managed зсуває масштаб в іншу лігу.

Другий корисний режим — стилістичне стиснення без зміни фактів. Claude прибирає важкі звороти й робить лист чистішим, не відводячи у фентезі:

Скороти цей супровідний лист до 120–150 слів.
Збережи всі факти, не додавай досвід, якого немає.
Якщо бачиш слова на кшталт production, leadership, team ownership без явного доказу,
заміни їх на точніші формулювання.

Дуже практично завести собі маленький файл-перевірку і проганяти через нього будь-яку адаптовану версію перед відправленням:

# tailoring-check.md

- [ ] У кожного сильного твердження є конкретний артефакт
- [ ] Немає слів production / led / managed без прямого доказу
- [ ] Усі технології в тексті я можу пояснити без підказок
- [ ] Версію під вакансію збережено окремо, базовий файл не затерто
- [ ] У листі та повідомленні рекрутеру збігаються ті самі 2–3 ключові докази

Цей чек працює майже як pre-commit hook для кар’єрних матеріалів. Особливо важливий тут останній пункт: якщо в резюме акцент на API та тести, а в листі раптом «люблю працювати в динамічному середовищі», у читача відчуття, ніби це троє різних людей.

І нюанс, який легко пропустити: Claude Code особливо корисний, коли ви просите його не тільки редагувати, а й заперечувати вам — запитанням «На що ти спираєшся, коли пишеш цю фразу?» Так він перестає бути фабрикою красивих слів і стає дорослим співрозмовником-редактором. Саме заради цієї ролі ви й проходили весь курс.