Jak napisać CV do IT, które przejdzie przez ATS

Cel kandydata: CV do IT, które nie utknie w ATS

Intencja jest prosta: stworzyć CV do IT, które przejdzie przez system ATS, nie „wysypie się” na formacie i jednocześnie będzie na tyle konkretne i techniczne, żeby przekonać rekrutera IT oraz hiring managera. Da się to zrobić bez magii – wymaga tylko zrozumienia, jak działa ATS i jak myślą osoby techniczne po drugiej stronie.

Czym jest ATS i jak wpływa na rekrutację w IT

ATS w IT – po co firmie ten system

ATS (Applicant Tracking System) to system do zarządzania aplikacjami kandydatów. W rekrutacjach IT firmy dostają dziesiątki, a czasem setki CV na jedno ogłoszenie. Bez ATS:

• rekruter musiałby ręcznie przeszukiwać maile i pliki,
• trudno byłoby filtrować kandydatów po technologiach lub lokalizacji,
• proces nie byłby powtarzalny i mierzalny.

ATS umożliwia m.in. filtrowanie kandydatów po słowach kluczowych (np. „Java”, „Kafka”, „Selenium”), tworzenie krótkich list i przekazywanie CV dalej – do liderów technicznych i hiring managerów. To nie jest „robot-do-zabijania-kandydatów”, tylko narzędzie porządkujące chaos.

Jak ATS czyta i filtruje CV kandydata IT

Większość popularnych systemów ATS pracuje według podobnego schematu. Po wysłaniu CV:

• system próbuje „wyciągnąć” z pliku podstawowe dane (imię, nazwisko, mail, telefon),
• szuka znanych nagłówków sekcji (Experience, Skills, Education, Projects),
• skanuje treść pod kątem słów kluczowych powiązanych z ogłoszeniem,
• umożliwia rekruterowi filtrowanie po słowach/technologiach i układanie rankingów.

Niektóre ATS-y tworzą nawet uproszczony profil kandydata: listę technologii, poziom doświadczenia, lokalizację. Jeżeli CV ma dziwny format (tabele, grafiki, dwie kolumny z tekstem wstawionym jako obraz), system może część treści pominąć, połączyć w jedną kolumnę lub „popsuć” kolejność.

Dlatego format CV pod ATS musi być możliwie prosty i tekstowy: standardowe nagłówki, brak istotnych danych w grafikach, rozsądne użycie kolumn i absolutne minimum „udziwnień” wizualnych.

Przejść ATS vs przekonać człowieka – dwa różne cele

„Przejść przez ATS” oznacza tyle, że:

• system poprawnie odczyta Twoje dane,
• CV nie zostanie odfiltrowane przez najbardziej podstawowe reguły (np. brak słowa „Java” w ogóle),
• rekruter będzie mógł Cię znaleźć, filtrując po technologiach i słowach kluczowych.

„Przekonać człowieka przy biurku” to coś innego. Osoba techniczna patrzy na CV inaczej niż ATS:

• szuka szybko odpowiedzi: czy ta osoba faktycznie robiła to, czego szukamy,
• patrzy na spójność historii – projekty, narzędzia, odpowiedzialności,
• wyłapuje przesadę i „spuchnięte” listy umiejętności.

Dlatego zadanie brzmi: naładować CV właściwymi słowami kluczowymi, ale użyć ich w naturalnych, konkretnych opisach doświadczeń i projektów. Samo „wypchanie” sekcji Skills technologiami nie wystarczy – rekruter techniczny będzie szukał potwierdzenia tych umiejętności w opisach projektów.

Mit: „ATS kasuje 90% CV automatycznie” – jak jest naprawdę

Często powtarza się mit, że ATS odrzuca „automatycznie” 80–90% CV. W praktyce:

• w wielu firmach IT ATS służy głównie do organizacji, a nie bezwzględnej selekcji,
• przy specjalistycznych rolach większość CV i tak ogląda człowiek – choćby pobieżnie,
• ATS może jednak utrudnić życie, gdy CV jest w nieczytelnym formacie albo kompletnie nie trafia w wymagania.

Rzeczywistość jest mniej dramatyczna: większość CV odpada nie dlatego, że „robot je wyrzucił”, tylko dlatego, że nie widać w nich wymaganych technologii lub doświadczenia. Albo są tak chaotyczne, że rekruter po 10 sekundach nie wie, kim jest kandydat.

Jak czytać ogłoszenie o pracę w IT pod kątem ATS

Rozbieranie ogłoszenia na części: must-have, nice-to-have, tech stack

Ogłoszenie o pracę w IT jest Twoją mapą słów kluczowych. Zanim cokolwiek zmienisz w CV, rozłóż ogłoszenie na kilka obszarów:

• Wymagania must-have – zwykle w punktach, czasem pod hasłem „Wymagania”:
  • konkretne technologie (np. Python, React, Docker),
  • lata doświadczenia w danej roli,
  • języki (np. angielski B2/C1).
• Nice-to-have – technologie lub doświadczenia, które „dobrze mieć”, ale nie są krytyczne.
• Tech stack – narzędzia i technologie używane w projekcie, niezależnie od tego, czy są w wymaganiach, np.:
  • Jira, Confluence, GitLab, Jenkins, Azure DevOps,
  • AWS, Azure, GCP, Kubernetes, Kafka, RabbitMQ.
• Obowiązki – często zawierają ukryte słowa kluczowe:
  • „tworzenie i utrzymanie mikroserwisów”,
  • „współpraca z Product Ownerem” (słowa: Agile, Scrum, backlog),
  • „automatyzacja testów UI i API” (Selenium, REST, Postman).

Jak wyłapać słowa kluczowe ważne dla ATS

Spójrz na ogłoszenie jak na dokument, z którego trzeba wyciągnąć zestaw fraz. Najczęściej to:

