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

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

Коротко:

  • Один проект = задача, ваш кусок, результат, ссылка. Название репозитория — не пункт.
  • Учебный проект так и подписывайте. Притворяться продом опасно на первом вопросе «кто пользователи».
  • Два сильных проекта лучше семи недоделанных.
  • README на 10–15 строк — часть резюме, не «потом допишу».
  • Перед рассылкой сверните формулировки в разборе резюме и сверьте роль с junior-вакансиями.

Зачем блок проектов вообще

У junior блок проектов закрывает пустой стаж. У middle он показывает инициативу вне должностной инструкции или домен, которого нет на текущей работе. У senior отдельные «пет-проекты» редко нужны — если только это публичный инструмент с пользователями.

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

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

В CIS-удалёнке 2026 проект ещё и заменяет «офисный вайб». Рекрутер не увидит вас у доски. Увидит ссылку. Поэтому карточка без открывающегося доказательства почти равна пустому стажу: обещание без проверки. Если NDA — схема и разбор на созвоне должны быть предложены в той же карточке, не фразой «обсудим на интервью» без содержания.

Формула карточки проекта

Шесть полей, можно уложить в 4–6 строк:

  1. Название и тип. «Учебный сервис заказов», «внутренний бот дежурств», «опенсорс-утилита логов». Тип честный.
  2. Задача. Кому и зачем. Не «практиковал React».
  3. Ваш вклад. Если команда — граница. «Верстка и состояния формы; API писал напарник».
  4. Стек — только тот, что в этом проекте, 4–8 слов. Не весь skills.
  5. Результат. Запуск, пользователи, закрытый сценарий, ускорение ручного шага. Без выдуманных процентов.
  6. Ссылка. Репозиторий, демо, папка с кейсами. Одна, открывается без пароля.

Плохо: «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».

Сколько проектов и в каком порядке

Два-четыре. Первый — самый релевантный вакансии, не самый любимый. Старые учебные CRUD после сильного рабочего инструмента можно убрать. Любимый пет-проект про игры не обязан быть первым, если вы ищете кабинеты B2B: релевантность сильнее привязанности.

Порядок: релевантность, затем свежесть, затем доказуемость (ссылка). Командный хакатон без вашей границы вклада — вниз или вон.

Перед/после и что спросят на созвоне

Карточка проекта должна выдерживать три вопроса: кто пользователи, что делали вы, что сломается, если нажать сюда. Если на любой из них ответ «ну, это учебное, как в курсе» — либо доработайте скоуп, либо уберите карточку. Учебное не стыдно. Учебное без своего решения стыдно в файле, который конкурирует с людьми со ссылкой. Доработка на 3–5 вечеров: один свой сценарий, одна честная недоделка, один запуск. Это обычно выгоднее, чем описывать семь клонов туториала.

Перед/после:

Было: «Pet-project: E-commerce (React, Redux, Node, Express, MongoDB, Docker, AWS). Полноценный интернет-магазин».

Стало: «Учебный каталог товаров: список, фильтр, корзина в памяти. Моя часть — клиент и валидация количества. Оплаты, аккаунтов и деплоя в облако нет — в README явно. Демо: [ссылка]».

Вторая версия короче и сильнее. Первая разваливается вопросом «как проводили платёж». Рекрутеры CIS в 2026-м этот вопрос задают часто: слишком много сгенерированных «магазинов».

Если проект командный, заранее напишите границу вклада так, чтобы напарник на том же созвоне не рассказал обратное. «Вместе делали» без разреза — риск. «Я — форма и состояния, напарник — API» — норма.

Фриланс без договора тоже проект, если есть сдача: скрины согласованного ТЗ, список принятых экранов, срок. Не выдумывайте ООО заказчика. Тип: «небольшой магазин, лендинг+форма, 3 недели, правки после сдачи две» — этого достаточно.

Для QA и аналитика те же правила: артефакт, не название. Папка кейсов, SQL-тетрадь с вопросом и выводом. Не «портфолио из 40 дашбордов». Один сильный разбор лучше. Аналитический угол — в портфолио аналитика.

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

Если проектов много и опыта мало, файл всё равно должен начинаться с роли и summary, не с GitHub-ленты. Каркас — в как составить резюме и summary.

Типичные провалы

  • Название репозитория латиницей без задачи.
  • Клон туториала без пометки и без своего скоупа.
  • «Командный проект» без границы вклада.
  • Ссылка, которая просит доступ или отдаёт 404.
  • Стек на 15 пунктов при трёх экранах.
  • Проценты пользователей, которых не было.

Формат всего файла — без колонок, которые ломают ATS. См. ошибки в резюме и как пройти ATS.

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

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

Нет. Выберите 2–3. Остальное пусть лежит в профиле без обещания в CV. Случайный форк туториала в файле вредит.

Можно ли писать курсовой, если он на Java, а вы ищете Python?

Только если показываете переносимый кусок: модель данных, тесты, деплой. Иначе он занимает место и путает заголовок. Лучше маленький релевантный контур за неделю.

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

Починить или убрать ссылку. Мёртвый README с «npm start» без lock-файла проверяют чаще, чем кажется. Лучше статическое демо.

Командный хакатон — это проект?

Да, с границей вклада и ссылкой на ваш кусок. «Мы за 48 часов сделали стартап» без роли — нет.

Стоит ли писать незавершённый проект?

Да, если честно указан скоуп «сделано / не сделано» и есть что разобрать. Нет, если это кладбище начал и бросил.

Нужно ли сопроводительное, если проекты сильные?

Короткое — да: укажите один проект под вакансию. Каркас — в сопроводительном письме. Для поля комментария хватит 4–6 строк.

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

Выберите один проект под одну роль. Заполните шесть полей формулы, напишите README, проверьте, что ссылка открывается в инкогнито. Уберите из CV остальные репозитории-заглушки. Если README длиннее резюме, сократите его: человеку нужно понять запуск и границу вклада, не историю всех коммитов.

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