Dlaczego CV juniora IT jest od razu odrzucane
Jak rekruter IT i team leader naprawdę czytają CV
Dla juniora CV to często dopieszczony dokument, nad którym siedzi się godzinami. Po drugiej stronie biurka wygląda to zupełnie inaczej. Rekruter HR lub osoba techniczna, która robi preselekcję, ma przed sobą dziesiątki, czasem setki zgłoszeń. Na jedno CV przypada zwykle kilkanaście–kilkadziesiąt sekund. W tym czasie trzeba odpowiedzieć na jedno pytanie: „Czy to ma sens jako kandydat na to konkretne stanowisko?”.
Najpierw skanowany jest nagłówek (imię, stanowisko, miejsce), potem sekcja umiejętności technicznych i projekty. Dopiero później – jeśli cokolwiek zainteresuje – przechodzi się do doświadczenia, edukacji i reszty. Jeśli czytelnik po kilku sekundach nie widzi jasnego profilu, pasującego do ogłoszenia, CV ląduje w folderze „odrzucone”, często bez żadnego komentarza zwrotnego.
Team leader lub developer, który pomaga przy preselekcji, patrzy jeszcze ostrzej: szuka konkretnych dowodów, że kandydat coś realnie zrobił w kodzie. Nie interesuje go ogólny opis „znam Reacta”, tylko link do repozytorium, opis projektu i choćby zgrubne liczby: ile funkcji, ile modułów, jaki problem rozwiązywała aplikacja. Jeśli tego nie widzi, zakłada, że to tylko teoria z kursu.
Dlaczego CV juniora musi być inne niż CV mida czy seniora
Doświadczeni programiści grają inną grę. Mają lata pracy komercyjnej, konkretne firmy, projekty, systemy w portfolio. Rekruter czyta ich CV, żeby ocenić, co dokładnie robili i jak duża odpowiedzialność na nich spoczywała. U juniora tego po prostu nie ma – cała uwaga ląduje więc na potencjale i dowodach, że dana osoba jest w stanie wejść w prawdziwy projekt, uczyć się i domykać zadania.
Mit, który niszczy wiele pierwszych aplikacji: „Muszę mieć jak najdłuższe CV, żeby wyglądało poważnie”. Rzeczywistość jest odwrotna – dla juniora liczy się kilka dobrze opisanych projektów, sensowny profil i realistyczna lista technologii. Historia zawodowa spoza IT, rozbudowane opisy szkolnych praktyk czy hobbystyczne detale bez powiązania z IT tylko rozmywają obraz.
Senior może mieć CV z historią kariery na trzech stronach. Junior programista, który dopiero startuje, wygrywa przejrzystością i selekcją treści: pokazuje to, co najbardziej pasuje do roli, o którą się stara, zamiast wszystkiego, co kiedykolwiek zrobił.
Mit „wystarczy znać dużo technologii, a CV się obroni”
Popularny scenariusz: pierwsze CV do pracy w IT zawiera długą, imponującą listę technologii – od Javy przez Pythona, DevOps, front-end, aż po chmurę i machine learning. Brzmi to efektownie dla samego kandydata, ale dla doświadczonej osoby po drugiej stronie to czerwona flaga. Nikt nie jest w stanie opanować tylu narzędzi na sensownym choćby poziomie w krótkim czasie, szczególnie na starcie.
Rekruter techniczny bardzo szybko wyłapuje „encyklopedyczne CV” – wygląda tak, jakby ktoś kopiował listy technologii z ogłoszeń. Brakuje w nim powiązania: konkretne zadania → konkretne narzędzia → konkretny efekt. Zamiast budować zaufanie, takie CV je niszczy, bo sugeruje, że kandydat albo zawyża swoje umiejętności, albo nie rozumie, co w ogóle jest ważne dla danego stanowiska.
Liczy się spójny obraz: kilka głównych technologii, które są naprawdę używane w projektach, i uczciwy opis znajomości pozostałych. Krótkie doprecyzowanie „poziom podstawowy”, „poznane w trakcie kursu”, „używane w jednym projekcie” jest dużo bardziej wiarygodne niż bezrefleksyjne wrzucenie piętnastu haseł w jednej linijce.
CV jako filtr bezpieczeństwa, a nie ostateczna ocena
Etap preselekcji to nie konkurs piękności. CV juniora IT rzadko kogo zachwyci, ale może bezpiecznie przejść przez filtr. Rekruter szuka przede wszystkim powodów, żeby nie ryzykować czasu zespołu na rozmowę: brak dopasowania technologicznego, chaos w profilu, wątpliwa wiarygodność czy kompletny brak projektów.
Mit: „Jeśli nie mam idealnego CV, nie mam szans”. Rzeczywistość: nikt nie wymaga od juniora CV jak z agencji headhunterskiej. Natomiast kilka kluczowych błędów potrafi zabić szanse już na starcie, zanim ktokolwiek kliknie w link do GitHuba. Dobrze zrobione CV nie ma być „wow”, tylko jasne, uczciwe i sensownie ułożone. To wystarcza, by dostać zaproszenie na rozmowę.
Błąd #1 – CV bez celu: chaos zamiast jasnego profilu juniora IT
Brak krótkiego profilu kandydata u góry CV
Większość CV juniorów IT zaczyna się od danych kontaktowych i od razu przechodzi do edukacji albo listy umiejętności. Brakuje krótkiego, treściwego opisu profilu, który ustawia kontekst. W efekcie rekruter musi sam zgadywać: „To bardziej backendowiec, frontendowiec, tester, a może ktoś jeszcze szuka kierunku?”. Im więcej zgadywania, tym większa szansa, że CV zostanie pominięte.
Dobry profil na górze CV działa jak nagłówek artykułu: mówi, o czym jest cała reszta. Dla juniora IT to 2–3 zdania, w których pojawia się:
- docelowa rola („Junior Java Developer”, „Junior QA Engineer”, „Junior Frontend Developer”),
- etap kariery („w trakcie przebranżowienia z księgowości na IT”, „absolwent informatyki”, „po intensywnym bootcampie”),
- konkretny akcent na projekty/technologie („buduję aplikacje w React”, „piszę testy automatyczne w Pythonie i Selenium”).
Brak takiego profilu to pierwszy sygnał, że kandydat nie do końca wie, czego szuka. Rekruter ma wtedy znacznie mniej cierpliwości, żeby przedzierać się przez dalszą część dokumentu.
Niespójne stanowiska w nagłówku – jak wygląda to z drugiej strony
Spotykany nagminnie błąd: pod imieniem i nazwiskiem widnieje coś w stylu: „Junior Developer / Tester / Data Analyst / DevOps / Admin”. To próba złapania wszystkiego naraz, żeby „trafić” w jakieś ogłoszenie. Z punktu widzenia osoby rekrutującej to wygląda jak brak decyzji i brak podstawowej samoświadomości, w czym kandydat w ogóle jest najlepszy.
Rekruter nie będzie dopasowywał twojego CV do różnych ról za ciebie. To kandydat ma wskazać jeden główny kierunek. Można oczywiście łączyć rzeczy sensownie powiązane („Junior Java / Kotlin Developer”), ale łączenie testów, devopsów, analizy danych i frontendu w jednym nagłówku sprawia wrażenie chaosu: „uczę się wszystkiego po trochu, więc niczego porządnie”.
Jeśli naprawdę bierzesz pod uwagę dwie ścieżki (np. testy i backend), lepiej przygotować dwie osobne wersje CV, lekko zmodyfikowane pod każde ogłoszenie, zamiast jednego „kombajnu” na wszystkie okazje.
Jak zdefiniować swój profil jako junior IT w 2–3 zdaniach
Dobrze napisany profil kandydata nie musi być literackim popisem. Chodzi o to, aby w kilku krótkich zdaniach dać odpowiedź na pytanie: „Kim jestem w IT dzisiaj i dokąd chcę iść?”. Poniżej kilka realistycznych wzorów, które można dostosować do siebie:
- „Junior Frontend Developer w trakcie przebranżowienia z marketingu, skupiony na JavaScript i React. Tworzę responsywne aplikacje SPA, mam na koncie kilka projektów w Next.js i TypeScript opublikowanych na GitHubie. Szukam pierwszej roli w zespole, w którym będę rozwijać się w kierunku frontendu produktowego.”
- „Absolwent informatyki i początkujący Java Developer. Buduję proste aplikacje webowe w Spring Boot i REST API, pracuję z bazami danych SQL i Git. Interesuje mnie rozwój w backendzie i nauka dobrych praktyk w komercyjnym zespole.”
- „Junior QA Engineer po bootcampie testowania i kilku miesiącach własnych projektów. Piszę testy manualne i automatyczne w Pythonie (pytest, Selenium), znam podstawy pracy z API i narzędziami typu Postman. Szukam wejścia do zespołu, gdzie będę łączyć testy manualne z automatyzacją.”
Takie 2–3 zdania już na starcie pomagają rekruterowi zakwalifikować cię do odpowiedniego stosu technologicznego i odpowiedniej roli. Całe CV pracuje wtedy na jedną, jasno zdefiniowaną historię.
Mieszanie kursów, hobby i starego zawodu bez kontekstu
Osoby przebranżawiające się do IT często wpisują do CV wszystko, co kiedykolwiek robiły: kompletną historię zawodową, każdy kurs online, zainteresowania od gór po jazdę na deskorolce. Bez spójnego profilu u góry dokument zamienia się w zbiór przypadkowych faktów. Rekruter nie ma narzędzi, żeby z tego złożyć sensowną opowieść.
Sama informacja „pracowałem w sprzedaży” niewiele daje. Jeśli jednak pokażesz to przez pryzmat przejścia do IT – np. „5 lat w sprzedaży B2B, doświadczenie w rozmowach z klientami, obecnie wykorzystuję to przy tworzeniu aplikacji nastawionych na użytkownika” – dostajesz plus za kompetencje miękkie i logikę zmiany branży.
Zamiast listować wszystkie kursy, lepiej wybrać te, które są faktycznie powiązane z rolą juniora IT i dodać 1–2 zdania, co z nich wyniosłeś. „Kurs Javy – 50h materiału” nic nie znaczy. „Kurs Javy – stworzyłem 3 aplikacje konsolowe i jedną prostą aplikację webową, pracowałem z kolekcjami, relacyjną bazą danych i podstawami Spring Boot” – pokazuje, co umiesz.
Błąd #2 – Zbyt ogólny, pusty opis umiejętności technicznych
Lista technologii bez kontekstu – efekt braku wiarygodności
Jedna z najczęstszych pułapek w CV juniora: sekcja „Umiejętności techniczne” wygląda jak wynik wyszukiwania w Google. Przykładowa linijka: „Java, Python, C#, SQL, Git, Docker, Kubernetes, AWS, React, Angular, Vue, HTML, CSS, JavaScript”. Dla początkującego brzmi to imponująco. Dla developera, który patrzy na takie CV, to sygnał, że kandydat nie ma dystansu do własnych kompetencji.
Nawet jeśli ktoś liznął każdej z tych technologii po kilka godzin, z punktu widzenia pracy w zespole to wciąż poziom turystyczny. Zespół potrzebuje kogoś, kto na poziomie juniora poradzi sobie w jednej, dwóch głównych technologiach, a resztę będzie stopniowo nadrabiał. Długa lista bez wskazania, gdzie jest rdzeń kompetencji, a gdzie tylko podstawy, budzi sceptycyzm.
Mit: „Im dłuższa lista technologii, tym lepiej”. Rzeczywistość: im dłuższa lista bez wyjaśnienia, tym bardziej wygląda to jak CV pisane pod wyszukiwarkę, a nie pod realne zadania. Rekruter techniczny będzie chciał to zweryfikować i zada pytania z losowo wybranych pozycji. Jedno, dwa nietrafione pytania wystarczą, żeby uznać, że cała lista jest mocno na wyrost.
Oddzielenie technologii głównych od pobieżnie poznanych
Dla przejrzystości opłaca się podzielić sekcję umiejętności na dwie części. Dzięki temu komunikujesz, w czym naprawdę możesz od razu pracować, a co dopiero eksplorujesz. Przykładowy układ:
- Technologie główne: Java (OOP, kolekcje, podstawy Spring Boot), SQL (proste zapytania, joiny, indeksy), Git (praca na branchach, merge, pull requesty), Maven/Gradle.
- Technologie poznane podstawowo: Docker (proste obrazy, docker-compose), Linux (nawigacja, praca w terminalu), HTML/CSS (podstawowe layouty), JavaScript (skrypty na potrzeby formularzy).
Taka struktura jest uczciwa i czytelna. Pokazuje, gdzie można się ciebie spodziewać jako realnego kontrybutora, a gdzie dopiero zaczyna się twoja nauka. Dla rekrutera to informacja: „Ten kandydat ma świadomość swojego poziomu i nie próbuje na siłę udawać mida”.
Jeśli aplikujesz konkretnie jako junior frontend developer, logiczne jest, że twoje „technologie główne” to np. JavaScript, React, HTML, CSS, a „poznane podstawowo” to Typescript, Node.js, Webpack. Układ sekcji powinien wzmacniać profil z nagłówka, zamiast go rozmywać.
Opisywanie umiejętności przez pryzmat użycia w projektach
Nagie nazwy technologii niewiele mówią. O wiele silniejszy efekt daje połączenie: technologia + rodzaj zadania/projektu. Przykład:
- React: stworzenie SPA do zarządzania zadaniami (listy, filtry, stan globalny w Redux Toolkit), integracja z REST API.
- Python: kilka skryptów do automatyzacji zadań (pobieranie danych z API, proste przetwarzanie plików CSV), podstawy testów jednostkowych (pytest).
- SQL: projekt bazy danych dla systemu rezerwacji (tabele powiązane relacjami, kilka widoków, złożone zapytania z grupowaniem i podzapytaniami).
Taki opis sprawia, że rekruter od razu widzi konkretne zastosowania. Łatwiej mu też wyobrazić sobie, jakie zadania możesz wykonywać w projekcie: „Ten kandydat potrafi już zbudować prostą aplikację w React, więc z pomocą zespołu ogarnie widok listy produktów w naszym panelu admina”.
Samopoziomowanie umiejętności (gwiazdki, procenty) bez kryteriów
Popularny element CV juniora: tabelka z umiejętnościami i samodzielnie przyznanymi „poziomami”. Java – 4/5, Python – 3/5, Git – 5/5, SQL – 2/5. Wygląda to efektownie graficznie, ale merytorycznie jest puste, jeśli nie stoi za tym żadne odniesienie do realnych zadań.
Problem jest prosty: nikt nie wie, co znaczy twoje „4/5 z Javy”. Dla jednej osoby to „przeszedłem kurs online”, dla innej „zdałem trudny egzamin na studiach”, a dla kogoś jeszcze „napisałem kilka aplikacji produkcyjnych”. Rekruter nie będzie się domyślał. Jeśli widzi 5/5 z Gita, a na rozmowie okazuje się, że nie rozumiesz rebase ani rozwiązywania konfliktów, zaufanie do całego CV gwałtownie spada.
Lepsze podejście: zamiast abstrakcyjnych gwiazdek pokaż konkretne działania i zakres, z którym miałeś styczność. Zamiast „Java – 4/5” napisz „Java – OOP, kolekcje, wyjątki, prosty REST API w Spring Boot, testy jednostkowe w JUnit”. To samo w sobie opisuje twój poziom o wiele lepiej niż dowolna ikonka.
Mit: „Ładna grafika z poziomami umiejętności robi wrażenie profesjonalizmu”. Rzeczywistość: dla osoby technicznej ważniejsze jest, czy potrafisz opisać konkretne zadania, które wykonywałeś, używając tych technologii. Gwiazdki nie przesłonią braków w opisie projektów.
Umiejętności miękkie odklejone od realnych sytuacji
Sekcja „umiejętności miękkie” w CV juniora potrafi wyglądać jak generator haseł: „komunikatywność, praca w zespole, kreatywność, zaangażowanie, odpowiedzialność”. Sam zestaw słów jest poprawny, ale kryje w sobie istotny problem – brak dowodu. Jeśli każdy wpisuje to samo, przestaje to cokolwiek odróżniać.
Zamiast wypisywać przypadkowe cechy, lepiej wybrać 2–3 i osadzić je w krótkim kontekście. Na przykład:
- Praca w zespole: 6-miesięczny projekt grupowy na studiach (3 osoby), wspólne repozytorium Git, code review, cotygodniowe statusy.
- Komunikacja z klientem: 4 lata pracy w obsłudze klienta B2B; prowadzę rozmowy telefoniczne i spotkania, obecnie przekładam to na zbieranie wymagań do aplikacji.
- Samodzielna nauka: regularne zadania na Codewars/LeetCode, utrzymywanie githubowego repozytorium z małymi projektami (co najmniej kilka commitów tygodniowo).
Takie mini-przykłady pokazują, że za hasłem stoi konkretne zachowanie. Rekruter od razu wie, o co dopytać na rozmowie. Same słowa-klucze bez kontekstu w praktyce nic nie wnoszą.
Błąd #3 – Źle opisane lub kompletnie niewidoczne projekty
Projekty schowane na dole CV albo tylko jako link do GitHuba
U juniora projekty są najważniejszym dowodem na umiejętności. Mimo to w wielu CV lądują na samym dole, pod kursami, językami, a czasem nawet pod hobby. Niekiedy cała sekcja „projekty” to jedno zdanie „Więcej projektów na GitHubie: link”. Dla osoby przeglądającej dziesiątki CV dziennie to sygnał: „żeby zobaczyć, czy ten kandydat cokolwiek umie, muszę jeszcze grzebać po repozytoriach”. W praktyce mało kto to zrobi.
Projekty powinny być wyeksponowane wysoko – zaraz po profilu i umiejętnościach technicznych, a nawet przed doświadczeniem zawodowym, jeśli twoje dotychczasowe role nie były związane z IT. To one pokazują, że potrafisz przejść cały cykl: od pomysłu, przez implementację, po działający efekt.
Mit: „Wrzucę link do GitHuba, jak kogoś zainteresuje, to sobie sam poszuka”. Rzeczywistość: jeśli sam nie zrobisz selekcji i nie opiszesz 2–3 kluczowych projektów, małe są szanse, że rekruter będzie na to tracił czas.
Opis projektu bez kontekstu biznesowego lub użytkowego
Częsty widok: „Aplikacja ToDo w React”, „Aplikacja bankowa w Javie”, „API do zarządzania użytkownikami”. Koniec opisu. Brakuje odpowiedzi na elementarne pytania: po co ten projekt powstał, jaki problem rozwiązuje, co może zrobić użytkownik.
O wiele mocniejszy przekaz daje prosty układ opisu:
- Cel / opis: co robi projekt i dla kogo mógłby być przydatny.
- Stos technologiczny: konkretne technologie backend/front, bazy danych, narzędzia.
- Zakres odpowiedzialności: co dokładnie zrobiłeś ty (zwłaszcza przy projekcie grupowym).
- Najważniejsze funkcje / wyzwania: 2–3 rzeczy, którymi możesz się pochwalić technicznie.
Przykładowy opis w stylu juniora backend:
„System rezerwacji wizyt dla małego gabinetu (projekt własny). Umożliwia rejestrację użytkowników, przegląd dostępnych terminów i rezerwację wizyty z potwierdzeniem e-mail. Backend w Spring Boot, REST API, baza danych PostgreSQL (relacje między klientami, wizytami i usługami), bezpieczeństwo oparte na JWT. Odpowiadałem za model bazy, logikę rezerwacji (walidacja nakładających się terminów) i integrację z prostą usługą wysyłki maili.”
Taki opis daje rekruterowi mnóstwo punktów zaczepienia do rozmowy technicznej, a jednocześnie pokazuje, że rozumiesz projekt także od strony użytkownika, nie tylko od strony kodu.
Brak informacji o skali i złożoności projektu
„Aplikacja w React” może znaczyć wszystko – od jednej strony z formularzem do rozbudowanego panelu z routingiem i stanem globalnym. Bez opisu skali rekruter nie wie, z czym ma do czynienia. Podobnie „API w Spring” – może to być jeden endpoint albo kilkanaście zasobów z autoryzacją i walidacją.
Warto dodać dosłownie kilka danych, które zarysują rozmiar:
- liczbę kluczowych widoków / modułów,
- liczbę głównych encji/bibliotek,
- informację, czy jest logowanie/rejestracja, uprawnienia, obsługa błędów, testy,
- czy projekt jest wdrożony gdzieś publicznie (np. Vercel, Netlify, Railway, Render).
Przykład krótkiego doprecyzowania: „Front: 6 głównych widoków (lista, szczegóły, koszyk, checkout, historia zamówień, panel admina), routing w React Router, globalny stan w Redux Toolkit, basic auth, walidacja formularzy po stronie klienta.” Od razu widać, że to coś więcej niż „Hello World”.
Brak rozróżnienia między projektami kursowymi a własnymi
Rekruterzy techniczni szybko rozpoznają sztandarowe projekty z popularnych kursów. Sama ich obecność nie jest problemem – każdy jakoś zaczyna. Problemem jest sytuacja, gdy w CV nic nie wskazuje, że potrafisz pójść krok dalej niż dokładne odtworzenie przykładu z tutoriala.
W opisie projektów kursowych warto jasno napisać, co było częścią materiału, a co zrobiłeś ponad to. Na przykład:
- „Projekt realizowany w ramach kursu X: początkowa wersja aplikacji (lista zadań, dodawanie/usuwanie) według instrukcji prowadzącego.
- Rozszerzenia własne: logowanie użytkowników, filtrowanie zadań po statusie, zapis w bazie danych, testy jednostkowe kilku kluczowych funkcji.”
Pokazujesz wtedy, że nie tylko śledzisz kurs, ale też potrafisz samodzielnie rozwijać projekt. To właśnie ta umiejętność „robienia kroku dalej” jest kluczowa w pierwszej pracy.
Mit: „Lepiej nie przyznawać się, że projekt jest z kursu, bo wyjdzie, że jestem początkujący”. Rzeczywistość: i tak wiadomo, że jesteś początkujący – ukrywanie tego budzi tylko nieufność. O wiele lepiej otwarcie pokazać, co zrobiłeś ponad minimum.
Nieklikalne linki i bałagan na GitHubie
Link do GitHuba w CV to za mało, jeśli repozytoria są chaotyczne: nazwy typu „test”, „nowe-repo-3”, brak README, kilka porzuconych projektów bez commita od roku. Z takiego profilu trudno cokolwiek wyczytać. Dodatkowo wiele osób wkleja linki jako czysty tekst, bez hiperlacza – na ekranie rekrutera to często dosłownie nieklikalna linijka.
Dużo lepiej działa podejście „mniej, ale porządnie”. Można:
- wybrać 2–4 repozytoria, które są aktualne i dopracowane,
- nazwać je jasno: task-manager-react, booking-api-spring,
- dodać sensowny README z opisem, technologiami, instrukcją uruchomienia, krótkimi zrzutami ekranu lub gifem,
- umieścić w CV bezpośrednie linki do tych konkretnych repozytoriów oraz ewentualnie link do profilu głównego.
Jeśli masz wdrożoną wersję demo (np. na Netlify, Vercel, Render), podaj także link do działającej aplikacji. Możliwość kliknięcia i zobaczenia efekty w przeglądarce robi znacznie większe wrażenie niż suchy kod.
Błąd #4 – Brak konkretnych efektów i liczb, sama „poezja” w opisach
„Uczestniczyłem”, „odpowiadałem za”, „brałem udział” – ale co z tego wyszło?
Opisy doświadczenia i projektów u juniorów często składają się z ogólnych sformułowań: „uczestniczyłem w tworzeniu aplikacji”, „odpowiadałem za rozwój funkcjonalności”, „brałem udział w testowaniu”. Problem nie w tym, że te zdania są błędne, tylko w tym, że nic konkretnego z nich nie wynika.
Osoba rekrutująca chce wiedzieć, co dokładnie zrobiłeś i jaki był rezultat. Nawet jeśli projekt był mały, da się z niego wyciągnąć twarde elementy. Zamiast „uczestniczyłem w projekcie aplikacji sklepu internetowego” lepiej napisać:
- „Zaimplementowałem moduł koszyka (dodawanie/usuwanie produktów, przeliczanie wartości, walidacja danych przed przejściem do płatności).”
- „Dodałem paginację i filtrowanie listy produktów po cenie i kategorii.”
- „Napisałem testy jednostkowe dla kluczowych funkcji koszyka (ok. 20 testów w JUnit).”
Nawet bez liczb pokazujesz wtedy konkretne obszary, które możesz wziąć na siebie w nowym zespole.
Jak wprowadzić liczby, nawet jeśli nie masz komercyjnego doświadczenia
„Nie mam doświadczenia, więc nie mam liczb” – to częsty argument. Tymczasem liczby mogą dotyczyć nie tylko KPI firmowych, ale też skali twojej pracy czy postępów w nauce. Kilka przykładów, które nie brzmią sztucznie:
- „Zaimplementowałem ok. 10 endpointów REST (CRUD dla 3 głównych encji + logowanie)”.
- „Napisałem ponad 30 testów jednostkowych i kilka prostych testów integracyjnych.”
- „Aplikacja frontowa ma 8 kluczowych widoków i około 15 komponentów wielokrotnego użytku.”
- „Pracuję regularnie z Git – ponad 200 commitów w głównym projekcie w ostatnich 3 miesiącach.”
Takie dane pokazują, że nie zatrzymałeś się na jednym tutorialu, tylko faktycznie robisz coś systematycznie. Nie muszą być perfekcyjnie precyzyjne – ważne, żeby nie były kompletnie z sufitu.
Używanie „poezji” zamiast technicznych konkretów
Część kandydatów próbuje nadrobić brak efektów barwnymi opisami: „tworzenie nowoczesnych rozwiązań IT”, „wdrażanie innowacyjnych funkcjonalności”, „dostarczanie wysokiej jakości oprogramowania”. Brzmi to jak fragment ulotki marketingowej, a nie CV developera. Problem w tym, że z takich zdań nie wynika ani technologia, ani zakres odpowiedzialności.
O wiele lepiej sprawdza się prosty, konkretny język: „napisałem”, „wdrożyłem”, „zoptymalizowałem”, „zaprojektowałem model”, „przeniosłem logikę do osobnej klasy”, „zastąpiłem X rozwiązaniem Y”. Opis w stylu:
„W projekcie systemu rezerwacji dodałem walidację zapytań po stronie backendu (Spring Validation), obsługę wyjątków przez globalny handler i logowanie błędów w formacie JSON, co ułatwiło debugowanie aplikacji.”
jest o klasę bardziej wiarygodny niż:
„Zapewniałem wysoką jakość i niezawodność aplikacji dla wymagającego klienta.”
Mit: „Trzeba pisać mądrze brzmiącym językiem, bo tak robią profesjonaliści”. Rzeczywistość: w rekrutacji technicznej wygrywa prosty opis, który wskazuje technologie, konkretne działania i ich konsekwencje.
Konkrety w doświadczeniu spoza IT
Nawet jeśli dotychczas działałeś w całkiem innej branży, da się z tego wyciągnąć twardsze elementy niż „obsługa klienta” czy „odpowiedzialność za wyniki sprzedaży”. Krótkie liczby robią tu dużą różnicę:
- „Prowadziłem średnio 20–30 rozmów telefonicznych dziennie z klientami B2B.”
- „Szkoliłem 3–4 nowe osoby w zespole rocznie z procedur i systemów wewnętrznych.”
- „Pracowałem równocześnie nad kilkunastoma aktywnymi sprawami klientów, korzystając z systemu CRM.”
Jak „uszyć” kilka mocnych zdań pod konkretną ofertę
Opis doświadczenia i projektów nie musi być uniwersalny na całe życie. CV, które działa, jest często delikatnie modyfikowane pod konkretną rekrutację. Nie chodzi o kłamstwa, tylko o podkreślenie tego, co jest najbliżej wymagań z ogłoszenia.
Przykład: w ofercie padają słowa kluczowe: React, TypeScript, REST API, Git, testy jednostkowe. Jeśli masz projekt, w którym te rzeczy się pojawiają, w opisie zrób na nie pierwszy plan:
- „Aplikacja SPA w React + TypeScript, ok. 8 widoków, stan globalny w Redux Toolkit.”
- „Integracja z REST API (pobieranie listy zadań, dodawanie, edycja, usuwanie, obsługa błędów).”
- „Testy jednostkowe kilku kluczowych komponentów w React Testing Library.”
Jeśli rekruter zobaczy w pierwszych sekundach te same słowa co w wymaganiach, rośnie szansa, że w ogóle zagłębi się w resztę.
Mit: „CV musi być jedno, uniwersalne, bo inaczej to manipulacja”. Rzeczywistość: zmieniasz priorytety, nie fakty. Dokładasz ostrości tam, gdzie pracodawca ma konkretne potrzeby.
Łączenie „poezji” z konkretami – krótki schemat
Jeśli już chcesz użyć ogólnego zdania typu „dbałem o jakość kodu”, podeprzyj je jednym technicznym przykładem. Zamiast:
„Dbałem o jakość kodu i optymalną architekturę projektu.”
napisz:
„Dbałem o jakość kodu – wydzieliłem logikę biznesową do osobnych serwisów, co uprościło testowanie i ponowne użycie kodu.”
Nadal brzmi „ładnie”, ale da się z tego wyciągnąć temat na rozmowę: jak projektujesz serwisy, jak testujesz, jak dzielisz odpowiedzialności.
Błąd #5 – Zły porządek informacji: to, co ważne, ginie w tle
Najważniejsze 5 sekund – co widać bez scrollowania
Większość rekruterów ogląda CV na ekranie laptopa lub w systemie ATS. Pierwsze, co widzą, to górna połowa pierwszej strony. Jeśli w tym obszarze dominuje ozdobny nagłówek, zdjęcie zajmujące pół szerokości i ogólny opis w stylu „ambitny, komunikatywny, nastawiony na rozwój”, to marnujesz najcenniejsze miejsce.
Dużo rozsądniejszy układ górnej części:
- imię, nazwisko, podstawowe dane kontaktowe,
- krótkie (2–3 linijki) podsumowanie profilu technicznego,
- zajawka sekcji „Umiejętności” – kluczowe technologie w jednej linii,
- linki: GitHub, portfolio, LinkedIn.
To, czy zdjęcie jest po lewej czy po prawej, naprawdę ma drugorzędne znaczenie. Kluczowe jest, żeby w pierwszym widoku dało się odpowiedzieć na pytanie: „czy ta osoba w ogóle pasuje technologicznie do ogłoszenia?”.
Doświadczenie vs projekty – co wyżej u juniora
U kandydata z kilkuletnim stażem sekcja „Doświadczenie zawodowe” jest naturalnie najwyżej. U juniora bywa odwrotnie: najciekawszą częścią są projekty, na których faktycznie pisał kod, a nie wcześniejsza praca np. w handlu czy hotelarstwie.
Rozsądny porządek dla typowego juniora IT:
- Podsumowanie profilu (krótkie, techniczne).
- Umiejętności techniczne (stosy, narzędzia).
- Projekty IT (z linkami, opisem roli i efektów).
- Doświadczenie zawodowe spoza IT (skrócone, z 2–3 konkretami).
- Edukacja, kursy, certyfikaty.
Mit: „Doświadczenie zawodowe zawsze musi być nad projektami, bo tak wygląda klasyczne CV”. Rzeczywistość: rekruter techniczny szuka śladów programisty, nie kolejności z szablonu sprzed 15 lat.
„Śmieciowe” sekcje, które wypychają treść techniczną
Spora część CV juniorów ma rozbudowane fragmenty, które nic nie wnoszą do decyzji o zaproszeniu na rozmowę. Typowe przykłady:
- „Zainteresowania” w stylu: sport, muzyka, książki – nic o tobie nie mówią w kontekście roli technicznej.
- „Umiejętności miękkie” w długich listach: komunikatywność, kreatywność, praca w zespole – to samo piszą wszyscy.
- Długa lista kursów, z których połowy nie pamiętasz i nie masz żadnych efektów (projektu, certyfikatu).
Takie elementy możesz zostawić, ale skrócone i przeniesione niżej. To „ładne dodatki”, nie powód zaproszenia na rozmowę.
Źle użyta oś czasu – wszystko na jednym poziomie
Szablony CV często dorzucają ozdobną oś czasu. Problem pojawia się, gdy na tej samej osi ląduje wszystko: studia, pojedynczy weekendowy kurs, 3-miesięczny projekt, poprzednie etaty. Dla rekrutera to wizualny szum.
Lepsze podejście:
- Doświadczenie i projekty – chronologicznie, od najnowszych, z datami w jednym formacie.
- Kursy – w osobnej sekcji, raczej jako lista (nazwa, organizator, rok).
- Edukacja formalna – jedna, maksymalnie dwie pozycje (studia, technikum), bez rozwlekania programu zajęć.
Gdy wszystko przestaje walczyć o uwagę w jednym miejscu, łatwiej wychwycić, co faktycznie robisz teraz i co robiłeś ostatnio.
Ukrywanie kluczowych informacji w stopce lub marginesach
Czasem najciekawsze rzeczy lądują w najmniej czytanych miejscach: w bocznej kolumnie, w szarej stopce, w mini-ramce na dole. Spotykany klasyk: „Zaawansowane projekty open-source” jako mały bullet w sekcji „Zainteresowania”, a na górze ogólnik typu „student informatyki, szukam pierwszej pracy”.
Jeśli coś może zrobić na rekruterze wrażenie (kontrybucje do OSS, hackathony, własne narzędzia), wrzuć to do sekcji projektów lub doświadczenia i opisz normalnie, z 2–3 zdaniami i linkiem. Marginesy zostaw na rzeczy naprawdę poboczne.
Złe grupowanie technologii – wszystko w jednym wierszu
Duże ściany tekstu z technologiami to kolejny powód odrzucenia CV po kilku sekundach. Gdy rekruter widzi linię w stylu:
„Java, Spring, React, Angular, Vue, Node.js, Python, Django, C#, .NET, Docker, Kubernetes, AWS, Azure, GCP, MySQL, PostgreSQL, MongoDB, Redis, RabbitMQ…”
to nie wie, w czym faktycznie jesteś w stanie cokolwiek zrobić samodzielnie. Wygląda to jak kopia z „Top 100 technologies 2024”.
Rozsądne grupowanie:
- Główne technologie (komercyjnie / projektowo): 3–6 rzeczy, w których się poruszasz swobodniej.
- Podstawy / w trakcie nauki: kilka technologii, które dopiero poznajesz.
- Narzędzia: Git, Docker, Jira, Postman itp.
Taki podział ułatwia rekruterowi dopasowanie twojego profilu do faktycznych zadań. I zabezpiecza cię przed sytuacją, w której ktoś zadaje pytania o narzędzie, które „dodałeś, bo było w kursie”.
Tabelki z procentami i „gwiazdkami” bez znaczenia
Popularny element szablonów: ocena własnych umiejętności w procentach albo za pomocą gwiazdek. Dla rekrutera „Java – 70%” czy „React ★★★★☆” nie znaczy nic. Nie ma wspólnej skali, więc nie da się tego porównać między kandydatami ani z oczekiwaniami roli.
Zamiast rysować pasek postępu, pokaż:
- konkretne projekty, w których użyłeś tej technologii,
- zakres – co potrafisz (CRUD, autoryzacja, testy, integracje),
- skale – ile kodu napisałeś, ile modułów ogarnąłeś.
Mit: „Procenty i gwiazdki wyglądają profesjonalnie”. Rzeczywistość: wyglądają efektownie w szablonie, ale nie pomagają podjąć decyzji o zaproszeniu na rozmowę. Konkrety z projektów robią tę robotę znacznie lepiej.
Jedna strona czy dwie? Problem rozwlekłego CV juniora
Spór o długość CV trwa od lat, ale w przypadku juniorów granica jest prosta: jeśli masz głównie projekty i pierwsze doświadczenia, zmieścisz się na jednej stronie, maksymalnie półtorej. Gdy rozlewasz opis na trzy strony, większość osób i tak nie dotrwa do końca.
Dla juniora sensowna zasada:
- 1–2 główne projekty opisane szerzej (po kilka bulletów),
- 2–3 mniejsze projekty wymienione krócej (1–2 zdania),
- streszczone doświadczenie spoza IT (po 2–3 punkty na rolę),
- bez długich akapitów typu „opis kierunku studiów” czy „pełna lista przedmiotów”.
Jeśli coś nie wspiera bezpośrednio obrazu ciebie jako przyszłego developera, skróć albo usuń. To nie raport roczny – to teaser, który ma wywołać chęć rozmowy.
Styl graficzny kontra czytelność – zbyt kreatywne szablony
Część kandydatów próbuje wyróżnić się kolorami, ikonami, nietypowym układem. Kończy się na tym, że kluczowe informacje lądują w kolorowych boxach, w małym foncie albo przełamane na dwie kolumny w dziwnych miejscach. ATS-y (systemy do rekrutacji) mają z tym dodatkowy problem – źle parsują pliki z rozbudowanym formatowaniem.
Bezpieczniejszy kierunek:
- prosty, jednokolumnowy lub czytelny dwukolumnowy układ,
- 2–3 kolory maksymalnie (tekst, nagłówki, akcent),
- bullet pointy zamiast długich bloków tekstu,
- format PDF – ale wygenerowany z edytora tekstu, nie zdjęcie/scan.
Jeśli chcesz pokazać zmysł estetyczny, zrób osobno mini-portfolio frontowe i podlinkuj je w CV. Sam dokument CV nie musi być dziełem sztuki, ma po prostu pozwolić szybko odczytać, kim jesteś technicznie.
Najczęściej zadawane pytania (FAQ)
Jakie są najczęstsze błędy w CV juniora IT, przez które od razu odpada?
Najczęściej CV juniora odpada z powodu braku jasnego profilu (nie wiadomo, czy celujesz w frontend, backend, testy itd.), przesadnie długiej i przypadkowej listy technologii bez żadnych projektów oraz chaosu w układzie dokumentu. Rekruter ma kilkanaście sekund – jeśli po szybkim skanie nie widzi sensownego dopasowania do ogłoszenia, dokument ląduje w koszu.
Częsty błąd to też brak jakichkolwiek linków do GitHuba lub portfolio – przy juniorze to często ważniejsze niż rubryka „doświadczenie”. Dochodzi do tego kopiowanie haseł z ogłoszeń („Znam React, Angular, Vue, Node, Java, Python, AWS…”), bez choć jednego zdania, w jakim projekcie zostało to faktycznie użyte.
Jak powinno wyglądać dobre CV juniora programisty / testera?
Dobre CV juniora IT jest krótkie (najczęściej jedna strona) i zbudowane wokół jednego, jasnego profilu. Na górze znajduje się nagłówek ze stanowiskiem, pod nim 2–3 zdania o tym, kim jesteś w IT dzisiaj, z jakiego punktu startujesz (studia, bootcamp, przebranżowienie) i w czym chcesz się rozwijać.
Dalej idą: lista kluczowych technologii dopasowana do roli, konkretne projekty z krótkim opisem (co zrobiłeś, jakich narzędzi użyłeś, jaki problem rozwiązywała aplikacja), dopiero potem edukacja i doświadczenie spoza IT. Mit: „Im więcej rubryk i opisów, tym lepiej”. Rzeczywistość: im bardziej przejrzyście i celowo, tym większa szansa na zaproszenie.
Czy junior IT powinien mieć jedno czy dwa CV, gdy rozważa różne ścieżki?
Jeśli realnie celujesz w dwie różne ścieżki, lepiej mieć dwie wersje CV niż jedno „do wszystkiego”. Przykład: osobne CV pod „Junior QA Engineer” i osobne pod „Junior Java Developer”, z innym nagłówkiem i minimalnie zmienionym akcentem na projekty oraz technologie.
Łączenie w jednym nagłówku ról w stylu „Junior Developer / Tester / Data Analyst / DevOps” wygląda z drugiej strony jak brak decyzji i brak samoświadomości. Rekruter nie będzie wybierał ścieżki za ciebie – jeśli ty nie wiesz, kim chcesz być, on tym bardziej nie będzie się w to bawił.
Ile technologii wpisać w CV juniora i w jaki sposób?
Lepiej pokazać kilka technologii na sensownym poziomie niż piętnaście haseł „z kursu”. Dobrą praktyką jest podzielenie stacku na 2–4 technologie główne, w których faktycznie coś zbudowałeś, oraz kilka pobocznych, opisanych uczciwie („poziom podstawowy”, „poznane na bootcampie”, „używane w jednym projekcie”).
Mit: „Im dłuższa lista technologii, tym lepiej wyglądam”. Rzeczywistość: długi, encyklopedyczny spis bez projektów budzi podejrzenia, że to tylko kopiuj–wklej z ogłoszeń. Rekruter techniczny szuka połączenia: konkretne zadanie → konkretne narzędzie → konkretny efekt, a nie katalogu buzzwordów.
Czy brak doświadczenia komercyjnego przekreśla CV juniora IT?
Brak doświadczenia komercyjnego nie jest problemem sam w sobie – problemem jest brak czegokolwiek w zamian. Jeśli nie masz firm w CV, to na pierwszy plan muszą wyjść projekty własne, uczelniane, z bootcampu: najlepiej opisane jednym–dwoma zdaniami plus link do repozytorium.
Dla juniora najważniejsze jest pokazanie potencjału: że umiesz doprowadzić zadanie do końca, ogarniasz podstawowe narzędzia (Git, praca z API, prosta baza danych) i potrafisz opisać, co zrobiłeś. CV bez doświadczenia, ale z kilkoma sensownie opisanymi projektami, ma większe szanse niż CV z przypadkową historią zawodową i pustym GitHubem.
Czy CV juniora IT może mieć więcej niż jedną stronę?
W zdecydowanej większości przypadków CV juniora powinno zmieścić się na jednej stronie. Masz po prostu za mało realnego materiału, żeby uzasadnić dwie strony, a rozciąganie dokumentu sztucznymi opisami praktyk czy pracy spoza IT tylko rozmywa obraz.
Wyjątkiem może być sytuacja, gdy masz za sobą kilka większych projektów i jednocześnie istotne doświadczenie techniczne z poprzedniej branży (np. admin sieci w małej firmie). Nawet wtedy lepiej jednak dociąć szczegóły i zostawić tylko to, co rzeczywiście pomaga w rekrutacji na daną rolę.
Jak napisać krótki profil kandydata na górze CV juniora IT?
Profil to 2–3 zdania, w których odpowiadasz na pytania: „Na jakie stanowisko celuję?”, „Z jakiego miejsca startuję?” i „Co już realnie robię w kodzie lub testach?”. Przykład: „Junior Frontend Developer w trakcie przebranżowienia z logistyki, skupiony na JavaScript i React. Buduję proste SPA w Next.js, mam kilka projektów na GitHubie i szukam pierwszej roli w zespole produktowym.”
Mit: „Profil musi brzmieć jak marketingowy slogan.” Rzeczywistość: ważniejsza jest klarowność niż fajerwerki słowne. Rekruter po przeczytaniu profilu ma natychmiast zrozumieć, do jakiej roli cię przypasować i czy w ogóle jest sens przewijać CV dalej.
Bibliografia
- Recruitment and Selection in Organizations. American Psychological Association (2013) – Badania nad preselekcją CV, czasem oceny i filtrami ryzyka
- Recruitment, Interviewing, Selection and Assessment. Kogan Page (2016) – Praktyki rekrutacyjne, rola CV jako narzędzia preselekcji kandydatów
- The CV Book: How to Avoid the Most Common Mistakes and Write a Winning CV. Pearson (2010) – Typowe błędy w CV, znaczenie przejrzystości i dopasowania do ogłoszenia
- Knock 'em Dead Resumes: How to Write a Killer Resume That Gets You Job Interviews. Adams Media (2016) – Struktura CV, profil zawodowy, selekcja treści pod konkretne role
- How to Write a Great Resume for an Entry-Level Job. Harvard Business Review Press (2014) – Wskazówki dla osób na starcie kariery, nacisk na potencjał i projekty
- Recruitment, Retention, and Turnover of IT Staff. Information Systems Management (2011) – Specyfika rekrutacji w IT, oczekiwania wobec kandydatów technicznych
- The Tech Resume Inside Out. Gergely Orosz (2021) – Praktyczne zalecenia dla CV programistów, w tym juniorów i midów
- Guide to Writing Resumes and Cover Letters for Technical Professionals. IEEE Computer Society (2015) – Standardy i dobre praktyki tworzenia CV w zawodach technicznych