• technologie i języki: Java, .NET, Python, JavaScript, TypeScript, SQL, Bash,
• frameworki i biblioteki: Spring, .NET Core, React, Angular, Vue.js, Django, Flask,
• narzędzia: Git, Jenkins, Docker, Kubernetes, Jira, Terraform, Cypress, Selenium,
• bazy danych: PostgreSQL, MySQL, MongoDB, Redis, Elasticsearch,
• metodyki i praktyki: Agile, Scrum, Kanban, TDD, BDD, CI/CD, Code Review,
• domena biznesowa: e-commerce, fintech, telco, insurtech, healthcare.

Te frazy mogą później trafić do kilku sekcji: podsumowania zawodowego, sekcji umiejętności technicznych i opisów doświadczeń/projektów. Nie chodzi o kopiowanie ogłoszenia 1:1, tylko o świadome użycie tych samych pojęć, którymi posługują się rekruter i ATS.

Mapa słów kluczowych z jednego i wielu ogłoszeń

Dobrym nawykiem jest tworzenie szybkiej, roboczej „mapy słów kluczowych” w prostym dokumencie tekstowym. Dla jednego ogłoszenia możesz wypisać:

• 3–5 kluczowych technologii (must-have),
• 2–4 nice-to-have,
• 2–3 słowa opisujące domenę/projekt (np. mikroserwisy, płatności online, data warehouse),
• metodyki i narzędzia (Agile, Scrum, Jira, Git, CI/CD).

Jeśli aplikujesz na podobne role (np. backend Java Developer), sklej taką mapę z kilku ogłoszeń. Szybko zobaczysz powtarzające się elementy: np. Java, Spring, REST, Docker, SQL, Git, mikroserwisy, AWS. To właśnie z tych powtarzalnych elementów powinna się składać główna część Twojej sekcji Skills.

Które słowa kluczowe powtarzać w kilku sekcjach CV

Nie wszystkie frazy mają tę samą wagę. Najmocniejsze słowa kluczowe warto umieścić:

• w nagłówku stanowiska (np. „Java Developer” zamiast „Programista”),
• w podsumowaniu zawodowym – w pierwszych 2–3 zdaniach,
• w sekcji umiejętności technicznych – w odpowiednich kategoriach,
• w opisach projektów – jako realnie używane technologie.

Jeżeli w ogłoszeniu trzy razy pojawia się „React”, a Twoje CV wspomina React tylko raz, na liście Skills, ATS i rekruter mogą mieć problem, żeby uznać Cię za kogoś faktycznie pracującego z tym frameworkiem, a nie tylko go znającego „na kursie”. Lepiej, gdy React pojawia się też w opisie projektu, np. „Rozwój panelu administracyjnego w React”.

Konstrukcja CV pod ATS: układ, długość, format pliku

Rekomendowany układ sekcji w CV do IT

Prosty, przewidywalny układ pomaga zarówno ATS-owi, jak i osobie czytającej. Typowa, skuteczna struktura dla CV w IT wygląda tak:

1. Nagłówek z danymi – imię, nazwisko, stanowisko docelowe, dane kontaktowe.
2. Podsumowanie zawodowe – 4–6 zdań z esencją Twojego profilu.
3. Umiejętności techniczne (Skills / Tech stack) – podzielone na kategorie.
4. Doświadczenie zawodowe – od najnowszego, z opisem projektów i osiągnięć.
5. Projekty (jeśli istotne) – szczególnie dla juniorów i osób po bootcampie.
6. Edukacja – studia, bootcampy, istotne szkolenia.
7. Certyfikaty – jeśli masz branżowe (np. AWS, ISTQB, Azure).
8. Linki – GitHub, LinkedIn, portfolio, ewentualnie blog techniczny.

Dla doświadczonych specjalistów projekty i doświadczenie można połączyć – kluczowe projekty opisujesz w ramach konkretnej roli. Dla juniorów sekcja „Projekty” często jest ważniejsza niż „Doświadczenie”, bo to tam widać realny kod, testy, analizy danych.

Formatowanie przyjazne ATS: prostota i tekst zamiast fajerwerków

Większość popularnych ATS-ów radzi sobie dziś lepiej z plikami niż kiedyś, ale nadal najbezpieczniejsze jest podejście minimalistyczne. Kilka praktycznych reguł:

• Stosuj proste nagłówki sekcji: „Experience”, „Work Experience”, „Professional Experience”, „Skills”, „Education”, „Projects”. Nie wymyślaj „Moja ścieżka” zamiast „Experience”.
• Unikaj umieszczania kluczowych informacji w tabelach – szczególnie danych kontaktowych i listy doświadczeń.
• Kolumny: jeśli używasz dwóch kolumn, zadbaj, aby w wersji tekstowej (kopiuj–wklej do notatnika) treść była nadal czytelna; nie przeciągaj opisów na całą szerokość w obu kolumnach.
• Ikony (telefon, email, LinkedIn) są ładne, ale nie mogą zastępować tekstu. Zawsze obok ikony musi być normalny tekst: numer, adres, URL.
• Korzystaj z standardowych fontów i prostego wyróżniania (pogrubienie, kursywa, listy punktowane).

System ATS nie ocenia designu, więc CV „ładne na Dribbble” może być bezużyteczne, jeśli kluczowe dane umieszczono w kształtach, grafikach lub jako obrazek. Funkcjonalność przed estetyką.

PDF czy DOCX – jaki format pliku dla ATS

Tu często pojawia się mit: „ATS nie czyta PDF”. Rzeczywistość: większość nowoczesnych ATS radzi sobie z PDF-em, o ile jest to standardowy, tekstowy PDF wygenerowany z edytora (Word, Google Docs), a nie skan czy obraz.

Bezpieczne podejście:

