ИИ перепишет формулировку, но не вспомнит то, чего в резюме нет. Если вы десять лет не записывали детали, модель про них не знает — и «улучшение» сведётся к перестановке слов и более бодрым глаголам. Поэтому порядок работы обычно перевёрнут: сначала база фактов о себе, потом текст.
Что вообще происходит, когда просишь ИИ доработать резюме
Стандартный поток выглядит так: старое резюме плюс вакансия на входе, модель в середине, «улучшенное» резюме на выходе. Слабое место тут не в модели. На входе лежит уже сильно урезанная версия истории: то, что казалось неважным, из неё вычищено. Модель работает с этим огрызком и физически не может достать факт, которого в документе нет.
Перевёрнутый поток: факты и контекст сначала, потом ИИ и только потом резюме. Резюме оказывается последним шагом, побочным продуктом. Звучит как лишняя бюрократия, пока не попробуешь описать несколько лет в одной компании.
Недостаточно сохранить факт — нужно сохранить контекст, в котором он был правдой.
Разделите историю по уровням
Минимальный набор сущностей выглядит так:
- Профиль — кто я и чего хочу.
- Работа — какую роль занимал в этот период.
- Проект — что делал, на каком стеке, в какой роли, с каким результатом.
Зачем так мелко? У одного работодателя у вас может быть Android-проект, где вы отвечаете за приложение и команду, Kotlin/Ktor BFF, где вы бэкендер и архитектор, и отдельно KMP, внутренние инструменты или CI/CD. Если всё это свалить в одно поле «опыт работы», модель смешает контексты: технология из одного проекта окажется рядом с достижением из другого, а роль тимлида расползётся на работу, где вы были обычным разработчиком.
Отдельно стоит держать приватное поле свободной формы. Фразы вроде «эту роль больше не хочу» или «людьми руководил, но точный размер команды не помню» ещё не материал для резюме, зато это контекст для модели. Плюс не каждая промежуточная правка публичного документа должна читаться как «он снова в поиске».
Самый полезный вывод модели — не текст, а вопросы
Когда база заполнена, имеет смысл запустить ревизию. Ожидаешь советов про сокращение и порядок блоков, а вместо этого получаешь допрос. Вы написали, что руководили Android-командами, — ИИ спрашивает, сколько именно человек. Написали про полностью удалённую работу — уточняет, рассматриваете ли гибрид. Перечислили несколько направлений карьеры — просит разделить, какое цель, а какое просто вариант.
На уровне конкретной работы вопросы становятся неприятными, и это хорошо:
- «Значительно ускорил разработку» — на сколько? Цикл релиза ушёл с шести недель до двух? С одного релиза в месяц до четырёх?
- «Сократил время реакции на инциденты» — с какого значения до какого?
- «Перенёс разработку с подрядчика внутрь» — размер команды, масштаб проекта и что изменилось в сроках, стоимости или скорости?
Показательно, когда рядом стоят два факта из одной истории. Один уже с числами: доля крашей упала примерно с 60% до 99,8% — тут улучшать нечего. Соседний — «значительно ускорил разработку», понятный автору, потому что он помнит контекст, и почти пустой для человека, который видит резюме впервые.
Метрики — не территория менеджера
Обычно кажется, что цифры нужны руководителю для отчётов. На практике они нужны вам самому, чтобы объяснить свою работу: размер команды, количество устройств в продакшене, число сторов, релизов, время цикла, доля ошибок, объём операций. Не всё измеряется деньгами. Но «я улучшил процесс» и «было столько, стало столько» — два разных утверждения.
Роли: подбор фактов, а не подгонка биографии
Отдельная задача — не как красиво назвать себя, а кем вообще идти. Выбирать титул и натягивать на него биографию неудобно; проще собрать то, что реально делал, и посмотреть, какие роли из этого следуют. Инструмент смотрит на профиль, опыт, проекты, стек и результаты и предлагает варианты позиционирования с обоснованием: Head of Mobile, Mobile Engineering Manager, Lead Android Architect, Mobile Platform Lead. Решение остаётся за вами — модель лишь строит гипотезу с аргументами из вашей же истории.
Сохранённая роль — это отдельный вид одной и той же базы фактов. Скажем:
- Head of Mobile: управление командой, найм, перевод разработки внутрь, инженерные стандарты, релизные процессы.
- Lead Android Architect: Android и Kotlin, архитектурные решения, стабильность, модернизация, руки в коде.
- Mobile Platform Lead: CI/CD, платформенные механизмы, фиче-тогглы, KMP, внутренняя инфраструктура.
Под конкретную вакансию логика другая. Бесполезно спрашивать у модели «я на 82% подхожу?». Полезнее: что из моего опыта нужно показать, чтобы резюме закрывало требования этого объявления. Вакансия становится контекстом для отбора фактов, а не приговором кандидату.
| Этап | Резюме как источник | База фактов как источник |
|---|---|---|
| Что на входе | Урезанный документ, который вы сами редактировали годами | Работы, проекты, роли, стек, числа, заметки |
| Что делает ИИ | Перефразирует, переставляет блоки, добавляет глаголов | Ищет пробелы, задаёт вопросы, предлагает позиционирование |
| Что на выходе | Одна версия под одну вакансию | Несколько резюме из одной истории |
| Где ломается | Нечего добавить: фактов в исходнике нет | Требует времени на заполнение и честности с собой |
| Публикация | Обычно сразу | Вручную, человеком |
Это не проблема программистов
Тот же механизм повторяется у бухгалтера: сколько юрлиц вела, сколько счетов в месяц выставляла, сколько проводок по списанию материалов, какой был месячный объём. Вопросы не про Android и не про Kotlin. Человек пишет «занимался X», модель отвечает «а каков масштаб X и чем это подтверждается», человек идёт обратно в свою реальную историю и дописывает.
Практика: что положить в базу и чего не делать
Рабочий минимум, который стоит завести, даже если вы не собираетесь искать работу прямо сейчас:
- Факты с числами в формате «было → стало»: релизы, ошибки, объём, сроки, размер команды.
- Контекст каждого факта: компания, период, роль, проект, стек, результат.
- Черновики мыслей отдельно от публичного документа: чего не хочу, что под вопросом, где не помню деталей.
- Импорт старых PDF и DOCX — с предпросмотром и подтверждением перед записью. Замена уже заполненного профиля должна требовать отдельного согласия.
- Роли как разные представления одной базы, а не отдельные биографии.
Типичные ошибки: сваливать всё в одно поле «опыт работы»; хранить только публичную версию и терять черновики; просить модель «усилить формулировки» до того, как собраны цифры; заливать распарсенный файл в базу автоматически, без проверки. И бесконечная полировка резюме, которая подменяет собой поиск.
Честный итог
Резюме получается заметно подробнее и лучше подкреплено: пробелы в собственной истории находятся, метрики добавляются, на роли смотришь иначе. Но звонков и сообщений почти нет — и почему именно, непонятно. Может быть рынок, может быть позиционирование, может быть сам документ, а может, вы оптимизируете не ту часть процесса. Есть неприятная гипотеза: долгая итерация резюме с ИИ загоняет в локальный максимум — документ становится логичнее для вас и для модели, но не для найма. Данных, чтобы утверждать это как факт, нет.
Резюме — временный снимок карьеры, а не её хранилище. Важное лежит раньше: факты, контекст, проекты, реальные роли, масштаб, числа, ограничения и предпочтения. Из слабой базы ИИ аккуратно перепишет слабый материал. Из хорошей — найдёт пробел, задаст неудобный вопрос и соберёт разные документы из одной истории.
Себе оставить стоит немного: решать, кем быть, не выдумывать достижения, не отдавать модели выбор «откликаться или нет» и публиковать финальную версию руками.
Fluxs
Комментарии (0)
Войдите, чтобы комментировать.
Пока нет комментариев. Будьте первым.