Ты открыл вакансии, а там — «опыт от 1 года». Звучит до боли знакомо, но переживать не стоит. Первое портфолио не требует коммерческих релизов — ему нужна понятная демонстрация твоих навыков: кода, решений, процесса. Покажи, как ты формулируешь задачу, планируешь работу, пишешь и тестируешь, описываешь результат — и рекрутер увидит не новичка, а младшего инженера, которого легко встроить в командный процесс.
Что положить в первое портфолио программиста
Начни с 3–5 небольших, но завершенных работ. Каждый проект должен решать практическую задачу и быть «живым» — то есть его можно запустить локально или посмотреть демо. Подойдут:
- Мини-продукт с реальным сценарием. Трекер расходов, чек-лист задач, конвертер валют, парсер публичного API, небольшой чат-бот и т. п.
- Клон части известного сервиса. Страница поиска с автодополнением, корзина интернет-магазина.
- Сервис с внешней интеграцией. Авторизация через OAuth, интеграция платёжного провайдера (sandbox), работа с картами или почтовым API.
- Консольный инструмент или библиотека. CLI для импорта/очистки данных, небольшой SDK к популярному API.
Каждый репозиторий должен коротко отвечать на три вопроса: что это, как запустить и как проверить. Официальная документация GitHub как раз про это: добавь README, .gitignore и лицензию — базовый минимум любого репозитория.
Как оформить репозиторий, чтобы им было удобно пользоваться
- README. Объясни проблему, опиши фичи, добавь инструкции по запуску (локально и через Docker, если есть), приложи скриншоты. Посмотри советы в документации GitHub по README и настройке репозитория. Полезно подсмотреть структуру удачных README в сообществе (разделы «Highlights», «Quickstart», «FAQ») — даже простой шаблон лучше «пустого» описания.
- Лицензия. Если публикуешь код открыто, выбери MIT License — популярный вариант для учебных и небольших проектов: минимум ограничений на использование.
- Понятные коммиты и версии. Пиши внятные сообщения коммитов (шаблон Conventional Commits упрощает ревью и автоматизацию релизов) и придерживайся семантического версионирования (SemVer) — это взрослый сигнал для любого инженера, который откроет твой репозиторий.
- Документация «минимум». Добавь CONTRIBUTING.md (как запускать тесты, стиль кода), .editorconfig, базовые настройки линтера. По желанию вынеси документацию на статический сайт (MkDocs — простой путь, если пишешь в Markdown).
Где взять темы и «реальные» задачи
- Публичные API и открытые данные. Подключи API погоды, валют, карт; собери бота, который реагирует на событие.
- Open source. Посмотри «good first issue» в репозиториях и сделай маленький вклад — исправь опечатку в документации, добавь тест, почисти конфиг. Гайд «How to Contribute to Open Source» от GitHub подскажет, как найти проект и пройти первый Pull Request без стресса.
- Свои боли = чужие боли. Автоматизируй личные рутины — переименование файлов, парсинг выписок, «пылесос» фото/видео. Такие вещи нравятся на собеседованиях: они показывают инженерное мышление.
Покажи процесс, а не только результат
Портфолио — не галерея скриншотов. Рекрутер и техлид смотрят, как ты работаешь. Добавь:
- Тесты. Даже небольшая «пирамидка» (юнит-тесты на ключевые функции) показывает, что ты умеешь страховать изменения.
- CI. Простой конвейер — линтинг + тесты на каждый pull request. Эта мелочь отличает «курс» от «рабочего процесса».
- Issue-борд. Разбей работу на задачи: «добавить валидацию», «дописать README», «сделать docker-compose». Видно план и прогресс — понятно, как ты думаешь.
- Демо. Выведи результат на хостинг (любой удобный сервис). Добавь в README кнопку «Live Demo» и команду для локального запуска через Docker.
YouTube
Командная работа без «коммерции»
Нет продакшн-опыта? Подхвати маленький open-source-кейс или собери общий проект на 2–3 человека (один пишет бэкенд, второй — фронтенд, третий — тесты и CI). Зафиксируйте правила в CONTRIBUTING.md, распределите задачи по Issues, работайте через Pull Requests. Так лучше всего имитировать «настоящую» разработку до первой работы — и так советуют стартовать Open Source Guides от GitHub.
