Najkrótsza droga do mocnego CV w IT
- Najpierw pokaż specjalizację, a dopiero potem listę technologii.
- Opisy stanowisk zamieniaj na efekty, zakres odpowiedzialności i skalę pracy.
- Dodaj 2-4 dopracowane projekty zamiast wielu przypadkowych repozytoriów.
- Trzymaj prosty układ PDF, bo czytelność i systemy ATS nadal mają znaczenie.
- Dopasuj ciężar sekcji do poziomu doświadczenia: junior, mid i senior wymagają innego akcentu.
Co rekruter musi zobaczyć w pierwszej kolejności
Ja zaczynam od bardzo prostego pytania: czy po kilku sekundach wiadomo, kim jesteś jako specjalista. Jeśli nie, nawet solidne doświadczenie potrafi przepaść. W branży IT liczy się szybki skan dokumentu, dlatego na górze powinny być specjalizacja, stack, ostatnia rola i linki do miejsc, gdzie widać twoją pracę.
Najlepiej działa układ, w którym od razu widać, czy jesteś backendowcem, frontendowcem, DevOپsem, data developerem czy osobą bardziej uniwersalną. Samo hasło „programista” jest zbyt szerokie. Rekruter chce wiedzieć, czy pracujesz z Pythonem, JavaScriptem, Javą, .NET-em, SQL-em czy chmurą, a nie tylko że „interesujesz się technologią”.
W praktyce dobrze napisany profil zawodowy powinien odpowiadać na trzy rzeczy:
- co robisz na co dzień,
- jakich technologii używasz,
- jaki efekt wnosi twoja praca.
Przykład? Zamiast ogólnego „szukam nowych wyzwań” lepiej napisać: Backend developer z 4-letnim doświadczeniem w Node.js i PostgreSQL, pracujący przy systemach e-commerce i integracjach API. To brzmi konkretnie i od razu ustawia kontekst rozmowy. Kiedy ta pierwsza warstwa jest jasna, warto uporządkować całą treść tak, by dokument czytało się bez wysiłku.
Jak ułożyć treść, żeby dokument był czytelny
Ja zwykle trzymam się prostego porządku, bo on najlepiej działa w rekrutacji technicznej. Najpierw identyfikacja, potem profil, doświadczenie, projekty, umiejętności i dopiero na końcu elementy dodatkowe. Taki układ pozwala rekruterowi przejść przez dokument bez zgadywania, gdzie co leży.
Nagłówek i kontakt
Na samej górze wystarczy imię i nazwisko, miasto, numer telefonu, e-mail, LinkedIn i GitHub. Jeśli masz portfolio albo demo aplikacji, dodaj je obok. Nie rozbudowuj tej części o szczegóły, które nie pomagają w rekrutacji. Adres zamieszkania, stan cywilny czy pełna data urodzenia zwykle nie wnoszą nic do oceny umiejętności.
Profil zawodowy
To powinny być 3-4 zdania, nie mini-esej. Najlepiej sprawdza się konstrukcja: specjalizacja, lata doświadczenia, kluczowy stack, najważniejszy typ projektów, ewentualnie obszar, w którym dowozisz najlepsze wyniki. Ja traktuję ten fragment jak szybki skrót całego CV. Jeśli jest zbyt ogólny, dokument od razu traci siłę.
Doświadczenie i projekty
Każdą rolę opisuj przez zadania, wpływ i zakres odpowiedzialności. Zamiast „tworzenie aplikacji webowych” napisz, co dokładnie zrobiłeś: integracje płatności, optymalizacja wydajności, rozwój panelu administracyjnego, migracja bazy danych, testy automatyczne, wdrożenie w chmurze. Dobrze działają też liczby: skrócenie czasu odpowiedzi, wzrost konwersji, liczba obsługiwanych użytkowników, skala zespołu lub liczba wdrożeń.Przeczytaj również: Programista - co robi naprawdę? Cała prawda o zawodzie!
Umiejętności i edukacja
Umiejętności techniczne warto pogrupować, a nie wrzucać jako długi ciąg nazw. Osobno języki, frameworki, bazy danych, narzędzia, chmura, testowanie. Dzięki temu dokument wygląda dojrzalej i jest łatwiejszy do zeskanowania. Edukacja ma sens, ale nie powinna dominować, jeśli masz już sensowne doświadczenie komercyjne. U juniora bywa ważniejsza, u seniora schodzi na dalszy plan.
Jeśli masz własne repozytoria albo demo aplikacji, nie chowaj ich na końcu. W IT to często najprostszy sposób na pokazanie, że nie tylko znasz nazwy technologii, ale potrafisz z nich zbudować działający produkt. A właśnie projekty najczęściej robią największą różnicę.
Projekty i GitHub, które naprawdę pomagają
Własne projekty nie są ozdobą. Są dowodem, że umiesz doprowadzić pracę do końca i pokazać efekt, który da się ocenić. Ja patrzę na nie jak na próbkę sposobu myślenia: czy ktoś wie, jak zaprojektować strukturę aplikacji, jak korzystać z API, jak testować kod i jak rozwiązywać problemy po drodze.
Najbardziej użyteczne są projekty, które mają jasny cel. Dobrze wypada na przykład:
- panel administracyjny z logowaniem i CRUD-em, bo pokazuje podstawy pracy z danymi i autoryzacją,
- aplikacja korzystająca z zewnętrznego API, bo widać w niej integracje i odporność na błędy,
- mały produkt wdrożony na serwer lub w chmurze, bo pokazuje nie tylko kod, ale też proces publikacji,
- projekt zespołowy, bo sygnalizuje współpracę, code review i pracę z repozytorium w praktyce.
Nie warto natomiast wymieniać dziesięciu podobnych repozytoriów z kursów. Lepiej mieć 2-4 dopracowane projekty, które umiesz obronić w rozmowie. Do każdego dopisz krótko: po co powstał, jakich technologii używa, co było trudne i jaki element zrobiłeś samodzielnie. Jeśli możesz, dodaj link do wersji live albo README z opisem architektury. To zwiększa wiarygodność bardziej niż efektowny opis bez treści.
Ja przy opisie projektu trzymam zasadę „jedno zdanie kontekstu, jedno zdanie technologii, jedno zdanie efektu”. To krótki format, ale bardzo skuteczny. Gdy projekty są opisane sensownie, pozostaje już tylko dopilnować formatu, który nie przeszkadza w odbiorze.
Format, który nie przeszkadza ATS i rekruterowi
W Polsce nadal najlepiej działa prosty, czytelny PDF. Nie dlatego, że kreatywne szablony są z definicji złe, tylko dlatego, że w rekrutacji technicznej ważniejsza jest treść niż fajerwerki. Ja zawsze stawiam na układ, który da się odczytać bez wysiłku zarówno na ekranie, jak i po szybkim przeskanowaniu przez systemy ATS.
W praktyce oznacza to:
- jedną, maksymalnie dwie kolumny, ale bez chaosu typograficznego,
- standardowe nazwy sekcji, takie jak doświadczenie, projekty, umiejętności i edukacja,
- brak tekstu wpisanego w grafiki, bo to często utrudnia odczyt,
- czytelne nazwy plików, na przykład Imię_Nazwisko_CV.pdf,
- spójne fonty i bezpieczne marginesy, które nie ściskają treści.
Co do długości, najbezpieczniej myśleć tak: junior zwykle mieści się na 1 stronie, a osoba z doświadczeniem najczęściej na 1-2 stronach. Dłuższy dokument ma sens tylko wtedy, gdy naprawdę wnosi dodatkową wartość, na przykład pokazuje kilka mocnych projektów, różne role techniczne albo złożone doświadczenie konsultingowe. Reszta to już zwykle nadmiar. Kiedy układ jest prosty, wychodzą wszystkie błędy merytoryczne, a te potrafią kosztować więcej niż kiepski szablon.
Błędy, przez które dobre CV przegrywa
Najczęstszy problem, który widzę, to lista technologii bez kontekstu. Sam fakt, że ktoś wpisał dany framework, nic nie mówi, jeśli nie wiadomo, czy używał go w projekcie komercyjnym, w ćwiczeniu, czy tylko raz na kursie. Wiarygodność rośnie wtedy, gdy technologia jest połączona z konkretnym zastosowaniem.
Drugi problem to opisy obowiązków zamiast osiągnięć. Frazy typu „tworzenie oprogramowania” albo „współpraca z zespołem” są zbyt miękkie. Lepiej napisać, co faktycznie zbudowałeś, naprawiłeś, zautomatyzowałeś albo usprawniłeś. W IT nawet drobny efekt ma większą wartość niż ogólnik.Na liście błędów zwykle trafiają się też:
- zbyt szeroki stack, którego nie da się obronić w rozmowie,
- brak linków do GitHuba, LinkedIna lub demo,
- nieaktualne repozytoria i martwe odnośniki,
- literówki w nazwach technologii i firm,
- przekombinowany design, który odciąga uwagę od treści,
- zmyślone kompetencje, które padają przy pierwszym pytaniu technicznym.
Ja mam do tego jedną zasadę: lepiej napisać mniej, ale dać się sprawdzić. W rekrutacji technicznej nikt nie premiuje dekoracyjnych deklaracji. Premiuje dokument, który brzmi konkretnie i trzyma się prawdy. Gdy ten filtr jest przejrzany, można już dopasować ciężar treści do poziomu doświadczenia.
Jak dopasować treść do juniora, mida i seniora
Nie ma jednego idealnego wzoru dla wszystkich. Junior, mid i senior sprzedają w CV coś innego, więc akcenty muszą się różnić. Ja traktuję to jak trzy osobne strategie, a nie trzy wersje tego samego dokumentu.
| Poziom | Co eksponować | Co ograniczyć | Typowa długość |
|---|---|---|---|
| Junior | Projekty, kursy, praktyki, GitHub, podstawowy stack | Rozbudowaną historię edukacji i ogólne hasła bez dowodu | 1 strona |
| Mid | Konkretną odpowiedzialność, skalę pracy, wdrożenia i współpracę z biznesem | Listy szkoleń, które nie wpływają na obecną specjalizację | 1-2 strony |
| Senior | Decyzje techniczne, architekturę, mentoring, wpływ na produkt i zespół | Opis podstawowych narzędzi, które są już dla ciebie oczywiste | 1-2 strony |
U juniora liczy się potencjał, ale pokazany przez działające rzeczy, nie przez deklaracje. U mida ważna jest już samodzielność i wpływ na wynik. U seniora najcenniejsze stają się decyzje techniczne, odpowiedzialność za kierunek i zdolność do upraszczania złożonych problemów. Jeśli aplikujesz do firmy międzynarodowej albo na stanowisko mocno produktowe, dobrze mieć też wersję anglojęzyczną, ale tylko wtedy, gdy tekst jest naprawdę dopracowany. Został już ostatni krok: krótki przegląd przed wysłaniem.
Ostatni przegląd, który oszczędza ci kilku pustych aplikacji
Zanim wyślesz dokument, sprawdź go raz jeszcze jak rekruter, nie jak autor. Czy po pierwszych kilku sekundach wiadomo, czym się zajmujesz. Czy najważniejsze projekty są widoczne bez przewijania. Czy opisy mają konkret, a nie tylko nazwy zadań. Czy linki działają. Czy plik otwiera się dobrze na telefonie i komputerze. To brzmi banalnie, ale właśnie te drobiazgi często decydują o pierwszym wrażeniu.
Jeśli miałbym zostawić jedną praktyczną radę, powiedziałbym tak: traktuj swoje CV jak narzędzie do pokazania dowodu kompetencji, nie jak katalog wszystkiego, co kiedykolwiek zrobiłeś. Dobre życiorysy w IT są krótkie tam, gdzie mogą być krótkie, i konkretne tam, gdzie trzeba pokazać wartość. Taki dokument łatwiej przeczytać, łatwiej obronić i dużo łatwiej zamienić w rozmowę rekrutacyjną.