• jeżeli ogłoszenie nic nie mówi o formacie – wysyłaj PDF,
• jeżeli system prosi o DOCX – użyj DOCX, nie kombinuj,
• zawsze możesz mieć dwie wersje: PDF (ładniejszy, do wysyłki mailowej) i DOCX (gdy system tego wymaga).

Prosty test „czytelności” dla ATS: otwórz wygenerowanego PDF-a, zaznacz cały tekst, skopiuj i wklej do Notatnika. Jeżeli treść jest w logicznej kolejności i nie brakuje istotnych fragmentów, ATS prawdopodobnie poradzi sobie podobnie.

Długość CV w IT – mit jednej strony kontra praktyka

Popularny mit: „CV musi mieć maksymalnie jedną stronę”. To rada sensowna dla studenta bez doświadczenia, ale niekoniecznie dla senior developera z 10-letnim stażem.

Praktyczne zasady dla IT:

• Junior / CV po bootcampie – często 1 strona wystarczy, pod warunkiem że sensownie opiszesz projekty, a nie tylko listę kursów.
• Mid – 1–2 strony to rozsądny zakres. Lepiej 2 strony z konkretnymi projektami niż 1 strona wypełniona ogólnikami.

Długość CV dla seniorów i specjalistów niszowych

Przy większym doświadczeniu kluczowe staje się nie to, ile stron ma dokument, ale jak szybko rekruter i ATS docierają do mięsa. Senior developer, architekt, devops czy data scientist z kilkunastoma latami w branży zazwyczaj i tak nie zmieści sensownych informacji na jednej stronie.

• Senior / Lead / Architekt – 2 strony to standard, 3 strony bywa akceptowalne, jeżeli:
  • masz kilka różnych specjalizacji (np. Java + Big Data + chmura),
  • pracowałeś w wielu organizacjach, a każda wnosi inny typ doświadczenia,
  • uczestniczyłeś w projektach o dużym wpływie (np. systemy płatnicze, krytyczne systemy dla banku).
• Specjaliści niszowi (np. low-level C, embedded, mainframe) – 2–3 strony są wręcz pożądane, bo liczą się konkretne technologie, standardy, protokoły, których ATS szuka po nazwie.

Mit: „Im krótsze CV, tym lepiej”. Rzeczywistość: im bardziej skondensowane i trafne do ogłoszenia, tym lepiej – niezależnie od tego, czy ma 1 czy 3 strony. ATS nie męczy się przewijaniem, ale gubi się przy wodolejstwie bez słów kluczowych.

Nagłówek i dane kontaktowe, które ATS i rekruter odczytają bez bólu

Jak nazwać stanowisko w nagłówku CV

Pierwsze linijki CV to Twoja wizytówka. ATS i rekruter zwracają szczególną uwagę na tytuł pod imieniem i nazwiskiem. Zamiast kreatywności w stylu „Tech Ninja” czy „Digital Wizard” użyj sformułowań, które występują w ogłoszeniach.

Praktyczny schemat:

• Imię i nazwisko
• Stanowisko docelowe – np. Java Developer, React Developer, QA Automation Engineer, Data Engineer.
• Lokalizacja + tryb (opcjonalnie) – np. „Kraków / zdalnie”, „Warszawa / hybryda”.

Jeżeli aplikujesz na kilka zbliżonych ról, możesz użyć kombinacji, np. „Backend Java Developer / Kotlin Developer”, ale nie doklejaj pięciu różnych specjalizacji. Lepiej przygotować dwie wersje CV z lekko odmiennym nagłówkiem niż jedno „CV do wszystkiego”.

Mit: „Stanowisko w nagłówku musi dokładnie kopiować nazwę z ogłoszenia”. Rzeczywistość: wystarczy, że jesteś blisko. „Java Developer” w CV spokojnie łączy się z ogłoszeniem na „Java Software Engineer”, ATS patrzy na słowa, nie na całą frazę 1:1.

Dane kontaktowe – minimalistyczne, ale kompletne

ATS szuka standardowych pól: imię, nazwisko, email, numer telefonu, lokalizacja. Nie komplikuj tego prostego obszaru.

• Email – w formacie tekstowym, najlepiej zawodowy: imie.nazwisko@…, bez ozdobników i pseudonimów.
• Telefon – z prefiksem kraju, np. +48 123 456 789. Nie zapisuj numeru w dziwnych formatach z ikonami zamiast cyfr.
• Lokalizacja – miasto + kraj są wystarczające, np. „Wrocław, Polska”. Pełny adres domowy nie jest potrzebny.
• Linki – LinkedIn, GitHub, ewentualnie portfolio lub blog. Podawaj pełne, klikalne URL-e lub krótkie domeny, nie „github: jan_koduje” bez linku.

Jeżeli stosujesz ikony (np. słuchawka, koperta), obok musi stać zwykły tekst z numerem lub adresem email. ATS nie wyciągnie danych z obrazka.

Elementy, które lepiej pominąć w nagłówku

Wielu kandydatów wpycha do górnej części CV masę zbędnych informacji, które tylko odciągają uwagę od tego, co ważne.

• Data urodzenia – niepotrzebna w większości rekrutacji IT, a w części firm wręcz niewskazana.
• Stan cywilny, liczba dzieci, zdjęcie z wakacji – te dane nie pomagają ani ATS-owi, ani rekruterowi.
• Adres zameldowania – jeżeli nie aplikujesz na stanowisko wymagające konkretnej lokalizacji fizycznej, wystarczy miasto.

Jeśli aplikujesz globalnie, dodaj informację o strefie czasowej lub gotowości do relokacji, ale nie w formie pół strony eseju. Jedno, dwa krótkie sformułowania: „CET (UTC+1)”, „Open to relocation in EU”.

Podsumowanie zawodowe do IT – jak w 4–6 zdaniach trafić w ATS i człowieka

