Резюме — это не летопись, а перевод. Восемь лет управления залом магазина, два года за стойкой ресепшена с телефоном и папками — и рядом два выпущенных Linux-проекта с живыми пользователями и баг-репортами от незнакомцев. Формально это одна биография. На бумаге она распадается на «настоящий опыт» и «пробел», и рекрутер однажды сформулировал это прямым текстом: годы в ритейле читаются как дыра в таймлайне, потому что ничто на странице не связывает их с остальным.
Проблема не в фактах. Проблема в чтении: и автоматический отбор, и человек за ним видят только то, что написано знакомыми им словами. Всё прочее для них не существует — даже если это была самая тяжёлая работа в вашей жизни.
Один проект, два совершенно разных текста
Приём простой и выматывающий: взять одну вещь и описать её дважды, под две разные вакансии. Текст при этом пишется заново, другими словами и с другой целью.
Возьмём KeyFlip — утилиту, которая отключает встроенную клавиатуру ноутбука и оставляет рабочей внешнюю.
Версия для вакансии разработчика:
Я написал KeyFlip — утилиту для Linux, которая отключает встроенную клавиатуру ноутбука, оставляя внешнюю в рабочем состоянии. Продумал поведение в аварийных ситуациях, протестировал на реальном железе, собрал пакет для Fedora и продолжаю дорабатывать проект по отзывам разработчиков на Linux.
Ни слова про магазин. Так и должно быть: проект сам доказывает, что он настоящий, ему не нужна предыстория.
Версия для вакансии в поддержке или онбординге:
В ранней версии проекта оставался крайний случай, при котором пользователь мог остаться без клавиатуры на своей же машине. Я нашёл этот сценарий, разобрался и закрыл его до того, как он кому-то навредил.
Поддержке неинтересно, что вы умеете собирать пакеты для Fedora. Ей важно знать, что вы не запаникуете, когда незнакомый человек злится на вас из-за сломанной вещи.
Дальше честно: к пятой заявке за день такое переписывание выматывает. Это не всегда увлекательная головоломка, иногда просто доказательство, что ради права быть понятым нужно работать вдвое больше, чем человеку с дипломом CS.
Одна и та же работа в двух сборках
| Что показывает | Инженерная вакансия | Поддержка и онбординг |
|---|---|---|
| В центре внимания | Техническое решение | Поведение в проблеме |
| Что доказываете | Умею строить и поддерживать код | Не сломаюсь, когда горит |
| Конкретные детали | Пакет для Fedora, тесты на железе | Разбор крайнего случая |
| Прошлый опыт вне IT | Не упоминается | Не упоминается, пока не отвечает на вопрос вакансии |
| Желаемая реакция читающего | «Он это делал» | «Он выдержит» |
Чек-лист перед отправкой
- Выпишите три самых «непрофильных» пункта биографии и напротив каждого — чему он вас научил: спокойствию, координации людей, разговору с недовольными. Это черновик перевода, ещё не финальный текст.
- Возьмите из описания вакансии три-четыре глагола и используйте их же. Если там «эскалировать», не пишите «сообщать о проблеме».
- Выберите один проект и перепишите его под эту вакансию. Один абзац на проект, не больше.
- Вычистите всё, что не отвечает на вопрос вакансии. Пустоты на странице — нормальная цена за внятность.
- Прочитайте вслух. Если звучит как выписка из протокола — переписывайте.
Где приём ломается
Переписывание не спасает, когда переписывать нечего. Если за душой только курсы и учебный проект из туториала, никакая формулировка не сделает его чужим боевым опытом. Второй случай — вакансии с жёстким требованием формального стажа: там фильтр читает не смысл, а строку «N лет в разработке». И третий: когда истории противоречат друг другу. Две разные версии одного проекта должны описывать разные его стороны, а не разные проекты.
Аргумент, который работает в разговоре
KeyFlip и Mochi — реальные, выпущенные, получающие отзывы. Но на собеседованиях полезнее держать под рукой что-то менее законченное и более похожее на их работу: Creator Operations Dashboard — капстоун, выбранный намеренно. Ввод сессий, данные в SQL, фильтрация, настоящий деплой, тесты, документация. Рекрутеру, которому всё равно на утилиту для клавиатуры, интереснее посмотреть на что-то формы его собственной задачи. Это не гарантия приглашения. Это доказательство, что вы не строите пустоту.
Что делать, когда ответов нет
Большая часть тишины — просто шум автоотбора, из него нечего извлечь. Ловить стоит только те редкие ответы, где назвали причину. Один такой разбор полезнее десяти глухих отказов, хотя ощущается хуже.
И ещё. Строительство не отвечает отказом, поэтому в него легко уйти с головой и перестать отправлять заявки. Граница простая: сначала выпускаете маленькую полезную версию, потом добавляете новое. Не наоборот.
Fluxs
Комментарии (0)
Войдите, чтобы комментировать.
Пока нет комментариев. Будьте первым.