Целевые роли и стратегия поиска

1. Поиск работы начинается до первой вакансии

Когда открываешь сайт вакансий без выбранной заранее роли, за пять минут поиск становится смесью шопинга, гадания и лёгкого экзистенциального кризиса. Сегодня вы почти бэкенд-разработчик, завтра AI product engineer, послезавтра примеряете tech lead. Проблема не в рынке, а в том, что поиск начался без рамки.

С карьерой работает тот же принцип, который вы уже много раз использовали в разработке. Мы же не начинаем реализацию без task spec — без него Claude Code «полезно» перекроит всё подряд. С работой так же — нет профиля роли и границ, и рынок подбрасывает случайные вакансии, а мозг случайные фантазии.

Здесь полезно держать в голове очень простую цепочку:

Career Evidence Bank → профиль целевой роли → границы поиска → только потом вакансии

Смысл этой цепочки в том, что вы не пытаетесь отвечать на большой философский вопрос «кем я буду через десять лет». Вместо этого вы задаёте себе более скромный, но куда более полезный вопрос: на какие роли я могу честно и уверенно откликаться уже сейчас, опираясь на свои артефакты.

Ваш capstone, PROOF_OF_WORK.md, демо, тесты, README, PR walkthrough, evidence log — это не украшения, а входные данные. Из них вы выводите несколько ролей, подтверждённых опытом. Без этого рынок похож на терминал без фильтра: данных много, а пользы как от лога на три тысячи строк без stack trace.

Хорошая новость в том, что профиль роли не высечен в граните — это рабочая гипотеза, а не брачный контракт с профессией. Но незаписанная гипотеза меняет форму под настроение, красивую вакансию или случайный пост в соцсетях. Зафиксируйте её.

2. AI-native — это позиционирование, а не должность

На этом этапе почти у всех появляется соблазн назвать себя как-нибудь красиво и современно: AI-native Software Engineer, AI Workflow Specialist или, если день особенно удачный, AI Product Builder. Звучит бодро. Проблема только в том, что рынок найма чаще всего ищет не бодрые формулировки, а понятные роли.

Рекрутер, hiring manager и поисковые фильтры обычно мыслят привычными категориями: backend developer, frontend developer, software engineer, QA automation, platform engineer, tech lead. Так устроены фильтры, ожидания и критерии отбора. Назовёте себя слишком оригинально — вас не поймут не из-за слабого опыта, а из-за несовпадения заголовка профиля с категорией вакансии.

Поэтому думайте не «моя роль — AI-native engineer», а: «моя базовая роль — традиционная инженерная роль, а AI — это моё усиление».

Сравните.

Плохо:
AI Workflow Ninja
AI-native Builder
Next-Gen AI Engineer

Сильнее:
Backend Developer (Python) с AI-assisted issue-to-PR workflow
Frontend Developer с verification-first подходом и сильным demo evidence
Software Engineer с опытом AI-assisted testing, review и documentation

Во втором варианте у рынка появляется за что зацепиться: понятная роль, понятный стек и ваше отличие — реальное AI-преимущество, доказуемое артефактами. Именно здесь формулировка вроде AI-native работает отлично: не как название должности, а как угол подачи.

Формула короткая:

традиционная роль + ваше AI-преимущество + подтверждающий evidence

Например, если у вас сильный MVP-capstone, аккуратный GitHub и внятный narrative про issue-to-PR, рынок скорее поймёт «AI-assisted Product Engineer», чем «человека, который умеет пользоваться Claude Code». А если сильнее бэкенд, API, тесты и verification, логичнее выходить как backend engineer, а не «архитектор AI-workflow».

И ещё один важный нюанс. Иногда кажется, что раз курс называется AI-native Software Engineer, то и job title надо искать такой же. Не обязательно. Название курса — это рамка навыка, название вакансии — категория рынка. Путать их — как написать в резюме «специалист по уверенной работе с отвёрткой» вместо «инженер-механик».

3. Реалистичная роль начинается с вашего уровня

Очень полезно один раз спокойно посмотреть на рынок через уровень, а не через мечту. Это не про занижение себя — это чтобы роль совпала с ответственностью, которую вы объясните на интервью без акробатики и поэзии.

Ниже — простая ориентировочная матрица, которая хорошо ложится на логику курса и на тот evidence bank, который вы уже собрали:

Здесь важно правильно понять слово stretch. Stretch — это не «роль, на которую я тайно надеюсь пройти чудом». Stretch — это роль, которая чуть выше вашей основной зоны комфорта, но уже подпирается конкретными артефактами. Например, Junior после сильного MVP, хорошего GitHub и уверенного demo действительно может попробовать роль с продуктовым уклоном. Но это всё ещё не превращает его в AI workflow lead, потому что для такой роли обычно нужен опыт командной эксплуатации процессов, а не только умение собрать хороший capstone.

Точно так же Middle-инженер может честно смотреть на CI/CD automation или developer productivity, если у него есть evidence по automation, policy, scripts и workflow design. Но если опыт team-level adoption, rollout и shared governance у него пока был только учебным, то роль Staff или серьёзного team lead лучше оставить как дальнюю цель, а не как основную ставку прямо сейчас.

В этом месте полезно снять эмоциональное напряжение. Уровневые ограничения — это не способ «поставить вас на место». Это страховка от очень неприятной ситуации, когда вакансия красивая, а интервью внезапно спрашивает про ownership зоны, budget impact, rollout across teams, incident response, hiring, stakeholder alignment и другие вещи, которые невозможно честно придумать на ходу. Курс дал вам сильные артефакты. Но календарь всё ещё помнит, сколько лет реального рабочего контекста у вас было на самом деле.

