Dobre portfolio programisty nie jest ozdobą do CV, tylko dowodem, że potrafisz dowieźć działający efekt i sensownie opisać swoje decyzje techniczne. W rekrutacji do IT liczy się nie tylko sam kod, ale też kontekst: co zbudowałeś, dlaczego tak to zrobiłeś, z jakimi kompromisami i czy projekt da się sprawdzić bez zgadywania. Poniżej pokazuję, co powinno się w nim znaleźć, jak wybrać projekty, jak je opisać i kiedy wystarczy GitHub, a kiedy lepiej dołożyć prostą stronę.
Najkrócej: portfolio ma pokazać efekt, proces i technologię
- Najlepiej działają 3-5 dobrze opisanych projektów zamiast długiej listy wszystkiego, co kiedykolwiek robiłeś.
- Każdy projekt powinien mieć krótki opis celu, użytych technologii, Twojej roli i jednego konkretnego problemu, który rozwiązał.
- Rekruter szuka przede wszystkim dowodu, że umiesz dowozić działające rozwiązania, porządkować własną pracę i uczyć się na błędach.
- GitHub często wystarcza jako baza, ale własna strona lub dobrze uporządkowany profil potrafią podnieść wiarygodność.
- Największy błąd to repozytoria bez kontekstu, bez README i bez wyjaśnienia, po co dany projekt w ogóle powstał.
Dlaczego samo CV już nie wystarcza
W IT sam opis umiejętności bywa zbyt ogólny. W CV można napisać, że znasz Reacta, Pythona albo Docker, ale dopiero projekt pokazuje, czy umiesz z tych narzędzi realnie korzystać. Ja zwykle patrzę na portfolio jak na skrócony zapis sposobu myślenia kandydata: czy umie dobrać zakres, czy rozumie strukturę aplikacji i czy potrafi zamknąć temat od pomysłu do wdrożenia.
To szczególnie ważne na początku kariery, kiedy doświadczenia komercyjnego jeszcze brakuje. Dobrze przygotowany zbiór projektów może wtedy zrobić większe wrażenie niż długa lista technologii wpisanych w sekcję „umiejętności”. Dla osób z większym stażem portfolio działa trochę inaczej: nie musi być rozbudowane, ale powinno jasno pokazywać specjalizację, poziom samodzielności i zakres odpowiedzialności. W praktyce to właśnie ono pomaga odpowiedzieć na pytanie, czy kandydat potrafi dowieźć coś więcej niż prostą demonstrację kodu. Skoro wiadomo już, po co to wszystko robić, czas przejść do tego, co rzeczywiście warto pokazać.
Jakie projekty naprawdę robią różnicę
Nie każdy projekt wnosi tyle samo. Jeden dobrze opisany produkt pokaże więcej niż pięć ćwiczeń z kursu, które różnią się tylko nazwą repozytorium. Ja zawsze rozdzielam projekty na te, które pokazują efekt końcowy, i te, które pokazują umiejętność techniczną. Obie grupy są potrzebne, ale ich proporcje zależą od poziomu doświadczenia.
Dla juniora
Na starcie najlepiej działają projekty, które pokazują pełny, ale niewielki proces: aplikację z logowaniem, prostym CRUD-em, podstawowym testowaniem i wdrożeniem. Liczy się nie skala, tylko domknięcie tematu. Jeśli zrobisz jedną aplikację end-to-end, łatwiej obronisz się na rozmowie niż przy kilku niedokończonych repozytoriach.
Dla mida
Na poziomie mid więcej znaczy jakość decyzji niż sam pomysł. Dobrze wyglądają projekty, w których widać refaktor, optymalizację, integrację z API, poprawę wydajności albo uporządkowanie architektury. Taki materiał pokazuje, że nie tylko umiesz pisać nowy kod, ale też potrafisz pracować z istniejącym systemem, a to w realnych firmach jest równie ważne.
Przeczytaj również: Pytania rekrutacyjne IT - Jak odpowiadać, by zachwycić?
Dla seniora
Na wyższym poziomie portfolio nie musi być długie. Wystarczy kilka wyraźnych przykładów: wkład w open source, publiczne studium przypadku, własne narzędzie, sensownie opisany proces migracji albo projekt, w którym widać decyzje architektoniczne. Tutaj szczególnie liczy się to, czy potrafisz pokazać wpływ, a nie tylko listę technologii. Sam kod jest ważny, ale jeszcze ważniejsze jest to, co mówi o Twoim sposobie pracy.
W każdej z tych grup warto wybierać projekty zróżnicowane, ale spójne z kierunkiem, w którym chcesz iść. Jeśli celujesz w backend, pokaż API, pracę z bazą danych i testy. Jeśli interesuje Cię front-end, dodaj interakcję, stan aplikacji, dostępność i dopracowany interfejs. Gdy portfolio odpowiada na konkretny profil, dalej pozostaje już tylko dobrze je opisać.
Jak opisać projekt, żeby rekruter zrozumiał jego wartość
Sam link do repozytorium nie wystarczy. Rekruter albo lider techniczny potrzebuje szybko zrozumieć, co projekt robi, jaki problem rozwiązuje i co dokładnie zrobiłeś Ty. Najlepiej działa krótki, uporządkowany opis. Ja zwykle trzymam się prostego schematu, który można przeczytać w mniej niż minutę.
| Element opisu | Co wpisać | Dlaczego to działa |
|---|---|---|
| Nazwa i cel | Jedno zdanie: co to jest i po co powstało | Od razu ustawia kontekst |
| Stack | Technologie użyte w projekcie | Pokazuje zakres techniczny bez lania wody |
| Twoja rola | Co zrobiłeś sam, a co było pracą zespołową | Porządkuje odpowiedzialność |
| Problem | Jedno konkretne wyzwanie, np. integracja, wydajność, testy | Pokazuje myślenie inżynierskie |
| Efekt | Co projekt daje użytkownikowi lub zespołowi | Przesuwa uwagę z kodu na wartość |
| Linki | Repozytorium, demo, dokumentacja, ewentualnie screeny | Ułatwia szybkie sprawdzenie projektu |
Jeśli opis robi się długi, zwykle znaczy to, że próbujesz opowiedzieć za dużo. Ja trzymam się zasady, że jeden projekt powinien dać się streścić w 90-150 słowach, a reszta szczegółów może trafić do README albo do osobnej podstrony. To wystarcza, żeby pokazać wartość bez zamieniania portfolio w ścianę tekstu. Następny krok to wybór miejsca, w którym wszystko pokażesz.
GitHub, własna strona czy oba
W praktyce najczęściej wygrywa zestaw hybrydowy: GitHub jako baza i prosta strona jako warstwa prezentacyjna. GitHub daje kod, historię zmian i techniczny kontekst. Strona porządkuje całość, skraca drogę do najważniejszych informacji i pozwala pokazać projekty tak, jak chcesz je opowiedzieć. Warto też pamiętać, że GitHub oferuje profile README, a GitHub Pages pozwala opublikować statyczną stronę bez dużej konfiguracji.
| Format | Kiedy ma sens | Plusy | Minusy | Koszt |
|---|---|---|---|---|
| GitHub | Prawie zawsze | Pokazuje kod, commity i README | Bywa chaotyczny, jeśli nie pilnujesz porządku | 0 zł |
| Profil README | Gdy chcesz szybki skrót o sobie | Jedno miejsce z najważniejszymi informacjami | Krótka forma, więc nie pomieści wszystkiego | 0 zł |
| Własna strona na GitHub Pages | Gdy masz już kilka sensownych projektów i chcesz lepszej ekspozycji | Pełna kontrola nad układem, estetyką i opisem | Wymaga dbałości o UX, treść i aktualność | 0 zł w prostym wariancie |
| PDF wysyłany z CV | Gdy aplikujesz klasycznie i chcesz załączyć skrót | Łatwy do wysłania i wydrukowania | Szybko się starzeje i jest mniej elastyczny | 0 zł |
Jeżeli mam wybierać tylko jedno rozwiązanie dla osoby, która dopiero zaczyna, stawiam na uporządkowany GitHub. Jeżeli ktoś ma już kilka dobrych projektów, własna strona daje wyraźnie lepszą kontrolę nad narracją. Najmocniej działa jednak połączenie obu rzeczy, bo kod można sprawdzić od ręki, a strona prowadzi wzrok dokładnie tam, gdzie chcesz. Skoro wiadomo już, gdzie to pokazać, warto uważać na błędy, które psują cały efekt.
Najczęstsze błędy, które obniżają wiarygodność
Widziałem wiele portfolio, które miały niezłe repozytoria, ale przegrywały przez drobiazgi. I to właśnie drobiazgi zwykle decydują o odbiorze. Najczęstszy problem nie polega na tym, że projekt jest za mały. Problem polega na tym, że nie da się go szybko zrozumieć albo sprawdzić.
- Brak README - bez krótkiego opisu rekruter nie wie, co ma otworzyć i po co.
- Projekty z tutoriali bez własnych zmian - takie repozytorium pokazuje odtworzenie kroku po kroku, a nie samodzielność.
- Martwe linki i niedziałające demo - jeśli coś nie działa, wrażenie psuje się natychmiast.
- Zbyt wiele niedokończonych repozytoriów - chaos bywa gorszy niż mała liczba projektów.
- Przeładowanie technologiami - dodawanie wszystkiego tylko po to, by wyglądać „bardziej senioralnie”, zwykle brzmi sztucznie.
- Brak informacji o roli autora - jeśli projekt był zespołowy, trzeba jasno napisać, za co odpowiadałeś.
- Ukrywanie wszystkiego w prywatnych repo - ma to sens tylko wtedy, gdy faktycznie nie możesz pokazać kodu, na przykład z powodu NDA.
Ja osobiście bardziej ufam mniejszemu portfolio, które jest czyste, niż dużemu zestawowi linków bez kontekstu. Z tej perspektywy lepiej jest od razu przyjąć prostą zasadę: mniej elementów, więcej jakości. To prowadzi do kolejnego pytania, które najczęściej pojawia się u osób startujących od zera.
Jak wystartować, jeśli dopiero budujesz pierwsze projekty
Jeżeli nie masz jeszcze doświadczenia komercyjnego, nie próbuj nadrabiać ilością. Lepiej zaplanować jeden sensowny projekt i doprowadzić go do końca niż zbudować trzy półprodukty. Ja zwykle polecam taki start, bo daje konkretny materiał do rozmowy i nie rozprasza energii.
- Wybierz jeden problem, który da się zamknąć w 1-2 weekendy albo w kilka spokojnych wieczorów.
- Ogranicz zakres do wersji minimalnej, ale działającej.
- Zadbaj o wdrożenie, nawet proste, żeby ktoś mógł wejść i kliknąć.
- Dopisuj README na bieżąco, a nie dopiero po zakończeniu projektu.
- Dodaj 3-5 screenów albo krótkie nagranie działania, jeśli interfejs ma znaczenie.
- Opisz, czego się nauczyłeś i co zrobiłbyś inaczej przy następnej wersji.
Takie podejście działa szczególnie dobrze u juniorów, studentów i osób przebranżawiających się do IT. Rekruter widzi wtedy nie tylko wynik, ale też proces, a to często ważniejsze niż sam poziom zaawansowania projektu. Gdy już masz pierwszą wersję gotową, pozostaje dopracowanie detali, które robią największą różnicę w odbiorze.
Co dopracować przed wysłaniem zgłoszenia
Przed wysłaniem aplikacji sprawdzam zawsze te same rzeczy. Nie są efektowne, ale właśnie one często decydują, czy portfolio wygląda profesjonalnie. Jeśli chcesz uzyskać mocniejszy efekt bez dokładania kolejnych projektów, zacznij od porządku.
- Ustaw 3 najważniejsze projekty na górze profilu albo na stronie głównej.
- Usuń repozytoria, które nic nie wnoszą albo są wyraźnie nieukończone.
- Sprawdź wszystkie linki na komputerze i na telefonie.
- Dodaj jedno zdanie o tym, w czym chcesz się specjalizować.
- Ujednolić nazwy projektów, bo bałagan w nazewnictwie od razu obniża czytelność.
- Przejrzyj tekst pod kątem błędów, skrótów myślowych i zbyt technicznego żargonu.
Dobre portfolio nie musi być rozbudowane ani „efektowne” w sensie marketingowym. Ma być czytelne, aktualne i prawdziwe. Jeśli pokazuje sensowne projekty, jasno opisuje Twoją rolę i pozwala szybko ocenić jakość pracy, działa dokładnie tak, jak powinno.
