Dobre cv programisty nie próbuje opowiedzieć całej historii zawodowej. Ma w krótkim czasie pokazać, w jakim stacku pracujesz, jakie projekty dowiozłeś i dlaczego warto zaprosić cię na rozmowę. W tym tekście rozkładam na czynniki pierwsze układ dokumentu, kolejność sekcji, opis doświadczenia, różnice między poziomami oraz błędy, które najczęściej obniżają skuteczność aplikacji.
Najważniejsze rzeczy, które decydują o skuteczności CV technicznego
- Najlepiej działa prosty układ, zwykle jedna kolumna i plik PDF bez ozdobników.
- Na górze umieść specjalizację, kontakty i linki do GitHuba, LinkedIna albo portfolio.
- Doświadczenie opisuj efektami, skalą i odpowiedzialnością, a nie samą listą obowiązków.
- Junior bez komercyjnego stażu powinien oprzeć dokument na projektach i repozytoriach.
- Dopasuj długość: jedna strona dla początkujących, 1-2 strony dla osób z doświadczeniem.
- Przed wysłaniem sprawdź ATS, literówki, daty i zgodność stacku z ogłoszeniem.
Jak powinno wyglądać CV programisty, żeby było czytelne w 30 sekund
W rekrutacji technicznej pierwsze wrażenie robi nie kreatywność, tylko porządek. Rekruter lub techniczny hiring manager chce w kilka sekund zobaczyć specjalizację, poziom doświadczenia i technologię, z którą naprawdę pracujesz, dlatego prosty układ wygrywa z efektownym szablonem.
Ja zwykle rekomenduję jedno- lub dwukolumnowy układ, ale z przewagą czytelności nad dekoracją. Jeśli dokument ma przejść przez system ATS, czyli oprogramowanie wstępnie odczytujące treść CV i porządkujące kandydatów, lepiej zrezygnować z ciężkich grafik, tekstu w stopkach i rozbudowanych tabel dekoracyjnych.
| Element | Co działa | Czego unikać |
|---|---|---|
| Układ | Jasne sekcje, dużo światła, czytelne nagłówki | Wiele kolumn, mała czcionka, chaos wizualny |
| Długość | 1 strona dla juniora, 1-2 strony dla doświadczonej osoby | 3-4 strony bez wyraźnego powodu |
| Format pliku | PDF, jeśli nie ma wyraźnego wymogu inaczej | Pliki, które rozjeżdżają się po otwarciu |
| Zdjęcie | Jeśli jest, to neutralne, aktualne i profesjonalne | Selfie, filtry, przypadkowe tło |
| Grafika | Minimalna, tylko jeśli naprawdę pomaga | Wykresy umiejętności, które niczego nie wyjaśniają |
W polskich rekrutacjach zdjęcie nadal bywa spotykane, ale nie traktowałbym go jako obowiązku. Jeśli nie masz dobrego ujęcia, lepiej zostawić pustą przestrzeń niż wstawiać fotografię, która obniża profesjonalny odbiór. Kiedy układ jest już prosty, trzeba zdecydować, co włożyć do środka i w jakiej kolejności.
Co umieścić w środku i jak ułożyć sekcje
W dobrze zbudowanym dokumencie sekcje nie są przypadkowe. Najpierw pokazujesz, kim jesteś zawodowo, potem udowadniasz to doświadczeniem, a dopiero na końcu dodajesz edukację i dodatki. Taki porządek skraca czas czytania i ułatwia porównanie kandydatów.
| Kolejność | Co wpisać | Po co to jest |
|---|---|---|
| 1. Nagłówek i kontakt | Imię, nazwisko, specjalizacja, e-mail, telefon, miasto, linki do GitHuba, LinkedIna lub portfolio | Żeby od razu było jasne, jak się z tobą skontaktować i gdzie zobaczyć kod |
| 2. Krótkie podsumowanie | 2-4 zdania o specjalizacji, stacku, typie projektów i kierunku rozwoju | Żeby rekruter szybko zrozumiał, czy pasujesz do roli |
| 3. Doświadczenie | Stanowisko, firma, daty, zakres odpowiedzialności, efekty | To najważniejszy dowód, że umiesz dowozić zadania |
| 4. Projekty | Opis projektów prywatnych, uczelnianych, freelance albo open source | Kluczowe szczególnie wtedy, gdy masz mało komercyjnego doświadczenia |
| 5. Umiejętności | Technologie, narzędzia, frameworki, chmura, testy, baza danych | Żeby łatwo porównać twój stack z ofertą |
| 6. Edukacja i kursy | Studia, bootcamp, szkolenia, certyfikaty, jeśli są istotne | Pomaga, gdy dopiero budujesz profil albo zmieniasz specjalizację |
| 7. Języki i dodatkowe informacje | Angielski, niemiecki, prawo jazdy, zgoda rekrutacyjna, jeśli wymagana | To sekcja uzupełniająca, nie główny argument sprzedażowy |
Nie rozdmuchiwałbym danych osobowych. Wystarczy to, co naprawdę pomaga w kontakcie i ocenie dopasowania. W praktyce najczęściej zbędne są takie informacje jak pełny adres zamieszkania, stan cywilny czy data urodzenia, chyba że konkretna rekrutacja wymaga czegoś innego. Jeśli aplikujesz w Polsce, sprawdź też aktualną klauzulę zgody na przetwarzanie danych, bo ten element warto dopasować do wymagań ogłoszenia.
Najkrótsza zasada, którą stosuję przy redakcji takich dokumentów, brzmi prosto: im więcej miejsca zajmuje treść mająca dowieść kompetencji, tym lepiej. A skoro o kompetencjach mowa, trzeba jeszcze pokazać je tak, by nie brzmiały jak lista haseł z internetu.
Jak opisać doświadczenie i projekty, żeby pokazać realną wartość
Najczęstszy błąd polega na tym, że kandydat wpisuje obowiązki zamiast efektów. Samo „tworzenie aplikacji webowych” albo „praca z JavaScript” nic nie mówi o skali, odpowiedzialności i jakości wykonania, a właśnie tego szuka osoba czytająca dokument techniczny.
Lepszy opis ma cztery warstwy: kontekst, działanie, technologię i rezultat. Można to ułożyć tak: co robiłeś, w jakim środowisku, czym to zrealizowałeś i jaki był efekt. Jeśli masz liczby, użyj ich. Jeśli nie masz twardych danych, pokaż skalę projektu, liczbę modułów, integracji, użytkowników, sprintów albo obszar odpowiedzialności.
Przykład słabszy: rozwijanie aplikacji i poprawianie błędów w zespole.
Przykład lepszy: rozwój panelu administracyjnego w React i TypeScript, odpowiedzialność za obsługę formularzy, integrację z API oraz poprawę stabilności widoku raportów.
To samo dotyczy projektów własnych. Nie wystarczy wrzucić nazwy repozytorium. Lepiej pokazać, po co projekt powstał, co rozwiązuje i co w nim było technicznie ważne. Przy opisie prywatnych realizacji dobrze sprawdza się prosty schemat:
- cel projektu,
- stack technologiczny,
- zakres funkcji lub modułów,
- twoja rola,
- link do kodu lub demonstracji.
Jeśli jesteś juniorem, to właśnie projekty zastępują część komercyjnego doświadczenia. W takiej sytuacji lepiej pokazać 2-4 mocne realizacje niż rozciągać dokument o dziesięć małych, nierównych przykładów. Jedna dopracowana aplikacja z sensownym opisem mówi więcej niż pięć połowicznych repozytoriów bez komentarza.
Warto też pisać o technologiach w sposób, który pokazuje ich użycie, a nie samą znajomość słów kluczowych. Zamiast rzucać ciągiem nazw, lepiej połączyć stack z zadaniem, na przykład: frontend w React i TypeScript, backend w Node.js, baza PostgreSQL, testy jednostkowe, CI/CD w GitHub Actions. Takie zestawienie od razu mówi, jak głęboko wchodzisz w projekt. Tę samą logikę trzeba jednak dopasować do poziomu doświadczenia, bo junior, mid i senior nie sprzedają się w identyczny sposób.
Dlaczego junior, mid i senior potrzebują innej wersji dokumentu
Jedno CV rzadko działa dobrze na wszystkie poziomy. Osoba na początku kariery musi zbudować wiarygodność przez projekty i edukację, mid pokazuje samodzielność i wpływ na produkt, a senior sprzedaje przede wszystkim skalę odpowiedzialności, decyzyjność i wpływ na zespół. To nie jest kosmetyka, tylko różnica w logice całego dokumentu.
| Poziom | Najlepsza długość | Na czym skupić uwagę | Czego nie rozdmuchiwać |
|---|---|---|---|
| Junior | 1 strona | Projekty, stack, edukacja, motywacja do wejścia do branży | Długiej listy obowiązków, których jeszcze nie było |
| Mid | 1-2 strony | Samodzielność, konkretne efekty, odpowiedzialność za moduły i jakość kodu | Zbyt ogólnego opisu zadań bez efektu końcowego |
| Senior | 1-2 strony, czasem więcej tylko przy bardzo szerokim profilu | Skalę, leadership, architekturę, mentoring, wpływ na proces i biznes | Każdego małego zadania z osobna |
W przypadku juniora szczególnie ważna jest sekcja projektów i link do kodu. Jeśli nie masz jeszcze komercyjnego stażu, pokaż, że umiesz zbudować coś od początku do końca, utrzymać porządek w repozytorium i sensownie opisać decyzje techniczne. To właśnie buduje zaufanie, a nie sam fakt ukończenia kursu albo studiów.
Mid i senior zyskują najwięcej na selekcji. W ich dokumentach nie powinno być wszystkiego, co kiedykolwiek zrobili, tylko to, co najlepiej udowadnia gotowość do konkretnej roli. Przy zmianie specjalizacji albo aplikacji do firmy międzynarodowej warto też przygotować wersję angielską, bo w IT to często najsensowniejszy drugi wariant. Kiedy poziom jest już dobrze dopasowany, zostaje ostatnia rzecz, która często przesądza o tym, czy ktoś w ogóle otworzy zaproszenie na rozmowę.
Najczęstsze błędy, które kosztują zaproszenie na rozmowę
Widziałem wiele dokumentów technicznych, które były „ładne”, ale po chwili lektury nie mówiły nic konkretnego. To właśnie one odpadają najczęściej, bo przy dużej liczbie aplikacji rekruter nie ma czasu domyślać się, co kandydat naprawdę potrafi.
- Lista technologii bez kontekstu. Sam React, samo Java albo samo SQL nie pokazuje, jak używasz tych narzędzi.
- Opis obowiązków zamiast efektów. „Praca nad aplikacją” jest zbyt ogólna, by coś udowodnić.
- Przesadzona liczba umiejętności. Lepiej podać 10-15 technologii, które znasz naprawdę, niż 40 haseł z kursów.
- Brak linków do kodu, demo lub profilu zawodowego. W IT to często duża strata, bo odbiorca nie ma jak szybko sprawdzić jakości pracy.
- Nieczytelny szablon. Dwie kolumny, drobny font i ozdobniki potrafią zepsuć nawet dobry content.
- Rozjazd między ogłoszeniem a CV. Jeśli oferta wymaga testów, chmury albo konkretnego frameworka, a w dokumencie tego nie ma, aplikacja słabnie już na starcie.
- Błędy w datach, nazwach stanowisk i nazwach firm. To drobiazg, ale bardzo psuje wiarygodność.
- Zbyt duże ego w opisie. Lepiej pisać konkretnie i spokojnie niż udowadniać, że wszystko robiłeś najlepiej.
- Stare informacje. Nieaktualny stack, nieaktualne certyfikaty albo projekt, który od lat nie działa, wyglądają po prostu słabo.
Jest też jeden błąd bardziej subtelny: kandydat pisze dokument pod własną wygodę, a nie pod odbiorcę. Tymczasem rekruter chce w kilka chwil zrozumieć, czy odpowiadasz na potrzeby konkretnej roli. Dlatego przed wysłaniem warto zrobić krótki, bezlitosny przegląd finalnej wersji.
Co sprawdzić przed wysłaniem, żeby nie przegrać przez detal
Zanim wyślesz dokument, przeczytaj go raz jak rekruter, a raz jak ktoś, kto ma tylko 20-30 sekund na wstępne przeskanowanie. Jeśli w tym czasie nie da się zobaczyć specjalizacji, stacku i sensownego dowodu kompetencji, tekst trzeba jeszcze skrócić albo uporządkować.
- Czy na górze widać specjalizację, a nie tylko imię i nazwisko?
- Czy pierwsza sekcja mówi jasno, w czym pracujesz i czego szukasz?
- Czy każda rola zawodowa ma 3-5 mocnych punktów, a nie ścianę tekstu?
- Czy projekty pokazują coś więcej niż sam tytuł repozytorium?
- Czy umiejętności są pogrupowane sensownie, na przykład frontend, backend, baza danych, chmura, testy?
- Czy plik ma prostą nazwę, którą łatwo zapisać i znaleźć?
- Czy nie ma literówek, rozjechanych dat i przypadkowych formatów?
- Czy wersja CV odpowiada konkretnemu ogłoszeniu, a nie jest generycznym szablonem?
Ja najlepiej oceniam takie dokumenty wtedy, gdy po poprawkach można je streścić jednym zdaniem: „ta osoba naprawdę umie to, czego potrzebujemy”. Jeśli po lekturze zostają tylko ogólne wrażenia, trzeba jeszcze dopracować treść albo przesunąć akcenty. Dobre CV techniczne nie jest ozdobą. To precyzyjny argument, że warto poświęcić ci kolejne 30 minut rozmowy.
