Как написать резюме для бэкенд-разработчика?

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

Обе проблемы решаемы, и решения специфичны для этой работы.

Нет квалификаций, регистраций или лицензий — говорите правду

Бэкенд-разработка в Великобритании не имеет защищенного названия, регистрирующего органа, от которого зависит найм, и лицензий. Членство в BCS и CEng существуют, но почти никогда не влияют на получение собеседования на бэкенд-позицию за пределами некоторых оборонных, железнодорожных и атомных подрядчиков. Степень в области компьютерных наук распространена, но не обязательна; стажировка Digital and Technology Solutions Professional уровня 6 и пути от буткемпов в индустрию хорошо представлены в командах, которые нанимают качественно. Если у вас пять и более лет опыта работы с продакшеном, строка о степени — это одна строка внизу, без перечисления предметов.

Вещи, которые действительно функционируют как credentials в этой области, другие:

Допуск безопасности. Допуск SC или DV — реальный барьер для бэкенд-работы в Home Office, MoD, поставщиках GCHQ и множестве консалтинговых компаний по Crown Commercial framework. Если он у вас есть, укажите его в шапке с уровнем и указанием, действителен он или истек. Если он был и истек, укажите и это — восстановить истекший допуск гораздо дешевле, чем начинать с нуля, и менеджеры по найму в этом секторе это знают.

Право на работу. Если у вас есть бессрочное разрешение на пребывание, settled status или паспорт, не требующий спонсорства, укажите это в одной строке. Работодатели, способные спонсировать, в меньшинстве, и те, кто не может, отфильтруют вас молча, а не спросят.

Опыт работы с отраслевым compliance. Работа в scope PCI DSS, продакшен-системы под регулированием FCA, NHS DSP Toolkit, HIPAA, контроли ISO 27001, которые вы реально внедрили. Это не сертификаты, которые вы получили, это ограничения, под которыми вы работали, и в найме в финтех и здравоохранении они весят больше любого сертификата. "Создавал и эксплуатировал сервисы внутри scope cardholder data environment PCI DSS" — строка, которую прочитают дважды.

На что в первую очередь смотрит менеджер по найму бэкенд-разработчиков

Примерно в таком порядке, и быстро:

1. Основной язык и рантайм с версией. Java 8 и Java 21 — это разные работы. Поддержка Python 2 и современный асинхронный Python — разные работы. Go, Kotlin, C#/.NET, Node/TypeScript, Ruby, Rust, Elixir, Scala — что бы это ни было, это должно быть видно в первой трети первой страницы, а не зарыто в блоке навыков в конце.
2. Хранилища данных. Postgres, MySQL, MongoDB, DynamoDB, Cassandra и что вы с ними делали. "PostgreSQL" само по себе ничего не говорит менеджеру. "Postgres: проектирование схемы, настройка индексов, партиционирование таблицы, переросшей производительность запросов на одном узле, миграции без даунтайма с dual-write и backfill" говорит всё.
3. Запускали ли вы системы в продакшене. Дежурства on-call, реагирование на инциденты, SLO, error budgets, постинцидентные отчеты, которые вы писали. Инженер, который только передавал код ops-команде, — это другой наём по сравнению с тем, кого будили по пейджеру из-за его собственного сервиса, и это проверяют рано.
4. Масштаб и характер трафика. Не чтобы впечатлить — чтобы понять, переносятся ли ваши инстинкты. Частота запросов, объемы данных, целевые задержки, размеры батчей, количество tenant'ов. Используйте реальные цифры. Если их нет, опишите характер: "финансовые транзакции низкого объема и высокой ценности, где корректность важнее пропускной способности" — действительно информативное предложение, и это не цифра, которую вам пришлось придумывать.
5. Обмен сообщениями и интеграция. Kafka, RabbitMQ, SQS/SNS, Pub/Sub, gRPC, REST, GraphQL, webhooks. Проектировали ли вы контракты или использовали чужие.

Всё остальное — Kubernetes, Terraform, CI-пайплайны, облачный провайдер — важно, но это второй проход. Инженеры, которые начинают со стены названий AWS-сервисов и зарывают язык, сортируют себя не в ту кучу.

Доказательства в этой области означают системы, а не обязанности

Самое большое различие между бэкенд-резюме, которое получает телефонный скрининг, и тем, которое не получает, — это различие между описанием роли и описанием системы.

Роль звучит так: "Отвечал за разработку и поддержку микросервисов в Java/Spring Boot с использованием Agile-методологий".

Система звучит так: "Владел сервисом order fulfilment: Kotlin/Spring Boot, Postgres, группа consumer'ов Kafka, обрабатывающая события от сервиса checkout. Переработал consumer, чтобы он был идемпотентным после того, как дублирующиеся доставки приводили к двойным списаниям; ввел outbox-таблицу, чтобы запись и публикация разделяли одну транзакцию".

Второй вариант едва длиннее. Он сообщает менеджеру, что вы знаете о том, что exactly-once delivery — ложь, о transactional outbox'ах и о режиме отказа, с которым вы столкнулись. Он дает интервьюеру вопрос, который можно вам задать, а это и есть настоящая цель документа.

Напишите два-три таких описания на каждую недавнюю роль. Не восемь. Выберите те, где что-то было сложным и вы можете объяснить компромисс.

Что бэкенд-разработчики регулярно упускают

