Dobre cv programisty nie wygrywa ozdobnikami, tylko tym, że w kilka sekund pokazuje stack, skalę odpowiedzialności i efekty pracy. W praktyce liczą się trzy rzeczy: czytelny układ, konkretne opisy projektów oraz selekcja informacji, która pasuje do roli, a nie do ego autora. Poniżej rozkładam to na części, które faktycznie pomagają przejść pierwszy skan i dojść do rozmowy.
Najważniejsze zasady, które od razu poprawiają dokument
- Na górze pokaż rolę, stack i 1-2 mocne osiągnięcia, zamiast ogólników o pasji do IT.
- Użyj prostego układu, bo w rekrutacji technicznej czytelność zwykle wygrywa z dekoracją.
- Każdy projekt i stanowisko opisuj przez technologię, zakres odpowiedzialności i efekt.
- Link do GitHuba lub portfolio ma sens tylko wtedy, gdy prowadzi do uporządkowanych materiałów.
- Dokument dopasuj do poziomu: junior sprzedaje potencjał, mid sprzedaje samodzielność, senior sprzedaje decyzje i wpływ.
Co rekruter widzi w pierwszej kolejności
W praktyce rekruter IT najpierw szuka odpowiedzi na cztery pytania: czy kandydat pasuje do roli, jakich technologii używał, czy widać samodzielność i czy można to szybko zweryfikować w linkach albo projektach. To oznacza, że nie trzeba pisać wszystkiego, co kiedykolwiek robiłeś; trzeba pokazać to, co ma znaczenie dla konkretnej oferty. Jeśli dokument od razu nie zdradza specjalizacji, stacku i skali pracy, reszta często nie doczeka się dokładnego czytania.
- tytuł roli i najważniejszy stack
- ostatnie doświadczenie albo najmocniejsze projekty
- konkretne efekty, a nie lista obowiązków
- GitHub, portfolio, LinkedIn, jeśli są dopracowane
Ja zwykle zaczynam od tego, czy kandydat w ogóle wygląda na osobę, której szukamy, bo jeśli ten sygnał jest słaby, układ i grafika niewiele pomogą. Skoro wiemy już, co ma znaleźć się na pierwszym planie, przejdźmy do tego, jak to ułożyć, żeby nie utrudniać sobie życia.
Jak zbudować układ, który pomaga rekruterowi i systemom ATS
Najbezpieczniej działa prosty układ, bez tekstowych sztuczek, wielopiętrowych tabel i ciężkich grafik. W dokumentach technicznych ja zwykle preferuję jedną kolumnę albo bardzo oszczędny układ dwukolumnowy, bo łatwiej go przejrzeć na ekranie telefonu, w PDF-ie i w systemie ATS, czyli oprogramowaniu, które automatycznie odczytuje dane z aplikacji. Jeśli sekcja wymaga szukania informacji po całej stronie, układ już przegrywa.
W IT najczęściej sprawdza się dokument na 1-2 strony. Jedna strona wystarczy wielu juniorom i osobom z krótszym stażem, dwie dają sensowny margines przy większym doświadczeniu. Trzecia strona ma sens tylko wtedy, gdy naprawdę masz długi i istotny dorobek albo działasz w mocno regulowanym środowisku.
| Sekcja | Co wpisać | Czego nie robić |
|---|---|---|
| Dane kontaktowe | Imię i nazwisko, numer telefonu, e-mail, miasto, link do LinkedIna i GitHuba | Adres zamieszkania co do numeru, prywatny mail z nieprofesjonalną nazwą |
| Podsumowanie zawodowe | 3-5 zdań o roli, stacku, skali pracy i kierunku, w jakim chcesz iść | Ogólnik typu „jestem ambitny, szybko się uczę i lubię wyzwania” |
| Doświadczenie | Nazwa firmy, stanowisko, daty i 3-5 punktów z efektami | Bloki tekstu bez konkretu i bez rozróżnienia między obowiązkami a osiągnięciami |
| Projekty | 2-4 najlepsze projekty z opisem problemu, stacku i rezultatu | Wrzucanie wszystkiego, co powstało na kursie, bez selekcji |
| Umiejętności | Logicznie pogrupowane technologie, narzędzia i obszary pracy | Długie listy „wszystkiego po trochu”, które niczego nie potwierdzają |
| Edukacja i certyfikaty | To, co realnie wspiera kandydaturę | Rozbudowana historia szkoły podstawowej albo kursy bez znaczenia |
Jeśli działasz na rynku polskim, zdjęcie w CV jest opcjonalne i w IT zwykle nie daje przewagi samo w sobie. Ja patrzę na nie wyłącznie jako na dodatek, a nie element decydujący. Lepszy jest spokojny, czytelny dokument niż wizualnie przekombinowany plik, którego nie da się łatwo przeskanować. Teraz czas na najważniejszą część: jak opisać to, co naprawdę zrobiłeś.
Jak opisać doświadczenie i projekty, żeby brzmiały konkretnie
Najlepszy opis doświadczenia ma jeden prosty wzór: co zrobiłem, w jakiej technologii, dla kogo i z jakim skutkiem. Gdy patrzę na życiorysy techniczne, największą różnicę robią liczby, zakres odpowiedzialności i decyzje, które da się obronić na rozmowie. „Pracowałem przy rozwijaniu aplikacji” znaczy niewiele; „zbudowałem panel administracyjny w React i Node.js, który skrócił ręczne operacje zespołu sprzedaży” brzmi już jak konkret.
- zaczynaj punkt od czasownika: zbudowałem, zoptymalizowałem, wdrożyłem, zautomatyzowałem
- dodawaj kontekst: aplikacja wewnętrzna, system dla klientów, mikrousługa, migracja, testy
- pokazuj skalę: liczba użytkowników, modułów, endpointów, wdrożeń albo zespołów
- używaj liczb, gdy tylko da się je uczciwie podać
- oddzielaj obowiązki od efektów, bo to nie jest to samo
| Słabo | Lepiej | Dlaczego to działa |
|---|---|---|
| Pracowałem nad aplikacją webową | Rozwinąłem panel w React i NestJS, dzięki czemu zespół obsługi klienta skrócił ręczne wprowadzanie danych | Widać stack, obszar i efekt biznesowy |
| Tworzyłem testy | Dodałem testy E2E w Cypress dla kluczowego checkoutu, ograniczając regresje po wdrożeniach | Pojawia się zakres, narzędzie i powód działania |
| Utrzymywałem backend | Przeprojektowałem cache dla endpointu raportowego i skróciłem czas odpowiedzi z 4 s do 1,2 s | Jest decyzja techniczna i mierzalny efekt |
Jeśli nie masz twardych danych liczbowych, pokaż przynajmniej skalę problemu, rodzaj modułu, liczbę osób w zespole albo zakres odpowiedzialności. To nadal brzmi lepiej niż opis w trybie „robiłem różne rzeczy”. Kiedy doświadczenie jest już opisane jasno, trzeba dopilnować sekcji, która najczęściej jest przeładowana: umiejętności i podsumowania zawodowego.
Umiejętności, stack i podsumowanie zawodowe bez przeładowania
Sekcja umiejętności ma pomagać, a nie udowadniać, że zna się wszystko z internetu. Ja rozdzielam ją na kilka logicznych grup: języki, frameworki, bazy danych, chmurę, narzędzia jakości i pracy zespołowej. Dzięki temu rekruter nie musi interpretować, czy Kubernetes pojawił się tu jako realne doświadczenie, czy jako kurs z ostatniego weekendu.
- wpisz tylko technologie, których używasz regularnie
- nie mieszaj fundamentów z ciekawostkami, bo lista traci wiarygodność
- poziom znajomości oznacz ostrożnie, jeśli naprawdę ma znaczenie
- soft skills pokaż przez efekt, a nie przez pustą listę przymiotników
Jeżeli profil zawodowy nie wnosi nic nowego ponad resztę dokumentu, lepiej go skrócić niż rozciągać na pół strony. To prowadzi prosto do kolejnego elementu, który może wzmocnić kandydaturę albo ją osłabić: linków do kodu i portfolio.
GitHub i portfolio, które naprawdę pomagają
GitHub i portfolio nie są obowiązkowe dla każdego, ale w IT bardzo często przechylają szalę, bo zamieniają deklaracje w dowód. Najbardziej cenię nie liczbę repozytoriów, tylko ich selekcję: 2-4 sensownie opisane projekty robią lepsze wrażenie niż 20 wrzuconych bez ładu i składu. Dobrze działa też krótki README z opisem problemu, architektury, stacku i decyzji, które podjąłeś po drodze.
- pokaż tylko najlepsze repozytoria, a nie całe archiwum eksperymentów
- dodaj zwięzły opis tego, po co projekt powstał i co rozwiązuje
- jeśli to możliwe, dodaj działającą wersję demo albo zrzuty ekranu
- opisz testy, wdrożenie albo ciekawą decyzję techniczną
- jeśli nie możesz pokazać kodu z pracy, zrób case study albo projekt poboczny w podobnym stylu
Portfolio ma pokazać myślenie, a nie tylko ładny kod. Dla juniora to często najważniejszy dowód, że potrafi doprowadzić projekt do końca; dla mida i seniora staje się raczej potwierdzeniem jakości, a nie jedynym argumentem sprzedażowym. Skoro wiemy już, co działa, warto też nazwać to, co najczęściej psuje nawet dobry dokument.
Najczęstsze błędy, które obniżają szanse
Najczęstsze błędy są zaskakująco przewidywalne: zbyt ogólny opis, za długa lista technologii, brak liczb, nieaktualne linki i dokument, który wygląda jak zestaw notatek z kursów. W IT przegrywa nie ten, kto ma mniej imponującą historię, tylko ten, kto nie potrafi jej jasno opowiedzieć.
| Błąd | Dlaczego szkodzi | Co zrobić zamiast |
|---|---|---|
| Ogólny opis obowiązków | Nie pokazuje wpływu ani poziomu odpowiedzialności | Pisz o efektach, decyzjach i mierzalnych rezultatach |
| Lista technologii bez selekcji | Wygląda jak próba przypodobania się każdej ofercie | Wybierz stack, którego naprawdę używałeś |
| Brak dopasowania do ogłoszenia | Dokument robi się zbyt szeroki i mało czytelny | Podkreśl elementy najbardziej zbliżone do roli |
| Nieaktualne linki i puste repozytoria | Podważają wiarygodność i zabierają czas rekruterowi | Sprawdź wszystko przed wysyłką i zostaw tylko sensowne materiały |
| Zbyt ozdobny format | Utrudnia skanowanie na telefonie i w ATS | Postaw na prosty, czysty układ i standardowe nagłówki |
| Projekty bez kontekstu | Nie wiadomo, co było Twoją pracą i czego się nauczyłeś | Opisz problem, swój wkład i końcowy efekt |
Jeśli masz wątpliwość, usuń wszystko, co nie pomaga podjąć decyzji o rozmowie. To jest prostsze niż rozbudowywanie dokumentu o kolejne akapity, które niczego nie wyjaśniają. Następny krok to dopasowanie treści do poziomu doświadczenia, bo junior, mid i senior nie sprzedają się tym samym zestawem argumentów.
Jak dopasować dokument do poziomu juniora, mida i seniora
Dokument juniora, mida i seniora powinien wyglądać inaczej, bo każdy sprzedaje coś innego. Junior pokazuje potencjał i fundamenty, mid pokazuje samodzielność, a senior pokazuje wpływ na produkt, ludzi i architekturę. Właśnie tu wiele osób popełnia błąd: pisze jeden szablon i wysyła go do wszystkich ról, choć oczekiwania wobec kandydata zmieniają się wyraźnie.
| Poziom | Co ma największą wagę | Na czym się skupić | Czego nie przeciążać |
|---|---|---|---|
| Junior | Potencjał, podstawy, projekty własne, pierwsze praktyki | 2-3 solidne projekty, GitHub, bootcamp, staż, testy, podstawy architektury | Długiej historii szkół, zbyt wielu kursów i pustych deklaracji |
| Mid | Samodzielność, odpowiedzialność za moduły, współpraca z zespołem | Własność feature'ów, wdrożenia, performance, testy, CI/CD, rozwiązywanie problemów | Teorii bez efektów i listy technologii bez kontekstu |
| Senior | Decyzje techniczne, wpływ na zespół i stabilność systemu | Architektura, mentoring, decyzje produktowe, skalowanie, redukcja ryzyka | Rozbudowywania dokumentu o rzeczy, które nie wspierają aktualnej kandydatury |
W praktyce junior powinien szczególnie mocno pokazać projekty i sposób myślenia, mid - dowody samodzielnej pracy, a senior - wpływ i odpowiedzialność. Kiedy to ustawisz poprawnie, dokument zaczyna mówić językiem rynku, a nie językiem szkolnego CV. Została jeszcze ostatnia korekta przed wysyłką.
Wersja, którą naprawdę warto wysłać
Na końcu odłóż dokument na kilka minut i przeczytaj go tak, jakbyś dostał go od obcej osoby. Jeśli po takim skanie nadal widać rolę, stack, konkretne efekty i sensowne linki, jesteś blisko dobrej wersji. Jeśli nie, skróć tekst, usuń ogólniki i zostaw tylko to, co pomaga podjąć decyzję.
- sprawdź, czy tytuł roli pasuje do ogłoszenia
- zostaw tylko 2-4 najlepsze projekty i 3-5 najmocniejszych osiągnięć
- upewnij się, że wszystkie linki działają
- zapisz plik jako PDF, chyba że system rekrutacyjny prosi o inny format
- nazwij plik prosto i czytelnie, na przykład imię_nazwisko_rola.pdf
- jeśli pracodawca tego oczekuje, dodaj aktualną klauzulę zgody zgodną z ogłoszeniem i obowiązującymi zasadami
W dobrze napisanym życiorysie technicznym nie chodzi o to, by powiedzieć wszystko. Chodzi o to, by w kilka minut pokazać wystarczająco dużo, żeby dostać rozmowę. To właśnie odróżnia dokument, który tylko istnieje, od dokumentu, który pracuje na Twoją kandydaturę.