Dlaczego podsumowanie ma sens w CV technicznym

Dobrze napisane podsumowanie pozwala w pierwszych 10–15 sekundach pokazać rekruterowi, że „to jest ten profil”. ATS z kolei wyłapuje tam najważniejsze słowa kluczowe powiązane ze stanowiskiem.

Podsumowanie ma pełnić trzy funkcje:

• określić poziom seniority i główny stack,
• pokazać zakres doświadczenia (rodzaje projektów, domeny),
• zaznaczyć efekty pracy (nie tylko wykonywane zadania).

Struktura skutecznego podsumowania dla IT

Zamiast ogólników typu „Ambitny, zmotywowany, nastawiony na rozwój”, skup się na faktach. Prosty szkielet:

1. Kim jesteś i w czym się specjalizujesz – tytuł + główne technologie.
2. Ile masz doświadczenia i w jakich typach projektów.
3. Jakie problemy rozwiązujesz (np. wydajność, automatyzacja, jakość kodu).
4. Jak pracujesz – metodyki, środowisko, odpowiedzialności.

Przykład dla backend developera:

„Backend Java Developer z ponad 4-letnim doświadczeniem w projektach opartych na mikroserwisach (Spring Boot, REST, Docker). Pracowałem przy systemach płatności online i platformach e-commerce o dużym ruchu, skupiając się na wydajności i skalowalności. Projektuję i implementuję REST API, integracje z systemami zewnętrznymi oraz procesy CI/CD (GitLab CI, Docker, Kubernetes). Na co dzień współpracuję blisko z zespołami QA i Product Ownerem w środowisku Agile (Scrum).”

Słowa kluczowe w podsumowaniu – jak nie przesadzić

Podsumowanie nie powinno być listą technologii rozdzielonych przecinkami. ATS i tak znajdzie stack w sekcji Skills, a rekruter szuka tu sensu, nie ściany nazw.

Dobre podejście:

• wprowadź 2–4 kluczowe technologie (te z must-have z ogłoszenia),
• dodaj 1–2 domeny (np. fintech, e-commerce, IoT),
• wpleć 1–2 frazy metodyczne (Agile, Scrum, CI/CD, TDD), ale tylko jeśli faktycznie z nimi pracujesz.

Mit: „Im więcej technologii napiszę w podsumowaniu, tym lepiej dla ATS”. Rzeczywistość: nadmiar nazw bez kontekstu może wyglądać jak kopiuj–wklej z kursu, a nie jak realne doświadczenie. Pokaż selekcję, nie katalog hurtowni IT.

Jak dostosować podsumowanie do ogłoszenia

Drobne modyfikacje pod konkretne ogłoszenie potrafią realnie podnieść dopasowanie w ATS i pierwsze wrażenie u rekrutera. Nie trzeba przepisywać całej sekcji – wystarczy zmienić kilka elementów.

• Zamień ogólną technologię na bardziej precyzyjną, jeżeli ogłoszenie ją wymienia (np. „chmura” → „AWS”, „testy automatyczne” → „Cypress, Playwright”).
• Doprecyzuj domenę, jeśli pokrywa się z Twoim doświadczeniem (np. z „systemy finansowe” na „płatności online i chargeback”).
• Dodaj słowo kluczowe ze stanowiska, jeśli już je masz w doświadczeniu, ale nie w podsumowaniu (np. „Data Engineer” zamiast tylko „Python Developer”).

Sekcja umiejętności technicznych: jak poukładać tech stack, żeby ATS go „polubił”

Logiczne kategorie zamiast jednej ściany tekstu

ATS zwykle indeksuje wszystko, ale rekruter nie ma czasu dekodować chaotycznej listy technologii. Dobrze uporządkowana sekcja Skills przyspiesza decyzję „pasuje / nie pasuje”.

Przykładowy podział dla developera:

• Języki programowania: Java, Kotlin, Python, JavaScript, TypeScript
• Frameworki / biblioteki: Spring, Spring Boot, Hibernate, React, Redux
• Bazy danych: PostgreSQL, MySQL, MongoDB, Redis
• DevOps / CI/CD: Git, GitLab CI, Jenkins, Docker, Kubernetes
• Chmura: AWS (EC2, S3, RDS), Azure DevOps
• Testy: JUnit, Mockito, Cypress

Dla QA, DevOpsów, analityków danych czy UX-ów kategorie będą inne, ale zasada ta sama: grupuj technologie, z których jesteś w stanie skorzystać dziś, bez dodatkowego kursu.

Poziomy zaawansowania – jak nie strzelić sobie w stopę

Skale typu „Java – 9/10, Python – 7/10” są bardziej komiczne niż użyteczne. Każdy inaczej definiuje „8/10”. Lepiej użyć prostszych, zrozumiałych etykiet lub w ogóle zrezygnować ze skali, a poziom pokazać w opisach projektów.

Rozsądne podejście:

• Primary / Main stack – technologie używane obecnie i regularnie.
• Secondary – technologie, z którymi umiesz pracować, ale nie są głównym narzędziem.
• Basic / Familiar – tylko jeśli rzeczywiście możesz coś z tym zrobić (np. utrzymać istniejący kod), a nie „obejrzałem tutorial na YouTube”.

Alternatywnie możesz pominąć poziomy i pokazać je pośrednio, np. umieszczając na górze listy to, w czym czujesz się najmocniej. ATS jest zadowolony w obu wariantach, rekruter – tylko wtedy, gdy nie przesadzasz z samozachwytem.

Jak wybrać, co w ogóle trafi do sekcji Skills

Naturalna pokusa: wpisać wszystko, czego kiedykolwiek dotknąłeś. W efekcie powstają kurioza typu „Windows, MS Office, Slack” w CV senior developera. W IT obowiązuje zasada: jeżeli nie jest to ani oczywiste, ani kluczowe dla roli – albo usuń, albo przenieś niżej.

