Przykład CV dla Software Engineer
CV inżyniera oprogramowania jest czytane przez dwie zupełnie różne grupy odbiorców – jedna po drugiej: najpierw automatyczny parser CV, potem starszy inżynier lub rekruter techniczny. Oboje oczekują zupełnie innych sygnałów z tej samej strony. Parser szuka dokładnych dopasowań słów kluczowych do opisu stanowiska – nazw języków programowania, frameworków, tytułów stanowisk w odpowiednim formacie. Człowiek szuka dowodów: zakresu tego, co faktycznie zbudowałeś, głębokości technicznej na poziomie wymaganym przez rolę i wyników, które dowodzą, że Twoja praca miała znaczenie. Ten wzór obejmuje strukturę, sekcję umiejętności, punkty doświadczenia, sekcję projektów i drobne szczegóły, które odróżniają CV inżyniera oprogramowania lądujące na rozmowach od tego, które zostaje odfiltrowane. Wszystko jest edytowalne w kreatorze Cvida; użyj go jako punktu wyjścia i dostosuj do swojego stosu technologicznego oraz poziomu doświadczenia.
Dlaczego CV inżyniera oprogramowania różni się od zwykłego CV
Zacznij od różnic, bo to one wyjaśniają wszystkie późniejsze wybory. Rekrutacja w branży oprogramowania rządzi się własnymi zasadami:
- Konkretność techniczna to istota gry: „web developer” to etykieta, „TypeScript / React / Node / PostgreSQL” to realne dopasowanie, które parser potrafi ocenić
- Projekty liczą się tak samo jak praca zawodowa: poważny wkład w open source lub prawdziwy projekt produkcyjny jest traktowany jak doświadczenie zawodowe przez starszych recenzentów
- Stos technologiczny ma większe znaczenie niż tytuł: „Starszy inżynier w małej, nieznanej firmie” jest oceniany na podstawie używanego stosu i skali dostarczonego kodu, a nie tytułu
- Kwantyfikacja jest techniczna, nie biznesowa: zmniejszone opóźnienia, obsługiwane żądania na sekundę, poprawiony MTTR, częstotliwość wdrożeń, pokrycie testami – a nie „zwiększyłem przychody”
- Dopasowanie słów kluczowych w systemach ATS jest bezlitosne w branży tech: setki zgłoszeń na jedno stanowisko oznaczają, że rekruter dosłownie skanuje pod kątem dokładnych frameworków wymienionych w ogłoszeniu
Traktuj CV jak dokument techniczny. Ta sama precyzja, której używasz w dokumencie projektowym systemu, obowiązuje tutaj: nazywaj właściwe prymitywy, pokazuj skalę, na jakiej działałeś, i udowadniaj to mierzalnymi wynikami.
Struktura CV, która sprawdza się w rolach inżynierskich
Większość CV inżynierów oprogramowania działa najlepiej w tej kolejności – sygnał techniczny trafia dokładnie tam, gdzie recenzenci patrzą w pierwszej kolejności:
- Nagłówek: imię i nazwisko, tytuł stanowiska, lokalizacja, e-mail, adres GitHub, adres LinkedIn, adres portfolio/strony – każdy link klikalny w pliku PDF
- Podsumowanie (3–4 zdania): lata doświadczenia, główny stos, jedna lub dwie specjalizacje dziedzinowe, rodzaj roli, o którą się ubiegasz
- Umiejętności: umiejętności techniczne pogrupowane według kategorii (języki, frameworki, infrastruktura, narzędzia) – możliwe do przeskanowania w 5 sekund
- Doświadczenie: stanowiska w odwróconej kolejności chronologicznej, każde z 3–6 punktami skupionymi na tym, co dostarczyłeś i jakie przyniosło to efekty
- Projekty (zwłaszcza dla juniorów i mid-level): 2–4 projekty własne lub open source ze stosem technologicznym i osiągniętym rezultatem
- Wykształcenie: tytuł + uczelnia + rok – krótko, chyba że jesteś świeżym absolwentem z istotnymi zajęciami do przywołania
- Opcjonalnie: certyfikaty (AWS, Kubernetes itp.) i znajomość języków, jeśli są istotne
Ogranicz CV do 1 strony przy mniej niż 5 latach doświadczenia, 2 strony powyżej. Inżynierowie na poziomie staff/principal o realnie szerokim zakresie zasługują na drugą stronę; pozostali powinni traktować jedną stronę jako dyscyplinę wymuszającą wybór najsilniejszych sygnałów.
Podstawy struktury i długości CV, na których opiera się ten wzórPodsumowanie: stos technologiczny na pierwszym miejscu, wyniki na drugim
Trzy lub cztery zdania, na samej górze strony. To najczęściej czytana część po imieniu i nazwisku. Powinna odpowiadać na pytania: kim jesteś, co dostarczasz, jakiego rodzaju rola pasuje:
- Zdanie 1: lata doświadczenia + główna specjalizacja. Przykład: „Inżynier backend z 6-letnim doświadczeniem w budowaniu rozproszonych serwisów Go na AWS.”
- Zdanie 2: skala, na jakiej działałeś. Przykład: „Odpowiadałem za serwisy obsługujące 50 tys. żądań na sekundę; prowadziłem zarządzanie incydentami w 12-osobowym zespole platformowym.”
- Zdanie 3: sygnał szerokości technicznej. Przykład: „Biegły w Go, Kafka, Postgres; swobodny w TypeScript i Python przy pracach pobocznych.”
- Zdanie 4 (opcjonalnie): czego szukasz dalej. Przykład: „Poszukuję ról na poziomie senior lub staff przy budowaniu infrastruktury platformowej w skali konsumenckiej.”
- Co usunąć: „pasjonat” / „gracz zespołowy” / „silnie zmotywowany” – to zapełniacze przestrzeni, które działają przeciwko Tobie. Przekonuje konkret techniczny
Podsumowanie, które wymienia prawdziwy stos, prawdziwą skalę i prawdziwy kolejny krok, bije za każdym razem przymiotnikowy bałagan. Jeśli nie możesz wymienić konkretnego stosu, którym byś zarządzał, podsumowanie nie jest gotowe – ta luka i tak wyjdzie na rozmowie kwalifikacyjnej.
Sekcja umiejętności: sygnały głębokości, nie ściana modnych słów
Pogrupuj umiejętności techniczne według kategorii, żeby recenzent mógł je przeskanować w kilka sekund. W obrębie każdej grupy uszereguj według faktycznej głębokości – najpłynniejsze na pierwszym miejscu:
- Języki: Go, TypeScript, Python, Rust (mniej więcej w tej kolejności biegłości)
- Frameworki: React, Next.js, Node/Express, FastAPI, gRPC
- Dane / infrastruktura: PostgreSQL, Redis, Kafka, ElasticSearch, Kubernetes, Terraform, AWS (EC2, S3, RDS, Lambda)
- Praktyki: projektowanie systemów rozproszonych, obserwowalność (Prometheus, Grafana, OpenTelemetry), CI/CD (GitHub Actions, ArgoCD), zarządzanie incydentami
- Co pominąć: narzędzia użyte raz 5 lat temu, języki ledwo dotknięte w jednym samouczku, „Microsoft Word” (naprawdę – rekruterzy tylko przewrócą oczami)
Bądź szczery co do głębokości: jeśli coś wymienisz, zostaniesz o to zapytany. Krótka i dokładna sekcja umiejętności bije długą pełną fałszywych sygnałów – złapanie Cię na kłamstwie o doświadczeniu z Kafka podczas rozmowy technicznej kosztuje Cię ofertę.
Jak zbudować wiarygodną, konkretną sekcję umiejętności dopasowaną do roliPunkty doświadczenia: dostarczone + skala + wpływ, w każdym wierszu
Najsilniejsze punkty inżynierskie trzymają się zwartego schematu: czasownik czynności → co zbudowałeś → skala lub wpływ wyrażony w liczbach. Porównaj:
- Słaby: „Pracowałem przy systemie przetwarzania płatności” – brak stosu, brak skali, brak wyników, brak zakresu odpowiedzialności
- Mocny: „Zaprojektowałem i dostarczyłem rozproszony serwis płatności w Go obsługujący 12 tys. transakcji na sekundę z dostępnością 99,99% w 3 regionach AWS”
- Mocny: „Zmniejszyłem opóźnienie p99 API z 480 ms do 90 ms, zastępując agregację in-memory zmaterializowanym widokiem opartym na Redis; wdrażałem za flagą funkcji przez 6 tygodni”
- Mocny: „Prowadziłem migrację zespołu z monolitu Rails do 4 serwisów Go; skróciłem czas wdrożenia z 35 do 6 minut, a MTTR z ~2 h do 28 minut”
- Mocny: „Zbudowałem wewnętrzną platformę flag funkcji, z której korzysta teraz 40 inżynierów z 6 zespołów; zintegrowałem zestawy SDK dla Go, TypeScript i Python”
- Schemat do zastosowania: zacznij każdy punkt od czasownika czynności (zaprojektowałem, dostarczyłem, prowadziłem, skalowałem, odpowiadałem, migrowałem, zautomatyzowałem), wymień technologię, podaj skalę lub różnicę przed/po
Liczby nie muszą być imponujące – muszą być prawdziwe i konkretne. „Obsługiwałem 200 żądań na sekundę w małym e-commerce” to mocny punkt dla inżyniera na poziomie mid-level; szczerość co do skali jest bardziej przekonująca niż ogólnikowe twierdzenia o wpływie.
Jak ująć pracę w liczbach tak, jak oceniają to komisje rekrutacyjne w inżynieriiSekcja projektów: kluczowa dla juniorów, przydatna dla wszystkich
Mocna sekcja projektów odpowiada na pytanie, które recenzenci zawsze mają w odniesieniu do kandydatów, których codzienna praca nie pokazuje pełnego zakresu możliwości: co potrafisz zbudować, gdy nikt Cię nie powstrzymuje? Ma poważne znaczenie dla inżynierów na początku kariery oraz dla osób zmieniających branżę:
- Wybierz 2–4 projekty, każdy z: nazwą, jednowierszowym opisem, stosem technologicznym, adresem GitHub lub strony działającej na żywo oraz 1–2 punktami o tym, co jest interesujące w sposobie realizacji
- Wkłady w open source się liczą: „Wniosłem przepisanie konsumenta Kafka do {project} (scalony, 30 tys. pobrań tygodniowo)” to poważny sygnał
- Projekty poboczne z prawdziwymi użytkownikami są na wagę złota: „Zbudowałem {tool}: narzędzie CLI dla X, używane przez ~200 deweloperów; napisane w Rust, pakowane przez Homebrew”
- Projekty kursowe / bootcampowe są najsłabsze – uwzględnij je tylko jeśli nie masz nic innego i zacznij od tego, co było technicznie nieoczywiste
- Jeśli masz 5+ lat solidnego doświadczenia zawodowego, sekcja ta staje się opcjonalna; zastąp ją sekcją „Wybrane wkłady open source”, jeśli takowe masz
Zadbaj o to, żeby każdy link do projektu był aktywny. Recenzent, który klika adres GitHub i trafia na prawdziwe, niedawno aktywne repozytorium z przejrzystym plikiem README, jest w połowie przekonany zanim przeczyta Twoje punkty – daj mu ten sygnał jednym kliknięciem.
Wykształcenie i certyfikaty: krótko
Dla inżynierów oprogramowania ta sekcja jest warta miejsca tylko wtedy, gdy wnosi konkretny sygnał:
- Jeśli masz dyplom, podaj go: rodzaj, kierunek, uczelnia, rok. Jeden wiersz. Pomiń średnią ocen, chyba że jesteś świeżym absolwentem z wysoką
- Świeży absolwenci (0–2 lata po ukończeniu): dodaj istotne przedmioty lub projekt dyplomowy, ale tylko te, które odpowiadają wybranej roli
- Absolwenci bootcampów: podaj nazwę bootcampu i rok; zacznij od projektów i kodu produkcyjnego dostarczonego od tamtej pory, nie od programu nauczania
- Samoucy: pomiń sekcję wykształcenia całkowicie; pozwól sekcji projektów i doświadczeniu zawodowemu wykonać całą robotę
- Certyfikaty warte wymienienia: AWS Solutions Architect / Associate, GCP Professional Cloud Architect, CKA (Certified Kubernetes Administrator). Pomiń „Ukończony kurs Codecademy” – rekruterzy tego nie liczą
Wykształcenie ma coraz mniejsze znaczenie, im dalej jesteś od ukończenia studiów. Po 5 latach mocna sekcja projektów i doświadczenia sprawia, że wiersz z wykształceniem staje się niemal niewidoczny – co jest dokładnie tym, czego chcesz. Rozmowa kwalifikacyjna będzie dotyczyła Twojego kodu, nie dyplomu.
Optymalizacja pod ATS: dopasuj ogłoszenie dokładnie
Nawet na poziomie starszym Twoje CV jest parsowane zanim zobaczy je człowiek. Punktacja ATS w inżynierii jest wyjątkowo dosłowna jeśli chodzi o nazwy technologii:
- Odzwierciedlaj dokładne nazwy frameworków z ogłoszenia. Jeśli ogłoszenie mówi „React.js”, napisz „React.js” (nie tylko „React”); jeśli mówi „Node.js”, napisz „Node.js”
- Podawaj zarówno skrót, jak i pełną nazwę tam, gdzie się różnią: „Kubernetes (K8s)”, „Continuous Integration (CI/CD)” – obejmujesz obie odmiany słów kluczowych
- Zachowaj format prosty: standardowe czcionki, bez układów dwukolumnowych, bez grafik z tekstem, bez ozdobnych separatorów sekcji. Parsery ATS niszczą wszystko, co jest wizualnie pomysłowe
- Zapisuj jako PDF, chyba że ogłoszenie wymaga formatu Word – układ przeżywa konwersję niezawodniej
- Nie upychaj słów kluczowych w ukrytym wierszu „umiejętności” zapisanym białym tekstem. Nowoczesne systemy ATS to wykrywają, rekruterzy się śmieją – a rozmowa techniczna i tak wychodzi na jaw z kłamstwem
Najprostszy test: czy możesz otworzyć CV w zwykłym edytorze tekstu i czytać je od góry do dołu w logicznej kolejności? Jeśli tak, parser też tak to przeczyta. Jeśli Twoje umiejętności lądują w środku wiersza z wykształceniem, formatowanie walczy z parserem.
Pełny przewodnik po ATS dotyczący bezpiecznego formatowania CV pod parsowanieTypowe błędy, które odfiltrują dobrych inżynierów
Nawet technicznie mocni inżynierowie tracą szanse na rozmowę z powodu błędów w CV, które łatwo naprawić:
- Wymienianie każdego języka, którego kiedykolwiek dotknąłeś: rozmywa prawdziwe sygnały i zaprasza do pytań rekrutacyjnych, na które się zaknujesz. Wymieniaj tylko to, co byłbyś pewien obronić na rozmowie
- Podsumowania pełne modnych słów bez stosu: „pełen pasji programista full-stack z silnymi kompetencjami komunikacyjnymi” nic nie mówi. Podaj stos i skalę
- Brak linków: CV inżyniera oprogramowania bez adresu GitHub lub portfolio jest podejrzane – recenzenci chcą zobaczyć kod. Dodaj adres nawet jeśli Twój GitHub jest skromny
- Punkty jak bloki tekstu: punkty dłuższe niż dwa wiersze gubią czytającego. Trzymaj je zwarto: czynność + technologia + wynik
- Przestarzałe sygnały stosu: zostawienie „jQuery” na liście języków, gdy od 5 lat piszesz w TypeScript, sygnalizuje, że CV nie było przepisywane od dawna – i że Ty też możesz nie być na bieżąco
Przeprowadź test rekrutera: w ciągu 30 sekund, czy zajęty recenzent widzi, co budujesz, w jakiej skali i do jakich ról pasujesz? Jeśli tak, to CV zapewni Ci rozmowy. Jeśli nie, rozwiązania są niemal zawsze takie same – zwartsze punkty, wymieniony stos, mniej przymiotników, działające linki.
Pełny przewodnik dostosowania CV do ról w branży tech – mapowanie stosu i sygnały poziomu seniorityNajczęstsze pytania
Jak napisać CV software engineera bez doświadczenia?
Pokaż to, co zbudowałeś, a nie stanowiska, których jeszcze nie miałeś. Zaraz po umiejętnościach dodaj sekcję „Projekty” z dwoma–czterema projektami dostępnymi online lub na GitHubie i opisz każdy jak pracę: stos technologiczny, co zrobiłeś, jeden efekt. Na przykład: „Aplikacja do budżetu domowego w React i Node.js, z uwierzytelnianiem JWT i bazą PostgreSQL”. Staże, praktyki, hackathony i przyjęte pull requesty do projektów open source też tu pasują.
Co zrobić, jeśli mój kod jest prywatny albo objęty NDA?
To najczęstsza sytuacja i rekruterzy techniczni dobrze o tym wiedzą. Opisz swoją pracę w doświadczeniu bez poufnych szczegółów: podaj technologie, skalę i efekt, ale nie nazwę klienta ani wewnętrznych systemów. Potem dodaj link do publicznego kodu, który masz, nawet jeśli to niewiele, na przykład dobrze udokumentowany projekt poboczny. Małe repozytorium z porządnym README mówi więcej niż profil GitHub pełen forków.
Czy dodać zdjęcie do CV software engineera?
To kwestia wyboru. W Polsce zdjęcie w CV wciąż jest popularne, ale w IT, zwłaszcza w firmach międzynarodowych, jego brak niczego nie odbiera. Jeśli je dodajesz, niech będzie małe, profesjonalne i na neutralnym tle. Pamiętaj za to o klauzuli o przetwarzaniu danych osobowych (RODO) na dole CV, jeśli ogłoszenie jej wymaga, bo jej brak mimo wyraźnej prośby źle świadczy o dbałości o szczegóły.
CV po polsku czy po angielsku?
Kieruj się językiem ogłoszenia. Wiele firm IT w Polsce pracuje dla klientów zagranicznych lub w międzynarodowych zespołach i publikuje oferty od razu po angielsku; wtedy wysyłaj CV po angielsku. Na ogłoszenie po polsku odpowiadaj po polsku, zostawiając nazwy technologii bez zmian (Kubernetes, React, CI/CD). Warto mieć gotowe obie wersje, żeby nie tłumaczyć CV w pośpiechu przed każdą aplikacją.