AI-native резюме, GitHub і LinkedIn

1. Рекрутер не має грати в археолога

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

Корисно дивитися на карʼєрний пакет так: це три поверхні, і кожна відповідає на своє запитання. Резюме: чи підходите ви під роль. GitHub: чи є реальні артефакти. LinkedIn: як ви описуєте себе публічно.

Корисно думати про це так: це не три різні історії, а три версії однієї й тієї самої з різною глибиною. Якщо одне каже «Junior backend developer», друге кричить «AI architect», а третє виглядає як сторінка мотиваційного коуча, довіра зникає миттєво. Ринок любить різний досвід, але не розбіжності.

Тримайте цю схему в голові, поки збираєте матеріали:

flowchart LR
    A["PROOF_OF_WORK.md"] --> B["Карта особистого наративу"]
    B --> C["Резюме"]
    B --> D["Профіль GitHub"]
    B --> E["LinkedIn"]

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

2. Від PROOF_OF_WORK.md до карʼєрних артефактів

Коли PROOF_OF_WORK.md і NARRATIVE_MAP.md уже зібрані, писати резюме з нуля більше не потрібно: джерело правди вже є, і ця база просто розходиться на три поверхні. Практично це означає, що матеріали не вигадуються, а збираються з уже наявних файлів: є capstone, PR walkthrough, migration plan і reviewer-agent — з них і народжуються пункти, profile README та LinkedIn About. Артефакта немає — не пишіть про нього.

Зручно тримати все це в окремій папці карʼєрних матеріалів. Наприклад, так:

career/
  PROOF_OF_WORK.md
  NARRATIVE_MAP.md
  RESUME_VARIANTS.md
  GITHUB_PROFILE.md
  LINKEDIN_PROFILE.md
  INTERVIEW_NARRATIVES.md
  STAR_stories/

Ролі розподіляються просто. PROOF_OF_WORK.md відповідає за факти й посилання. NARRATIVE_MAP.md відповідає за кут подачі: ваш рівень, 3–5 сильних історій, що ви свідомо не перебільшуєте. Решта файлів — різні форми однієї й тієї самої історії. Така структура нудна, але в хорошому сенсі нудна: інженерія взагалі любить передбачуваність більше, ніж творчу дим-машину.

Тут Claude Code справді корисний, але тільки як редактор, а не як письменник-фантаст. Ви не просите його «зроби мені сильне резюме» — ви даєте реальний артефакт і просите переформулювати без виходу за факти. Хороша заготовка запиту:

Нижче запис із PROOF_OF_WORK.md.
Зроби 3 варіанти пункту для резюме.
Не додавай команду, продакшн, користувачів, метрики й роль, яких немає в артефакті.
Збережи чесний scope: demo-ready, навчальний, solo, якщо це правда.
Кожен варіант — максимум 2 рядки.

Це дуже важливий момент курсу: AI допомагає формулювати, але ліцензії на художнє перебільшення у нього немає. Якщо ви пишете «production-ready», хоча у вас demo-ready capstone, — і самі влаштовуєте собі співбесіду з мінним полем: пояснюйте потім, чому у проєкту немає ні моніторингу, ні rollout strategy, ні нормального відновлення. Ніяковість — це вже майже баг, тільки в людському інтерфейсі.

3. Резюме: короткі пункти, чесний scope

Резюме — це місце, де особливо хочеться виглядати «солідніше, ніж є». Але якщо дивитися по-інженерному, хороший пункт схожий на хороший commit message: короткий, конкретний, описує дію і показує, що змінилося. Пункт у дусі «займався розробкою із застосуванням AI» — це приблизно як commit fix stuff. Формально щось сталося, фактично ніхто нічого не зрозумів.

Тут зручно використовувати одну й ту саму формулу для кожного сильного пункту: дія → конкретний артефакт → перевірюваний результат → посилання або відсилання до доказу. Живий URL у кожному bullet не обовʼязковий, але артефакт назвіть так, щоб його можна було показати за десять секунд.

Якщо у вас поки немає комерційного досвіду, це не катастрофа і не привід вигадувати компанію «ТОВ Інноваційні Рішення Майбутнього». Просто не видавайте навчальний проєкт за досвід роботи в організації: є розділи «Проєкти», «Практичні проєкти», «Навчальні та pet-проєкти». Чесніше і, парадоксально, сильніше: коли видно, що ви нічого не маскуєте, довіра зростає.

Наприклад, так можуть виглядати нормальні, живі пункти:

- Створив demo-ready capstone з плануванням за допомогою Claude Code, чернетками реалізації
  та smoke checks; відповідав за task spec, перевірку diff і фінальну верифікацію. [repo]

- Реалізував bugfix PR у зразковій ecommerce codebase:
  issue → plan → regression test → diff review → PR walkthrough. [PR]

- Спроєктував reviewer-agent із контрактом вихідних даних і межами лише для читання;
  використовував його для перевірки змін у коді перед фінальним людським рішенням. [artifact]

А ось так — звучить бадьоро, але пахне бідою:

- Очолив production AI migration для enterprise-платформи.
- Створив автономні агенти, що замінили ручну інженерну роботу.
- Створив production-ready SaaS з Claude.

Проблема не в тому, що ці фрази «занадто сміливі». Проблема в тому, що на наступне запитання інтервʼюера ви або почнете відступати назад, або застрягнете. Demo-ready — означає demo-ready, solo-проєкт — означає solo-проєкт. Чесний scope не робить вас слабшими — він робить вас перевірюваними.

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

Технології: Java, Spring Boot, PostgreSQL, React/Next.js
Процес: Git, task spec, diff review, регресійні тести, delivery з пріоритетом README
AI workflow: Claude Code, custom skills, reviewer-agent, базові можливості MCP

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