Zadaj sobie trzy pytania dla każdej technologii:

1. Czy ta technologia pojawia się w ogłoszeniach, na które aplikuję?
2. Czy potrafię użyć jej samodzielnie w realnym zadaniu w pracy?
3. Czy potrafię opowiedzieć o konkretnym przykładzie jej użycia na rozmowie?

Jeśli choć na jedno pytanie odpowiadasz „nie”, rozważ usunięcie lub przeniesienie do sekcji typu „Other tools”. ATS nie da Ci dodatkowych punktów za dekoracje, a na rozmowie szybko wyjdzie, że „Kubernetes” oznaczał tylko „odpaliłem raz lokalny klaster z tutoriala”.

Unikanie duplikatów i martwych technologii

Kolejny mit: „Im dłuższa lista Skills, tym bardziej wyglądam na ogarniacza”. Rzeczywistość: lista złożona z 40–50 pozycji obniża wiarygodność. Lepiej trzymać się aktualnego stacku i świadomie pokazać starsze technologie tylko wtedy, gdy rzeczywiście mają znaczenie (np. dla legacy systemów).

• Usuń technologie, których nie dotykałeś od lat i nie chcesz do nich wracać (chyba że ogłoszenie dokładnie ich dotyczy).
• Nie powtarzaj tej samej technologii w trzech różnych kategoriach (np. Docker w „DevOps”, „Tools” i „Other”).
• Ogranicz egzotyczne skróty, które pojawiły się w jednym kursie online – ATS i tak ich raczej nie ma na liście wymagań.

Doświadczenie zawodowe w IT: opisy, które zawierają słowa kluczowe, ale nie brzmią sztucznie

Struktura opisu stanowiska przyjazna ATS

Każde stanowisko powinno zawierać kilka podstawowych elementów. To ułatwia życie systemowi i osobie po drugiej stronie:

• Nazwa firmy + ewentualnie krótko, czym się zajmuje (np. „fintech, bankowość elektroniczna”).
• Stanowisko – najlepiej w formie zgodnej z rynkiem: „Backend Java Developer”, „QA Automation Engineer”.
• Okres zatrudnienia – miesiąc/rok – miesiąc/rok lub „obecnie”.
• Krótki opis projektu/domeny – 1–2 zdania.
• Lista obowiązków i osiągnięć – w punktach.
• Stack technologiczny – osobna linijka, np. „Stack: Java, Spring Boot, PostgreSQL, Docker, Kubernetes, AWS”.

Jak łączyć obowiązki, osiągnięcia i słowa kluczowe

Sucha lista zadań w stylu „implementacja nowych funkcjonalności, utrzymanie aplikacji” ani nie pomaga ATS-owi, ani nie przekonuje rekrutera technicznego. Z drugiej strony, nadmuchane opisy pełne ogólników typu „odpowiedzialny za rozwój innowacyjnych rozwiązań” brzmią jak generator marketingowy.

Praktyczny schemat jednego bullet pointu:

• czasownik (co robiłeś) + konkretny obszar (funkcja, moduł, proces) + technologie + efekt (jeśli da się go nazwać).

Przykłady:

• „Projektowałem i implementowałem mikroserwisy dla modułu płatności online (Java, Spring Boot, PostgreSQL), co skróciło czas autoryzacji transakcji i ułatwiło skalowanie systemu.”
• „Automatyzowałem testy regresji krytycznych ścieżek zakupowych (Cypress, TypeScript), redukując liczbę błędów wykrywanych dopiero na produkcji.”

Mit: „ATS potrzebuje tylko suchych słów kluczowych, więc nie ma sensu bawić się w efekty”. Rzeczywistość: system wychwyci nazwy technologii niezależnie od tego, czy są podane w zdaniu, czy w gołej liście. A rekruter techniczny znacznie chętniej zaprosi osobę, która potrafi połączyć technologię z rezultatem.

Gdzie umieścić słowa kluczowe z ogłoszenia w opisach doświadczenia

Najczęściej kopiowane błędne podejście to dorzucenie pod koniec CV sekcji „Keywords” i wrzucenie tam wszystkiego, co było w ogłoszeniu. ATS w części firm faktycznie to odczyta, ale rekruter szybko zauważy brak pokrycia z rzeczywistym doświadczeniem.

Bardziej sensowny schemat:

• przy każdym stanowisku dodaj linijkę „Stack:” z technologiami obecnymi w projekcie,
• w punktach z obowiązkami wpleć kluczowe narzędzia i praktyki („CI/CD”, „TDD”, „event-driven architecture”),
• przy projektach dopasowanych do ogłoszenia podciągnij na górę te bullet pointy, które pokrywają wymagania.

Jeżeli ogłoszenie mocno podkreśla np. „REST API, integracje z zewnętrznymi systemami, chmurę AWS”, upewnij się, że te frazy pojawiają się w opisach konkretnych zadań, a nie tylko w sekcji Skills. To tam rekruter szuka dowodów na to, że faktycznie pracowałeś z tymi rzeczami.

Jak opisywać projekty, gdy stanowisko miało „dziwną” nazwę

Firmy bywają kreatywne: „Software Ninja”, „IT Rockstar”, „Data Wizard” – ATS i rynek pracy tego nie rozumieją. Nie musisz jednak fałszować historii zatrudnienia, wystarczy mała korekta formy.

Bezpieczna technika:

• w linii stanowiska połącz rynkową nazwę z wewnętrzną, np. „Backend Java Developer (oficjalnie: Software Ninja)”,
• albo zastosuj zapis: „Backend Java Developer / Software Ninja”, jeżeli firma kładzie nacisk na brand.

