Fullstack-резюме часто выглядит слабее узкого backend или frontend: полстраницы стека, ни одной глубокой задачи. Рекрутер не понимает, с какой стороны вас сажать в первую неделю, и откладывает файл «на потом». «Потом» обычно не наступает.
Этот материал про выбор главной стороны и честную ширину. Не про то, что fullstack «не существует». Про то, как в CIS IT 2026 показать, что вы закрываете вертикаль фичи — и при этом не врать, что одинаково сильны в Kubernetes и в анимации. Каркас файла — в как составить резюме. Сравнение с узкими ролями — в резюме backend и резюме frontend.
Коротко:
- Выберите основную сторону: API или интерфейс. Вторая — подтверждающая, не равная.
- Одна фича целиком сильнее десяти названий фреймворков с обеих сторон.
- Стек режьте. Fullstack-стек из двадцати пунктов читается как курс.
- Не маскируйте junior frontend под «fullstack», если бэкенд — учебный CRUD.
- Перед рассылкой сверните файл через разбор резюме и три объявления из вакансий fullstack.
Почему fullstack-CV часто проигрывает
Узкий backend приносит 4 сильные пули про API, данные, ошибки, деплой своей части. Fullstack без дисциплины приносит «делал фронт и бэк на React, Node, Postgres, Docker, AWS, Next, Nest, Redis…». Глазу не за что зацепиться. На скрининге спросят случайный пункт с конца — и доверие к ширине падает.
Команды, которые пишут fullstack в заголовке, всё равно держат в голове вопрос: вы ближе к продуктовому UI или к сервисам? Если файл не отвечает, вас сравнивают с двумя узкими кандидатами сразу и вы проигрываете обоим.
В 2026-м генераторы усугубляют это: симметричный «полный стек» на полстраницы. Короткий честный контур одной фичи проходит дальше. Как не убить отбор форматом — в ошибках в резюме.
Отдельно проигрывает «fullstack на все языки»: Java в прошлом месте, Node в учебном, Go в wish-листе вакансии. Выберите линию откликов. Вторую линию — вторым файлом. Иначе ATS найдёт все слова, а человек не поймёт, на каком языке вас сажать в понедельник. Для удалённых CIS-команд это критично: онбординг короткий, первой задачей почти всегда будет конкретный репозиторий, не «любая сторона».
Выберите главную сторону
Правило: 70/30 в тексте, не в душе. Посчитайте последние полгода по задачам. Больше ревью, багов и деплоя на какой стороне? Туда заголовок.
- Frontend-leaning fullstack: заголовок «Fullstack (акцент frontend), React / Node». Верхние пули — интерфейс, состояния, контракт с API. Бэкенд — эндпоинты, которые вы сами держали.
- Backend-leaning fullstack: «Fullstack (акцент backend), API и админки». Верхние пули — сервис, данные, ошибки. Фронт — формы и кабинет, которые вы доводили до прода.
- Продуктовый вертикальный: одна доменная фича (биллинг, кабинет заказов, онбординг). Тогда fullstack честный: вы реально возили слой целиком.
Если обе стороны учебные и симметрично слабые, вы не fullstack. Вы junior с двумя курсами. Соберите одно доказательство глубины — см. резюме без опыта — и не раздувайте титул. Как входят в роль с нуля — в как стать fullstack-разработчиком.
Формула пункта опыта
Сделал вертикальный кусок: UI + API + что увидели пользователи или смежная команда. Не «работал с React и Express».
Шаблон: «Собрал [фича]. На клиенте — [состояние / форма / список]. На сервере — [эндпоинт / проверка / хранение]. Результат — [запуск, меньше ручных шагов, меньше ошибок ввода]».
Вторая пуля той же роли может быть уже узкой: только перф списка или только идемпотентность оплаты. Так вы показываете глубину, не только ширину. Общая формула X→Y→Z — в как описать опыт.
Пет-проекты описывайте как продукты с границей: что в проде, чего нет. Репозиторий «интернет-магазин» без README и без честной недоделки вредит сильнее отсутствия ссылки. Как упаковать — в как описывать проекты в резюме.
Пример 1. Frontend-leaning, продукт
Вакансия: fullstack, кабинет клиента, React, простой Node/Postgres, не микросервисы.
Fullstack-разработчик, акцент frontend. Кабинеты и формы, API на Node, Postgres. 3 года, удалённо.
Собрал кабинет заказов: фильтры, статусы, форма возврата. На клиенте — состояния загрузки и ошибок, чтобы поддержку не дёргали «кнопка не нажимается». На сервере — эндпоинты статусов и идемпотентный возврат, чтобы двойной клик не плодил заявки. Запуск на проде, поддержка перестала эскалировать этот сценарий как «баг фронта».
Инфраструктуру k8s не администрировал: деплой через существующий CI. Redis — кэш сессии, не кластер. Готов разобрать форму возврата и контракт API на созвоне.
Ширина есть, но она подчинена фиче. Ограничения названы до вопросов. Это сильнее стены из Docker/K8s/AWS «на всякий случай».
Пример 2. Backend-leaning, B2B
Вакансия: fullstack в B2B, сложнее API, админка на React «чтобы закрывать экраны».
Fullstack (акцент backend). API биллинга и внутренняя админка. Python/Django, React по необходимости.
Держал API счетов: пересчёт статуса оплаты, вебхук провайдера, повтор без дублей. Админку счетов верстал сам: список, фильтр по статусу, ручной пересчёт. Фронт не витрина — рабочий инструмент поддержки, без анимаций.
TypeScript на клиенте базовый. Сложный UI-kit и дизайн-систему не собирал. Ищу роли, где ценность в доменном API и простой админке, не в графике.
Такой файл отсекает вакансии «сильный React» и усиливает те, где fullstack = закрыть экран вокруг сервиса. Это и есть честная ширина.
Стек без каши
Три корзины, не алфавит:
- Основное — язык и фреймворк главной стороны, БД, Git.
- Вторая сторона — 3–5 пунктов, которыми закрываете вертикаль.
- Поставка — Docker/CI, если сами собирали пайплайн, не «в команде было».
Не дублируйте React, React.js, ReactJS. Не пишите HTML/CSS отдельной гордостью, если вы middle frontend-leaning: ожидаемо. Продаёт специфика: формы, доступность, контракт ошибок, фоновые джобы. Раскладка по местам файла — в как указать стек. Общие правила блока skills — в навыках в IT-резюме.
Summary: кто, главная сторона, одна фича, формат. Не «полный цикл разработки». Формула — в summary в резюме.