Jak napisać CV na pracę w IT (inżynierowie oprogramowania, programiści, data)

CV w IT czyta się inaczej — co się zmienia

Zanim przejdziemy do taktyki, najważniejsza różnica strukturalna. CV w IT ocenia się przez inny pryzmat niż CV korporacyjne, a ta różnica kształtuje każdą sekcję:

• Menedżer ds. rekrutacji w inżynierii czyta CV równolegle z (albo zaraz po) szybkim rzutem oka na twój GitHub, twoją stronę osobistą, jeśli ją masz, oraz LinkedIn. CV nie jest jedynym sygnałem — to jeden z wielu sygnałów w ocenie z kilku źródeł
• Sekcję umiejętności technicznych czytają jako pierwszą zarówno rekruterzy, jak i inżynierowie, ale szukają w niej różnych rzeczy. Rekruterzy skanują pod kątem dopasowania słów kluczowych do ogłoszenia; inżynierowie sprawdzają, czy głębia i szerokość pasują do poziomu stanowiska
• Projekty często liczą się bardziej niż historia zatrudnienia na poziomie juniora i mida. Samodzielny projekt, który realnie coś wdrożył, świadczy o inicjatywie i umiejętności doprowadzania rzeczy do końca w sposób, jakiego staż czy pierwsza praca nie pokażą
• Historię zatrudnienia czyta się pod kątem zakresu, wpływu i poziomu kontekstu — nie tylko nazw firm. Praca w zespole odpowiedzialnym za logowanie w 50-osobowym startupie to coś innego niż w korporacji liczącej 50 000 osób; CV powinno czytelnie pokazywać ten zakres
• Obecność na GitHubie jest sprawdzana. Kandydat z aktywnym profilem (realne commity, kilka repozytoriów, wykres aktywności pokazujący niedawne działania) jest traktowany jako bardziej wiarygodny inżynier niż ten bez — nawet jeśli faktyczne umiejętności są identyczne
• CV ma jedną stronę, dopóki naprawdę się nie da. Dwie strony są akceptowalne dla inżynierów z 8+ latami doświadczenia, ale druga strona powinna nieść realną treść, a nie wypełniacz
• Wykształcenie liczy się na poziomie juniora (zwłaszcza dla świeżych absolwentów), staje się mniej istotne na poziomie mida i niemal nieistotne na poziomie senior+. Dostosuj jego widoczność do etapu kariery
• Certyfikaty liczą się przy konkretnych rolach chmurowych (AWS, GCP, Azure) i konkretnych specjalizacjach (bezpieczeństwo, sieci), ale przy ogólnych stanowiskach programistycznych są w dużej mierze bez znaczenia

Reszta tego przewodnika jest zbudowana wokół tych faktów strukturalnych. Każda sekcja mówi, co napisać, jak to uporządkować, co podkreślić, a co wyciąć — skalibrowane konkretnie pod stanowiska inżynierskie, a nie ogólne role korporacyjne.

Sekcja umiejętności technicznych — jak ją uporządkować

Sekcja umiejętności technicznych jest najczęściej skanowaną sekcją w CV w IT. Zarówno rekruterzy, jak i inżynierowie patrzą na nią najpierw. To, jak jest zorganizowana, decyduje, czy przekazuje kompetencje, czy szum:

• Porządkuj według kategorii, a nie jako jedną płaską listę. Języki, frameworki, bazy danych, infrastruktura/chmura, narzędzia, metodyki — każda jako osobna grupa. Ściana 40 technologii oddzielonych przecinkami czyta się jak wysypisko słów kluczowych; te same 40 ułożonych według kategorii czyta się jak uporządkowana mapa kompetencji
• Wpisuj technologie, o których pewnie porozmawiasz na rozmowie technicznej. Rozmówca dobierze z tej sekcji pytania techniczne; jeśli wpiszesz Rusta, bo użyłeś go w jednym tutorialu trzy lata temu, oblejesz rozmowę
• Każdą kategorię ułóż według rzeczywistej biegłości, a nie według tego, co chciałbyś, żeby było prawdą. Jeśli najmocniejszy jesteś w Pythonie, a najsłabszy w Go, postaw Pythona na początku — kolejność czyta się jako sygnał pewności
• Unikaj etykiet poziomu (Początkujący / Średnio zaawansowany / Ekspert / 8 na 10). Są subiektywne, często niedokładne i rodzą niezręczne pytania na rozmowie. Albo wpisz technologię, bo potrafisz o niej pewnie mówić, albo ją pomiń
• Dopasuj słownictwo techniczne do ogłoszenia. Jeśli ogłoszenie mówi „React, Node.js, PostgreSQL, AWS”, użyj dokładnie tych terminów — a nie „frameworki JavaScript, serwery WWW, relacyjne bazy danych, platformy chmurowe”. Dopasowanie słów kluczowych w ATS jest dosłowne
• Podawaj wersje lub konkretne dialekty, gdy to istotne: „Python 3.x”, „PostgreSQL 14+”, „React 18 z hookami”. Konkret sygnalizuje głębię
• Pomiń podstawy, które zakłada się u każdego. Wpisywanie „HTML, CSS, Git, wiersz poleceń” w CV seniora to wypełniacz, który wypiera realny sygnał
• Jeśli masz specjalistyczną wiedzę (kompilatory, systemy rozproszone, infrastruktura ML, systemy czasu rzeczywistego), wydziel osobną linię „specjalizacje” lub „domeny”, która ją wyeksponuje. Na poziomie seniora specjalizacja jest cenniejsza niż szerokość

