IT-резюме — это не CV «обо всём хорошем». Это карточка специалиста: роль, уровень, стек, домен, доказательства. Если после первого экрана непонятно, разработчик вы, аналитик или «человек из IT», документ не работает. Рекрутер не будет собирать роль за вас из курсов и хобби.

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

Коротко:

  • Заголовок = роль на рынке, не внутренний грейд компании и не «IT-специалист».
  • Стек рядом с ролью, а не спрятанный на третьей странице.
  • Проекты и прод важнее списка курсов и сертификатов.
  • Ссылки на код, портфолио, отчёты — только если их можно открыть без квеста.
  • Уровень считывают по самостоятельности в пулях, не по слову middle в шапке.

Чем IT-резюме отличается от «общего CV»

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

В пачке 2026 года на HeadHunter, в ATS и в Telegram-откликах сравнивают не «гармоничность личности», а совпадение роли, стека и одного домена. Фото, герб вуза, шкала soft skills этому не помогают. Помогают заголовок, три результата, живая ссылка.

«IT-специалист» как должность на рынке почти не существует. Это отказ выбрать. Выберите разработку, тест, данные, поддержку, администрирование, аналитику. Затем соберите карточку под это, а не под страх упустить соседнюю вакансию. Какие роли сейчас живые, видно в каталоге; для входа — в junior-вакансиях.

Каркас для разработки, QA, аналитики, поддержки

Общее для всех: роль + стек + 3 результата на первом экране. Затем опыт по местам или проекты, если они сильнее текущей должности. Дальше навыки группами, образование внизу.

Разработка. Язык и фреймворк в шапке. Пули про фичи, инциденты, тесты, ревью, прод. GitHub с README, если можно показать. Домен: платежи, кабинеты, внутренние инструменты — одна фраза, не секретное имя.

QA. Типы тестов, платформы (web, API, mobile), как выглядят ваши отчёты, есть ли автоматизация в проде. Ссылка на папку с 2–3 лучшими баг-репортами сильнее «знания теории тест-дизайна». Не пишите Selenium, если не готовы к тестовому на нём.

Аналитика. Источники данных, SQL / Python / BI, какие решения приняли по вашим цифрам, кто потребитель отчёта. Дашборд без потребителя — учебная картинка. Лучше один отчёт, который кем-то пользовались.

Поддержка. Линии, каналы, SLA, типы эскалаций, язык, смены. Процесс тикет → уточнение → решение или эскалация. Примеры без персональных данных. Стек Zendesk/Intercom — плюс, не замена процесса.

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

Как показать уровень без наклейки грейда

Не пишите «middle», если рынок вас не так читает. Грейд компании внутри и грейд на рынке часто не совпадают. Уровень считывают по самостоятельности:

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

Junior честно показывает узкий контур и готовность к тестовому. Middle показывает, что контур можно оставить на человека на неделю. Senior в резюме — не слово, а влияние на систему и людей; если этого нет, наклейка только вредит: вас будут собеседовать «на уровень выше» и отсекать.

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

Стек, домен, ссылки

Стек рядом с ролью: «Backend, Python / Django / PostgreSQL, платежи». Домен в той же строке экономит вопрос «а чем занимались». Спрятанный на третьей странице список из сорока слов не спасает, если шапка пустая.

Ссылки: GitHub, демо, Notion/папка с отчётами, живой LinkedIn, если он не заброшен. Для разработки пустой профиль хуже нескольких сильных репозиториев. Для аналитики и поддержки достаточно рабочих артефактов без кода. Мёртвая ссылка — это уже форматная ошибка, см. ошибки в резюме.

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

Примеры первого экрана: было и стало

Разработка, три года, размытый верх.

Было. IT-специалист. Опыт работы в сфере информационных технологий. Знание современных методологий разработки. Стремление к профессиональному росту. Стек: см. ниже. Рекомендации предоставлю.

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

QA, вход, стена курса.

Было. Начинающий специалист по тестированию. Прошёл курсы A, B и C. Знаком с полным циклом разработки. Ищу компанию, которая даст шанс. Готов на офис и удалёнку. Фото прилагается.

Стало. Junior QA, ручной web. 18 сценариев и 11 баг-репортов по учебному сервису заказов, шаблон «шаги / ожидание / факт / окружение» — [ссылка]. Коммерческого стажа нет, к тестовому готов на этой неделе. Минск / UTC+3.

