Резюме программиста: что писать в опыте и как пройти первый отбор

Резюме разработчика смотрят быстро и по диагонали: стек, последнее место, сколько там пробыли, что конкретно делали. Тридцать секунд, и решение принято. Всё остальное читают, только если первые тридцать секунд прошли успешно.

Из этого и надо исходить.

Структура

Порядок стандартный, отклонения не помогают.

Заголовок: позиция и стек одной строкой. «Python-разработчик, FastAPI, PostgreSQL». Не «специалист по разработке программного обеспечения».

Саммари в три-четыре строки: сколько лет, на чём пишете, в какой предметке работали, что ищете.

Опыт от последнего к первому. Главный блок.

Стек: языки, фреймворки, базы, инфраструктура. Без шкал и звёздочек.

Проекты, если опыта мало.

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

Одна страница до пяти лет опыта, полторы дальше. Всё, чему больше семи лет, схлопывается в строку.

Опыт: задачи вместо обязанностей

Стандартный текст, который встречается в половине резюме:

Разработка нового функционала, исправление ошибок, участие в код-ревью, взаимодействие с командой, поддержка существующего кода.

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

Как надо:

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

Три конкретные вещи вместо пяти абстрактных. Каждая порождает вопрос на собеседовании, а это ровно то, чего вы добиваетесь.

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

Цифры, которые можно называть честно

Не «увеличил выручку на 30%», если вы писали код, а решение о запуске принимал продукт.

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

Всё это ваша работа, и всё это проверяемо в разговоре.

Стек: правило одно

Пишите только то, о чём готовы говорить двадцать минут.

Каждая строчка в блоке стека это приглашение к вопросу. Указали Kafka, спросят про гарантии доставки и партиции. Указали Kubernetes, спросят, что делали руками. Ответ «видел в проекте, но не трогал» портит впечатление сильнее, чем отсутствие строчки.

Если хочется показать широту, разделите: «в проде использовал» и «пробовал на пет-проектах». Честно и снимает лишние ожидания.

Пет-проекты и опыт без коммерции

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

Слабый проект: очередной todo-лист по туториалу.

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

Обязательно ссылка на репозиторий, а в нём README на русском или английском: зачем эта штука, как запустить, что внутри. Половина ссылок в резюме ведёт на репозиторий без единого пояснения, и туда никто не заходит второй раз.

Что отсеивает на скрининге

Отсутствие стека в начале. Рекрутер ищет ключевые слова первым делом. Не нашёл, закрыл.

Общие фразы про личные качества. Стрессоустойчивость и нацеленность на результат не проверяются, поэтому пропускаются.

Простыня без форматирования. Абзац на пятнадцать строк не читают.

Дыры в датах без объяснения. Год перерыва нормален, попытка его скрыть подозрительна.

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

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

Про адаптацию под вакансию

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

Если в вакансии асинхронный Python и очереди, а у вас это есть, но упомянуто в четвёртом пункте третьего места работы, поднимите наверх. Тот же опыт, другой порядок, совсем другой шанс дойти до интервью.

Проверка перед отправкой

Три теста.

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

Откройте вакансию рядом и сверьте ключевые слова. Не для обмана фильтров, а чтобы не потерять то, что у вас реально есть.

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

Дальше начинается техническая часть

Резюме доводит до собеседования, а там всё решают ответы на вопросы про GIL, транзакции, N+1, устройство HashMap или гарантии доставки, в зависимости от вашего стека.

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