Гайд по резюме

Как написать резюме junior-разработчика, если опыта нет, а есть pet-проекты

Если коммерческого опыта нет, центр резюме смещается в раздел "Проекты". Для junior-разработчика важны не десять сырых репозиториев, а 2-3 понятных кейса с задачей, стеком, вашим вкладом и ссылкой на GitHub или демо. Хорошее резюме показывает, что вы уже умеете решать рабочие задачи, пусть пока и вне коммерческой команды.

На что смотреть в примерах

На что смотреть в примерах

Для junior-кандидата отсутствие коммерческого опыта само по себе не является стоп-фактором. На первом просмотре рекрутер ищет не трудовую книжку, а признаки того, что вы уже умеете работать с задачей, стеком и собственной ответственностью.

  • У репозиториев понятные названия, а не final-final-new.
  • Есть README с описанием проекта, стека и инструкцией запуска.
  • Нет битых ссылок на демо, API или скриншоты.
Разбор

Что хочет увидеть HR, если опыта работы нет

Для junior-кандидата отсутствие коммерческого опыта само по себе не является стоп-фактором. На первом просмотре рекрутер ищет не трудовую книжку, а признаки того, что вы уже умеете работать с задачей, стеком и собственной ответственностью.

  1. Понятную цель: на какую роль вы идёте и в каком стеке ищете работу.
  2. 2-3 проекта, которые можно быстро проверить по описанию и ссылкам.
  3. Аккуратный GitHub: понятные названия репозиториев, README, рабочие ссылки.
  4. Логику роста: курсы, самостоятельная практика, хакатоны, стажировки или open source.
Диагностика

Проверьте себя по чеклисту

  • У репозиториев понятные названия, а не final-final-new.
  • Есть README с описанием проекта, стека и инструкцией запуска.
  • Нет битых ссылок на демо, API или скриншоты.
  • Коммиты выглядят живыми, а не одним массовым заливом в последний день.
  • Публичные репозитории не содержат ключей, мусорных файлов и случайных черновиков.

Что хочет увидеть HR, если опыта работы нет

Для junior-кандидата отсутствие коммерческого опыта само по себе не является стоп-фактором. На первом просмотре рекрутер ищет не трудовую книжку, а признаки того, что вы уже умеете работать с задачей, стеком и собственной ответственностью.

  • Понятную цель: на какую роль вы идёте и в каком стеке ищете работу.
  • 2-3 проекта, которые можно быстро проверить по описанию и ссылкам.
  • Аккуратный GitHub: понятные названия репозиториев, README, рабочие ссылки.
  • Логику роста: курсы, самостоятельная практика, хакатоны, стажировки или open source.

Соберите резюме из 5 рабочих разделов

Не пытайтесь имитировать большой опыт. Для junior-резюме важнее структура и доказуемость каждого блока.

  • Раздел 1. Контакты и ссылки: email, телефон, GitHub, LinkedIn, портфолио или демо.
  • Раздел 2. Summary на 2-3 предложения: роль, стек, тип задач, которые вы уже делали в проектах.
  • Раздел 3. Навыки: языки, фреймворки, базы данных, инструменты и то, что действительно используете.
  • Раздел 4. Проекты: 2-3 pet-проекта как главный заменитель коммерческого опыта.
  • Раздел 5. Образование, курсы, стажировки, хакатоны или иные подтверждения обучения.

Как выбрать pet-проекты для резюме

В резюме побеждает не самый красивый список, а самый понятный. Лучше два законченных проекта, чем семь случайных репозиториев без контекста.

  • Оставьте проекты, которые совпадают с вакансией по стеку или типу задач.
  • Выбирайте кейсы, где вы можете объяснить архитектуру, решения и свой личный вклад.
  • Если проект командный, прямо пишите, за что отвечали именно вы.
  • Если проект не закончен, показывайте завершённый кусок: авторизацию, CRUD, тесты, деплой или документацию API.

Слабое и сильное описание backend pet-проекта

Описание проекта должно отвечать на четыре вопроса: что это, на чём сделано, что сделали именно вы и где это посмотреть.

  • Слабо: "Сделал API на Python и PostgreSQL. Есть авторизация. Код на GitHub."
  • Почему слабо: неясно, какую задачу решает проект, что именно реализовано и чем он отличается от учебной заготовки.
  • Сильнее: "Task Tracker API | Python, FastAPI, PostgreSQL, Docker. Реализовал REST API для управления задачами, JWT-авторизацию, фильтрацию, пагинацию и Docker-сборку. Добавил README с локальным запуском и примерами запросов. GitHub: [ссылка]."
  • Почему работает: видны задача, стек, функциональность и уровень самостоятельности.

