Portfolio juniora: 7 projektów, które robią różnicę w rekrutacji

Scenka z rekrutacji: dwóch juniorów, jedno zaproszenie

Dwóch kandydatów, ten sam stos technologiczny, podobne kursy na liście, równy poziom na zadaniu testowym. Rekruter wysyła linki do ich GitHubów liderowi technicznemu. Po pięciu minutach lider wraca: „Zapraszamy tylko tego drugiego”. Różnica? Portfolio, nie CV.

Co widzi rekruter, gdy klikasz „wyślij” z linkiem do GitHuba

Dla kandydata link do GitHuba to dopisek na dole CV. Dla rekrutera technicznego – najszybszy sposób, żeby stwierdzić, czy jest sens inwestować czas w rozmowę. Jeden rzut oka i widać, czy masz projekty do portfolio IT, które cokolwiek mówią o Twoim myśleniu, czy tylko listę forków z tutoriali.

Doświadczony developer nie szuka u juniora zaawansowanych algorytmów. Szuka śladów, że:

• potrafisz dowieźć projekt do końca (commit „Initial commit” to nie projekt),
• umiesz nazwać problem, który rozwiązujesz,
• ogarniasz podstawy pracy z Gitem i strukturą projektu,
• dbasz o to, żeby inni zrozumieli, co zrobiłeś (README, opis, screeny),
• uczyłeś się świadomie, a nie tylko „klikałeś dalej” w kursie.

Dla rekrutera nietrudno odróżnić, czy portfolio junior developera to zlepek przypadkowych repozytoriów, czy przemyślany zestaw kilku projektów pokazujących różne kompetencje. Nie chodzi o ilość, tylko o spójność i jakość.

Lista projektów z kursu vs. dowód rozwiązywania problemów

Portfolio zbudowane z samych tutoriali zwykle wygląda tak samo: „react-todo”, „bootstrap-landing-page”, „calculator-app”, czasem nawet z identycznymi opisami jak w kursie. Na pierwszy rzut oka rekruter widzi, że kandydat przeszedł kolejne moduły, ale nie widać ani grama własnej inicjatywy.

Inaczej jest, gdy Twoje projekty do nauki programowania są osadzone w realnych kontekstach: „Planer treningowy z historią postępów”, „Budżet domowy z kategoriami”, „Mini CRM dla freelancera”. Każdy z nich rozwiązuje konkretny, życiowy kłopot. Lider techniczny od razu widzi, że myślisz w kategoriach produktu, nie tylko kodu.

Przykład z praktyki: dwóch juniorów wysyła linki. Pierwszy ma pięć różnych „ToDo app” – każdy w innym frameworku. Drugi ma jedną porządną aplikację do śledzenia zadań w projekcie, z priorytetami, terminami, filtrowaniem i komentarzami. Pierwszy komunikuje: „umiem przerobić tutoriale”. Drugi: „umiem wymodelować realny proces pracy i zamienić go w działającą aplikację”.

Siedem projektów ważniejszych niż kolejne certyfikaty

Na etapie juniora certyfikaty pomagają „przejść filtr” u nietechnicznego rekrutera, ale to konkretne przykładowe projekty programistyczne decydują, kto dostanie zaproszenie od lidera technicznego. Jeden dobrze opisany, dopracowany projekt potrafi przeważyć nad dwiema stronami listy ukończonych kursów.

Główna myśl jest prosta: siedem dobrze przemyślanych projektów (nawet stosunkowo prostych) mówi o Tobie znacznie więcej niż kolejny certyfikat z platformy e-learningowej. Klucz tkwi w tym, żeby nie były przypadkowe, tylko wzajemnie się uzupełniały i pokazywały, że:

• opanowałeś fundamenty wybranej ścieżki (frontend, backend, fullstack, data, QA),
• masz pierwszy kontakt z „prawdziwym światem” (API, błędy, zespół, testy),
• potrafisz samodzielnie definiować i rozwiązywać problemy.

