Иногда после прочтения очередного резюме разработчика хочется проверить, как там поживает российская экономика. Производительность выросла на 43%, расходы сократились на 27%, процессы ускорились на 35%. Судя по описанию, человек не просто работал в компании, а лично обеспечивал её экономическое процветание. Возможно, где-то в переговорной уже висит его портрет.

Только есть небольшая неприятность. Я понятия не имею, что он разрабатывал.

Какой продукт? Какая архитектура? С какими техническими проблемами сталкивался? Что делал самостоятельно? Зато производительность выросла. И обязательно на 43%, а не на какие-нибудь скучные 40%.

Я больше девяти лет занимаюсь IT-рекрутингом и всё чаще вижу резюме, в которых достижения описаны подробнее, чем сама работа. Причём больше всего меня удивляет не то, что кандидаты так пишут.

А то, что мы сами их этому научили.

Как карьерные советы превратились в соревнование по процентам

«Уберите обязанности, никому не интересно, чем вы занимались».

«Покажите результат».

«Добавьте цифры».

«Докажите пользу для бизнеса».

Звучит разумно. До тех пор, пока не начинаешь применять эти рекомендации буквально к каждой строчке резюме.

Представим разработчика, который пишет:

Разрабатывал backend-сервисы на Java/Spring Boot, работал с PostgreSQL, занимался интеграциями.

Карьерный эксперт объясняет, что это всего лишь обязанности. Нужно показать достижения.

После нескольких правок получаем:

Повысил эффективность backend-сервисов на 40%, обеспечив масштабируемость и отказоустойчивость системы.

Прекрасно. Технических подробностей стало меньше, зато появилась та самая эффективность.

Человек может действительно быть сильным инженером. Может, он два года разбирал сложнейшие проблемы в распределённой системе, проектировал интеграции и оптимизировал запросы. Но теперь весь этот опыт прячется за фразой, которая одинаково подходит и разработчику, и руководителю склада.

Мы хотели научить кандидатов лучше рассказывать о себе, а в результате научили их разговаривать на языке квартальных отчётов.

И как теперь отличать реальные достижения от хорошо упакованных?

Допустим, вы ускорили API на 40%. И что?

Я не против цифр. Более того, иногда они принципиально важны для понимания технического результата. Например, разработчик пишет, что ускорил API на 40%.

Хорошо. А что именно ускорилось?

Время ответа? Пропускная способность? Обработка одного конкретного запроса? И при какой нагрузке проводили измерения?

Представим два варианта.

Первый:

Повысил производительность API на 40%.

Второй:

Оптимизировал SQL-запросы в PostgreSQL, устранил N+1 и переработал индексы. p95 времени ответа API оформления заказов при сопоставимой нагрузке снизился с 800 до 480 мс.

Во втором случае уже можно обсуждать техническое решение. Почему выбрали такой способ оптимизации? Как изменился план выполнения запроса? Не ухудшилось ли потребление ресурсов? Как проверяли результат?

А в первом я даже не понимаю, о какой производительности идёт речь. Причём эти формулировки вполне могут описывать одну и ту же работу. Разница лишь в том, что вторая позволяет оценить опыт, а первая предлагает поверить в красивое число.

Здесь и далее технические ситуации и цифры условные, они используются для сравнения формулировок.

А что делать инженерам, которые ничего не ускорили?

Представим SRE-инженера, который несколько лет отвечает за production-инфраструктуру. Он сопровождает Kubernetes-кластеры, разбирает инциденты, обновляет компоненты, настраивает мониторинг и помогает командам выпускать релизы. За это время инфраструктура пережила несколько миграций. Сервис продолжает стабильно работать, серьёзных аварий удаётся избегать.

Теперь попросим инженера описать достижения в цифрах.

«Не допустил падения прода на 100%»?

«Предотвратил неизвестное количество потенциальных инцидентов»?

Можно, конечно, написать что-нибудь про стабильность и эффективность. Но, если компания не собирала соответствующие метрики или невозможно отделить личный вклад от командного, откуда брать числа? Даже когда показатели есть, они не всегда рассказывают всю историю. Допустим, доступность сервиса до прихода инженера составляла 99,95% и через два года осталась такой же.

Он ничего не улучшил?

Или за эти два года нагрузка выросла, инфраструктуру перенесли, заменили часть компонентов и удержали прежний уровень надёжности?