Test dla sekcji umiejętności technicznych: inżynier, który ją czyta, powinien umieć przewidzieć, jak naprawdę wyglądała twoja codzienna praca. Jeśli sekcja to ogólny obłok słów pasujący do dowolnego kandydata, zawodzi. Jeśli jest uporządkowana, skalibrowana i uczciwa, wykonuje większość pracy ekranu technicznego, zanim ten ekran w ogóle się odbędzie.

Pokazywanie projektów — kiedy projekty liczą się bardziej niż stanowiska

CV w IT często zawiera sekcję Projekty obok Doświadczenia zawodowego. U części kandydatów to właśnie sekcja Projekty jest najmocniejszą częścią CV. Kiedy ją dodać i jak z niej korzystać:

• Inżynierowie juniorzy i świeżi absolwenci: sekcja Projekty jest niezbędna. Przy ograniczonej historii zatrudnienia projekty są głównym dowodem, że potrafisz wdrażać kod. Umieść tę sekcję nad Wykształceniem lub tuż po nim
• Osoby zmieniające branżę na inżynierię: sekcja Projekty jest niezbędna. To pomost między twoim wcześniejszym doświadczeniem a kompetencją inżynierską — i jedyny dowód, że naprawdę coś zbudowałeś
• Inżynierowie mid z mocną historią zatrudnienia: sekcja Projekty jest opcjonalna. Dodaj ją, jeśli masz projekty po godzinach pokazujące umiejętności, których nie widać w historii pracy (open source, eksperymenty z ML, opublikowana biblioteka, popularne rozszerzenie do Chrome)
• Inżynierowie senior i wyżej: sekcja Projekty jest zwykle zbędna. Na tym poziomie ciężar ma nieść historia zatrudnienia. Wyjątek: znaczące utrzymywanie projektu open source, rozpoznawalna opublikowana praca lub istotny wkład w społeczność
• Każdy wpis projektu powinien mieć: nazwę projektu (z linkiem do repozytorium lub działającej wersji), jednolinijkowy opis tego, co robi, użyty stos technologiczny oraz 1–2 punkty o tym, co było nietrywialne w jego budowie
• Lepsze są 2–4 mocne projekty niż 8 słabych. Aplikacja todo zrobiona za tutorialem nie pomaga; projekt, który rozwiązał realny problem i o którym potrafisz mówić w szczegółach — owszem
• Jeśli projekt to klon albo przejście tutorialu krok po kroku, nie wpisuj go jako projekt. Wpisz go co najwyżej jako „ćwiczenie edukacyjne” albo pomiń
• Przy projektach skierowanych do użytkownika działające linki liczą się bardziej niż linki do repozytorium. Wdrożona strona, którą menedżer ds. rekrutacji może kliknąć i zobaczyć, jest zdecydowanie bardziej przekonująca niż repozytorium, które musi sklonować
• Jeśli projekt miał współautorów, wymień ich i swoją konkretną rolę. „Zbudowałem backendowe API i warstwę bazy danych dla 4-osobowego zespołu” jest uczciwe i konkretne; przypisywanie sobie autorstwa całego zespołowego projektu to coś, co wychodzi na rozmowie

