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

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

Коротко:

  • Один пункт = одна мысль: что сделали и к чему это привело.
  • Начинайте с глагола действия, не с «участие» и не с «осуществлял».
  • Цифры хороши, но масштаб, надёжность и срок тоже считаются.
  • 3–6 пуль на последнюю роль. Больше — уже рассказ, его оставят на интервью.
  • Командный запуск без вашей роли почти бесполезен. Узкий честный вклад сильнее.

Почему опыт читают по диагонали

На отклик junior и middle в CIS в 2026-м смотрят быстро: роль, стек, две-три пули последней работы. Должностная инструкция на двенадцать строк не увеличивает шанс. Она прячет единственный факт, который стоило поставить первым.

Пули — не хроника спринта. Это выборка. Вы отбираете то, что стыкуется с целевой вакансией и что можете разобрать вслух за 20 секунд. Остальное живёт в голове и в Git, не в файле.

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

Формула, которая работает

Сделал X, чтобы решить Y, получилось Z. Не обязательно три придаточных в одном предложении. Обязательно три смысла.

  • X — ваше действие: собрал, перевёл, покрыл тестами, разобрал, написал, внедрил, сократил ручной шаг.
  • Y — задача или боль: таймаут отчёта, потеря писем, ручная рассылка, регресс на полдня, очередь тикетов.
  • Z — эффект: быстрее, стабильнее, меньше потерь, появился процесс, можно повторить без вас.

Пример с цифрами: «Оптимизировал запросы к БД, отчёт перестал падать по таймауту, время сборки снизилось с 40 до 12 секунд». Пример без процентов: «Перевёл рассылку с ручного процесса на очередь, отдел перестал терять письма при пиковой нагрузке».

Глагол в начале читается быстрее. «Была проведена оптимизация» — канцелярит и прячет исполнителя. «Участвовал» — прямой сигнал, что вклад неясен. Если вклад совместный, так и напишите: «вместе с бэкендом закрыл контракт формы; моя часть — валидация и состояния ошибки».

Что делать, если «просто работал»

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

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

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

Запишите черновик списком дел, потом сожмите в 3–6 пуль. Если за три месяца нечего сжать — либо роль была наблюдательная, либо вы ещё не вытащили факты. Тогда помогут тикеты, релизы, переписка в трекере, не память «ну, работал».

Типичные слабые формулировки

  • «Принимал участие в разработке» — не видно вклада.
  • «Работал с Python, Docker, Kubernetes» — это навыки, не опыт.
  • «Выполнял поручения руководителя» — нет задачи.
  • Копипаст из вакансии своей же должности или из чужого объявления.
  • «Осуществлял взаимодействие со смежными отделами» — канцелярит без факта.
  • «Улучшал производительность / качество / процессы» без того, что именно перестало болеть.
  • «Команда запустила продукт» без вашей роли.

Слабая формулировка часто прячет нормальную работу. Лечится не эпитетами, а уточнением: какой контур, какой ваш кусок, какой эффект. Если уточнить нельзя — пункт не ваш, вычеркните.

Примеры: было и стало

Backend, платежи.

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

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

Аналитик / отчёты, без «громких KPI».

Было. Построение отчётов. Работа с Excel и SQL. Взаимодействие с бизнесом. Сбор требований. Визуализация данных.

Стало. Собрал еженедельный отчёт по отказам оплаты для поддержки и продукта: вместо ручной выгрузки в понедельник отчёт приходит сам. Описал, какие статусы считать отказом — перестали спорить из разных выгрузок. SQL + таблица; дашборд в BI не успел, так и написано.

Во втором примере нет «+300% insight». Есть боль, действие, эффект и честная граница. Этого достаточно, чтобы позвать на разговор. Те же правила на учебных проектах: не «сделал интернет-магазин», а какой кусок и что можно открыть.

Когда нет цифр

Цифры врут чаще, чем их отсутствие, если их выдумали. Не пишите «ускорил на 50%», если не измеряли. Пишите наблюдаемый эффект:

  • перестали терять X;
  • процесс перестал жить в чате и лёг в тикеты;
  • релиз перестал откатываться из-за этой формы;
  • новичок проходил онбординг по чек-листу, а не «спрашивал в личке»;
  • очередь обращений разбирали в тот же день, а не «когда вспомним».

Масштаб тоже цифра без процента: 3 сервиса, 2 линии поддержки, отчёт на 12 витрин, 18 сценариев, контур с пиком в час X. Срок: «за квартал», «перед чёрной пятницей», «пока дежурил неделю». Надёжность: «инцидент не повторился», «алерт срабатывает на это падение».

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