Поэтому реалистичная роль — это не компромисс с мечтой. Это умный первый рынок, где ваши артефакты будут звучать убедительно, а не как «почти то же самое, только без продакшена, команды и ответственности».

4. Оформляем профиль целевой роли в target-roles.md

Очень полезно вынести все эти решения из головы в отдельный небольшой файл. Проще всего держать его в career/target-roles.md внутри своего career workspace. Роли лучше фиксировать отдельно: JOB_TRACKER.md потом пригодится для статусов и next actions, а не для хранения ролевой гипотезы. Суть всё равно не в названии. Суть в том, что роль должна быть зафиксирована письменно, иначе она будет меняться каждый раз, когда вам попадётся особенно красиво написанная вакансия.

Хороший профиль целевой роли обычно состоит из четырёх блоков: ваш текущий уровень, основные роли, stretch-роли и роли, которые вы сознательно не берёте. Уже сама последняя секция очень полезна. Она экономит много времени и немного бережёт нервную систему.

Например, файл может выглядеть так:

# target-roles.md

## Уровень
Middle

## Основные роли
- Backend Engineer (Python / Node) — есть capstone API, тесты, issue-to-PR
- Software Engineer — есть verification, review, documentation evidence
- AI-assisted Product Engineer — есть MVP demo и README с reproducibility

## Растяжимая часть
- CI/CD Automation Engineer — есть GitHub Actions и automation artifacts
- Developer Productivity — только если вакансия не требует team rollout experience

## Пока не беру
- Tech Lead — нет team ownership
- Staff Engineer — недостаточно production-scale evidence

Обратите внимание на маленькую, но важную деталь: каждая роль связана не только с названием, но и с обоснованием — какие артефакты её подтверждают. Тогда файл перестаёт быть списком мечтаний и становится инженерной запиской. Ещё одна сильная привычка — записывать рядом не только «почему да», но и «где у меня дыра»: «есть CI/CD sample evidence, но нет production-scale rollout». Такая пометка делает вас не слабее, а точнее. А точность полезнее громкости.

Пересматривать target-roles.md нужно не после каждого отказа. Один ghosting, одно странное screening-интервью, одна мутная вакансия — ещё не означают, что роль выбрана неверно. Пересмотр начинается тогда, когда появляется паттерн: вы пять раз доходите до одного типа вакансии и упираетесь в один и тот же gap. Вот тогда файл действительно стоит обновить.

5. Границы поиска: фильтр, который экономит недели

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

Обычно хватает восьми.

Удобно зафиксировать в career/search-boundaries.md:

# search-boundaries.md

уровень: Middle
стек: Python / Node.js, PostgreSQL, AWS
регион: Европа
формат: удалённо или remote-first
вилка: 60–90k EUR
домен: B2B SaaS, внутренние инструменты
язык: английский рабочий, русский родной
тип компаний: 20–500 человек

Смысл этого файла очень практичен. Допустим, вы открыли три вакансии: middle backend engineer в B2B SaaS на удалёнку; senior platform engineer в финтех с on-site офисом и жёстким compliance; junior full-stack в локальном аутсорсе. Без зафиксированных границ мозг начнёт сравнивать их одновременно. А это три разных рынка, три профиля, три типа собеседования.

Именно здесь границы поиска работают как хороший WHERE в запросе: не «ограничивают возможности», а убирают шум. Если запрос слишком широкий, вы тратите энергию на варианты, которые изначально не подходят; потом кажется, что рынок хаотичный и злой, хотя чаще всего он просто не был отфильтрован. Поэтому на старте полезнее делать поиск уже, чем хочется: узкая, но честная воронка, где роли совпадают с доказательствами, выглядит сильнее, чем попытка быть всеми сразу.

6. Claude Code как зеркало, а не гадалка

На этом этапе Claude Code становится очень удобным партнёром, но не в роли «карьерного оракула». Он не решает за вас, кем вам быть; его задача — сопоставить evidence bank с профилем роли, найти overclaim и предложить честные формулировки. Это очень в духе всего курса: Claude не заменяет решение, а усиливает проверку.

Например, вы можете дать ему PROOF_OF_WORK.md, capstone README и черновик target-roles.md и попросить прогнать профиль через stress-test. Хороший запрос может выглядеть так:

Прочитай PROOF_OF_WORK.md, capstone README и мой draft target-roles.md.

Для каждой роли ответь:
1. что у меня реально подтверждено артефактами;
2. что выглядит как stretch;
3. что пока рано заявлять;
4. какие формулировки в резюме звучат как overclaim.

Не придумывай опыт, которого нет.
Если уверенности мало — так и напиши.

Такой режим работы полезен по двум причинам. Во-первых, Claude хорошо замечает несостыковки между формулировками и артефактами. Во-вторых, он убирает лишний маркетинг — мы сами влюбляемся в красивые слова и не замечаем, что буллет обещает больше, чем проект доказывает.

Но здесь есть одна жёсткая граница: Claude не утверждает финальный профиль роли. Если он написал «вам, возможно, подходит AI Workflow Lead» — это не стало правдой автоматически. Рекомендацию вы сверяете с evidence, уровнем ответственности и тем, что объясните на собеседовании без подсказок.

Хороший результат такой работы — не «Claude сказал, что я готов», а файл, где у каждой роли честное обоснование, понятный уровень и ясная граница между основными и stretch-вариантами. Когда он появляется, рынок становится спокойнее. Вакансия больше не случайная реклама — это документ, который вы сравниваете со своим профилем так же трезво, как раньше сравнивали задачу с task spec.