Najmocniejsze CV w IT na poziomie junior/mid często ma 2–3 solidne projekty, o których kandydat potrafi mówić w głąb, z działającymi demami. To często waży więcej niż dłuższa, ale mniej wyróżniająca się historia zatrudnienia. Buduj projekty świadomie, tak by stały się najmocniejszym dowodem w twoim CV.

GitHub, portfolio i namacalne dowody pracy

Linki, które umieszczasz w CV w IT, czyta się jako dowód, że jesteś praktykującym inżynierem, a nie posiadaczem papierka. Które linki dodać i jak je zaprezentować:

• GitHub: dodaj przy niemal wszystkich stanowiskach inżynierskich. Upewnij się, że profil, do którego linkujesz, jest prawdziwy (niedawne commity, kilka repozytoriów, uzupełnione readme profilu). Pusty lub martwy GitHub w CV jest gorszy niż brak linku
• Strona osobista: dodaj, jeśli ją masz i jest aktualna. Nie musi być wystrzałowa; wystarczy proste portfolio z linkami do projektów, krótkim biogramem i danymi kontaktowymi. Strona zepsuta albo z roku 2019 jest gorsza niż brak strony
• LinkedIn: dodaj. Nawet jeśli uważasz, że LinkedIn to głównie szum, rekruterzy go sprawdzają, a pusty profil sygnalizuje brak profesjonalizmu
• Profil Stack Overflow: dodaj tylko, jeśli masz znaczącą reputację i dobre jakościowo odpowiedzi. Profil z reputacją 50 nie sygnalizuje niczego; profil z reputacją 50 000 sygnalizuje realną wiedzę
• Blog osobisty lub teksty techniczne: dodaj, jeśli regularnie piszesz treści techniczne. Inżynierskie wpisy na blogu pokazują umiejętność komunikacji, głębię techniczną i nawyk refleksji — wszystko to ceni menedżer ds. rekrutacji
• Prelekcje konferencyjne, podcasty, wystąpienia wideo: dodaj, jeśli jakieś masz. Działają jak zewnętrzne potwierdzenie, że potrafisz przekazywać idee techniczne
• Wszystkie linki w PDF zrób klikalnymi (Word i Google Docs to obsługują przez „Wstaw hiperłącze”). Rekruterzy będą klikać; zepsute lub nieklikalne linki kosztują cię to przejście dalej
• Zrób porządek, zanim wstawisz link. Zanim dodasz link do GitHuba, spójrz na swój profil świeżym okiem. Przypnij 4–6 najlepszych repozytoriów. Zadbaj o napisane README. Usuń lub zarchiwizuj repozytoria, które istnieją tylko jako niedokończone tutoriale. Menedżer ds. rekrutacji wyrobi sobie wrażenie w 30 sekund oglądania profilu — zadbaj, by było to wrażenie, którego chcesz

Każdy link w twoim CV w IT to obietnica — kliknięcie odsłoni więcej dowodów twojej kompetencji inżynierskiej. Jeśli kliknięcie pokaże mniej, niż sugerowało CV, kandydatura słabnie. Linki są na plus tylko wtedy, gdy materiał pod nimi dorównuje temu, co CV obiecuje.

ATS przy stanowiskach IT — dopasowanie słów kluczowych, które ma znaczenie

Większość rekrutacji technicznych w dużych firmach wciąż przechodzi przez systemy ATS filtrujące po słowach kluczowych. Jak działa dopasowanie ATS przy stanowiskach inżynierskich:

• ATS przy stanowiskach IT często robi dosłowne dopasowanie słów kluczowych do ogłoszenia. Jeśli ogłoszenie mówi „React”, a twoje CV mówi „React.js”, część systemów tego nie dopasuje. Gdzie się da, używaj dokładnej pisowni z ogłoszenia
• Wymieniaj technologie w kilku sekcjach, nie tylko w sekcji Umiejętności. Senior, który używał Kubernetesa na produkcji w trzech różnych firmach, powinien mieć „Kubernetes” w opisach tych trzech stanowisk plus w sekcji Umiejętności — algorytm dopasowania waży liczbę wystąpień
• Konkretne frameworki i narzędzia liczą się bardziej niż ogólne kategorie. „React, Vue, Angular” jest lepsze niż „frameworki JavaScript”. „PostgreSQL, MongoDB, Redis” jest lepsze niż „bazy danych”
• Skróty i pełne formy: dodaj oba. „Machine Learning (ML)” pokrywa zapytania o „ML” i „machine learning”. „Continuous Integration (CI/CD)” robi to samo
• Częste warianty: „Node.js”, „Nodejs” i „Node” to ta sama technologia, ale systemy ATS mogą o tym nie wiedzieć. Jeśli ogłoszenie mówi „Node.js”, dopasuj dokładnie tę formę
• Branżowe certyfikaty i normy: dodaj, jeśli istotne. „PCI DSS”, „HIPAA”, „SOC 2”, „RODO”, jeśli z nimi pracowałeś. „Agile”, „Scrum”, „Kanban”, jeśli prowadziłeś te procesy
• Unikaj upychania słów kluczowych, które psuje czytelność. CV po przejściu ATS czyta człowiek; jeśli ludzki czytelnik widzi ścianę nazw technologii bez kontekstu, kandydatura przepada na ekranie ludzkim, nawet jeśli przeszła ekran ATS
• Dopasowuj pod każdą aplikację. Lista słów kluczowych, która przepuści CV przez ATS Google’a, jest inna niż lista, która przepuści je przez Greenhouse w startupie. Dopasuj do konkretnego ogłoszenia