Слабое и сильное описание frontend pet-проекта

Frontend-проект тоже должен выглядеть как решённая продуктовая задача, а не как список библиотек.

  • Слабо: "Сделал сайт на React. Есть адаптив. Использовал Redux."
  • Почему слабо: описание не показывает сценарий пользователя, объём вашей работы и итоговый результат.
  • Сильнее: "Movie Finder SPA | React, TypeScript, Redux Toolkit. Собрал интерфейс поиска фильмов с авторизацией, фильтрами, сохранением избранного и загрузкой данных из внешнего API. Настроил роутинг, обработку ошибок и деплой на Vercel. Демо и код: [ссылки]."
  • Почему работает: у проекта появляется продуктовая логика, а у кандидата - понятный вклад.

Что проверить в GitHub и ссылках

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

  • У репозиториев понятные названия, а не final-final-new.
  • Есть README с описанием проекта, стека и инструкцией запуска.
  • Нет битых ссылок на демо, API или скриншоты.
  • Коммиты выглядят живыми, а не одним массовым заливом в последний день.
  • Публичные репозитории не содержат ключей, мусорных файлов и случайных черновиков.

Ошибки, из-за которых pet-проекты не засчитываются

Обычно проблема не в том, что проектов мало, а в том, что по ним невозможно быстро понять уровень кандидата.

  • В резюме перечислены только технологии без задачи и результата.
  • Проектов слишком много, но ни один не разобран нормально.
  • Нет ссылок на GitHub, демо или хотя бы внятного README.
  • В описании смешаны командный результат и личный вклад без разграничения.
  • Summary и проекты не совпадают с вакансией: например, ищете backend, а показываете только лендинги.

Что сделать перед первым откликом

Перед отправкой резюме соберите одну убедительную версию под конкретный тип роли, а не универсальный документ на все случаи.

  • Под каждую роль переставляйте проекты так, чтобы самый релевантный стоял первым.
  • Синхронизируйте формулировки в резюме, GitHub и отклике: стек и задачи не должны расходиться.
  • Попросите кого-то из рынка быстро прочитать резюме и сказать, что он понял о вашем уровне за 30 секунд.
  • Если сомневаетесь в качестве упаковки, отправьте резюме на HR-ревью до массовых откликов.
Ошибки

Что чаще всего ломает результат

  • В резюме перечислены только технологии без задачи и результата.
  • Проектов слишком много, но ни один не разобран нормально.
  • Нет ссылок на GitHub, демо или хотя бы внятного README.
  • В описании смешаны командный результат и личный вклад без разграничения.
  • Summary и проекты не совпадают с вакансией: например, ищете backend, а показываете только лендинги.
План

Что делать по шагам

Соберите резюме из 5 рабочих разделов

  • Раздел 1. Контакты и ссылки: email, телефон, GitHub, LinkedIn, портфолио или демо.
  • Раздел 2. Summary на 2-3 предложения: роль, стек, тип задач, которые вы уже делали в проектах.
  • Раздел 3. Навыки: языки, фреймворки, базы данных, инструменты и то, что действительно используете.
  • Раздел 4. Проекты: 2-3 pet-проекта как главный заменитель коммерческого опыта.
  • Раздел 5. Образование, курсы, стажировки, хакатоны или иные подтверждения обучения.

Что сделать перед первым откликом

  • Под каждую роль переставляйте проекты так, чтобы самый релевантный стоял первым.
  • Синхронизируйте формулировки в резюме, GitHub и отклике: стек и задачи не должны расходиться.
  • Попросите кого-то из рынка быстро прочитать резюме и сказать, что он понял о вашем уровне за 30 секунд.
  • Если сомневаетесь в качестве упаковки, отправьте резюме на HR-ревью до массовых откликов.
FAQ

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

Сколько pet-проектов достаточно для junior-резюме?

Обычно хватает 2-3 проектов. Лучше меньше, но с сильным описанием, ссылками и понятным вкладом, чем длинный список без деталей.

Можно ли указывать учебные проекты?

Да, если они оформлены как реальные кейсы: есть задача, стек, ваш вклад и ссылка на код. Учебное происхождение само по себе не мешает.

Что делать, если проект не завершён?

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

Нужен ли раздел "Опыт работы", если коммерческого опыта нет?

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

Можно ли обойтись без GitHub?

Технически да, но шансы ниже. Для junior-разработчика GitHub или хотя бы рабочее демо - это главное подтверждение того, что навыки не только на словах.

Связанные материалы