1. Narrative — не замість доказів, а фокус на них
На цьому кроці легко запитати: якщо у вас вже є PROOF_OF_WORK.md, посилання на capstone, PR walkthrough і перевірювані артефакти, навіщо зверху ще якась «професійна історія»? Запит дуже слушний. Narrative потрібен не замість доказів, а щоб людина навпроти побачила: це повторюваний патерн, а не випадковий набір навчальних подвигів.
Уявіть, що evidence bank — це комірчина. У ній TASK_SPEC.md, REVIEW_NOTES.md, MIGRATION_PLAN.md, agents/reviewer.md, capstone README, demo, smoke checks, нотатки з refactoring. Але якщо просто відчинити двері й сказати «ось, у мене тут багато всього» — це не допомагає. Narrative — не комірчина, а меню: що головне, у чому ви сильні, який тип задач ведете передбачувано і на що є докази.
Тут дуже важливо не переплутати narrative з гарною легендою. Він говорить не «ким я мрію здаватися», а «який патерн роботи я вже можу довести». Поганий narrative один: обраний за амбіцією, а не за доказами.
Тому сьогодні ми працюємо не над прикрашанням досвіду, а над його фокусуванням. Прикрашання закінчується фразою «AI architect» після одного capstone. Фокусування — тим, що людина за артефактами розуміє, у чому ви надійні.
2. Три версії однієї історії: Junior, Middle, Senior
Тепер вже можна чесно розвести три версії історії. Спочатку зʼявилися докази — лише потім обираємо рівень. Рівні відрізняються не довжиною тексту, а центральною обіцянкою роботодавцю. У кожного свій головний дієслово: Junior доводить, Middle веде, Senior проєктує і регулює.
Нижче — корисна порівняльна таблиця. Її не потрібно завчати як молитву перед співбесідою, але дуже корисно один раз чесно прикласти до свого досвіду.
| Рівень narrative | Центральна обіцянка | Які артефакти зазвичай це підтверджують | Що особливо небезпечно перебільшувати |
|---|---|---|---|
| Junior | Я вмію доводити невелике інженерне завдання до робочого результату через дисциплінований workflow | TASK_SPEC.md, один зрозумілий PR, README, demo, smoke checks, capstone core flow | Масштаб, production-ready формулювання, командне лідерство |
| Middle | Я вмію вести завдання за циклом issue → plan → implementation → tests → review → docs | PR walkthrough, regression tests, REVIEW_NOTES.md, test strategy, CI evidence, refactor case | Архітектурне лідерство команди, governance, «керував міграцією» без реальної зони відповідальності |
| Senior | Я вмію проєктувати та впроваджувати AI-assisted workflow на рівні системи, команди або складного legacy-потоку | agents/reviewer.md, AI_CODING_POLICY.md, MIGRATION_PLAN.md, risk map, modernization artifacts, team-level decisions | Формальне управління людьми, production incident ownership, «впровадив у компанії» без реального team adoption |
Корисно зауважити одну тонкість. Narrative Junior — не «слабкий», він обіцяє інше: «вмію акуратно працювати за процесом, доводити невеликий scope до кінця, не втрачати перевірки, не замітати обмеження під килим».
Narrative Middle теж не зобов’язаний звучати як маленький Senior. Його сила — ownership завдання: decomposition, diff review, тести, documentation trail, робота з незнайомим кодом.
Narrative Senior починається там, де досвід говорить уже не «я зробив завдання», а «я спроєктував спосіб, за яким завдання робить система або команда». Але тут є пастка: шапка Senior дуже красиво блищить. Іноді так, що хочеться вдягнути її просто тому, що блищить. Краще не треба — карнавальні костюми роботодавці помічають швидше, ніж здається.
3. Чесний вибір свого narrative-треку
Найчастіша помилка тут зовсім не технічна. Люди обирають narrative за самооцінкою, віком, бажаною зарплатою або гарною назвою ролі. Це дуже по-людськи. Але він працює інакше: не «ким бути приємно», а «що я вже можу довести кілька разів, не додаючи в кожне речення слово майже».
Для чесного вибору зручніше ставити собі не абстрактне запитання «який я рівень?», а більш прикладні.
- Який тип завдань у мене вже виходив повторювано?
- Чи можу показати не один вдалий епізод, а хоча б три артефакти в один і той самий патерн?
- Де в моїх матеріалах лежить ownership — у дисципліні виконання, у веденні циклу чи в проєктуванні самого workflow?
- Якщо інтерв’юер попросить відкрити будь-який заявлений артефакт і пояснити без допомоги Claude — витримаю спокійно чи почну шукати аварійний вихід?
Дуже допомагає маленька внутрішня перевірка на чесність. Якщо історія звучить сильно тільки з підсилювачами — «майже production», «майже керував», «майже впровадив», «майже migration architect» — narrative обрано вище за докази. Це не трагедія і не вирок, це просто сигнал змістити фокус ближче до реальності: реалістичний Middle майже завжди звучить сильніше за вигаданий Senior.
Ще одна корисна думка: основний narrative має бути один. Middle із сильним issue-to-PR циклом згадає advanced кейс з агентом або migration plan — якщо той підсилює центральну історію, а не перетворює вас на папері на «AI workflow lead». Narrative — не салат олів’є, куди кинули все з холодильника. Він читається краще з однією центральною лінією.
4. Personal narrative map: шість опор історії
Коли рівень обрано, дуже корисно зібрати все це в окремий робочий файл — NARRATIVE_MAP.md. Коротка нотатка «моя професійна позиція», якщо вона була у вас на початку шляху, тут доростає до карти: не публічний текст, а внутрішній каркас, з якого потім зручно збирати резюме, GitHub, LinkedIn і відповіді на інтерв’ю. Шести полів майже завжди достатньо.
Нижче — шість полів:
| Поле | Що туди писати | На яке запитання відповідає |
|---|---|---|
| Цільова роль | Конкретна роль, під яку ви себе позиціонуєте | Куди я взагалі йду |
| Найсильніший патерн роботи | Один повторюваний сценарій: доводжу small scope, веду issue-to-PR, проєктую workflow | У чому моя головна надійність |
| Докази | 3–5 артефактів із PROOF_OF_WORK.md | Чим я це підтверджую |
| Опорні історії | Три найсильніші історії, які можна розповісти вголос | Через які епізоди мене найлегше зрозуміти |
| Що я не перебільшую | Чесні межі: не називаю demo продакшеном, не кажу, що керував командою, якщо працював сам | Де мої стоп-лінії |
| Зони росту | Що я посилюю далі: CI, migrations, архітектура, тести | Як я сам бачу наступний крок |
Добре працює такий мінімальний шаблон:
# NARRATIVE_MAP.md
Цільова роль: Junior backend developer / internal tools
Найсильніший патерн: доводжу невелике завдання від spec до demo з перевірками
Докази: capstone README, Commerce OS PR, TASK_SPEC.md
Опорні історії: bugfix, capstone core flow, reviewer notes
Не перебільшую: production scale, team leadership, real incident ownership
Зони росту: CI, складніші integration testsЗверніть увагу на поле «Що я не перебільшую». Воно здається скромним, але на практиці одне з найкорисніших полів карти. Під стресом люди майже завжди «підфарбовують» формулювання. Коли межі записані заздалегідь, narrative стійкіший: solo capstone — не впровадження в компанії, навчальний pilot migration — не завершена трансформація.
5. Відбір 3–5 опорних історій з артефактів курсу
Тепер із усієї вашої комірчини потрібно вибрати не все підряд, а кілька справді сильних історій. Тут допомагає просте правило: опорна історія — не файл, а ланцюжок «була задача → я ухвалив рішення → ось перевірюваний результат». Артефакт без дії та результату — доказ, але ще не історія.
Подивімося, як це зазвичай працює на матеріалах курсу.
| Артефакт | Що він може доводити | Кому особливо корисний |
|---|---|---|
| TASK_SPEC.md із Commerce OS | Умію формулювати завдання інженерно, а не розпливчасто | Junior, Middle |
| PR walkthrough + REVIEW_NOTES.md | Умію вести change через diff, tests і review | Junior, Middle |
| Refactor case + characterization checks | Умію змінювати структуру, зберігаючи поведінку | Middle |
| agents/reviewer.md | Розумію agent contract, boundaries і output format | Middle, Senior |
| MIGRATION_PLAN.md + rollback note | Умію думати фазами, ризиками та verification | Senior, сильний Middle |
| Capstone demo + README | Умію доводити проєкт до показуваного результату | Усі рівні |
Зверніть увагу, один і той самий артефакт живе в різному narrative по-різному. Capstone demo в Junior доводить дисципліну та завершеність, у Middle — уже ownership повного циклу. У Senior він має сенс лише якщо всередині справді є системний шар: governance, workflow design, migration path, tool design, team asset. Не факт capstone робить вас Senior — важливо, що в ньому лежить.
Гарна опорна історія майже завжди витримує три запитання. Яка була проблема? Що ви зробили самі, а що прискорив Claude? Чим перевірили? Ламається на другому або відповідає розпливчасто — це ще не історія, а симпатичний файл: залиште в evidence bank, у narrative беріть епізоди з чітким причинно-наслідковим зв’язком.
Є ще одне корисне налаштування фільтра — на різноманітність. Воно потрібне не саме по собі, а коли підсилює основний патерн. Для Middle поєднуються PR із Commerce OS, refactor case з tests і capstone. Для Senior — reviewer agent, migration plan і team policy artifact. А зібрати в одну розповідь усе підряд, від MVP до hooks, тому що шкода викинути, — шкідливо: історія не багатша, а мутніша.
6. Короткий narrative-абзац
Коли карта заповнена і історії обрано, з них уже можна зібрати короткий професійний абзац. Не резюме і не публічний профіль, а внутрішню заготовку в чотири-п’ять речень, щоб тримати одну лінію і не розповзатися в деталі.
Зручна формула виглядає так:
Я [тип спеціаліста], який уміє [головний патерн роботи].
Це підтверджують [2–3 ключові артефакти або історії].
Claude Code прискорював [які кроки], але я сам відповідав за [ownership].
Найкраще у мене виходить [дві конкретні зони].
Поки я не перебільшую [межі], але вже посилюю [зону росту].Подивіться, як це звучить на трьох рівнях.
Junior:
Я початківець backend-розробник, який уміє доводити невелике завдання
від task spec до робочого результату з перевірками. Це підтверджують мій
capstone, один PR у Commerce OS і TASK_SPEC.md. Claude Code прискорював аналіз
і чернетки змін, але я сам перевіряв diff, запускав smoke checks і
фіксував обмеження.Middle:
Я software engineer, який уміє вести завдання за циклом issue → plan →
implementation → tests → review. Це підтверджують PR walkthrough, regression
tests, refactor case і capstone з reproducible README. Claude Code допомагав
в investigation, test scaffolding і documentation drafts, але відповідальність
за scope, перевірки та фінальне рішення залишалася на мені.Senior:
Я senior engineer, який проєктує AI-assisted workflow для складних
інженерних задач і legacy-сценаріїв. Це підтверджують reviewer-agent,
migration plan з rollback і policy artifacts із Workflow Kit. Claude Code
прискорював підготовку та аналіз, але я задавав межі, risk model, verification
path і decision points.Зверніть увагу, що сильний абзац не намагається довести все на світі. Він не кричить «я універсальний», «я і Junior, і Senior, і ще трохи DevOps wizard». Він обирає одну лінію і тримає її спокійно. У цьому доросла сила narrative: він не театральний, а стійкий.
Якщо відчуваєте, що абзац звучить сухо, не потрібно терміново додавати гучні слова — краще додати трохи більше конкретики. Не «працював з AI-assisted workflow», а «вів завдання через task spec, small diff, tests і review». Не «займався migration», а «підготував migration plan з compatibility matrix і rollback note». Не «вмію працювати з агентами», а «спроєктував reviewer-agent із boundaries та output contract». Конкретика надійніша за пафос.
І ось у цей момент narrative починає працювати по-справжньому. Вам більше не потрібно грати роль — ви обираєте правильний ракурс для реальних артефактів. Історія звучить спокійно, і її найлегше захищати: зібрана вона не з амбіцій, а з доказів.
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