Career narrative: Junior, Middle, Senior

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 проектирует и регулирует.

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

Полезно заметить одну тонкость. Junior narrative — не «слабый», он обещает другое: «умею аккуратно работать по процессу, доводить небольшой scope до конца, не терять проверки, не заметать ограничения под ковёр».

Middle narrative тоже не обязан звучать как маленький Senior. Его сила — ownership задачи: decomposition, diff review, тесты, documentation trail, работа с незнакомым кодом.

Senior narrative начинается там, где опыт говорит уже не «я сделал задачу», а «я спроектировал способ, по которому задачи делает система или команда». Но здесь есть ловушка: шляпа 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 и ответы на интервью. Шести полей хватает почти всегда.

Ниже — шесть полей:

Хорошо работает такой минимальный шаблон:

# 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 опорных историй из артефактов курса

Теперь из всей вашей кладовки нужно выбрать не всё подряд, а несколько действительно сильных историй. Здесь помогает простое правило: опорная история — не файл, а цепочка «была задача → я принял решения → вот проверяемый результат». Артефакт без действия и результата — доказательство, но ещё не история.

Посмотрим, как это обычно работает на материалах курса.

Заметьте, один и тот же артефакт живёт в разном 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 начинает работать по-настоящему. Вам больше не нужно играть роль — вы выбираете правильный ракурс для реальных артефактов. История звучит спокойно, и её легче всего защищать: собрана она не из амбиций, а из доказательств.