Opis obowiązków i tak zrobi swoje – jeżeli w bullet pointach jasno wyjdzie, że zajmowałeś się backendem w Javie, ATS przypisze Cię do odpowiedniej puli, a rekruter nie będzie zgadywał, co kryje się pod żartobliwą etykietą.

Jak pokazać awanse i zmiany ról w tej samej firmie

W IT częste są sytuacje, w których ktoś zaczyna jako Junior, a kończy jako Senior lub Tech Lead w tym samym miejscu. Spójrz na to oczami ATS i rekrutera: jedna długa linijka z datą „2018–obecnie” i trzema różnymi tytułami robi chaos.

Przejrzystszy układ:

• jedna nazwa firmy, pod nią kilka pozycji z osobnymi datami i tytułami,
• każda rola z 2–4 punktami pokazującymi zmianę odpowiedzialności (np. mentoring, code review, kontakt z biznesem),
• dla wszystkich ról wspólny opis projektu/domeny, żeby nie powtarzać tego samego tekstu.

Przykładowy zarys:

<strong>ABC Software</strong> – platforma e-commerce B2C o dużym ruchu (Europa)
<em>Senior Backend Java Developer</em> – 2022–obecnie
- ...
<em>Mid Backend Java Developer</em> – 2020–2022
- ...
<em>Junior Java Developer</em> – 2019–2020
- ...

ATS widzi trzy odrębne stanowiska z datami, co pomaga przy filtrowaniu po „min. 2 lata jako Senior”, a rekruter szybko dostrzega ścieżkę awansu, zamiast zgadywać, kiedy nastąpiła zmiana poziomu.

„Brzydkie” przerwy w zatrudnieniu a ATS

Mit: „Każda przerwa w CV to automatyczne odrzucenie przez ATS”. Rzeczywistość: większość systemów zlicza łączną liczbę lat doświadczenia z podanych okresów, nie „karze” za luki. Problem zaczyna się dopiero wtedy, gdy brakuje dat lub są one niespójne.

Kilka praktycznych zasad:

• podawaj miesiąc i rok, nie same lata („2021–2023” może oznaczać od stycznia do grudnia albo od grudnia do stycznia),
• przy dłuższej przerwie możesz dodać krótki opis typu „przerwa na opiekę nad dzieckiem”, „bootcamp data science”, „freelance – mniejsze zlecenia”,
• nie próbuj „naciągać” dat, łącząc dwa różne etaty w jedno – niespójności wyjdą przy background checku.

Systemom zależy na strukturze i klarowności. Rekruterom – na spójności historii. Lepiej jasno pokazać, co się działo, niż sztucznie zasłaniać przerwę w zatrudnieniu.

Opis doświadczenia przy projektach krótkoterminowych i kontraktach B2B

Consulting, body leasing, kontrakty B2B – typowe realia IT. Z punktu widzenia ATS problem zaczyna się wtedy, gdy masz 10 firm w 3 latach, każda z jednym zdaniem opisu. To wygląda na „job hoppera”, nawet jeżeli w praktyce przez cały czas pracowałeś przy jednym produkcie klienta końcowego.

Rozwiązanie to połączenie porządku i zdrowego rozsądku:

• możesz podać firmę-matkę (software house / vendor) jako głównego pracodawcę, a projekty u klientów opisać jako podpozycje,
• dla krótkich kontraktów (np. 2–3 miesiące) wystarczą 1–2 precyzyjne punkty – lepiej mniej, ale konkretnie, niż pięć ogólników,
• dla powtarzalnych zleceń (np. kilka sklepów internetowych na tym samym stacku) można zastosować zbiorczy opis z zaznaczeniem zakresu odpowiedzialności.

Przykład:

<strong>XYZ Software House</strong> – projekty dla klientów z branży e-commerce i fintech
<em>Backend Java Developer (B2B)</em> – 2020–obecnie
Wybrane projekty:
- Platforma marketplace dla retail – projektowanie i implementacja mikroserwisów (Java, Spring Boot, Kafka, PostgreSQL).
- System płatności odroczonych BNPL – integracje z systemami bankowymi, optymalizacja wydajności REST API.

Jak pokazać doświadczenie „okołotechniczne” (mentoring, leadership, współpraca z biznesem)

ATS-owi jest w zasadzie wszystko jedno, czy prowadziłeś code review, czy nie. Za to rekruter techniczny i hiring manager patrzą na te elementy przy rolach mid/senior, a już na pewno przy leadach.

Zamiast osobnej sekcji typu „Soft skills”, która brzmi jak katalog życzeń („komunikatywność, praca w zespole”), umieść konkretne przejawy tych umiejętności w opisach stanowisk:

• „Prowadziłem regularne code review dla zespołu 4 developerów, dbając o zgodność ze standardami i jakość kodu.”
• „Współpracowałem z Product Ownerem przy doprecyzowaniu wymagań i planowaniu sprintów (Scrum).”
• „Mentorowałem 2 junior developerów, wspierając ich w planowaniu zadań i rozwoju technicznym.”

Tego typu zdania są neutralne dla ATS (technologie i tak się w nich pojawiają), a jednocześnie dużo mówią o Twojej roli w zespole ponad czyste „klepanie ticketów”.

Projekty poboczne, open source i hackathony – jak je dołożyć, żeby nie zaszkodzić

Mit: „Projekty poboczne to tylko dla juniorów”. Rzeczywistość: kontrybucje open source potrafią zrobić świetne wrażenie także przy osobach senior, ale pod jednym warunkiem – są opisane konkretnie, a nie jako „udział w wielu projektach open source”.

Dla ATS-u dobrze, by sekcja z projektami pobocznymi była strukturalnie podobna do doświadczenia zawodowego:

• nazwa projektu / repozytorium i rola (np. „Contributor”, „Maintainer”),
• krótki opis, czego dotyczy projekt,
• 2–3 punkty, co faktycznie zrobiłeś, z technologiami wplecionymi w treść.