Оба «стало» уже можно класть в папку «поговорить». Оба «было» нельзя отнести ни к одной вакансии. В этом и есть разница IT-карточки и общего CV.

Что почти всегда стоит убрать

  • Школьные олимпиады десятилетней давности, если вы уже middle по фактам.
  • Десяток сертификатов без применения и без ссылки на работу.
  • Внутренние аббревиатуры компании без расшифровки.
  • Секретные названия, из-за которых не понять продукт.
  • Цель «реализовать потенциал в динамичной команде».
  • «IT-специалист», «инженер 2 категории», «специалист» без роли.
  • Шкалы навыков, цветовые полоски, логотипы стека картинками вместо текста.

Хобби — только если это прямой сигнал для роли (вклад в open source, модерация сообщества для поддержки). Настольный теннис уровень не показывает. Водительские права — не для продуктовой разработки.

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

Английская версия и GitHub

Если целитесь за пределы русскоязычных команд — отдельный файл на английском, не машинный слой поверх русского. Проверьте термины: role titles, stack names, «maintained» vs «was responsible for». Ошибки в названиях фреймворков отсекают быстрее слабой пули.

Русскоязычная вакансия — русское резюме. Двуязычный винегрет в одном абзаце «для солидности» не помогает. Можно держать две версии и выбирать по языку объявления.

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

Синхронизируйте имя, контакты и ссылки между PDF, GitHub и профилем на площадке. Расхождение почты и ника — лишний шаг, на котором отклик теряют.

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

Базовая версия — одна роль. Под пачку похожих объявлений меняйте заголовок, три строки профиля, порядок верхних пуль и порядок групп навыков. Не собирайте компромисс «backend + QA + support» в одной шапке.

Слова из вакансии совпадайте по фактам: если пишут FastAPI, а у вас Django — так и оставьте Django, плюс честно «касался FastAPI в учебном контуре», если это правда. Враньё по стеку на IT-собеседовании вскрывается быстрее, чем в общем HR-скрининге.

Для удалёнки в карточке сразу: пояс, формат, язык команды, что уже работали асинхронно (тикеты, RFC, статусы инцидентов). Не «хочу удалёнку». Для офиса — город и готовность к нему без романа.

Файл для площадки и файл в почту

Карточка одна по смыслу, носителей может быть два. На HeadHunter часто режет вёрстку: простой текст, кликабельные ссылки текстом, без колонок. В PDF для почты и формы компании можно чуть плотнее, но всё равно одна колонка и выделяемый текст. Не держите «красивый» PDF, который на площадке превращается в кашу, и «голый» текст, где пропал стек.

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

Третий пример, аналитика:

Было. Специалист по работе с данными. Опыт в IT. Построение гипотез. Работа с большими данными. Tableau, Power BI, Python, SQL, Excel, SAP, 1C, Jira, Scrum. Ищу интересные задачи.

Стало. Аналитик (продукт + поддержка), SQL / Python / таблицы. Еженедельный отчёт по отказам оплаты: статусы согласованы с поддержкой, выгрузка больше не собирается руками по понедельникам. Потребители — поддержка и продукт. Демо отчёта без клиентских ПДн — [ссылка].

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

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

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

Нужно ли резюме на английском?

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

GitHub обязателен?

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

Писать ли грейд junior / middle / senior?

Можно, если он совпадает с самостоятельностью в пулях и с вакансиями, на которые идёте. Нельзя как замена фактам. Неверная наклейка вредит сильнее её отсутствия.

Одно резюме на все IT-роли?

Нет. Разработка, QA, аналитика и поддержка — разные карточки. Общий файл «IT-специалист» обычно не берёт никто.

Нужно ли портфолио кроме GitHub?

Если код не показать: дашборды, отчёты, баг-репорты, примеры ответов поддержки, дизайн-кейсы. Главное — открывается и подписано, что сделали вы.

Что важнее: красивый шаблон или факты?

Факты и читаемый текст. Шаблон с колонками и иконками часто ломает ATS. Одна колонка, роль, стек, пули, ссылки — достаточный IT-формат в 2026-м.

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

Соберите одноэкранную версию: роль, стек, домен, 5 пуль, одна ссылка. Уберите «IT-специалист» и курсы без работы. Проверьте, что за 15 секунд читается профессия, а не биография.

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