Как переписать резюме при смене профессии: один проект — две разные истории

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

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

Один проект, два совершенно разных текста

Приём простой и выматывающий: взять одну вещь и описать её дважды, под две разные вакансии. Текст при этом пишется заново, другими словами и с другой целью.

Возьмём KeyFlip — утилиту, которая отключает встроенную клавиатуру ноутбука и оставляет рабочей внешнюю.

Версия для вакансии разработчика:

Я написал KeyFlip — утилиту для Linux, которая отключает встроенную клавиатуру ноутбука, оставляя внешнюю в рабочем состоянии. Продумал поведение в аварийных ситуациях, протестировал на реальном железе, собрал пакет для Fedora и продолжаю дорабатывать проект по отзывам разработчиков на Linux.

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

Версия для вакансии в поддержке или онбординге:

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

Поддержке неинтересно, что вы умеете собирать пакеты для Fedora. Ей важно знать, что вы не запаникуете, когда незнакомый человек злится на вас из-за сломанной вещи.

Дальше честно: к пятой заявке за день такое переписывание выматывает. Это не всегда увлекательная головоломка, иногда просто доказательство, что ради права быть понятым нужно работать вдвое больше, чем человеку с дипломом CS.

Одна и та же работа в двух сборках

Чек-лист перед отправкой

1. Выпишите три самых «непрофильных» пункта биографии и напротив каждого — чему он вас научил: спокойствию, координации людей, разговору с недовольными. Это черновик перевода, ещё не финальный текст.
2. Возьмите из описания вакансии три-четыре глагола и используйте их же. Если там «эскалировать», не пишите «сообщать о проблеме».
3. Выберите один проект и перепишите его под эту вакансию. Один абзац на проект, не больше.
4. Вычистите всё, что не отвечает на вопрос вакансии. Пустоты на странице — нормальная цена за внятность.
5. Прочитайте вслух. Если звучит как выписка из протокола — переписывайте.

Где приём ломается

Переписывание не спасает, когда переписывать нечего. Если за душой только курсы и учебный проект из туториала, никакая формулировка не сделает его чужим боевым опытом. Второй случай — вакансии с жёстким требованием формального стажа: там фильтр читает не смысл, а строку «N лет в разработке». И третий: когда истории противоречат друг другу. Две разные версии одного проекта должны описывать разные его стороны, а не разные проекты.

Аргумент, который работает в разговоре

KeyFlip и Mochi — реальные, выпущенные, получающие отзывы. Но на собеседованиях полезнее держать под рукой что-то менее законченное и более похожее на их работу: Creator Operations Dashboard — капстоун, выбранный намеренно. Ввод сессий, данные в SQL, фильтрация, настоящий деплой, тесты, документация. Рекрутеру, которому всё равно на утилиту для клавиатуры, интереснее посмотреть на что-то формы его собственной задачи. Это не гарантия приглашения. Это доказательство, что вы не строите пустоту.

Что делать, когда ответов нет

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

И ещё. Строительство не отвечает отказом, поэтому в него легко уйти с головой и перестать отправлять заявки. Граница простая: сначала выпускаете маленькую полезную версию, потом добавляете новое. Не наоборот.