Przykład:

<strong>Open source – projekt <a href="#">X</a></strong> – narzędzie do monitoringu mikroserwisów
Rola: Contributor
- Dodanie integracji z Prometheusem i aktualizacja dashboardów w Grafanie.
- Refaktoryzacja modułu autoryzacji (Java, Spring Security), poprawiająca czytelność i testowalność kodu.

Tak opisany projekt dostarcza dodatkowych słów kluczowych, nie rozmywa proporcji w CV i daje rekruterowi konkretny punkt zaczepienia do rozmowy technicznej.

Jak pisać o technologiach, których było mało w projekcie

Jeżeli dotknąłeś technologii tylko epizodycznie, np. przez dwa sprinty, zamiast udawać, że to pełnoprawny element stacku, nazwij rzecz po imieniu.

Kilka wariantów, które nie rozjeżdżają się z prawdą:

• „Epizodycznie wspierałem zespół DevOps przy konfiguracji pipeline’ów w GitLab CI.”
• „Miałem okazję współpracować przy wdrożeniu aplikacji w AWS (ECS, RDS) – utrzymanie i proste modyfikacje.”
• „Przeprowadziłem POC dla usługi X w Kubernetesie na potrzeby przyszłej migracji.”

Dla ATS-u ważne jest, że pojawia się nazwa narzędzia. Dla rekrutera – że rozumiesz różnicę między „robiłem to codziennie” a „miałem okazję się z tym zetknąć”. To znacznie buduje zaufanie i redukuje ryzyko niemiłych niespodzianek podczas rozmowy technicznej.

Najczęstsze błędy w opisach doświadczenia, które mylą ATS i ludzi

Przeglądając CV w IT, łatwo wychwycić powtarzalne pułapki:

• Brak stacku przy konkretnych rolach – technologie pojawiają się tylko w sekcji Skills. Skutek: ATS nie łączy ich z konkretnym okresem doświadczenia, a rekruter nie wie, co jest świeże, a co sprzed pięciu lat.
• Ogólniki zamiast konkretów – „rozwój aplikacji webowej”, „udział w projekcie migracji”. Bez informacji, co dokładnie robiłeś, trudno ocenić poziom samodzielności.
• Brak dopasowania nazewnictwa – stanowisko w CV: „Informatyk / Programista”, podczas gdy w ogłoszeniu jest „Backend .NET Developer”. ATS i rekruter często filtrują po tytułach; drobne doprecyzowanie potrafi zdziałać więcej niż dodatkowy kurs online.
• Przesadnie marketingowy język – „kreowanie innowacyjnych rozwiązań”, „aktywny udział w budowaniu sukcesu firmy”. Brzmi efektownie, ale nie niesie informacji. Lepiej jedno proste zdanie z technologiami i efektem niż trzy kwieciste bez treści.

Im mniej zgadywania po drugiej stronie, tym większe szanse, że CV przejdzie przez automaty i ręczną selekcję do etapu rozmowy technicznej.

Najczęściej zadawane pytania (FAQ)

Co to jest ATS w rekrutacji IT i czy naprawdę „odrzuca” większość CV?

ATS (Applicant Tracking System) to system do zarządzania aplikacjami kandydatów. W IT pomaga rekruterom filtrować CV po technologiach, lokalizacji, poziomie doświadczenia i przekazywać je dalej do liderów technicznych. Działa jak wyszukiwarka i baza danych, a nie jak bezduszny „robot-zabójca” kandydatów.

Mit brzmi: „ATS automatycznie wyrzuca 80–90% CV”. W praktyce w wielu firmach IT ATS służy głównie do porządkowania zgłoszeń, a nie do twardej selekcji. Najwięcej CV odpada dlatego, że nie ma w nich wymaganych technologii, doświadczenia albo są tak źle napisane i sformatowane, że rekruter po kilku sekundach dalej nie wie, kim jest kandydat.

Jak napisać CV do IT, które przejdzie przez ATS?

CV pod ATS musi być proste w formacie i konkretne w treści. Technicznie – stosuj standardowe sekcje (Experience, Skills, Education, Projects), unikaj tabel, tekstu w grafikach i skomplikowanych układów z wieloma kolumnami. Plik najlepiej wysłać jako PDF lub DOCX, zgodnie z tym, co sugeruje ogłoszenie.

Treściowo – zadbaj o słowa kluczowe zgodne z ogłoszeniem (technologie, frameworki, narzędzia, metodyki). Powinny pojawiać się nie tylko w sekcji „Skills”, ale też w opisach projektów i obowiązków. Przykład: zamiast „Odpowiedzialny za rozwój aplikacji”, napisz „Rozwój mikroserwisów w Javie (Spring, REST, Docker) w zespole pracującym w Scrum”. Dzięki temu ATS widzi frazy, a człowiek – realny kontekst.

Jakie słowa kluczowe dodać do CV pod ATS na stanowisko w IT?

Punktem wyjścia jest konkretne ogłoszenie. Rozbij je na kilka grup: technologie must-have (np. Java, React, Python), nice-to-have, narzędzia (Git, Docker, Jira), metodyki (Agile, Scrum, CI/CD) i domenę biznesową (np. e-commerce, fintech). Z tych fragmentów tworzysz własną „mapę słów kluczowych”, którą potem wplatasz w CV.

Mit jest taki, że wystarczy wrzucić ścianę technologii do sekcji „Skills” i ATS „złapie”. Rzeczywistość: dobre systemy i doświadczeni rekruterzy patrzą też na opisy projektów. Jeśli piszesz, że znasz Kubernetesa, ale nigdzie nie ma wzmianki o jego realnym użyciu, to budzi to podejrzenia. Lepiej mieć mniej technologii, ale z konkretnymi przykładami ich zastosowania.