Одна и та же цифра может скрывать совершенно разный объём и сложность работы.

Разумеется, само по себе отсутствие аварий ещё не доказывает профессионализм инженера. Но и отсутствие красивого прироста не означает, что человек не создавал ценности. Я бы скорее обсудила с ним архитектуру, миграции, инциденты и принятые решения, чем заставляла доказывать, насколько процентов он улучшил то, что изначально работало нормально.

А если достижение вообще не ваше?

Представим продуктовую команду, которая увеличила конверсию оформления заказа на 30%. Над изменениями работали продакт, аналитик, разработчики, тестировщики и дизайнеры. Параллельно маркетинг запустил новую кампанию.

Кому записывать эти 30%?

Продакту, предложившему новый сценарий? Аналитику, который описал требования? Разработчику, реализовавшему API? Или тестировщику, благодаря которому изменения вообще удалось выпустить?

Каждый может быть причастен к результату, но это не делает каждого его единственным автором. Однако фраза «увеличил конверсию на 30%» выглядит куда привлекательнее, чем «разработал API для нового сценария оформления заказа».

А потом на собеседовании выясняется, что человек не знает, как считали конверсию, какие изменения повлияли на результат и почему вообще решил приписать его себе.

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

Как я предлагаю описывать опыт вместо выдуманных KPI

На разборах резюме я часто предлагаю довольно простой эксперимент.

Уберите из описания все проценты и слова «оптимизировал», «повысил эффективность» и «улучшил процессы».

Осталось что-то, по чему можно понять вашу квалификацию?

Если нет, описание стоит пересмотреть.

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

Например:

Backend-разработчик

Разрабатывал сервис обработки платежей на Java/Spring Boot, реализовывал REST API и интеграции с платёжными провайдерами. Отвечал за обработку ошибок, повторные запросы и доработку логики проведения транзакций.

Системный аналитик

Проектировал интеграции ERP и WMS: описывал контракты API, согласовывал форматы обмена данными, прорабатывал обработку ошибок и сценарии повторной отправки сообщений.

SRE-инженер

Сопровождал Kubernetes-инфраструктуру, участвовал в миграции сервисов между кластерами, настраивал мониторинг и процедуры отката при релизах.

Это ещё не идеальные описания. Для полноценного резюме потребуется уточнить масштаб, самостоятельность и особенности проектов. Но уже понятно, чем занимались специалисты и какие вопросы имеет смысл задавать на интервью.

Если есть подтверждённые результаты, добавляем их. Сократили latency - укажите, как измеряли. Уменьшили MTTR - объясните, за счёт чего. Успешно провели миграцию без простоя - расскажите о масштабе и собственной роли.

А если результат нельзя корректно посчитать, необязательно изобретать 37% эффективности ради того, чтобы резюме выглядело дороже.

Хотя работодатели тоже хороши

От кандидатов мы требуем технического контекста, конкретных результатов и измеримой пользы.

А потом открываем вакансию:

«Развитие высоконагруженной платформы. Работа над интересными задачами. Участие в проектировании архитектуры».

Какая платформа? Что за нагрузка? Какие архитектурные проблемы предстоит решать? Человек будет разрабатывать новые сервисы или разгребать легаси?

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

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

Так что важнее: достижения или обязанности?

Мне кажется, мы вообще неправильно поставили вопрос. Резюме должно помогать понять, насколько опыт специалиста соответствует конкретной работе. А не доказывать, что за последние три года он совершил несколько экономических чудес.

При этом я не предлагаю оправдывать плохие описания опыта. Если Senior-разработчик за восемь лет не может рассказать ни об одном сложном техническом решении, которое он принимал, вопросы совершенно справедливы. Но и считать человека сильным только потому, что у него в каждом абзаце по три процента, довольно странно.

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

А если нет, это ещё не повод считать его работу бесполезной.

И теперь мне интересно мнение технической аудитории Хабра.

Представьте двух кандидатов на одну позицию.

У первого подробно описаны архитектура, стек, сложные задачи и зона ответственности, но практически нет достижений в цифрах.

У второго впечатляющие проценты, экономия и ускорения, но почти нет технических подробностей.

Кого вы пригласите на собеседование первым?

И отдельный вопрос к тем, кто сам нанимает инженеров, а вы действительно обращаете внимание на проценты в резюме или сразу переходите к тому, что человек непосредственно делал?