Рекрутер смотрит на резюме меньше шести секунд. За это время он успевает прочитать два-три пункта опыта и решить, звать вас дальше или нет. Автоматический скринер делает почти то же самое: ищет ключевые слова и цифры, по которым вас можно сравнить с другими кандидатами.
Значит, всё решают формулировки в нескольких строках. Есть приём, который повторяется в резюме инженеров из FAANG и из обычных стартапов: каждый сильный пункт построен по схеме «Проблема → Действие → Результат», и в результате обязательно стоит число.
Что не так со списком задач
Работал над бэкенд-сервисом аутентификации пользователей.
Помогал улучшать производительность платёжного пайплайна.
Писал юнит-тесты для новых фич.
Всё честно. Но читается как список дел из трекера: нет масштаба, нет ставок, нет эффекта. Такой пункт ничего не говорит ни о сложности задачи, ни о том, что изменилось после вас.
Формула PAR
Проблема — что было сломано, медленно, дорого или рискованно. Действие — что именно вы сделали, с названием стека и подхода. Результат — измеримое следствие: проценты, деньги, время, масштаб.
Вместо «улучшил производительность» получается что-то вроде: «Сократил задержку API на 42 % за счёт кэширования и async I/O, время загрузки страницы упало с 2,8 до 1,6 секунды». Разница в том, что вторую строчку можно проверить и сравнить с чужой. Рекрутер и парсер резюме любят конкретику именно за это.
Три разобранных примера
| Проблема | Действие | Результат |
|---|---|---|
| Задержка аутентификации подскакивала до 350 мс в пик, 12 % попыток входа падали по таймауту | Переписал цикл валидации JWT, добавил кэш токенов на Redis, заменил синхронные обращения к БД на async-запросы к PostgreSQL (Node.js + TypeORM) | Средняя задержка упала до 140 мс (−60 %), таймауты исчезли, конкурирующих логинов стало в три раза больше на том же железе |
| Ретраи платёжных вебхуков падали молча, терялось около $8 тыс. в месяц | Сделал идемпотентную обработку вебхуков с экспоненциальным бэкоффом, добавил мониторинг dead-letter queue через AWS SQS и алерты в CloudWatch | Восстановил 95 % упавших вебхуков, вернул примерно $7,5 тыс. в месяц, ручная сверка сократилась на 4 часа в неделю |
| Покрытие тестами держалось на 58 %, регрессии уходили в продакшн | Внедрил pre-commit hook с Jest и порогом покрытия, переписал легаси-колбэки на async/await | Покрытие выросло до 92 % за два спринта, багов после релиза стало на 40 % меньше, фидбек от QA ускорился с 3 дней до 12 часов |
Четыре ловушки
- Размытые глаголы. «Работал над», «участвовал в», «помогал с», «отвечал за» — эти формулировки описывают присутствие на работе, а не вклад. Меняйте на спроектировал, внедрил, оптимизировал, автоматизировал. Это первое, что бросается в глаза при вычитке, и самое дешёвое исправление.
- Нет чисел. Если точной метрики нет, ставьте примерную: «примерно на 30 % быстрее» лучше, чем ничего. Помните: оценка — это не ложь, если она честная и вы готовы объяснить, откуда она взялась.
- Забыт стек. Рекрутеры сканируют резюме глазами по ключевым словам, и названия технологий тут работают как магнит. React, Django, Kubernetes, конкретная база или очередь — всё это стоит упоминать прямо в описании действия.
- Длинные абзацы. Два строки максимум.
Что это даёт
Резюме перестаёт быть перечнем обязанностей и становится списком результатов. Проходимость фильтров растёт: ключевые слова и метрики начинают совпадать с текстом вакансии. У рекрутера появляется за что зацепиться взглядом — цифра в конце строки сама по себе повод дочитать остальное.
Есть и побочный эффект, о котором редко говорят. Когда вы раскладываете свою работу на проблему, действие и результат, вы начинаете видеть её в терминах бизнес-ценности. Это пригодится не только в резюме, но и на собеседовании, и на performance review: вы уже знаете, как объяснить, зачем вас держат в команде.
Что сделать сегодня
- Откройте текущее резюме и выберите один пункт, который кажется самым слабым.
- Вспомните, что именно было сломано или неоптимально до вас.
- Опишите своё действие, назвав инструменты и подход.
- Прикиньте результат: процент, сумма, сэкономленное время, выросший масштаб. Если данных нет — спросите у аналитики, у тимлида или посмотрите в старые дашборды, оттуда обычно и берутся эти числа.
- Сделайте так с тремя пунктами сегодня, с остальными — завтра.
В конце прочитайте получившееся вслух. Если после каждой строки хочется кивнуть и сказать «да, я правда это сделал» — формулировка рабочая. Если строка не вызывает ничего, кроме смутного узнавания, её ещё рано оставлять в резюме: либо не хватает конкретики, либо это была не ваша задача.
Самая частая причина провала на этом шаге — не лень, а отсутствие доступа к метрикам. Тогда работает обходной путь: опишите эффект в единицах, которые вы точно знаете. Сколько сервисов затронули изменения, сколько людей пользовалось фичей, сколько тикетов перестало приходить, сколько часов ручной работы ушло. Любая из этих единиц читается лучше, чем пустое «участвовал в разработке».
Fluxs
Комментарии (0)
Войдите, чтобы комментировать.
Пока нет комментариев. Будьте первым.