Резюме Python-разработчика: проекты вместо стека

Резюме Python-разработчика часто превращается в список библиотек: «Python, Django, Flask, FastAPI, pandas, NumPy, Docker, Kubernetes». За таким перечнем не видно, что человек умеет на самом деле, — а нанимающий тимлид ищет именно результат кода. На первичный просмотр резюме уходит всего несколько секунд, и за это время должно читаться, на чём вы пишете, в каком направлении и что уже сделали.

Резюме Python-разработчика оценивают по коду и результатам, а не по длине списка технологий: за первые секунды тимлид считывает уклон и уровень, а потом решает, открывать ли GitHub. Что он ищет:

• Уклон. Backend, Data или ML — под каждый свой стек и свои результаты; «Python на всё» читается как отсутствие специализации.
• Результат, а не задачи. «Ускорил обработку данных в 5 раз» весит больше, чем «писал скрипты на Python».
• Живой код. Ссылка на GitHub с рабочими проектами и тестами для junior заменяет опыт.
• Стек под вакансию. Названия инструментов, как в описании вакансии, — их читает и человек, и ATS.
• Уровень. Junior подтверждают проектами, middle и senior — масштабом систем и зоной ответственности.

Дальше — как собрать резюме, чтобы эти сигналы читались с первого экрана.

Резюме держится на шести блоках, порядок — от сильного к второстепенному:

1. Должность и контакты. Конкретно: «Python-разработчик (backend)», а не «программист»; город, Telegram, почта и ссылка на GitHub прямо в шапке.
2. Саммари. Три-четыре строки: уклон, ключевой стек, 1–2 результата и цель.
3. Навыки. Сгруппированы по категориям, названиями из вакансии, без шкал-процентов.
4. Опыт. Строки-результаты: что ускорили, автоматизировали, починили — с метрикой и стеком.
5. Проекты и GitHub. Для junior — ключевой блок вместо опыта; для middle+ — пет-проекты и open-source как дополнение.
6. Образование и курсы. Ниже опыта; курсы — релевантные, за последние 2–3 года.

Разберём блоки, которые решают исход, — навыки, опыт и проекты.

Раздел навыков читают буквально, поэтому его собирают под конкретную вакансию и уклон, а не как опись всего, что вы видели. Ядро одинаковое (Python, Git, SQL, API, тестирование через pytest), а дальше расходится по направлению. Три правила:

• Группируйте по смыслу — язык и инструменты, базы и хранилища, инфраструктура, профильное направление.
• Пишите как в вакансии. «FastAPI», «PostgreSQL», «Docker», а не «веб-фреймворки» — знакомые термины ищет и наниматель, и ATS.
• Не приписывайте лишнего. Библиотеку, которую видели в туториале, на интервью разберут первым вопросом.

Указывайте названия как в вакансии — совпадение терминов помогает пройти автоматический отбор (ATS), который отсеивает резюме без нужных ключевых слов.

Это блок, где резюме выигрывает или проваливается. Большинство пишет, что делал, — а наниматель ищет, что изменилось благодаря коду. «Разрабатывал backend» — процесс. «Ускорил ответ API с 800 до 120 мс за счёт кеширования и индексов» — результат, и такие строки дочитывают.

Собирайте каждую строку по формуле глагол + метрика + стек, опираясь на измеримое: скорость, нагрузку, объём данных, покрытие тестами, сэкономленное время.

Цифры в примерах иллюстративные — подставьте свои реальные. Резюме с измеримыми результатами получает больше откликов: на первичном отборе наниматель ищет именно конкретный результат, а не перечень задач. Держите 3–5 таких строк на место работы. Как превратить задачу в строку-результат, разобрано в статье как описать достижения в резюме.

Пет-проекты и GitHub закрывают отсутствие коммерческого опыта живым кодом — для junior это часто главный блок резюме. Показывайте не количество, а доведённость: 2–3 рабочих проекта под целевой уклон сильнее десятка набросков.

• README для каждого проекта — что делает, как запустить, какой стек.
• Результат вместо описания — «Telegram-бот: 300 пользователей, покрыт тестами», а не «бот на Python».
• Чистая история коммитов — видно, что вы пишете код, а не залили одну папку.
• Ссылка в шапке — GitHub рядом с контактами, а не в конце.

Заброшенный профиль с одним форком лучше не прикладывать: пустой GitHub работает против кандидата. Как оформить проекты витриной, разобрано в статье портфолио к резюме.

Один и тот же Python в разных ролях требует разного резюме. Не смешивайте направления в одном резюме — под каждую вакансию выносите вперёд свой стек и свои результаты.

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

Свой код мы оцениваем мягче, чем сделал бы наниматель. Анализ резюме с ИИ в Сопроводе за 45 секунд проходит по 10 критериям и показывает, где стоит стек вместо результата, где навык не подтверждён проектом и где формулировки расходятся с языком вакансии, — и подсказывает, что усилить. Проверка идёт по фиксированному набору критериев, поэтому результат воспроизводимый, в отличие от разового ответа чата. Факты и цифры подставляете вы: сервис находит разрыв, но не выдумывает за вас проекты. Как собрать сильную базовую структуру, показано в общем разборе резюме разработчика.

1. Должность названа с уклоном (backend / Data / ML), как в вакансии?
2. Саммари за три строки называет уклон, ключевой стек и главный результат?
3. Навыки сгруппированы под вакансию, без библиотек «для объёма»?
4. В каждой строке опыта есть метрика и стек, а не список задач?
5. GitHub со ссылкой в шапке и 2–3 закреплёнными проектами с README?
6. Сможете на интервью объяснить любую технологию и любую цифру из резюме?

Если хотя бы один ответ «нет» — доведите этот пункт прежде, чем откликаться.

• Хабр (hh.ru): идеальное резюме разработчика
• Практикум: как составить резюме разработчику
• Т—Ж: как описать достижения в резюме