Tailoring без выдуманного опыта

1. Tailoring на человеческом языке

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

Но делать это для каждой найденной вакансии — дорогой и бесполезный спорт. Смысл появляется только после career/applications/[slug]/FIT_ANALYSIS.md, когда решение принято: «эту заявку доводим». До этого вы не адаптируете — вы проверяете fit.

Если перевести это на язык разработки, то базовое резюме — это ваш main, а версия под вакансию — отдельная ветка. Никакого force push поверх истории. Берёте нужные куски, убираете шум, меняете порядок акцентов и следите, чтобы ни один «коммит» не содержал выдуманных фактов. Резюме, письмо и сообщение рекрутеру ссылаются на одни и те же артефакты, а не живут тремя жизнями, как три микросервиса без API-контракта.

Удобно думать о сегодняшнем процессе как о коротком конвейере.

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

2. Резюме: одна база, много честных версий

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

Практически это означает одну базовую версию, например в career/RESUME_VARIANTS.md, и отдельную под вакансию в career/applications/[slug]/TAILORED_RESUME.md. Базовый файл не перезаписывается — иначе через три итерации сами не поймёте, где правда, а где следы отчаянного вторника.

Хороший путь для адаптации выглядит так: рядом кладёте must-have из FIT_ANALYSIS.md и PROOF_OF_WORK.md и выбираете не «всё, что умею», а те доказательства, что показывают совпадение. Роль просит REST API, тесты и CI — не начинайте с passion for innovation. Маппинг «требование → артефакт → безопасная формулировка»:

Заметьте важную деталь: формулировки сильные, но не раздутые. У многих студентов проблема даже не в преувеличении, а в занижении собственных артефактов: reproducible demo, smoke checks, migration plan и объяснимый workflow — серьёзный материал, только не называйте его «управлял enterprise-трансформацией».

Очень полезно иметь перед глазами таблицу опасных и безопасных формулировок — она быстро остужает фантазию.

Если хочется короткого правила, держите его перед глазами: заменяйте громкий масштаб на точный масштаб. Точность почти всегда выглядит взрослее завышения.

Небольшой фрагмент адаптированного резюме может выглядеть так:

## Опыт и проекты

- Собрал demo-ready backend-сервис на Python/PostgreSQL с REST API,
  README по запуску и smoke-проверками основного сценария.
- Использовал Claude Code для codebase analysis, test scaffolding и docs,
  сохраняя за собой diff review и финальные решения.
- Подготовил pilot migration plan для учебного legacy-модуля:
  compatibility analysis, rollback path, validation checklist.

Такой фрагмент можно защищать голосом. А это, как ни странно, лучший тест на качество bullet-пункта.

3. Сопроводительное письмо как мост к доказательствам

Сопроводительное письмо часто превращают либо в роман про любовь к технологиям с детства, либо в вежливую копию резюме, которую никто не дочитывает. На практике оно полезно только тогда, когда делает одну вещь: быстро объясняет, почему эта роль сочетается именно с вашими доказательствами. Не больше.

Хорошая структура очень простая: роль и причина подачи, две-три связки «требование → мой артефакт», честно закрытый gap или готовность разобрать workflow на созвоне. Письмо на пять экранов — уже не письмо, а попытка взять интервью у рекрутёра в ответ.

Рабочий шаблон может быть таким:

Здравствуйте!

Меня заинтересовала позиция Backend Engineer, потому что в ней совпадают
мой текущий стек и тип задач, с которыми я уже работал в capstone и
учебных issue-to-PR сценариях.

С вашей вакансией особенно хорошо совпадают три пункта: REST API и
PostgreSQL в моём capstone-проекте, risk-based testing и verification
trail в README, а также migration planning на учебном legacy-сервисе.

У меня нет production-scale опыта с большим AWS-контуром, но есть
воспроизводимый pipeline и чёткое понимание, как я проверяю изменения
и где именно Claude Code ускоряет работу.

Буду рад показать репозиторий и коротко пройтись по workflow на созвоне.

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

Есть ещё одна полезная тонкость: письмо не обязано быть одинаково длинным. Иногда это поле “why are you a fit?” на 600 символов, иногда форма на два абзаца. Логика та же — сокращайте до ядра.

И не начинайте с «С детства я мечтал стать разработчиком». Трогательно, но вакансии не выделяют на это бюджет внимания.

4. Сообщение рекрутеру и запрос на рекомендацию

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

Различие удобно держать в маленькой таблице.

Хорошее сообщение рекрутеру не должно быть длинным, но должно быть конкретным. Ему не нужен весь ваш путь с первого проекта — нужен ответ на один вопрос: «Почему открыть именно этот профиль, а не следующий из двадцати?» Две-три связки с вакансией плюс честная граница вашего опыта. Например так:

Здравствуйте, [Имя]!

Увидел у вас вакансию Backend Engineer. По требованиям у меня хорошо
совпадают три вещи: Python/PostgreSQL стек в capstone-проекте,
tests + verification workflow, а также опыт подготовки migration plan
для учебного legacy-сервиса.

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

Если роль ещё актуальна, буду рад прислать репозиторий и короткий walkthrough.

Это коротко, не навязчиво и сразу объясняет, чем вы отличаетесь от обычного «прикрепляю CV». Важная деталь — фраза про Claude Code: она не прячет AI, а заранее ставит разговор в честную рамку. Для части ролей это плюс.

С запросом на рекомендацию тон должен быть ещё аккуратнее. Человеку должно быть легко сказать и «да», и «нет», не чувствуя, что его загоняют в угол, — тем более если знакомы вы слабо. Гораздо лучше дать контекст, конкретную роль и короткое объяснение fit, чтобы не заставлять его догадываться.

Небольшой пример:

Привет, [Имя]!

Увидел, что у вас в компании открыта роль Backend Engineer. Я подаюсь на неё,
потому что по стеку и формату задач она хорошо совпадает с моим capstone и
AI-assisted workflow из курса: REST API, verification, README/demo, migration awareness.

Если вам комфортно, буду благодарен, если посмотрите мой профиль и скажете,
есть ли смысл просить referral. Если нет — всё ок, я пойму.

Такое сообщение уважает время и репутацию человека и сильнее сухого «можешь зарефералить?»: оно снижает нагрузку на адресата, а не увеличивает.

Есть ещё одно правило, которое очень помогает: не превращайте outreach в атаку ссылками. Одна ссылка на GitHub и, если уместно, одна на demo — достаточно. Четыре репозитория, видео, PDF и десять bullet-пунктов в коротком сообщении — и человек не изучит ничего.

5. Claude Code как редактор, а не биограф-фантаст

На этой теме Claude Code может быть невероятно полезен, но только если вы изначально ставите ему правильную роль. Попросите «сделай резюме сильнее» — он и сделает: добавит масштаб, лидерство и production там, где их не было. Не злой умысел, а языковое сглаживание. Лучший режим — не «напиши за меня», а «проверь, сократи, уточни и найди неподтверждённые claims».

Самый полезный паттерн — давать Claude Code одновременно три входа: текст вакансии, ваш PROOF_OF_WORK.md и текущие bullet-пункты, и просить не писать с нуля, а сравнить и отметить расхождения:

Сравни эту версию резюме с моим PROOF_OF_WORK.md и FIT_ANALYSIS.md.
Для каждого сильного утверждения пометь:
[подтверждено] — если есть явный артефакт,
[слабо подтверждено] — если артефакт косвенный,
[нет артефакта] — если формулировка звучит сильнее, чем мои доказательства.
Ничего не дописывай от себя, только ревью.

Это очень хороший режим, потому что Claude здесь — внутренний reviewer: не «сочиняет карьеру», а показывает, где вы сами начали приукрашивать. А это, честно говоря, чаще, чем кажется: даже без сознательной лжи слово вроде production, led, owned platform, managed сдвигает масштаб в другую лигу.

Второй полезный режим — стилистическое сжатие без изменения фактов. Claude убирает тяжёлые обороты и делает письмо чище, не уводя в фэнтези:

Сократи это сопроводительное письмо до 120–150 слов.
Сохрани все факты, не добавляй опыт, которого нет.
Если видишь слова вроде production, leadership, team ownership без явного доказательства,
замени их на более точные формулировки.

Очень практично завести себе маленький файл-проверку и прогонять через него любую адаптированную версию перед отправкой:

# tailoring-check.md

- [ ] У каждого сильного утверждения есть конкретный артефакт
- [ ] Нет слов production / led / managed без прямого доказательства
- [ ] Все технологии в тексте я могу объяснить без подсказок
- [ ] Версия под вакансию сохранена отдельно, базовый файл не затёрт
- [ ] В письме и сообщении рекрутеру совпадают те же 2–3 ключевых доказательства

Этот чек работает почти как pre-commit hook для карьерных материалов. Особенно важен здесь последний пункт: если в резюме акцент на API и тесты, а в письме вдруг «люблю работать в динамичной среде», у читателя ощущение, будто это три разных человека.

И нюанс, который легко упустить: Claude Code особенно полезен, когда вы просите его не только редактировать, но и возражать вам — вопросом «На что ты опираешься, когда пишешь эту фразу?» Так он перестаёт быть фабрикой красивых слов и становится взрослым собеседником-редактором. Ради этой роли вы и проходили весь курс.