Портфолио на GitHub для junior-разработчика

Портфолио на GitHub делает за junior-разработчика то, чего не может резюме: показывает, что код существует и написан руками. Обычно оно с этой задачей не справляется. Не потому что человек плохо пишет, а потому что в закрепе висят три учебных проекта из одного курса и обсуждать по ним нечего. Ниже про то, какие проекты добавить в портфолио, как его структурировать, что включить обязательно и как выглядит профиль, после которого зовут на разговор. Оформление самого профиля (шапка, README, коммиты) вынесено в отдельную статью, здесь речь про состав портфолио.

Зачем нанимающему ваше портфолио

Тимлид открывает портфолио не ради красоты кода. Он проверяет две вещи: можно ли по этому проекту задать вопрос на собеседовании и доводит ли человек начатое до состояния «работает».

Отсюда следует критерий отбора проектов. Хорош не тот, который сложнее, а тот, где вы принимали решения и можете их объяснить. Проект, собранный по видеоинструкции, бесполезен на интервью с обеих сторон: интервьюеру нечего спросить, кандидату нечего рассказать. Формально портфолио есть, в найме оно не участвует.

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

Какие проекты добавить в портфолио на GitHub

Типы проектов, которые дают материал для разговора. Собирать все не нужно, хватит трёх под ваш стек.

1. Сервис с внешним API и собственной логикой

Приложение, которое ходит в чужой API, что-то с данными делает и отдаёт результат: агрегатор объявлений, трекер цен, бот со свежим расписанием. Ценность - в решениях, которые приходится принимать самому. Что делать, когда внешний сервис отвечает ошибкой. Как не выгребать одно и то же по десять раз. Где хранить промежуточные данные. Про это и спрашивают.

2. Проект с авторизацией и ролями

Регистрация, сессии, разграничение доступа. Здесь джуны ошибаются предсказуемо, поэтому область любят проверять. Если вы сами разбирались с токенами, хранением паролей и правами доступа, на вопросы по безопасности вы отвечаете из практики, а не из статьи.

3. Что-то на реальных данных

Проект на настоящем датасете или живом источнике отличается от учебного тем, что в данных бывает мусор. Пропуски, дубликаты, внезапно сменившийся формат. Обработка этого и есть работа. В README видно, что автор столкнулся с реальностью, а не с идеальным примером из методички.

4. Инструмент, которым вы сами пользуетесь

Скрипт, CLI или маленький сервис под собственную боль. Такие проекты почти всегда дописаны до конца, потому что нужны автору, и про них хорошо рассказывать: есть история, зачем это вообще появилось. Размер тут не важен - важна законченность.

5. Вклад в чужой проект

Принятый pull request в открытый репозиторий показывает то, чего не покажет ни один свой проект: вы способны разобраться в незнакомой кодовой базе и играть по её правилам. Это ближе всего к первым неделям на работе. Не обязательно, но выделяет сильно.

В портфолио не идут todo-лист, калькулятор, клон лендинга и проект «как в уроке» без единого своего решения. Где проходит граница между настоящим проектом и туториалом, разобрано в статье про пет-проекты в резюме. Конкретные идеи под стек есть в подборках для junior frontend и junior backend.

Как структурировать портфолио

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

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

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

Имена репозиториев - человеческие. price-tracker понятно с первого взгляда, project2 и test-app - нет. Имя попадает в ссылку, которую вы вставляете в резюме, и работает как заголовок.

Описание у каждого репозитория. Строка description под названием остаётся единственным, что видно в списке. Не оставляйте её пустой.

Внутри проекта - понятная структура папок и рабочий запуск. Никто не будет чинить ваш проект, чтобы его посмотреть. Не поднимается по инструкции из README - значит, дальше README дело не пойдёт.

Разные стеки - в разные репозитории. Монорепозиторий «мои работы» с пятью несвязанными папками читается как свалка.

Что включить обязательно

Минимум, без которого проект не считается показанным:

Усиливают, но не обязательны: тесты (даже пара штук показывает, что вы про них знаете), CI с прогоном линтера, Dockerfile, пара абзацев в README о том, почему сделано именно так. Последнее недооценивают зря: два предложения про архитектурное решение превращают репозиторий в тему для разговора.

Пример: как выглядит сильный профиль

Возьмём двух джунов с одинаковым набором навыков в резюме.

Профиль А. В закрепе todo-app, weather-app, js-course-final. У всех трёх README из шаблона генератора, последний коммит три месяца назад, сообщения lesson 5, lesson 6. Демо нет. Тимлид тратит на профиль двадцать секунд и не находит ни одного вопроса, который можно задать на интервью.

Профиль Б. В закрепе тоже три проекта:

• price-tracker. Раз в час опрашивает API маркетплейса, складывает историю цен и шлёт уведомление при падении. В README: что делает, стек, запуск через docker compose up, скриншот телеграм-уведомления и абзац о том, почему очередь, а не крон. Коммиты вида add retry with backoff for api errors.
• hh-stats. Разбор выгрузки вакансий: сколько чего требуют, какие связки стеков встречаются вместе. Ноутбук с графиками, данные приложены, выводы в README.
• readme-linter. Маленький CLI, которым автор пользуется сам. Есть тесты и CI-бейдж.

Код в профиле Б не сложнее. Разница в том, что по нему интервьюер соберёт полчаса разговора, не открывая заготовленный список вопросов. Вот это и называется сильным портфолио.

Как показывать портфолио при отклике

Портфолио работает, только если по нему пошли. Три вещи, которые это обеспечивают.

• Ссылка на видном месте резюме - в контактах, а не в описании последнего места работы.
• Точная ссылка в сопроводительном. Вместо «мой GitHub есть в резюме» напишите: «ближе всего к вашей вакансии проект price-tracker, там как раз FastAPI и очереди». Как встроить это в письмо, разобрано в статье про сопроводительное письмо разработчику.
• Совпадение с текстом резюме. Если в навыках указан PostgreSQL, а во всех проектах SQLite, это замечают. Проверить связку целиком помогает чек-лист перед откликом.

При этом портфолио повышает шанс на ответ, но не отменяет объём откликов. Реалистичные ожидания разобраны в статье сколько откликов нужно джуну до оффера.

Коротко

• Хорош не сложный проект, а тот, по которому можно задать вопрос на интервью.
• Три проекта в закрепе: один основной для защиты, два под остальной стек.
• Работают: сервис с внешним API, проект с авторизацией, работа на реальных данных, свой инструмент, принятый PR в чужой репозиторий.
• Не работают: todo-лист, калькулятор, проект «как в уроке» без своих решений.
• Обязательный минимум: README, рабочий запуск, осмысленные коммиты, демо или скриншот, .env.example.
• Учебный проект годится, если вы достроили его сверх задания и написали об этом в README.
• Ссылку на портфолио ставьте на видное место резюме, конкретный репозиторий называйте в сопроводительном.