Dopasowanie ATS to konieczna pierwsza przeszkoda przy stanowiskach IT w większości dużych firm. Potraktuj je jak dosłowne ćwiczenie z dopasowania: użyj słownictwa z ogłoszenia, wymieniaj technologie w kontekście (w opisach stanowisk, nie tylko na liście Umiejętności) i zakładaj, że dopasowanie jest „głupie”. Po przejściu ATS pałeczkę przejmuje ludzki czytelnik i wtedy treść liczy się bardziej niż zagęszczenie słów kluczowych.

Kwantyfikowanie wpływu inżynierskiego

CV w IT często cierpi na ten sam problem ogólników co CV korporacyjne: „rozwijałem funkcje”, „poprawiłem wydajność”, „pracowałem nad platformą”. Konkretny, zmierzony wpływ to właśnie to, co odróżnia mocne CV w IT od przeciętnego:

• Wydajność: „obniżyłem opóźnienie p99 API z 850 ms do 120 ms” bije „poprawiłem wydajność API”. Konkretne liczby są wiarygodne; mgliste deklaracje nie
• Skala: „obsługa 50 tys. żądań/s w szczycie” lub „przetwarzanie 2 mld zdarzeń/dobę” osadza pracę w realnej skali. Bez liczb czytelnik musi się domyślać; z liczbami — rozumie
• Koszt: „obniżyłem koszt infrastruktury AWS o 180 tys. USD rocznie dzięki optymalizacji bazy i właściwemu dobraniu zasobów” to język, który trafia do liderów inżynierii. Redukcja kosztów to często metryka o najwyższej dźwigni
• Niezawodność: „obniżyłem liczbę incydentów produkcyjnych z 8 na miesiąc do 1 na miesiąc” lub „poprawiłem SLO usługi z 99,5% do 99,95%” to konkretne metryki niezawodności
• Zespół i zakres: „tech lead 6-osobowego zespołu” lub „odpowiedzialny za projekt i wdrożenie usługi płatności od początku do końca” mówi czytelnikowi o zakresie twojej odpowiedzialności. Bez tego praca mogłaby być czymkolwiek — od „napisałem jedną funkcję” po „zaprojektowałem cały system”
• Dostarczanie: „wdrożyłem 12 wydań produkcyjnych w 18 miesięcy bez poważnych incydentów” lub „dostarczyłem projekt 3 tygodnie przed terminem, zrównoleglając prace infrastrukturalne i funkcyjne” opowiada historię dostarczania
• Adopcja: „wewnętrzna biblioteka używana przez 15+ zespołów” lub „projekt open source z 8 tys. gwiazdek na GitHubie” kwantyfikuje wpływ pracy, która nie ma metryk widocznych dla klienta
• Gdy nie masz konkretnych liczb, daj konkretne opisy. „Zmigrowałem usługę płatności z monolitu do architektury zdarzeniowej, bez przestoju podczas przełączenia” jest konkretne nawet bez liczby

Wzorzec: każdy punkt powinien odpowiadać na pytanie „i co z tego?”. Jeśli punkt mówi „rozwijałem funkcje”, sens jest niewidoczny. Jeśli mówi „zbudowałem proces checkoutu, który podniósł konwersję z 2,1% do 3,2% w 6-tygodniowym eksperymencie”, sens jest na wierzchu. Przepisuj ogólnikowe punkty, aż będą miały albo liczbę, albo konkretny, namacalny efekt.

