AI-native resume, GitHub и LinkedIn

1. Рекрутер не должен играть в археолога

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

Полезно смотреть на карьерный пакет так: это три поверхности, и каждая отвечает на свой вопрос. Резюме: подходите ли вы под роль. GitHub: есть ли реальные артефакты. LinkedIn: как вы описываете себя публично.

Полезно думать об этом так: это не три разные истории, а три версии одной и той же с разной глубиной. Если одно говорит «Junior backend developer», второе кричит «AI architect», а третье выглядит как страница мотивационного коуча, доверие исчезает мгновенно. Рынок любит разный опыт, но не разнобой.

Держите эту схему в голове, пока собираете материалы:

flowchart LR
    A["PROOF_OF_WORK.md"] --> B["Personal narrative map"]
    B --> C["Резюме"]
    B --> D["GitHub profile"]
    B --> E["LinkedIn"]

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

2. От PROOF_OF_WORK.md к карьерным артефактам

Когда PROOF_OF_WORK.md и NARRATIVE_MAP.md уже собраны, писать резюме с нуля больше не нужно: источник правды уже есть, и эта база просто расходится на три поверхности. Практически это значит, что материалы не сочиняются, а собираются из уже существующих файлов: есть capstone, PR walkthrough, migration plan и reviewer-agent — из них и рождаются bullets, 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. Резюме: короткие bullets, честный scope

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

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

Если у вас пока нет коммерческого опыта, это не катастрофа и не повод изобретать компанию «ООО Инновационные Решения Будущего». Просто не выдавайте учебный проект за опыт работы в организации: есть разделы «Проекты», «Практические проекты», «Учебные и pet-проекты». Честнее и, парадоксально, сильнее: когда видно, что вы ничего не маскируете, доверие растёт.

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

- Built a demo-ready capstone with Claude Code-assisted planning, implementation drafts
  and smoke checks; owned task spec, diff review and final verification. [repo]

- Implemented a bugfix PR in an ecommerce sample codebase:
  issue → plan → regression test → diff review → PR walkthrough. [PR]

- Designed a reviewer-agent with output contract and read-only boundaries;
  used it to review code changes before final human decision. [artifact]

А вот так — звучит бодро, но пахнет бедой:

- Led production AI migration for an enterprise platform.
- Built autonomous agents that replaced manual engineering work.
- Created a production-ready SaaS with Claude.

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

Ещё один важный участок — раздел навыков: его тоже легко превратить в склад случайных слов. Лучше группировать по смыслу, а не вываливать всё подряд через запятую. Если вы не можете объяснить технологию без помощи поисковика, не стоит включать её только ради красоты.

Технологии: Java, Spring Boot, PostgreSQL, React/Next.js
Процесс: Git, task spec, diff review, regression tests, README-first delivery
AI workflow: Claude Code, custom skills, reviewer-agent, MCP basics

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

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 for non-trivial changes
- small commits, tests, 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,
tests и финальное решение. В моём портфолио — 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 говорят одним голосом, рекрутер перестаёт гадать и начинает доверять.