Команда против вашего вклада

Можно писать достижения команды, если ясно, что сделали вы. «Команда запустила», без роли, почти бесполезно. Формулы:

  • «Вдвоём с QA закрыли регресс платежей; моя часть — фиксы таймаутов и тесты на вебхуки».
  • «Команда переехала на новую кассу; я вёл интеграцию статусов заказа, не кассовый UI».
  • «Собрал RFC, по нему бэкенд и мобилка согласовали контракт; реализацию API делал не я».

Приписать себе чужой запуск вскрывается одним вопросом. Узкий вклад, который можете нарисовать на доске, проходит дальше. Для open source и курсовых то же: файлы, модуль, ваши коммиты, не «проект группы».

Как сжать длинный стаж

Последние одна-две роли — подробно, 3–6 пуль. Старое — коротко: домен, стек, одна строка эффекта, если усиливает текущую цель. Десять лет поддержки 1С при цели «junior React» не заслуживают страницы. Одна строка «поддержка учёта, смены, клиенты» может закрыть дыру в годах, не занимая первый экран.

Не описывайте каждую позицию одинаково подробно. Рынок читает вас по последнему релевантному куску. Внутренние переводы внутри компании можно склеить, если роль та же, и разделить, если роль сменилась: аналитик → разработчик — это две истории.

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

Порядок пуль, даты и тип занятости

Внутри роли ставьте сильнейший факт первым, не хронологию спринта. Рекрутер может не дойти до пятой пули. Если лучшее, что вы делали, — очередь уведомлений, она не должна стоять под «участвовал в дейликах». Слабые ритуальные пункты (митинги, «работа в Agile») вычёркивайте: они не отличают вас ни от кого в пачке 2026 года.

Даты: месяц и год достаточно. «2023–н.в.» без месяца на последнем месте выглядит нормально, если роль ещё идёт. Дыры длиннее полугода не объясняйте в файле романом; коротко в профиле или на интервью. Фиктивные даты хуже честного пробела.

Тип занятости имеет смысл указать, если иначе читается неправда: штат, договор ГПХ, ИП, самозанятость, стажировка, проект. Для CIS IT это обычные формы, не пятно. Не маскируйте три месяца ГПХ под «ведущий инженер с 2024-го» без пояснения. Не раздувайте подработку на выходных до полной ставки в заголовке роли.

Третий пример, QA в штате без «громких процентов»:

Было. Тестирование функционала. Написание тест-кейсов и баг-репортов. Участие в релизах. Взаимодействие с разработчиками. Обеспечение качества продукта.

Стало. Перевёл приёмку оплаты с «потыкать на стенде» на чек-лист из 14 шагов — блокеры формы перестали уезжать в прод два релиза подряд. Баг-репорты пишу в шаблоне шаги / ожидание / факт / окружение, без «не работает, скрин». Регресс перед релизом закрываю сам по списку, а не жду, пока продукт «глянет».

Тот же принцип на подряде и на стажировке: не притворяйтесь штатом десятилетия. Напишите формат и две-четыре пули фактов. Смотрят на задачу и эффект, не на печать в трудовой. Если формат смущает площадку — это уже разговор, не повод писать воду вместо X–Y–Z.

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

Можно ли писать достижения команды?

Да, если ясно, что сделали вы. «Команда запустила», без вашей роли, почти бесполезно. Укажите свой кусок даже одной фразой.

Нужно ли описывать каждую позицию одинаково подробно?

Нет. Последние 1–2 роли — подробно. Старое — коротко, только если усиливает текущую цель или закрывает дыру в годах.

Что если NDA и нельзя называть продукт?

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

Можно ли брать формулировки из вакансии?

Слова роли и стека — да, если они правдивы. Абзац обязанностей целиком — нет. Ваш пункт должен показывать вклад, а не зеркалить объявление.

Сколько пуль на стажировку в два месяца?

Две-четыре сильные. Не раздувайте до шести, чтобы «выглядело как работа». Лучше два факта со ссылкой, чем вода.

Нужно ли писать стек в каждой пуле?

Только если он важен для этой задачи. Повтор «Python, Docker» в каждой строке вместо эффекта — слабая формулировка. Стек живёт в шапке и в блоке навыков.

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

Перепишите пять пунктов последней роли — или двух проектов, если штата не было — по формуле X–Y–Z. Если пункт нельзя объяснить вслух за 20 секунд, он слишком общий. Вычеркните «участие», «осуществлял», список технологий вместо задачи.

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