Резюме для работы в IT в 2026 году проигрывает не из-за «не того шаблона». Оно проигрывает, когда за 15 секунд непонятно: на какую роль вы, что уже делали, можно ли вас позвать. Рекрутер в пачке из сотни файлов не читает биографию. Он ищет совпадение с вакансией и один-два факта, которые стоит проверить на созвоне.

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

Коротко:

  • Одна страница для junior и middle, максимум две для длинного коммерческого стажа.
  • Первый экран: роль, стек, город или таймзона, 3–5 результатов, кликабельные ссылки.
  • Опыт пишется задачами и эффектом, а не списком обязанностей из должностной инструкции.
  • Под каждую пачку похожих вакансий — своя версия верха, не один абзац «на все роли».
  • В файл попадает только то, что готовы разобрать на интервью. Остальное — шум.

Что рекрутер решает за 15 секунд

На HeadHunter, в ATS и во внутренней таблице откликов документ почти никогда не читают сверху донизу. Смотрят так:

  1. Это наша роль или человек пишет «в IT / открыт к предложениям»?
  2. Есть ли стек и домен, которые совпадают с вакансией хотя бы частично?
  3. Есть ли доказательство: результат, ссылка, понятный продукт?
  4. Можно ли быстро связаться и не сломать глаза о вёрстку?

Если заголовок, контакты и первые три пункта опыта не закрывают это — дальше часто не идут. Именно поэтому «ответственный командный игрок» наверху вреднее короткого сухого профиля. Цель резюме — попасть в правильную пачку и получить 20 минут разговора, а не рассказать жизнь.

Типичная пачка в СНГ в 2026-м: junior backend, QA, поддержка, аналитик, иногда frontend. Универсальный файл на все пять ролей проигрывает узкому. Смотреть, под какую роль вообще имеет смысл собирать документ, удобнее в каталоге вакансий, а не по ощущению «лишь бы в IT».

Рабочая структура

Держите один порядок. Рекрутер привык к нему; ломать его ради «креатива» обычно ничего не даёт.

  1. Шапка. Заголовок роли как на рынке, город или таймзона, телефон, почта, Telegram, GitHub или портфолио, LinkedIn если живой.
  2. Профиль на 3–4 строки. Что делаете, на каком стеке, в каком домене, какой масштаб. Не мечта и не «ищу дружную команду».
  3. Опыт или проекты. Для каждой позиции 3–6 пуль. Для входа без стажа этот блок — проекты и практика, не пустая строка «опыта нет».
  4. Навыки. Только то, чем готовы пользоваться на тестовом и на первой неделе. Как собрать список — в материале какие навыки указывать в IT-резюме.
  5. Образование, языки, факты. Внизу. Курсы — только если рядом есть работа, а не сертификат.

Не ставьте фото обязательным блоком. Для международного и большей части CIS IT оно не продаёт. Не ставьте «цель» отдельным романом. Не размазывайте контакты иконками без текста: ATS и копирование ломаются.

Как писать верх, который работает

Верх — это карточка роли. Его читают даже те, кто не откроет опыт. Плохой верх описывает характер. Рабочий верх описывает работу.

Плохо. Ответственный, коммуникабельный, быстро обучаюсь. Ищу работу в стабильной компании с возможностями роста. Готов к новым вызовам в сфере IT.

Лучше. Backend-разработчик, Python / Django / PostgreSQL, 3 года, платежи и биллинг. Снижал время ответа API, покрывал платёжный контур тестами, дежурил по инцидентам. Москва / UTC+3, remote. GitHub: [ссылка].

Если роль другая, верх другой. Тот же человек на QA не должен называться «IT-специалист». «IT-специалист» — это отказ рекрутера решать за вас. Каркас карточки для разработки, тестирования, аналитики и поддержки разобран в резюме IT-специалиста.

В шапке пишите роль так, как её ищут: «Junior QA (manual, web)», «Frontend, React», «Специалист поддержки, чат и почта», не внутренний грейд вроде «инженер 2 категории». Город нужен даже на удалёнке: юрисдикция, налоги, пояс. Если целитесь в европейские remote-команды, сразу укажите пояс и пересечение часов.

Опыт: формула пункта

Один пункт — одна мысль: задача, действие, эффект. «Участвовал в разработке сервиса» почти ничего не даёт. Человек не понимает, ваш это сервис или вы сидели на дейликах. Формула:

  • Что сделали вы, не «команда сделала».
  • Для кого или в каком контуре: биллинг, кабинет, поддержка, отчёты.
  • Чем кончилось: быстрее, стабильнее, меньше ручной работы, появился процесс.

Цифры желательны, но не обязательны. Масштаб, срок, надёжность, «перестали терять X» тоже считаются результатом. Подробная формула и разбор слабых глаголов — в как описать опыт в резюме. Здесь достаточно правила: если пункт нельзя объяснить вслух за 20 секунд, он слишком общий.

3–6 пуль на последнюю роль. Больше — уже рассказ, его оставят на интервью. Старые места — короче: две-три пули или одна строка с доменом и стеком, если они усиливают текущую цель.

Примеры: плохой пункт и рабочий

Ниже — не «красивый слог», а то, что можно спросить на скрининге. Берите структуру, не копируйте чужой домен.

Backend, продукт с платежами.