Open source, projekty po godzinach, hackathony

Rekrutacja w inżynierii ceni wkład poza pracą zarobkową jako dowód autentycznego zaangażowania w rzemiosło. Jak ująć to w CV:

• Wkład w open source: dodaj, jeśli jest znaczący. „Maintainer projektu X (opis, 8 tys. gwiazdek)” to mocny sygnał. „Wniosłem poprawkę błędu do popularnej biblioteki Y” to średni sygnał. „Zgłosiłem PR do projektu Z” to słaby sygnał, chyba że PR był istotny
• Określ charakter wkładu: maintainer, stały współautor, okazjonalny współautor, jednorazowy współautor. To rozróżnienie ma znaczenie, a uczciwe ujęcie buduje wiarygodność
• Jeśli stworzyłeś popularną bibliotekę lub narzędzie open source, postaw to na początku CV. Szeroko używany projekt open source to jeden z najmocniejszych możliwych sygnałów kompetencji inżynierskiej
• Projekty po godzinach: dodaj 2–3 najmocniejsze w sekcji Projekty. Pomiń te, które są przejściem tutorialu, niedokończone albo istnieją tylko jako prywatne repozytoria
• Hackathony: dodaj tylko, jeśli wygrałeś lub zająłeś miejsce na liczącym się wydarzeniu. 2. miejsce na dużym hackathonie uczelnianym lub branżowym warto wpisać; sam udział w studenckim hackathonie — nie, chyba że jesteś bardzo młody stażem
• Wewnętrzne projekty firmowe: zwykle nie liczą się jako „open source”, nawet jeśli mówiono o nich publicznie. Wpisz je raczej w Doświadczenie zawodowe
• Zaangażowanie w społeczność: organizator meetupów, prelegent konferencyjny, gość podcastu, autor tekstów technicznych — dodaj, jeśli znaczące. Sygnalizują inżyniera, który angażuje się w szerszą społeczność, a nie tylko wykonuje swoją pracę
• Bądź uczciwy co do zakresu. „Współtworzyłem Reacta” może znaczyć „otworzyłem jedno zgłoszenie, które zamknięto bez PR-a” albo „napisałem 30 PR-ów, które trafiły na produkcję”. Deklaracja w CV i dowody na GitHubie muszą się zgadzać

Rola open source i projektów po godzinach zmienia się wraz z poziomem. Na poziomie juniora są niezbędnym dowodem bycia praktykującym inżynierem. Na poziomie mida wyróżniają. Na poziomie seniora sygnalizują dalsze zaangażowanie w rzemiosło poza codzienną pracą. Skaluj ich widoczność do etapu kariery.

Wykształcenie i certyfikaty — co ma znaczenie

Stanowiska IT ważą wykształcenie i certyfikaty zupełnie inaczej niż inne branże. Jak to wygląda dziś:

• Inżynierowie juniorzy (0–2 lata): wykształcenie ma znaczenie. Dyplom z informatyki lub pokrewnego kierunku ze znanej uczelni waży. Umieść wykształcenie eksponowanie, blisko góry CV
• Inżynierowie mid (3–7 lat): wykształcenie liczy się mniej. Głównym sygnałem jest historia zatrudnienia. Przenieś wykształcenie na dół CV, chyba że masz szczególnie wyróżniający się dyplom (czołowa uczelnia, stopień zaawansowany w istotnej dziedzinie)
• Inżynierowie senior (8+ lat): przy większości stanowisk wykształcenie jest niemal nieistotne. Wystarczy jedna linia na dole. Wyjątkiem są role, które wprost cenią dorobek akademicki (research engineering, niektóre role ML/AI)
• Absolwenci bootcampów: wpisz bootcamp. Rynek dla absolwentów bootcampów dojrzał; renomowane bootcampy są rozpoznawalne. Połącz to z mocnymi projektami, by zrównoważyć krótszy czas nauki
• Inżynierowie samoucy bez formalnego wykształcenia informatycznego: postaw na projekty i historię zatrudnienia. Wpisz uczciwie naukę kierowaną samodzielnie („samouk, od 2019 skupiony na full-stack web developmencie”). Nie wymyślaj dyplomów, ale też nie czuj się zobowiązany wpisywać żadnych, jeśli ich nie masz
• Certyfikaty AWS / GCP / Azure: liczą się przy rolach skupionych na chmurze (DevOps, SRE, architekt chmury, inżynieria infrastruktury). Podaj konkretny poziom certyfikatu (Associate, Professional itp.)
• Certyfikaty z bezpieczeństwa (CISSP, OSCP, CEH): liczą się przy rolach z obszaru bezpieczeństwa. Podaj z datą uzyskania
• Ogólne certyfikaty programistyczne (Oracle Java, Microsoft .NET): w dużej mierze ignorowane. W CV seniora to wypełniacz
• Ukończone kursy online (Coursera, Udemy, edX): zwykle nie wpisuj. Sygnalizują, że potrafisz ukończyć kurs, a nie że potrafisz wykonać pracę. Wyjątek: ukończenie wyspecjalizowanego programu (Stanford ML, specjalizacja deep learning Andrew Ng) może uzasadniać jednolinijkową wzmiankę
• Doktorat: wpisz na górze, jeśli świeży i istotny; przesuwaj w dół wraz z poziomem. Doktorat jest mocnym sygnałem przy rolach badawczych i neutralnym (czasem lekko negatywnym z powodu odbioru „zbyt akademicki”) przy produktowych rolach inżynierskich