Это та часть, которая стоит людям собеседований, и она постоянна.

Миграции. Декомпозиция монолита, Python 2 на 3, самоуправляемый Postgres на RDS или Aurora, on-prem в облако, REST на gRPC, один message broker на другой, повышение мажорной версии фреймворка на десятки сервисов. Инженеры упускают это, потому что это были не фичи и казалось maintenance. Менеджеры по найму оценивают это очень высоко, потому что миграционная работа — это место, где проявляются суждение, обратная совместимость, feature flags, dual-writes, backfills и планы отката. Если вы возглавляли миграцию, ей место в верхней части описания той роли.

Моделирование данных. "Проектировал схему" — предложение, которое большинство бэкенд-разработчиков могут написать правдиво, но большинство не пишут. Скажите, какие были сущности, какое было сложное ограничение и что вы сделали неправильно и пришлось изменить.

Операционная работа со стоимостью. Сокращение расходов на облако, удаление Redis-кластера, который никому не нужен, правильный размер инстансов, устранение N+1, которое било по read replica. Инженеры думают, что это негламурно. Все, у кого есть бюджет, так не считают.

Инциденты. Не для признания вины — чтобы продемонстрировать, что вы были рядом с продакшеном, когда он ломался. "Диагностировал исчерпание connection pool под скачком трафика; внедрил PgBouncer и circuit breaker на downstream-вызов" — сильная строка.

Тестирование за пределами слова 'тесты'. Контрактное тестирование между сервисами, Testcontainers, property-based тесты, нагрузочное тестирование с k6 или Gatling, как вы тестировали миграцию. "Писал unit-тесты" — шум. "Создал контрактные тесты между нашим сервисом и тремя consumer'ами, чтобы мы могли деплоить независимо" — сигнал для найма.

Форма команды и кодовой базы. Сколько инженеров, сколькими сервисами вы владели, сколько лет кодовой базе, были ли вы единственным бэкенд-разработчиком. Работать в одиночку над legacy Rails-монолитом и работать в платформенной команде из двенадцати человек — оба варианта респектабельны, и ни один не выводится из должности.

Design documents и RFC. Если вы подаетесь на senior, staff или principal уровень, оценивается масштаб принятия технических решений. Авторство design docs, против которых строили другие команды, — самое ясное доказательство этого. Скажите, сколько, на какие темы и для какой аудитории.

Секция навыков и как она обычно проваливается

Распространенный провал — список из шестидесяти технологий в одном абзаце, включая каждый AWS-сервис, для которого вы когда-либо открывали консоль. Это читается как заполнение места и делает реальную силу невидимой.

Группируйте по функциям и держите каждую группу короткой: языки, хранилища данных, обмен сообщениями, инфраструктура, observability. Уберите всё, о чем вы не хотели бы, чтобы вас спрашивали десять минут. Не ставьте годы рядом с каждым пунктом и не ставьте полоски владения или звездочки на что-либо — менеджер по разработке, читающий "Kafka ★★★☆☆", ничего не узнает и формирует мнение об авторе.

Если вы full-stack инженер, подающийся на бэкенд-роли, блок навыков — это место, где вы решаете, о чем резюме. React, Tailwind и Figma вверху приведут к тому, что вас прочитают как фронтенд-разработчика, желающего смены. Сохраните опыт фронтенда — это действительно полезный контекст — но поместите его после бэкенд-материала и опишите как то, чем он был.

Вещи, которые спорны, честно говоря

Облачные сертификации. AWS Solutions Architect Associate, GCP Professional Cloud Developer, CKA. В консалтинговых компаниях, системных интеграторах, AWS partner shops и частях публичного сектора они явно взвешиваются, иногда потому, что партнерский статус работодателя зависит от количества людей, их имеющих. В большинстве продуктовых компаний они близки к нейтральным, и несколько senior-инженеров активно их дисконтируют. Нет честного универсального ответа. Посмотрите, упоминает ли их объявление. Если да, поместите их в шапку. Если нет, одна строка внизу.

Ссылки на GitHub. Профиль из восьми tutorial-репозиториев и форкнутых dotfiles хуже, чем отсутствие ссылки. Один развернутый сервис с README, объясняющим компромиссы, или прямая ссылка на смерженный PR в проекте, который поддерживает кто-то другой, стоит многого. Давайте ссылку на конкретную вещь, а не на профиль.

Длина. Правило одной страницы — американская конвенция, которая не управляет наймом инженеров в Великобритании. Две страницы нормальны для middle-инженера, три приемлемы на staff-уровне с длинной историей, а роли старше примерно десяти лет должны сворачиваться до одной строки каждая. Фронтлоадьте в любом случае.

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

Что делать дальше

Возьмите последнее объявление о бэкенд-вакансии, на которое вы получили отказ без ответа. Выпишите четыре-пять вещей, которые оно реально запрашивает — язык, хранилище данных, message broker, масштаб, нужен ли кто-то, кто был on-call. Затем откройте резюме и засеките, сколько времени нужно, чтобы найти каждую. Если на любую из них уходит больше нескольких секунд, переместите её выше.

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

Делать это правильно для каждого объявления медленно, поэтому большинство людей перестают это делать после первой дюжины заявок; jobmarket.pro читает каждое объявление полностью и готовит заявку из одного профиля, в который нельзя добавить опыт.