Budowanie pierwszego CV w IT to nie sztuka wypełnienia szablonu, tylko zbudowanie dowodu, że potrafisz tworzyć rzeczywiste rozwiązania i myśleć jak ktoś, kogo da się włączyć do zespołu. Dobre cv programisty bez doświadczenia opiera się na projektach, technologii, czytelnym układzie i uczciwym pokazaniu tego, czego już się nauczyłeś. W tym tekście pokazuję, jak to ułożyć, żeby dokument nie wyglądał na pusty, nawet jeśli nie masz jeszcze komercyjnych lat pracy.
Najkrótsza wersja brzmi tak
- Na pierwszym miejscu pokaż projekty, stack i linki do kodu, nie samą deklarację, że interesujesz się programowaniem.
- Opisuj projekty jak dowód umiejętności: cel, technologia, efekt, a nie tylko nazwę repozytorium.
- Umiejętności wpisuj uczciwie i konkretnie; lepiej 8 realnych pozycji niż 30 haseł z kursów.
- W CV juniora liczą się też kursy, staże, hackathony, open source i aktywność własna, nawet jeśli nie były komercyjne.
- Jedna strona zwykle wystarcza, a jeśli dokument jest dłuższy, to dlatego, że ma treść, nie ozdobniki.
- Najczęściej przegrywają CV przeładowane grafiką, zbyt ogólne i pozbawione linków do pracy, którą można sprawdzić.
Co rekruter chce zobaczyć u kandydata na start
Ja patrzę na takie CV jak na odpowiedź na jedno pytanie: czy ta osoba potrafi wykonać mały, sensowny kawałek pracy i jasno go opisać. W praktyce rekruter w IT szuka nie tylko nazw technologii, ale też sygnałów, że umiesz się uczyć, szukasz informacji samodzielnie i nie naciągasz historii. W 2026 w Polsce nadal da się wejść do branży bez komercyjnego doświadczenia, ale samo „interesuję się programowaniem” nie wystarcza. Potrzebujesz konkretu.
- linku do GitHuba, portfolio lub działającego demo;
- krótkiego profilu, który mówi, w czym chcesz się specjalizować;
- 2-4 projektów z opisem, a nie samej listy repozytoriów;
- uczciwej listy technologii, które naprawdę potrafisz użyć;
- jednego lub dwóch dowodów regularności, na przykład kursu, bootcampu, stażu, hackathonu albo aktywności open source.
Jeśli tych elementów brakuje, dokument wygląda jak obietnica bez zaplecza. Kiedy je dodasz, łatwiej przejść do najbardziej nośnej części, czyli projektów.
Jak opisać projekty, żeby wyglądały jak dowód umiejętności
To jest zwykle najważniejsza sekcja. Przy kandydacie bez stażu projekty zastępują doświadczenie komercyjne, więc opis musi być konkretny: co zrobiłeś, po co, w jakim stacku i co z tego wynika. Sam tytuł repozytorium nic nie mówi. Dobre CV juniora pokazuje, że umiesz myśleć produkcyjnie, a nie tylko odtwarzać ćwiczenia z kursu.
Jak opisać jeden projekt
- Cel - co aplikacja rozwiązuje, na przykład planowanie zadań, zapis rezerwacji albo prosty panel administracyjny.
- Stack - np. React, TypeScript, Node.js, PostgreSQL, Docker, jeśli faktycznie ich użyłeś.
- Twoja rola - co zrobiłeś samodzielnie, a co było pracą zespołową.
- Efekt - np. autoryzacja JWT, filtrowanie danych, testy jednostkowe, integracja z API.
- Dostęp - link do repo, demo lub screeny, jeśli projekt działa publicznie.
W opisie lepiej brzmi zdanie: „Stworzyłem aplikację do zarządzania zadaniami z filtrowaniem, logowaniem i testami jednostkowymi” niż „Projekt: Task Manager”. Pierwsze zdanie daje obraz umiejętności, drugie tylko nazwę.
Przeczytaj również: Jak przebranżowić się do IT? Prosty plan i gotowe ścieżki
Dopasuj projekty do kierunku, na który aplikujesz
Front-end? Pokaż responsywność, stan aplikacji, dostępność i pracę z API. Backend? Opisz REST API, bazę danych, autoryzację, kolejki lub testy. Full stack? Pokaż, jak łączysz oba światy, ale nie rozdmuchuj zakresu, jeśli projekt jest prosty. Rekruterowi nie chodzi o liczbę użytych bibliotek, tylko o to, czy wiesz, po co ich użyłeś.
Najlepszy zestaw dla początkującego to zwykle 2-4 dopracowane projekty. Lepiej mieć trzy repozytoria z porządnym README, wdrożeniem i krótkim opisem decyzji technicznych niż dziesięć pustych ćwiczeń z kursu. Po projekty sięga się wzrokiem jako pierwsze, więc to one najczęściej decydują, czy dokument przejdzie dalej.
Gdy projekty są już opisane sensownie, trzeba pilnować, by sekcja umiejętności nie zjadła całej wiarygodności.
Jak pokazać umiejętności bez nadmuchania CV
W CV początkującego najłatwiej przesadzić właśnie tutaj. Widzę często długą listę technologii, które kandydat zna tylko z kursu albo jednego ćwiczenia. Ja wolę mniej pozycji, ale takich, które można obronić na rozmowie. Jeśli wpisujesz React, to umiej opisanie stanu, propsów i komponentów. Jeśli wpisujesz SQL, to potrafisz wytłumaczyć JOIN, agregacje i podstawy indeksów.
| Sekcja | Lepszy zapis | Gorszy zapis |
|---|---|---|
| Technologie | JavaScript, TypeScript, React, Node.js, PostgreSQL, Git | programowanie, internet, bazy danych, frontend |
| Poziom | technologie użyte w projektach, z krótkim opisem gdzie je zastosowałeś | gwiazdki, skale 1-10 i hasła bez kontekstu |
| Narzędzia | GitHub, Docker, Postman, Figma, VS Code | wszystko, co choć raz otworzyłeś na kursie |
| Języki | angielski B1/B2, jeśli realnie czytasz dokumentację | „komunikatywny” bez żadnego przykładu użycia |
Jeśli aplikujesz na konkretną ofertę, dopasuj kolejność technologii do ogłoszenia. Nie chodzi o manipulację, tylko o czytelność. W praktyce rekruter chce w kilka sekund zobaczyć, że masz przynajmniej część wymaganego stacku i potrafisz to nazwać bez zbędnego ozdobnictwa. Następny krok to pokazanie, skąd wzięły się Twoje kompetencje, jeśli nie z etatu.
Jak pokazać doświadczenie, którego formalnie nie było
Brak etatowego stażu nie oznacza pustego CV. W IT bardzo liczy się aktywność poza pracą, bo to właśnie ona często pokazuje, czy ktoś dowozi rzeczy do końca. Jeśli zrobisz to dobrze, rekruter widzi nie „brak doświadczenia”, tylko „kandydat z udokumentowaną praktyką”.
- Kursy i bootcampy - wpisz je, jeśli obejmowały realny projekt końcowy, a nie tylko oglądanie lekcji.
- Projekty własne - domowe aplikacje, skrypty, automatyzacje, małe narzędzia.
- Open source - nawet drobny pull request pokazuje, że potrafisz pracować na cudzym kodzie.
- Hackathony i konkursy - ważne, bo pokazują tempo, współpracę i odporność na presję czasu.
- Staż, praktyki, wolontariat technologiczny - jeśli był choć krótki, opisz go konkretnie: zakres, narzędzia, efekt.
Kiedy ta warstwa jest uczciwie pokazana, pozostaje kwestia formy, a ta w IT ma większe znaczenie, niż wiele osób zakłada.
Jaki układ i format działają najlepiej w IT
W 2026 nie wygrywa samo „ładne PDF”. Wygrywa dokument, który jest czytelny dla człowieka i bezproblemowy dla systemów ATS, czyli narzędzi używanych do wstępnej selekcji kandydatów. Ja trzymam się prostej zasady: jeśli element wygląda efektownie, ale utrudnia skanowanie treści, zwykle szkodzi bardziej niż pomaga.
| Element | Rekomendacja | Dlaczego to działa |
|---|---|---|
| Długość | 1 strona, maksymalnie 2 przy większej liczbie projektów | łatwiej przejść przez preselekcję i szybciej widać sedno |
| Format pliku | zachowuje układ i wygląda tak samo na różnych urządzeniach | |
| Układ | prosty, jednokolumnowy lub bardzo oszczędny dwukolumnowy | ułatwia odczyt przez ATS i przez człowieka |
| Font | czytelny, bez ozdób, 10-12 pkt | tekst ma być szybki do przeskanowania |
| Nazwa pliku | Imie_Nazwisko_CV_Junior_React.pdf | porządek od razu po stronie rekrutera |
Unikaj kluczowych informacji w tabelkach, nagłówkach, stopkach i grafikach, bo część systemów rekrutacyjnych odczytuje je słabo. Zdjęcie nie jest tu najważniejsze, więc nie poświęcaj mu miejsca kosztem treści. Jeśli chcesz, żeby dokument wyglądał profesjonalnie, postaw na konsekwencję i hierarchię, nie na fajerwerki. Z takiego układu bardzo łatwo przejść do listy błędów, które najczęściej psują cały efekt.
Najczęstsze błędy, które psują pierwsze wrażenie
Przy juniorach błędy powtarzają się zaskakująco często, a większość z nich da się wyeliminować w kwadrans. Najbardziej szkodzi miętolenie ogólników i udawanie seniora. Dobry rekruter bardzo szybko wyczuje, czy kandydat pokazuje realny warsztat, czy tylko zlepia modne hasła.
- Zbyt ogólne wstępy - „chcę rozwijać się w IT” niczego nie mówi. Lepiej od razu podać stack i kierunek.
- Brak linków - jeśli rekruter nie może wejść do repozytorium albo zobaczyć demo, projekt traci połowę wartości.
- Pompowanie umiejętności - wszystko, czego nie umiesz wytłumaczyć, prędzej czy później wyjdzie na rozmowie.
- Przeładowanie grafiką - kreatywne CV może wyglądać dobrze na ekranie, ale utrudnia szybkie czytanie i selekcję.
- Błędy językowe i chaos - literówki, niespójne daty i przypadkowa interpunkcja obniżają wiarygodność.
- Brak dopasowania do ogłoszenia - to samo CV wysłane wszędzie daje zwykle słabszy efekt niż wersja pod konkretną ofertę.
Najlepszy test jest prosty: czy po przeczytaniu Twojego CV ktoś wie, czym chcesz się zajmować i gdzie może sprawdzić Twoje umiejętności? Jeśli nie, dokument trzeba skrócić, doprecyzować albo przerobić. Ostatnia rzecz to przygotowanie go tak, by każda wysyłka była świadoma, a nie masowa.
Zanim wyślesz pierwsze aplikacje, dopracuj te elementy
Na końcowym etapie liczą się małe rzeczy, bo właśnie one często odróżniają CV „niby gotowe” od CV, które faktycznie działa. Ja przed wysyłką sprawdzam zawsze pięć rzeczy: czy profil pasuje do ogłoszenia, czy linki działają, czy projekty mają opis i README, czy sekcja umiejętności jest uczciwa oraz czy plik ma sensowną nazwę. To zajmuje kilka minut, a potrafi oszczędzić wiele pustych aplikacji.
- Przygotuj jedną wersję główną i 2-3 warianty pod różne technologie, zamiast zmieniać wszystko od zera.
- W pierwszym akapicie CV pokaż kierunek: front-end, backend, data, testing albo full stack.
- Do każdego projektu dopisz 1-2 zdania o decyzjach technicznych, bo to dobrze działa na rozmowie.
- Sprawdź profile publiczne, zwłaszcza GitHub i LinkedIn, bo rekruterzy naprawdę tam zaglądają.
- Jeśli masz mało treści, nie sztucznie wydłużaj dokumentu. Lepiej zostawić jedną stronę konkretu niż dwie strony pustych fraz.
Jeśli potraktujesz CV jak krótki dowód na to, że umiesz budować i opisywać rzeczy, a nie jak formalność do wysłania, od razu będzie mocniejsze. W praktyce najwięcej daje prostota, uczciwość i projekty, które da się sprawdzić jednym kliknięciem.