Wzorzec: wykształcenie to sygnał juniorski, który z czasem blednie. Certyfikaty to sygnał ról wyspecjalizowanych, który liczy się, gdy jest na temat, i jest wypełniaczem, gdy nie jest. Skaluj widoczność tych sekcji do miejsca, w którym jesteś w karierze.

CV przyjazne pracy zdalnej — nowa norma

Znaczna część stanowisk inżynierskich w 2026 roku jest zdalna lub hybrydowa. CV powinno sygnalizować gotowość do pracy zdalnej, która sama w sobie stała się kryterium rekrutacyjnym:

• Jeśli masz doświadczenie w pracy zdalnej, zaznacz to: „Senior Engineer (zdalnie), Acme Corp, 2022–2025”. Rekruterzy tego szukają; doświadczenie zdalne jest pozytywnym sygnałem przy rolach zdalnych
• Lokalizacja: podaj obecne miasto i kraj, ale zasygnalizuj elastyczność, jeśli to istotne. „Berlin, Niemcy (otwarty na zdalną pracę, strefy czasowe UE)” lub „Warszawa (otwarty na zdalną pracę w UE)”. Mgliste „otwarty na relokację” jest słabsze niż konkretna dostępność
• Strefa czasowa: podaj ją, jeśli aplikujesz na role zdalne w innej geografii. „Strefa czasowa: CET (UTC+1)” ułatwia planowanie
• Doświadczenie z narzędziami do komunikacji: w kontekście zdalnym wspomnienie o doświadczeniu ze Slackiem, Notion, Linearem, Figmą, programowaniem w parach przez wideo i pracy asynchronicznej sygnalizuje dopasowanie do zdalnej kultury inżynierskiej
• Język samodzielności: „prowadziłem projekt od początku do końca, od specyfikacji po wdrożenie” sygnalizuje autonomię, której wymaga praca zdalna. „Pracowałem z zespołem nad dostarczeniem X” jest neutralne; „samodzielnie poprowadziłem X od koncepcji do startu” jest mocniejsze przy pracy zdalnej
• Dokumentacja i pisanie: podkreśl wszelkie teksty techniczne, pisanie design doców czy wkład w RFC. Zespoły zdalne mocno polegają na komunikacji pisemnej; inżynierów, którzy dobrze piszą, łatwiej zatrudnić zdalnie
• Sygnały pracy między strefami czasowymi: jeśli wprost pracowałeś w różnych strefach (inżynier z USA z zespołem w Berlinie albo na odwrót), wspomnij o tym. Umiejętność współpracy asynchronicznej jest nietrywialna
• Nie sygnalizuj sztywnego „tylko zdalnie”, jeśli jesteś otwarty na pracę w biurze. Uprzedzenie wciąż istnieje w części firm; jeśli jesteś elastyczny, zasygnalizuj elastyczność

Przyjazność pracy zdalnej przeszła z preferencji kandydata do kryterium rekrutacyjnego. Pokazanie w CV, że pracowałeś zdalnie, komunikowałeś się asynchronicznie i działałeś samodzielnie, jest teraz częścią zadania CV — nie tylko przy rolach w pełni zdalnych, ale też hybrydowych, a nawet niektórych stacjonarnych, gdzie gotowość do pracy zdalnej traktuje się jako sygnał jakości.

