Цільові ролі та стратегія пошуку

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-перевага + підтверджувальні артефакти

Наприклад, якщо у вас сильний 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.