Od tej perspektywy warto zacząć, zanim pojawi się pokusa dorzucenia dwudziestego piątego repozytorium z kursu.

Czego rekruter szuka w portfolio juniora (i czemu o tym rzadko mówi wprost)

Co realnie jest oceniane poza samym kodem

Portfolio juniora to dla rekrutera skrócony test kilku kluczowych umiejętności, o których rzadko pisze się w ogłoszeniach. Oceniane jest przede wszystkim:

• Myślenie problemowe – czy potrafisz zidentyfikować problem użytkownika lub firmy i zaprojektować sensowne rozwiązanie.
• Konsekwencja – czy projekty są doprowadzone do stanu „używalnego”, czy każdy kończy się na „MVP, kiedyś dokończę”.
• Komunikacja – jak opisujesz projekty, czy README są zrozumiałe, czy commit message cokolwiek mówią.
• Jakość kodu – podstawy: nazewnictwo, podział na moduły, brak kopiuj-wklej, prosta, ale sensowna architektura.
• Umiejętność współpracy – praca na branchach, pull requesty, komentarze, reagowanie na uwagi.

Przy juniorach mniej liczy się to, czy znasz „właściwy” framework, a bardziej to, czy widać, że potrafisz się uczyć i współpracować. Technologie zmieniają się szybko; nawyki pracy i myślenia – wolniej.

Czerwone flagi, które obniżają Twoje szanse

Istnieje kilka powtarzających się wzorców w portfolio juniora, które od razu obniżają noty, nawet jeśli projekty są liczebnie imponujące. Do najczęstszych należą:

• Same tutoriale bez modyfikacji – repozytoria o nazwach typu „course-react-2023”, „javascript-udemy-section-4”. To pokazuje tylko, że potrafisz przepisywać kod z ekranu.
• Brak README – rekruter widzi kod, ale nie ma pojęcia, co robi aplikacja ani jak ją uruchomić. Pierwsze wrażenie: chaos i brak szacunku do czasu innych.
• Martwe repozytoria – dużo projektów z jednym–dwoma commitami, często sprzed roku, bez żadnych oznak doprowadzenia ich do używalnego stanu.
• Ogromne commity typu „fix” – cała historia w trzech commitach: „initial commit”, „fix”, „changes”. Trudno z tego wyczytać proces myślowy i styl pracy.
• Brak konsekwencji technologicznej – dziś trochę Pythona, jutro React, pojutrze Unity, później dwa projekty w Go. Przy braku solidnych fundamentów wygląda to, jakbyś skakał po technologiach bez planu.

Te czerwone flagi nie dyskwalifikują, ale powodują, że rekruter szybko traci zainteresowanie. Nawet kilka bardzo dobrych projektów może utonąć w morzu niechlujnie zostawionych repozytoriów.

Jak wygląda 60-sekundowy „skan” portfolio

Doświadczony developer nie spędza pół godziny na każdym GitHubie. Często ma na początek minutę, maksymalnie dwie. Tyle wystarcza, żeby ustalić, czy kandydat jest wart rozmowy. Taki skan wygląda mniej więcej tak:

1. Wejście na profil GitHuba – wrażenie ogólne: chaos czy porządek? Jest przypiętych kilka repozytoriów?
2. Przegląd 2–3 przypiętych projektów – nazwy, opisy, języki, liczba commitów, aktywność.
3. Wejście w jeden projekt – szybki rzut oka na README: czy opisuje, co projekt robi i jak go uruchomić.
4. Struktura katalogów i kilka plików źródłowych – nazwy, podział kodu, komentarze.
5. Historia commitów – czy są regularne, czy jest masa zmian „na raz”.

Jeśli po tej minucie rekruter widzi przemyślany zestaw projektów, jasne opisy i dowody, że potrafisz pracować systematycznie, Twoje szanse rosną. Jeśli widzi chaos, przypadkowe technologie i brak opisu – wraca do kolejnych CV.