Czy w CV do IT pod ATS lepszy jest format PDF czy DOCX?

Większość nowoczesnych ATS dobrze radzi sobie zarówno z PDF, jak i z DOCX, ale nie każdy system jest równie „sprytny”. Jeśli w ogłoszeniu podano preferowany format, trzymaj się go w pierwszej kolejności. Gdy nie ma wskazówki, bezpiecznym wyborem jest prosty PDF wygenerowany z edytora tekstu (bez niestandardowych fontów, ramek, grafik z tekstem).

Największy problem nie leży w samym formacie, tylko w układzie. PDF z jedną kolumną tekstu i klasycznymi nagłówkami będzie czytelny dla większości systemów. DOCX pełen tabel, pól tekstowych i ozdobników potrafi się „wysypać” nawet w najnowszym ATS. Im prostsza struktura, tym mniejsze ryzyko, że system poprzekłada treści.

Jak dopasować CV do konkretnego ogłoszenia IT bez „kłamania”?

Najpierw wyciągnij z ogłoszenia listę kluczowych wymagań (must-have) i otoczkę techniczną (nice-to-have, narzędzia, metodyki). Potem przejdź przez swoje doświadczenie i projekty i dopasuj nazewnictwo do tego, czym posługuje się pracodawca. Przykład: jeśli robiłeś „frontend w React”, a ogłoszenie mówi o „Single Page Applications w React”, możesz napisać: „Tworzenie SPA w React z użyciem TypeScript”. To to samo, tylko w ich języku.

Dopasowanie nie oznacza dopisywania technologii, których nie znasz. Podbijasz to, co faktycznie używałeś, i usuwasz szum. Jeśli występowałeś na styku z AWS-em tylko marginalnie, nie rób z siebie „AWS Experta”. Rekruter techniczny bardzo szybko zweryfikuje przesadzone CV na rozmowie – i to jest moment, w którym takie „podrasowanie” zwykle się mści.

Jakie sekcje powinno mieć CV programisty / testera pod ATS?

Przy rolach technicznych sprawdza się prosty, przewidywalny układ. Najczęściej wystarczą: nagłówek z danymi (imię, nazwisko, stanowisko docelowe, kontakt), krótkie podsumowanie zawodowe, sekcja umiejętności technicznych (podzielona na kategorie, np. języki, frameworki, narzędzia, bazy danych), doświadczenie zawodowe z opisem projektów oraz edukacja. Juniorzy i osoby po przebranżowieniu mogą dodać osobną sekcję „Projekty” lub „Projekty własne/open source”.

Kluczowe jest to, żeby ATS rozpoznał nagłówki sekcji i żeby opisy były konkretne technicznie. Z punktu widzenia systemu CV bez sekcji „Skills” i „Experience” jest po prostu trudniejsze do przeszukania. Z punktu widzenia lidera technicznego – opis „Pracowałem przy projekcie bankowym” mówi niewiele; „Projekt bankowy: mikroserwisy w Javie, REST API, Spring, PostgreSQL, Docker, CI/CD w Jenkinsie” od razu ustawia Cię w konkretnym miejscu.

Czy graficzne CV (kreator online, kolorowe szablony) nadaje się do ATS w IT?

Większość efektownych, mocno graficznych szablonów z kreatorów jest tworzona z myślą o designie, nie o ATS. Dwie kolumny z tekstem w formie obrazków, ikony zamiast nazw technologii, „paski poziomu umiejętności” – to ładnie wygląda, ale system często nie potrafi poprawnie odczytać takiego CV. Efekt jest taki, że część treści znika albo ląduje w złych miejscach.

Mit: „Im bardziej kreatywne CV, tym większa szansa, że się wyróżnię”. Rzeczywistość przy rekrutacjach IT jest inna: dużo ważniejsze jest to, żeby dało się Cię łatwo znaleźć po technologiach i zrozumieć Twój profil w kilkanaście sekund. Jeśli chcesz mieć „ładną” wersję CV, miej ją osobno – a pod ATS przygotuj prostą, tekstową wersję, która bez problemu przejdzie przez system.

Co warto zapamiętać

• CV do IT musi jednocześnie „przejść” przez ATS i przekonać człowieka: prosta, tekstowa forma dla systemu + konkretne, techniczne opisy projektów dla rekrutera i lidera.
• ATS nie jest robotem do eliminacji kandydatów, tylko filtrem porządkującym chaos – najczęściej odrzuca CV pośrednio, gdy brakuje w nim oczywistych słów kluczowych lub ma ono nieczytelny format.
• Format CV pod ATS powinien być maksymalnie prosty: standardowe nagłówki (Experience, Skills, Education), brak kluczowych treści w grafikach, rozsądne użycie kolumn i zero „udziwnień” utrudniających odczyt.
• Sam „worek” technologii w sekcji Skills nie wystarczy – rekruter techniczny szuka potwierdzenia umiejętności w opisach projektów, odpowiedzialnościach i użytym stacku, inaczej uzna CV za „napompowane”.
• Ogłoszenie o pracę to gotowa mapa słów kluczowych: trzeba z niego wyłuskać wymagania must-have, nice-to-have, tech stack, obowiązki i przełożyć je na język własnych doświadczeń zamiast kopiować fragmenty 1:1.
• Mit, że „ATS kasuje 90% CV automatycznie”, rozmija się z praktyką – w wielu rekrutacjach IT większość aplikacji i tak widzi człowiek, ale szybko odrzuca te, z których po 10 sekundach nie da się zrozumieć profilu kandydata.
• Tworzenie swojej „mapy słów kluczowych” (z jednego lub wielu ogłoszeń) pozwala świadomie nasycić CV właściwymi technologiami, narzędziami i domenami biznesowymi, bez przypadkowego pomijania istotnych fraz.