CV juniora vs mida vs seniora vs staff/principal

Akcenty w CV inżyniera przesuwają się dramatycznie wraz z etapami kariery. To, co działa w CV juniora, zatopi CV staff engineera — i na odwrót:

Podsumowanie zawodowe przy rolach technicznych

Podsumowanie na górze CV w IT jest opcjonalne przy rolach juniorskich i coraz ważniejsze od poziomu mida w górę. Jak napisać takie, które naprawdę pracuje:

• Długość: 3–5 linii. Na tyle długie, by zaramować specjalizację, na tyle krótkie, by czytelnik faktycznie je przeczytał
• Zacznij od lat doświadczenia i głównej specjalizacji: „Backend engineer z 7-letnim doświadczeniem w projektowaniu wysokoskalowych systemów rozproszonych, głównie w Go i Pythonie”. To pierwsza rzecz, którą widzi czytelnik, i powinna zakotwiczyć całe CV
• Dalej zdanie o rodzaju pracy, którą robisz dobrze: „Skupiam się na styku projektowania API i infrastruktury, z głębokim doświadczeniem w architekturach zdarzeniowych i wnętrzu baz danych”.
• Zakończ tym, czego szukasz: „Szukam ról senior+, gdzie poprowadzę projektowanie krytycznego systemu backendowego i w ciągu 2 lat dojdę do zakresu staff”.
• Unikaj ogólnych określeń: „pełen pasji”, „nastawiony na wyniki”, „dbający o szczegóły”. Nie niosą sygnału i czyta się je jak wypełniacz
• Nie streszczaj reszty CV. Podsumowanie powinno dodać informację, której czytelnik nie wyłowi ze skanowania reszty — konkretnie twój obszar specjalizacji, kierunek kariery i to, co czyni cię spójnym kandydatem
• Dopasowuj pod każdą aplikację. Podsumowanie to najłatwiejsze miejsce, by zasygnalizować, że CV jest celowane w to konkretne stanowisko. Podsumowanie pod backendową rolę infrastrukturalną w firmie bazodanowej powinno czytać się inaczej niż podsumowanie tej samej osoby pod backendową rolę produktową w firmie SaaS
• Pomiń podsumowanie w ogóle, jeśli jesteś juniorem. Na tym etapie kariery podsumowanie grozi pustym wypełniaczem bez dodawania sygnału; niech mówi za ciebie sama praca

Podsumowanie to cenna przestrzeń na górze CV. Dobrze użyte, mówi czytelnikowi w 3–5 liniach, kim jesteś jako inżynier, i ramuje wszystko, co następuje dalej. Źle użyte (ogólne przymiotniki, mgliste aspiracje) jest wypełniaczem, który wypiera realny sygnał.

Format CV w IT — jedna strona czy dwie

Pytanie o jedną stronę kontra dwie jest przy CV w IT bardziej niuansowe niż w innych branżach. Schemat:

• Jedna strona: inżynierowie juniorzy (0–3 lata), większość midów (3–7 lat) oraz inżynierowie na rynkach, gdzie jedna strona to norma kulturowa (duża część branży IT w USA)
• Dwie strony: seniorzy ze sporym doświadczeniem (8+ lat), staff/principal z istotnym zakresem do zakomunikowania oraz inżynierowie na rynkach, gdzie dwie strony są normalne (duża część Europy, zwłaszcza Niemcy, Francja, Wielka Brytania)
• Nigdy trzy strony. Jeśli nie mieścisz CV na dwóch stronach, problemem jest redakcja, a nie miejsce. Skróć starsze role do jednolinijkowych podsumowań, wytnij szczegóły z wcześniejszych ról, przytnij mniej istotne projekty
• Jeśli masz dłuższy dokument w stylu CV (akademicki, z publikacjami, prelekcjami, patentami), trzymaj go osobno. CV to podsumowanie dla rekrutera; dłuższy dokument jest na późniejsze prośby
• Format: jedna kolumna czy dwie? Jedna kolumna jest bezpieczniejsza dla ATS. Jeśli używasz dwóch kolumn (pasek boczny na umiejętności/kontakt, główna kolumna na doświadczenie), przetestuj parsowanie, przepuszczając PDF przez internetowy parser CV przed wysłaniem
• Czcionka: trzymaj się standardowych (Calibri, Helvetica, Arial, Source Sans, Inter). Dizajnerskie czcionki potrafią zepsuć parsowanie w ATS. Tekst 10–11 pt, nagłówki 12–14 pt
• Kolor: minimum. Jeden kolor akcentu na nagłówki sekcji jest w porządku; pełnokolorowy projekt jest zbędny i może zepsuć ATS. Sygnałem jest treść, nie design
• Zdjęcie: nie w amerykańskich CV w IT. W krajach europejskich, gdzie zdjęcia są normą (Niemcy, Francja), dodaj profesjonalny portret
• Format pliku: PDF. Zawsze PDF. Dokumenty Worda przepływają inaczej na różnych maszynach i wyglądają na zepsute; PDF-y renderują się spójnie. Nazwij plik konsekwentnie: „Imie-Nazwisko-CV.pdf” lub „Imie-Nazwisko-SeniorEngineer-CV.pdf”

