Проект в резюме — не название репозитория и не «интернет-магазин на React». Рекрутер за десять секунд должен понять: для кого это было, что сделали вы, чем кончилось и где открыть доказательство. Если открывать нечего, строка «Pet-project» работает против вас: выглядит как курс без артефакта.
Ниже — формула описания, как отличать свой вклад от командного, что делать с учебными работами, два полных примера и короткий блок под GitHub. Общая рамка опыта — в как описать опыт в резюме. Если коммерческого стажа нет, проекты и есть ваш опыт: см. резюме без опыта.
Коротко:
- Один проект = задача, ваш кусок, результат, ссылка. Название репозитория — не пункт.
- Учебный проект так и подписывайте. Притворяться продом опасно на первом вопросе «кто пользователи».
- Два сильных проекта лучше семи недоделанных.
- README на 10–15 строк — часть резюме, не «потом допишу».
- Перед рассылкой сверните формулировки в разборе резюме и сверьте роль с junior-вакансиями.
Зачем блок проектов вообще
У junior блок проектов закрывает пустой стаж. У middle он показывает инициативу вне должностной инструкции или домен, которого нет на текущей работе. У senior отдельные «пет-проекты» редко нужны — если только это публичный инструмент с пользователями.
Блок не дублирует опыт один в один. Если проект сделан в рамках работы, он живёт в пулях роли. Отдельной строкой его тащат, когда иначе не видно: опенсорс, внутренний инструмент, учебный контур, фриланс без юрлица. Не тащите в блок «проекты» то, что уже подробно расписано в последнем месте работы: рекрутер решит, что коммерческого опыта мало и вы маскируете его пет-проектами. Исключение — публичный инструмент с пользователями вне работы, его можно показать отдельно как доказательство инициативы.
На собеседовании вас попросят рассказать один проект целиком. Пишите в файл только то, что готовы разобрать: сбой, ограничение, что не сделали. Как рассказывать вслух — в как рассказать о проекте на собеседовании.
В CIS-удалёнке 2026 проект ещё и заменяет «офисный вайб». Рекрутер не увидит вас у доски. Увидит ссылку. Поэтому карточка без открывающегося доказательства почти равна пустому стажу: обещание без проверки. Если NDA — схема и разбор на созвоне должны быть предложены в той же карточке, не фразой «обсудим на интервью» без содержания.
Формула карточки проекта
Шесть полей, можно уложить в 4–6 строк:
- Название и тип. «Учебный сервис заказов», «внутренний бот дежурств», «опенсорс-утилита логов». Тип честный.
- Задача. Кому и зачем. Не «практиковал React».
- Ваш вклад. Если команда — граница. «Верстка и состояния формы; API писал напарник».
- Стек — только тот, что в этом проекте, 4–8 слов. Не весь skills.
- Результат. Запуск, пользователи, закрытый сценарий, ускорение ручного шага. Без выдуманных процентов.
- Ссылка. Репозиторий, демо, папка с кейсами. Одна, открывается без пароля.
Плохо: «Project X — fullstack приложение (React, Node, Mongo, Docker, AWS)». Хорошо: «Учебный кабинет заказов: список, фильтры, форма. Моя часть — клиент и контракт ошибок. README честно пишет, что авторизации нет. Демо и репозиторий: [ссылка]».
Коммерческий, учебный, «для себя»
Коммерческий фриланс: заказчик (тип, без NDA-истерики), срок, что сдано, что на поддержке. Если NDA — схема без бренда, как в опыте.
Учебный: курс или самостоятельный. Обязательна пометка. Добавьте, чем он отличается от домашки модуля: свой скоуп, свои проверки, свой деплой. Сертификат без репозитория в этот блок не ставьте.
«Для себя»: нужен пользователь хотя бы в лице вас и одной конкретной боли. «Клонировал Twitter» почти никогда не продаёт. «Бот, который собирает смены дежурных из чата в таблицу» — продаёт, потому что задача узкая.
Волонтёрство и сообщества — проекты, если есть артефакт: регламент, бот, набор сценариев. Не «помогал людям».
Пример 1. Junior frontend, учебный кабинет
Кабинет заказов (учебный). Нужен был экран, на котором видно статусы и можно оформить возврат без звонка в поддержку.
Собрал список, фильтр по статусу, форму возврата, состояния загрузки и ошибки валидации. Стек: React, TypeScript, CSS-модули, mock API. Авторизацию и боевой бэкенд не делал — это в README.
Демо и репозиторий: [ссылки]. На созвоне могу разобрать форму и как обрабатывал пустой список.
Честная недоделка здесь плюс. Рекрутер junior-роли ищет человека, который не раздувает объём. Сравните с типичной стеной «E-commerce, Redux, Node, AWS» без демо.
Пример 2. Middle backend, внутренний инструмент
Внутренний сервис пересчёта статусов счетов. Поддержка руками правила статусы в админке и ошибалась на спорных кейсах.
Написал сервис пересчёта и идемпотентный вход с вебхука. Админку не верстал — отдал фронту контракт. Стек: Python, Postgres, очередь. Код внутренний; схема потока и примеры ошибок — в приложении к резюме / на созвоне.
Ручные правки спорных счетов ушли из ежедневной рутины поддержки. Метрику «минус N тикетов» не считали — фиксирую качественно: тип тикетов пропал из очереди.
Нет ссылки на GitHub — и это нормально, если вы предлагаете схему. Пустой «проект в банке, ничего нельзя» без схемы не работает.
GitHub, README, демо
Один репозиторий в карточке, не «посмотрите профиль». В README: что это, как запустить, что сделано вами, что не сделано, как смотреть главное. Скрин без подписи не заменяет.
Демо: публичный URL или запись на 60–90 секунд. Логин/пароль в резюме не кладите в открытый PDF, если это боевые данные. Учебный стенд — ок.
Не ведите на архив из 80 файлов. Для QA — 2–3 лучших отчёта. Для аналитика — один дашборд или SQL-тетрадь с вопросом и выводом. Портфолио аналитика отдельно разобрано в как подготовить портфолио аналитика.
Стек внутри проекта и в skills
В карточке проекта стек служит доказательством: «на этом контуре я это применял». В блоке skills — то, чем готовы пользоваться на тестовом. Если технология есть только в учебном проекте, не дублируйте её как «основное» в шапке. Раскладка — в как указать стек.
Не раздувайте карточку синонимами. React достаточен. Next.js пишите, если реально рендеринг и маршруты, не потому что «так модно в 2026».