Dlaczego warto znać kryteria, zanim zbudujesz portfolio

Bez zrozumienia, jak rekruter ocenia portfolio junior developera, łatwo zmarnować miesiące na tworzenie projektów, które niewiele wnoszą. Lepiej od początku budować je tak, żeby:

• pokrywały kluczowe obszary (logika biznesowa, UI/UX, API, współpraca, testy),
• były spójne z wybraną ścieżką (np. portfolio frontend junior vs. backend),
• dało się je sensownie opisać w CV i na LinkedIn.

Znając zasady gry, nie musisz robić wszystkiego. Skupiasz się na tych siedmiu projektach, które naprawdę robią różnicę w rekrutacji.

Strategia: jak zaplanować 7 projektów, które się uzupełniają

Dlaczego nie wystarczą „ładne” projekty

Ładnie wyglądający landing page czy prosty kalkulator w JS może zarobić kilka punktów „na start”, ale szybko przestaje wystarczać. Rekruterzy zaczynają pytać:

• czy potrafisz modelować dane i logikę (CRUD, relacje, walidacje),
• czy umiesz pracować z API i obsłużyć błędy zewnętrznych usług,
• czy miałeś jakikolwiek kontakt z testami, bezpieczeństwem, wydajnością,
• czy wiesz, co to jest proces zespołowy (branch, PR, code review).

Dlatego portfolio oparte tylko na „ładnych” projektach frontowych bez większej logiki szybko się wyczerpuje. Potrzebna jest różnorodność techniczna i problemowa: od prostych formularzy po projekt z integracją z API i testami.

Zasada 3 + 3 + 1: fundamenty, pogłębienie, projekt przewodni

Dobrze działający schemat na jak zbudować pierwsze portfolio IT to podejście 3 + 3 + 1:

• 3 projekty fundamentów – proste, ale kompletne aplikacje pokazujące podstawowe umiejętności:
  • solidna aplikacja CRUD,
  • projekt z dopracowanym UI/UX,
  • aplikacja integrująca z zewnętrznym API.
• 3 projekty pogłębienia – podnoszą poprzeczkę o poziom wyżej:
  • projekt zespołowy lub kontrybucja do open source,
  • aplikacja z testami (jednostkowymi, integracyjnymi lub e2e),
  • projekt pokazujący dodatkowy aspekt – np. automatyzację, data analysis, CI/CD.
• 1 projekt przewodni – większa, dopieszczona aplikacja, którą można pokazywać na rozmowie jako główny przykład tego, co umiesz.

Taki układ pozwala pokazać szerokie spektrum kompetencji bez rozpraszania się na dziesiątki małych, niedokończonych pomysłów.

Dopasowanie projektów do wybranej ścieżki

Te same typy projektów można zrealizować inaczej w zależności od tego, na jaką ścieżkę celujesz:

• Frontend:
  • CRUD z naciskiem na UI (np. React + lokalne API/mock),
  • aplikacja z dopracowanym UX (design system, responsywność),
  • integracja z zewnętrznym API (np. TMDB, Spotify, GitHub),
  • testy komponentów (Jest, Testing Library),
  • projekt przewodni: dashboard lub mini aplikacja SPA.
• Backend:
  • CRUD z prawdziwą bazą danych (PostgreSQL, MongoDB),
  • API z autentykacją i autoryzacją,
  • integracja z zewnętrznym API (np. płatności, wysyłka maili),
  • testy jednostkowe i integracyjne,
  • projekt przewodni: REST/GraphQL API dla konkretnego produktu.
• Fullstack:
  • CRUD z frontendem i backendem,
  • dopracowany UI plus logika biznesowa,
  • integracja z API zarówno po stronie serwera, jak i klienta,
  • choć podstawowe testy po obu stronach,
  • projekt przewodni: pełna aplikacja (np. mini SaaS).