Было. Участвовал в разработке и поддержке существующего функционала. Работал с Python, Docker, PostgreSQL. Выполнял задачи по постановке руководителя. Участвовал в код-ревью и дейликах.

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

Junior QA без громких метрик.

Было. Тестирование веб-приложения. Написание тест-кейсов. Поиск багов. Работа в Jira. Взаимодействие с командой разработки.

Стало. Собрал 18 сценариев и 11 баг-репортов для учебного сервиса заказов в шаблоне «шаги / ожидание / факт / окружение» — [ссылка]. Ловил расхождения макета и формы оплаты до релиза, а не «кнопка некрасивая». Регресс гонял по чек-листу, а не «потыкал сайт».

Второй пример годится и для входа без коммерческого стажа: проект описан как работа, не как домашнее задание. Если коммерческого опыта нет совсем, не добивайте пустой блок «Опыт работы» водой — соберите резюме без опыта через проекты.

Навыки, образование и ссылки

Блок навыков подтверждает заголовок за пять секунд. Он не склад курса. HTML у frontend не продаёт. «Знание ПК» не продаёт никого. Пишите то, чем готовы пользоваться. Стена из тридцати строк — частая причина отказа ещё до опыта; разбор таких провалов — в ошибках в резюме.

Группируйте: языки, фреймворки, данные, инфраструктура, инструменты команды. Софт-скиллы списком не ставьте. «Командность» доказывают ревью, онбординг, разбор инцидента в опыте.

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

Ссылки должны открываться без пароля. GitHub с README: что это, как запустить, что сделано вами. Пустой профиль хуже, чем две сильные папки. Не ведите на архив из восьмидесяти файлов. Не просите «посмотреть весь аккаунт».

Формат файла и ATS

PDF подходит, если текст выделяется, ссылки кликаются, документ не является картинкой. Word ещё жив на части локальных рынков, но для IT чаще ждут PDF. Имя файла: Ivanov_Backend_Python.pdf, не resume_final_final2.

Что ломает разбор и человека:

  • Две колонки, иконки вместо слов «телефон» и «почта», текст в картинках.
  • Таблицы на всю ширину, шапка в колонтитуле, куда ATS не смотрит.
  • Нестандартные шрифты, которые превращают «C++» в крокозябры.
  • Ссылки вида «клик сюда» без URL рядом, если файл распечатают или разобьют парсером.

Одна страница — норма для входа и mid-уровня. Три страницы на три года опыта читаются как неумение выбрать. Фото, герб вуза, цветные полоски «навыки 80%» не помогают пройти отбор в продуктовую команду.

Проверьте, что файл открывается с телефона. Часть рекрутеров смотрит отклик в мессенджере. Если PDF весит 12 МБ из-за фона — сожмите.

Адаптация под вакансию

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

  • заголовок под формулировку вакансии, если она честная («QA engineer», не «супергерой качества»);
  • 3–4 строки профиля;
  • порядок и 5–8 верхних пуль опыта;
  • порядок навыков: то, что в требованиях, выше.

Слова из вакансии нужны не для SEO. Нужны, чтобы человек и ATS увидели тот же стек и те же задачи. Копировать абзац «обязанности» из объявления целиком не стоит: это видно и не показывает ваш вклад.

Один файл на backend, менеджмент и «готов на всё» — главная причина тишины. Если хотите сменить роль, соберите отдельную версию, а не компромисс, который не берёт никто. Для первой роли без стажа смотрите junior-вакансии и пишите верх уже под выбранную, а не «в IT вообще».

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

Что убрать в конец или вычеркнуть

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

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

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

Частые вопросы

Нужно ли фото?

Для международного IT и большей части продуктовых команд в СНГ — нет. Для части локальных работодателей вне разработки — по желанию, если фото нейтральное. Пользы меньше, чем от нормального опыта и рабочей ссылки. Фото не заменяет заголовок роли.

Можно ли резюме в PDF?

Да, если текст выделяется и ссылки кликаются. Картинка-PDF, колонки и таблицы на всю ширину часто ломаются в ATS и при копировании. После экспорта откройте файл и попробуйте выделить абзац.

Сколько страниц нормально?

Одна для junior и большинства middle. Две — если стаж длинный и каждая роль усиливает текущую цель. Три страницы на три года почти всегда можно сжать, убрав обязанности и курсы.

Нужна ли английская версия?

Если целитесь в англоязычные команды — да, отдельным файлом, не машинным слоем поверх русского. Термины проверяйте: «experience» не равен «экспертизе», «responsible for» снова звучит как обязанности. Русскоязычная вакансия — русское резюме.

Можно ли одно резюме на все junior-роли?

Каркас — да. Готовый файл — нет. QA, поддержка и frontend читаются как разные профессии. Одинаковый верх на все три выглядит как рассылка и обычно не работает нигде.

Что делать, если нет цифр в опыте?

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

Что сделать сейчас

Выберите одну роль, не пять. Перепишите только верх: заголовок, 3–4 строки профиля, 5 пуль последней работы или двух проектов. Сверьте, что за 15 секунд читается роль, стек и один результат. Прогоните файл через разбор резюме.

Затем откликнитесь на пять похожих вакансий с тем же заголовком, не размазывая документ на соседние профессии. Входные роли удобно смотреть в каталоге junior-вакансий, остальные — в общем каталоге Talanto. Если после правки верха всё ещё тишина, сначала уберите типичные ошибки в резюме, а не добавляйте третью страницу.