4. GitHub profile README: вітрина, а не комірчина

GitHub-профіль часто сприймають як склад репозиторіїв: ось мої двадцять сім папок, ось зламаний pet-проєкт 2023 року, ось ще три спроби зрозуміти Docker, насолоджуйтеся. Рекрутер зазвичай просто закриває вкладку. Profile README потрібен саме для того, щоб провести людину по артефактах, а не кинути її саму в лісі репозиторіїв.

Хороший profile README відповідає на три запитання: хто ви професійно, над чим працюєте і як працюєте. Зверніть увагу: не «як ви мрієте звучати», а як влаштований ваш реальний інженерний процес. У цьому сенсі profile README — майже публічна версія вашої професійної операційної системи.

Нижче дуже проста, але робоча структура:

# [Імʼя]
AI-native software engineer. I use Claude Code as an agentic coding environment,
not as a chat, and I verify through diff, tests and review.

## Як я працюю
- task spec before code
- plan-first для нетривіальних змін
- маленькі коміти, тести, review

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

Після короткого вступу доречно показати 3–4 головні артефакти: capstone як головний якір, один технічний кейс (PR walkthrough або migration artifact) і один workflow-артефакт (skill або reviewer-agent). Якщо артефакти розкидані по репозиторіях, зробіть окремий публічний індекс-репозиторій із README, що посилається на решту.

Корисна мініструктура для блоку з проєктами може бути такою:

Дуже важливо не перетворювати профіль на альбом марнославства з AI evangelist, building the future, disrupting software. GitHub — місце, де особливо швидко видно різницю між словами й артефактами. Бачить людина після резюме ту саму історію, але глибше й предметніше — довіра зростає. Бачить пафос і нуль навігації — падає швидше, ніж тести при зламаній конфігурації.

5. LinkedIn: не міні-резюме, а публічна візитівка

LinkedIn часто псують двома способами: або копіюють резюме з сухими пунктами, або, навпаки, влаштовують із нього маленький театр самопрезентації. По-хорошому це проміжок — трохи живіше за резюме, але так само чесно й evidence-based. Якщо GitHub — вітрина інженера, то LinkedIn — табличка на дверях, а не ціла дисертація.

Простіше за все збирати заголовок профілю за формулою: тип ролі + ваш AI-workflow + домен + поточний статус. Спочатку роль, потім робочий кут, потім предметна область — не навпаки: людина має спочатку зрозуміти, ким ви є в класичному сенсі ринку, а вже потім дізнатися, що ви робите це в AI-native workflow.

Нижче три акуратні приклади без зайвої піротехніки:

Junior Software Engineer | AI-Assisted Workflow | Backend / Internal Tools | Open to work
Software Engineer | AI-Native Workflow Design | Full-Stack / Product Engineering | Open to work
Senior Engineer | AI Workflow, Legacy Modernization, DevOps Automation | Open to work

Блок About краще тримати коротким — трьох-пʼяти речень цілком достатньо. Перше: хто ви і який фокус. Друге: як ви працюєте. Третє: на яких артефактах це видно. Четверте: який тип задач вам зараз цікавий. Усе. Не переповідайте весь курс і історію вашої любові до технологій із восьмого класу.

Ось спокійний і робочий шаблон:

Я працюю як AI-native software engineer: використовую Claude Code для аналізу,
чернеткової реалізації та перевірки, але відповідаю за task spec, diff review,
тести та фінальне рішення. У моєму портфоліо — capstone, кейси issue-to-PR,
workflow artifacts і reproducible README. Шукаю ролі, де важливі інженерна
дисципліна, зрозумілий delivery process і evidence-based підхід.

У LinkedIn особливо легко скотитися в небезпечні формулювання, тому що платформа спонукає здаватися більшими, ширшими, голоснішими. Але правило залишається незмінним. Не пишіть AI architect, якщо ви поки junior і маєте один сильний навчальний проєкт; не пишіть production migration lead, якщо у вас migration slice на sample repo. Публічне перебільшення потім болючіше відкотити, ніж локальне.

Ще одна корисна деталь: блок Featured, якщо платформа дозволяє, віддайте не випадковим постам, а трьом головним посиланням — capstone repo, demo або README і, за потреби, GitHub profile. Тоді LinkedIn перестає бути анкетою і веде людину до доказів.

6. Узгодженість пакета на всіх поверхнях

Коли ви збираєте три майданчики окремо, виникає спокуса трохи «підкрутити» кожен під настрій. У результаті виходить кумедний персонаж: у резюме — спокійний junior/middle developer, на GitHub — інженер-практик із workflow discipline, у LinkedIn — майже пророк AI-автоматизації. Роботодавець зустрічає трьох різних людей і не знає, кому вірити.

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

Зручно пройтися такою матрицею:

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

На практиці фінальна самоперевірка виглядає дуже буденно. Відкриваєте три файли поруч і ставите собі кілька неприємно корисних запитань. Чи однаково названий головний проєкт? Чи не обіцяю я в одному місці production, а в іншому demo? Чи можу за тридцять секунд показати артефакт під кожен сильний пункт? Чи не виглядає мій LinkedIn так, ніби його писав мій занадто самовпевнений двоюрідний брат? Чесні відповіді швидко вирівнюють пакет.

І в цьому, мабуть, уся логіка сьогоднішньої лекції. Хороший карʼєрний пакет не робить вас «крутішою людиною». Він прибирає шум між вашою реальною роботою і тим, хто її оцінює. Коли резюме, GitHub і LinkedIn говорять одним голосом, рекрутер перестає гадати і починає довіряти.