Ти відкрив вакансії, а там — «досвід від 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-кейс або зроби спільний проєкт на двох-трьох людей (один пише бекенд, другий — фронтенд, третій — тести й CI). Зафіксуйте правила у CONTRIBUTING.md, розподіліть задачі по Issues, попрацюйте над Pull Requests. Саме так найкраще імітувати «справжню» розробку до першої роботи — і саме так радять стартувати Open Source Guides від GitHub.