• Data / analityka:
  • projekt danych z ETL (zaciągnięcie danych, czyszczenie, analiza),
  • dashboard (np. w Streamlit, Dash, Power BI),
  • praca z publicznym API danych (np. finanse, sport, open data),
  • testy prostych funkcji przetwarzających dane,
  • projekt przewodni: case businessowy oparty na danych.
• QA / automatyzacja:
  • projekt z testami e2e dla istniejącej aplikacji,
  • framework testów automatycznych (np. Cypress, Playwright, Selenium),
  • integrowanie testów z CI,
  • praca zespołowa przy pisaniu scenariuszy,
  • projekt przewodni: zestaw testów dla realnej aplikacji (np. wybranego open source).

Plan na 6–9 miesięcy budowy portfolio

Budowa GitHub juniora z sensownym zestawem projektów nie musi zająć lat. Wystarczy dobrze rozplanowane 6–9 miesięcy:

Realistyczny harmonogram krok po kroku

Wyobraź sobie, że co tydzień po pracy masz 6–8 godzin na kod. Ani dużo, ani mało. Jeśli rozłożysz to z głową na kilka miesięcy, jesteś w stanie dowieźć 7 projektów, które nie będą wyglądały jak przypadkowe „strzały”.

Przykładowy plan możesz potraktować jak szkielet, który później dopasujesz do siebie:

• Miesiące 1–3: fundamenty (projekty 1–3)
  • tydzień 1–4: aplikacja CRUD,
  • tydzień 5–8: projekt z naciskiem na UX/UI,
  • tydzień 9–12: integracja z zewnętrznym API.
• Miesiące 4–6: pogłębienie (projekty 4–6)
  • tydzień 13–18: projekt zespołowy lub open source,
  • tydzień 19–22: projekt z testami,
  • tydzień 23–26: projekt „dodatkowej kompetencji” (np. automatyzacja, dane, CI).
• Miesiące 7–9: projekt przewodni (projekt 7)
  • tydzień 27–36: większa aplikacja, rozwijana iteracyjnie, z refaktoryzacją i dopieszczonym README.

Nie każdy tydzień będzie idealny. Czasem choroba, czasem sesja na studiach albo nadgodziny w pracy. Dlatego plan zakłada bufor – lepiej mieć luźny margines niż kończyć wszystko w pośpiechu, na ostatnią chwilę przed wysłaniem CV.

Niewielkie, ale świadome przesunięcia (np. dodatkowe dwa tygodnie na projekt przewodni) są w porządku. Chodzi o to, żeby nie zatrzymać się na jednym projekcie na trzy miesiące i nie ugrzęznąć w perfekcjonizmie.

Jak dokumentować postępy, żeby było co pokazać

Wielu juniorów faktycznie pracuje nad projektami, ale ich GitHub na to nie wskazuje – wygląda na martwy. Rekruter widzi daty commitów sprzed kilku miesięcy i zakłada, że kandydat dawno przestał kodować.

Rozwiązaniem jest prosta higiena pracy z repozytorium:

• Regularne, małe commity – zamiast jednego ogromnego „project finished” rób:
  • „Add basic layout for dashboard”
  • „Implement form validation for login”
  • „Refactor user service – extract repository layer”
• Krótki dziennik w README – sekcja „Changelog” lub „Postęp prac” z datami i 2–3 punktami na sprint/tydzień.
• Gałęzie feature’owe – nawet w solo projekcie pracuj na branchach: feature/auth, feature/payments, a potem rób merge przez PR (możesz sam sobie zostawiać komentarze).

Z punktu widzenia rekrutera taki projekt wygląda, jakby żył. Widać, że uczysz się iteracyjnie, umiesz dzielić zadania i używasz narzędzi w sposób zbliżony do komercyjnego.

Projekt 1 – Solidna aplikacja CRUD z prawdziwym problemem w tle

