Резюме для IT: почему шаблоны не работают и что писать вместо «знаю Python»

Универсальные советы про резюме в IT работают плохо: здесь другой порядок чтения. Первым ваш текст открывает рекрутер и ищет стек, вторым — тимлид и ищет задачи, которые вы решали руками. Ни тому, ни другому не нужны «командный игрок» и «нацелен на результат». Разбираем, что писать вместо этого.

Кто и в каком порядке читает резюме разработчика

Понимание маршрута объясняет всю структуру.

• Автоматический отбор. В крупных компаниях резюме сначала проходит через систему, которая ищет совпадения по словам из вакансии. Отсюда правило: технологии называйте так же, как в объявлении, включая версии.
• Рекрутер. Смотрит верх страницы: должность, грейд, основной стек, город и формат. На этом этапе отсеивают за несовпадение по стеку, а не за скромные достижения.
• Тимлид или будущий коллега. Читает опыт и ищет ответ на один вопрос: что этот человек делал сам и насколько сложные задачи закрывал.

Значит, наверху резюме — то, что нужно первым двум, а глубина и детали задач — ниже, для третьего.

Первый экран: пять строк, которые решают

• Должность и грейд. «Backend-разработчик (middle), Python» понятнее, чем «IT-специалист» или «разработчик программного обеспечения».
• Основной стек одной строкой. Три-пять главных технологий, а не весь список, что вы когда-либо открывали.
• Формат и локация. Город, удалёнка, готовность к переезду или командировкам, часовой пояс — если работаете на зарубежную команду.
• Ссылки. GitHub, портфолио, профиль в профессиональном сообществе. Ссылка на живой код заменяет абзац описаний.
• Одна строка про масштаб. Нагрузка, размер команды, размер кодовой базы: «сервис на 5 тысяч запросов в секунду», «команда из шести человек, монолит на 400 тысяч строк».

Блок навыков: как не превратить его в свалку

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

• Группируйте. Языки, фреймворки, базы данных, инфраструктура, инструменты. Так глаз находит нужное за секунду.
• Разделяйте уровни. Отдельно то, чем работаете каждый день, отдельно то, с чем сталкивались. Честность здесь окупается: на собеседовании спросят именно про верхнюю строку.
• Не пишите то, что не готовы обсуждать. Любая технология в резюме — приглашение к вопросу о ней.
• Указывайте версии и специфику там, где они важны. «PostgreSQL, партиционирование, оптимизация запросов» точнее, чем просто «SQL».

Опыт: действие, технология, результат

Формула на каждый пункт: что сделали — чем — что изменилось. Третья часть отличает разработчика от исполнителя тикетов.

Бэкенд.

• Было: Разработка и поддержка серверной части, участие в проектировании архитектуры.
• Стало: Вынес из монолита четыре сервиса на Go, перевёл обмен на очереди Kafka. Время ответа профиля упало с 400 до 90 мс, релизы стали еженедельными вместо ежемесячных.

Фронтенд.

• Было: Вёрстка и разработка интерфейсов на React, взаимодействие с бэкендом.
• Стало: Переписал личный кабинет на React с TypeScript, внедрил разбиение бандла: первая отрисовка ускорилась с 3,4 до 1,2 секунды. Настроил тесты на Playwright, регрессии перед релизом ловятся автоматически.

Тестирование и инфраструктура.

• Было: Тестирование веб-приложений, написание тест-кейсов, работа в команде.
• Стало: Автоматизировал регресс на Python и pytest: 220 сценариев, прогон в CI за 12 минут вместо трёх дней ручной проверки. Доля багов, доехавших до продакшена, снизилась вдвое за полгода.

Если точных цифр нет, берите приблизительные и говорите об этом честно: «примерно вдвое», «около 200 сценариев». Порядок величины важнее точности до процента.

Пет-проекты, опенсорс и учебные работы

Они помогают, когда коммерческого опыта мало или вы меняете направление. Но и вредят, если оформлены плохо.

• Ссылка обязана открываться, а в репозитории должен быть внятный README: что это, зачем, как запустить.
• Опишите проект как рабочую задачу: проблема, решение, стек, что получилось.
• Три доведённых проекта лучше пятнадцати заброшенных: список из брошенных форков читается против вас.
• Вклад в чужой опенсорс указывайте конкретно: что за проект и что именно вы там сделали.

Если опыта пока нет

Резюме джуниора отличается порядком блоков, а не содержанием: наверх поднимается всё, что доказывает практику.

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

Пять ошибок, из-за которых резюме в IT не читают

• «Участвовал в разработке». Непонятно, что делали вы. Пишите от первого лица и про свою часть.
• Простыня технологий без структуры. Глаз не находит главного и уходит.
• Дизайнерский макет в две колонки с иконками. Красиво выглядит у человека и разваливается при разборе автоматикой. Простая структура надёжнее.
• Секретность вместо конкретики. «Проект под NDA, подробностей раскрыть не могу» в каждом месте работы. Раскрывать детали не нужно, но задачу, стек и масштаб описать можно почти всегда.
• Одно резюме на все вакансии. Backend и data-инженер — разные роли, и слова в них разные. Проще держать две версии, чем надеяться, что поймут.

Чек-лист перед откликом

• В заголовке есть роль и грейд, а не «IT-специалист».
• Основной стек виден в первых пяти строках.
• Ссылки на код и портфолио открываются в режиме инкогнито.
• В каждом месте работы есть хотя бы один результат с цифрой.
• Технологии названы теми же словами, что в вакансии.
• Файл сохранён в PDF с текстовым слоем: разбирается автоматикой и открывается везде одинаково.

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