Decyzje o formacie mają służyć treści, a nie ją przyćmiewać. CV w IT, które używa standardowych czcionek, prostej struktury i skromnego koloru, jest czytelniejsze niż takie, które próbuje wyglądać jak portfolio graficzne. Wyjątkiem są role design engineering lub front-end, gdzie pewna wizualna finezja samego CV jest istotnym sygnałem — ale nawet tam powściągliwość czyta się jako pewność siebie.

Spójność CV, LinkedIn, GitHuba i strony osobistej

CV w IT to jeden dokument w skoordynowanej obecności online. Menedżerowie ds. rekrutacji w inżynierii zajrzą na kilka powierzchni, a niespójność między nimi to negatywny sygnał. Schemat koordynacji:

• LinkedIn: powinien opowiadać tę samą historię co CV w zakresie ról, dat i zakresu. Nagłówek może być bardziej aspiracyjny („Senior Backend Engineer zainteresowany systemami rozproszonymi i tooling deweloperskim”), ale treść musi się zgadzać. LinkedIn sprzeczny z CV (inne daty, inne tytuły, inny zakres) niszczy zaufanie
• GitHub: powinien żyć. Niedawne commity, uzupełnione readme profilu, 4–6 przypiętych repozytoriów reprezentujących najlepszą pracę, czyste README. Pusty GitHub w linku z CV jest gorszy niż brak linku. Jeśli GitHub jest ubogi, zainwestuj weekend w jego uporządkowanie przed wysłaniem CV
• Strona osobista: opcjonalna, ale potężna, gdy zrobiona dobrze. Wystarczy prosta strona z jednoakapitowym biogramem, wyróżnionymi projektami, linkiem do pobrania CV i danymi kontaktowymi. Unikaj Flasha, zepsutych formularzy kontaktowych, martwych linków i daty ostatniej aktualizacji z 2020 roku
• Spójność nazwy i tożsamości: używaj tej samej formy imienia i tego samego portretu w CV, na LinkedIn, GitHubie i stronie osobistej. Rekruterzy zestawiają źródła; „Jan Kowalski” w CV, który jest „Janek Kowalski” na LinkedIn, tworzy zgrzyt
• Adres e-mail: spójny na wszystkich powierzchniach. Używaj profesjonalnego adresu (imie@twojadomena.pl lub imie.nazwisko@gmail.com), nie studenckiego maila ani nicka z 2005 roku
• Numer telefonu, lokalizacja i strefa czasowa: spójne na wszystkich powierzchniach. Sprzeczne sygnały lokalizacji wyglądają na nieuwagę
• Jeśli masz portfolio opublikowanych prac (wpisy techniczne, prelekcje, artykuły), linkuj z CV do źródła kanonicznego — twojej strony osobistej lub jednego centralnego profilu, a nie do 10 osobnych linków
• Zrób audyt przed aplikowaniem. Przed wysłaniem CV kliknij każdy link w nim, tak jakbyś był rekruterem. Spójrz na profil LinkedIn świeżym okiem. Przejrzyj GitHub. Jeśli znajdziesz cokolwiek, co przeczy CV lub je podkopuje, popraw to przed aplikowaniem

Menedżer ds. rekrutacji buduje jedno wrażenie o tobie ze skoordynowanych powierzchni, a nie osobne wrażenia z każdej z nich. CV, które wskazuje na spójną obecność online, czyta się jako bardziej wiarygodne niż takie z mocnym CV, ale słabym lub sprzecznym LinkedIn/GitHubem. Te trzydzieści minut porządkowania na wszystkich powierzchniach to jedno z najbardziej dźwigniowych wykorzystań czasu w poszukiwaniu pracy w IT.