Dwóch kandydatów wysyła link do „todo app”. U jednego to trzy endpointy z przypadkowo nazwanymi polami i brak walidacji. U drugiego – przemyślana aplikacja z kategoriami, filtrami, prostym systemem ról i sensownym modelem danych. Na papierze oba to „CRUD”, ale w praktyce różnica jest kolosalna.

Co oznacza „solidny” CRUD na poziomie juniora

Podstawowy CRUD to za mało. Chodzi o to, żeby pokazać:

• przemyślany model danych – relacje typu użytkownik → zadania, produkt → zamówienia,
• walidację – wymagane pola, długości, zakresy, formaty (np. mail),
• obsługę błędów – co się dzieje, gdy użytkownik poda złe dane lub zasób nie istnieje,
• podstawową autoryzację – użytkownik widzi tylko swoje dane lub ma ograniczone uprawnienia,
• podział warstw – kontrolery/route’y, logika biznesowa, dostęp do danych.

Nawet jeśli backend stoi na prostym frameworku (np. Express, Django, Spring Boot), a frontend to zwykły formularz bez spektakularnego UI, aplikacja może pokazać dojrzałe podejście do problemu – i o to chodzi.

Przykładowe pomysły na CRUD z sensem

Zamiast kolejnej listy „zadań”, poszukaj problemu z życia, który znasz:

• Menadżer zgłoszeń serwisowych – statusy typu „nowe”, „w trakcie”, „zakończone”, role (klient, serwisant, admin), proste raportowanie.
• System rezerwacji zasobów – sale konferencyjne, sprzęt fotograficzny, samochody; daty, kolizje rezerwacji, podstawowe reguły biznesowe.
• Organizer treningów – plan tygodniowy, typ treningu, intensywność, możliwość kopiowania planów między tygodniami.

Im bardziej projekt przypomina mini wersję realnego narzędzia biznesowego, tym łatwiej rekruterowi uwierzyć, że poradzisz sobie z prawdziwym kodem w firmie.

Elementy, które powinny znaleźć się w repozytorium CRUD-a

Nawet najlepsza aplikacja straci na wartości, jeśli repozytorium będzie surowe. Dobrze, jeśli zawiera co najmniej:

• README z opisem problemu – 2–3 zdania o tym, dla kogo jest aplikacja i jakie problemy rozwiązuje,
• instrukcję uruchomienia – komendy, zmienne środowiskowe, wymagane narzędzia,
• zrzuty ekranu lub GIF-y – szybki podgląd działania appki,
• sekcję „Technologie i decyzje” – krótkie uzasadnienie wyboru stacku i kilku kluczowych rozwiązań (np. sposób autoryzacji).

Taki CRUD staje się nie tylko dowodem, że umiesz coś napisać, ale też, że potrafisz o tym opowiedzieć technicznie i biznesowo.

Projekt 2 – Aplikacja z interfejsem dopracowanym pod użytkownika (UX/UI)

Jeden z kandydatów przychodzi na rozmowę z aplikacją, której da się używać na telefonie bez powiększania ekranu, bez zgadywania, gdzie kliknąć, i bez krzyczących kolorów. Nagle junior przestaje być „kolejnym kursantem”, a zaczyna wyglądać jak ktoś, kto myśli o użytkowniku.

UX/UI na poziomie juniora – co jest realne

Nikt nie oczekuje, że zostaniesz projektantem. Chodzi o kilka konkretnych rzeczy:

• responsywność – aplikacja działa sensownie na telefonie, tablecie i desktopie,
• spójny styl – te same odstępy, paleta kolorów, typografia,
• jasna nawigacja – użytkownik wie, gdzie jest i dokąd może przejść,
• czytelne stany – ładowanie, błędy, puste listy, sukcesy (np. „Brak zadań na dziś – dodaj pierwsze”),
• podstawowa dostępność – kontrast, alt teksty, fokus na elementach interaktywnych.

Takie rzeczy robią ogromne wrażenie, bo pokazują, że nie kończysz pracy na tym, że „kod się kompiluje”. Obchodzi Cię, czy ktoś faktycznie może z tego korzystać.

