Коротка відповідь. Портфоліо Junior – це не кількість репозиторіїв, а два-три проєкти, про які ти можеш розповісти: яку задачу вирішує, чому обрані саме такі рішення, які помилки виправив. Один туторіал-клон, скопійований у десятьох варіаціях, працює гірше, ніж один власний продукт із чесним README. Нижче – три типи проєктів, шаблон README і чекліст, за яким варто пройтись перед тим, як показувати код.
Що насправді показує проєкт у портфоліо
Рекрутер і технічний інтерв'юер дивляться на різне. Рекрутер – чи є взагалі щось живе, чи виглядає охайно, чи задеплоєно. Інтерв'юер – як ти мислиш: структура коду, назви, обробка помилок, історія комітів. Обох об'єднує одне питання: «ця людина робила осмислені рішення чи повторювала відео?». Тому головна валюта портфоліо – рішення, які ти можеш пояснити.
Чому туторіал-клони не працюють
Проєкт з обучалки впізнається миттєво: та сама структура, ті самі назви змінних, той самий дизайн, що в тисяч інших випускників. Він не шкодить, але й не відповідає на жодне питання про тебе. Мінімальний спосіб оживити туторіал – змінити предметну область і додати три власні функції, яких у відео не було. Максимальний – зробити власний проєкт з нуля.
Три проєкти, які закривають портфоліо Junior Frontend
1. Інтерфейс поверх відкритого API
Показує: робота з HTTP, асинхронність, стани loading/error/empty, робота з чужими даними. Приклади: пошук по відкритій базі фільмів/книг, погодний дашборд із збереженням міст, каталог із фільтрами. Ключова вимога – обробити ВСІ стани, а не лише щасливий шлях.
2. Застосунок зі станом (React)
Показує: архітектура компонентів, керування станом, форми, збереження даних. Приклади: трекер звичок із статистикою, планувальник тижня, менеджер особистих фінансів. Тут має бути видно рішення: чому стан лежить саме тут, чому компонент розбитий саме так. Маршрут побудови такого застосунку крок за кроком є в статті як стати frontend-розробником.
3. Повний CRUD із тестами
Показує: цілісність мислення – створення, читання, оновлення, видалення, валідація, хоча б кілька тестів на ключову логіку. Це може бути фронтенд із мок-API або повноцінний маленький fullstack. Тести навіть у мінімальній кількості різко виділяють портфоліо: у більшості кандидатів їх нуль.
README-шаблон, який працює
README – це половина цінності проєкту: саме його читають перед кодом. Шаблон:
# Назва проєкту
Одне речення: яку задачу вирішує і для кого.
**Live:** https://... · **Стек:** React, TypeScript, Vite
## Чому цей проєкт
2-3 речення: яку проблему я хотів розв'язати
і чому обрав саме такий підхід.
## Ключові рішення
- Стан зберігаю в X, тому що ... (яка була альтернатива і чому ні)
- Дані з API кешую так: ...
- Валідація форм зроблена через ..., бо ...
## Що було найскладнішим
Чесний абзац: де застряг, як розібрався, що зрозумів.
## Як запустити
npm install
npm run dev
## Що покращив би далі
- ...
- ...Розділи «Ключові рішення» і «Що було найскладнішим» – найважливіші: саме вони перетворюють репозиторій на історію мислення. І саме за ними інтерв'юеру зручно ставити питання, на які ти вже готовий.
Чекліст аудиту репозиторію перед показом
Пройди по кожному проєкту:
- README відповідає шаблону вище, лінк на живу версію працює.
- Проєкт задеплоєно (безкоштовних хостингів достатньо) – «подивитись можна лише локально» різко знижує шанси, що подивляться взагалі.
- Історія комітів осмислена: «add expense form validation», а не «fix», «fix2», «final».
- Немає закомічених секретів,
node_modules, мертвих файлів. - Код відформатовано однаково по всьому проєкту; назви змінних читаються.
- Обробка помилок є хоча б у ключових місцях: що бачить користувач, коли API впав?
- У консолі браузера немає червоних помилок на основних сценаріях.
- Мобільна версія не розвалена (перевір у DevTools).
Пункти 3 і 4 недооцінюють найчастіше – а Git-історію інтерв'юери відкривають регулярно: вона показує, як ти працюєш, чесніше за будь-яку співбесіду.
Як розповідати про проєкт на співбесіді
Структура на дві хвилини: задача → рішення → складність → результат. «Я хотів трекер звичок без реєстрації (задача). Зробив на React зі збереженням у localStorage, стан підняв до кореневого компонента, бо статистиці потрібні всі звички одразу (рішення). Найдовше воював із датами й таймзонами – переписав логіку на порівняння днів, а не таймстемпів (складність). Тепер користуюсь сам і додав експорт у CSV (результат)».
Порівняй із типовим «ну, це туторіал по React, там тудушка». Різниця – і є твоє портфоліо. Питання, які ставитимуть після такої розповіді, передбачувані – і це твоя перевага: підготуй відповіді про альтернативи своїм рішенням заздалегідь. Як тренувати таку розмову – у статті про підготовку до технічної співбесіди за 30 днів.
Практичне завдання
Обери свій найкращий наявний проєкт і прожени його через чекліст аудиту – сьогодні, це година роботи. Потім перепиши README за шаблоном. Якщо проєктів ще немає – почни з типу 1 (інтерфейс поверх API): він найшвидше доводиться до стану «можна показувати» і одразу дає матеріал для розмови на співбесіді.