Jak zaplanować projekt pod użytkownika, a nie pod technologię

Dobry punkt wyjścia to prosty scenariusz użycia. Zamiast zaczynać od wybierania biblioteki do styli, zacznij od odpowiedzi na pytania:

• kto będzie używał tej aplikacji (student, trener, freelancer, rodzic?),
• co robi najczęściej (np. dodaje nowe wpisy, przegląda listę, filtruje),
• co jest dla niego najbardziej frustrujące w istniejących narzędziach,
• które 2–3 ekrany są najważniejsze (np. dashboard, formularz główny, widok szczegółowy).

Do tego wystarczą kartka i długopis. Prosty szkic ekranu z zaznaczeniem, co jest gdzie, wiele zmienia. Potem możesz go przenieść do narzędzia (Figma, Excalidraw), ale nie jest to konieczność.

Techniczne smaczki, na które rekruter patrzy przy projekcie „wizualnym”

Nawet w projekcie, który ma grać głównie interfejsem, kod nadal ma znaczenie. Doświadczony frontendowiec zwróci uwagę na:

• strukturę komponentów – brak gigantycznych plików z tysiącem linii; podział na mniejsze, wielokrotnego użytku elementy,
• stylowanie – konsekwentne użycie metod (CSS Modules, styled-components, Tailwind) zamiast miksu wszystkiego naraz,
• system designu – prosta biblioteka własnych komponentów: <Button />, <Input />, <Card /> zamiast kopiowania styli za każdym razem,
• obsługę stanów – loader przy pobieraniu danych, komunikaty przy błędach formularza, disabled przycisków w trakcie zapisu.

Dzięki temu „projekt UI” nie wygląda jak jednorazowa zabawa w CSS, tylko jak kawałek aplikacji, który można później rozbudować.

Projekt 3 – Integracja z zewnętrznym API i obsługa błędów świata zewnętrznego

Na rozmowie technicznej często pada pytanie: „Pracowałeś z jakimś zewnętrznym API?”. Większość juniorów odpowiada: „Tak, pobierałem listę filmów z TMDB”. Gdy padnie pytanie o obsługę błędów, timeouty albo limity zapytań, zapada cisza.

Dlaczego API to must-have w portfolio

Dzisiejsze aplikacje rzadko żyją w próżni. Łączą się z systemami płatności, wysyłają maile, pobierają dane pogodowe, używają logowania przez Google. Projekt z sensowną integracją API pokazuje, że:

• umiesz czytać dokumentację techniczną,
• rozumiesz różnicę między sukcesem a błędem HTTP,
• potrafisz radzić sobie z opóźnieniami, limitami i niepełnymi danymi,
• myślisz o bezpieczeństwie (klucze API, dane wrażliwe).

To sygnał, że nie zatrzymasz się na pierwszym fetch(), który nagle przestanie działać, tylko spróbujesz zrozumieć, co się stało.

Jakie API wybrać na start

Zamiast łapać pierwsze lepsze API z listy „Public APIs”, poszukaj czegoś, co pasuje do Twojego CRUD-a lub projektu UI. Kilka sprawdzonych kategorii:

• dane rozrywkowe – filmy, seriale, muzyka (TMDB, Spotify, Last.fm),
• dane miejskie i transport – rozkłady jazdy, stacje rowerów miejskich, open data z Twojego miasta,
• finanse i kursy walut – notowania giełdowe, ceny kryptowalut, kursy walut,
• sport – wyniki meczów, tabele ligowe, statystyki zawodników.

Łatwiej obronić projekt, w którym zintegrowałeś się z API pokazującym dane, które faktycznie Cię interesują (np. ulubiona liga piłkarska), niż z przypadkowym „API cytatów dnia”.

Na co zwracać uwagę przy implementacji integracji

Sama integracja to nie tylko wywołanie endpointu i wyświet