CV w IT ma jedną cechę, która odróżnia je od dokumentów w innych branżach: czyta je zwykle dwie osoby o zupełnie różnych oczekiwaniach. Najpierw rekruter, który sprawdza, czy w ogóle pasujesz do wymagań. Potem osoba techniczna, czyli lider zespołu albo programista, która patrzy, co konkretnie robiłeś i czy da się z tego wyczytać poziom.
Dokument napisany wyłącznie pod jedną z nich zwykle przegrywa. Zbyt techniczny odpada na pierwszym filtrze, zbyt ogólny odpada na drugim.
Co sprawdza rekruter, a co osoba techniczna
| Rekruter | Osoba techniczna |
|---|---|
| zgodność technologii z ogłoszeniem | skala i złożoność tego, co budowałeś |
| lata doświadczenia w danym stacku | rola w projekcie, czyli co było Twoje |
| dyspozycyjność, tryb pracy, lokalizacja | decyzje techniczne i ich powody |
| poziom stanowiska | czy opis brzmi wiarygodnie |
Stąd prosty wniosek: technologie muszą być łatwe do znalezienia, a opisy projektów mają nieść konkret. Jedno bez drugiego nie wystarcza.
Sekcja technologii: najważniejsza część dokumentu
To pierwsze miejsce, do którego trafia wzrok i filtr. Warto ją uporządkować, zamiast wrzucać wszystko do jednego worka.
Frameworki: Spring Boot, Hibernate
Bazy danych: PostgreSQL, Redis
Infrastruktura: Docker, Kubernetes, AWS (EC2, S3, RDS)
Narzędzia: Git, Jenkins, Grafana
Podział na kategorie robi dwie rzeczy naraz. Rekruterowi pozwala szybko sprawdzić zgodność z ogłoszeniem, a osobie technicznej pokazuje, że rozumiesz, czym różni się język od frameworka. Lista trzydziestu haseł wrzuconych obok siebie sugeruje coś odwrotnego.
Nie zaniżaj i nie zawyżaj przez podawanie wszystkiego
Technologia, której dotknąłeś raz na szkoleniu, nie powinna stać obok tej, w której pracujesz od lat. Jeśli chcesz ją zachować, zrób osobną grupę „Podstawowa znajomość". Osoba techniczna i tak zapyta o dowolną pozycję z listy, więc wszystko, co tam jest, musisz umieć obronić.
Pisz pełne nazwy obok skrótów
Filtry działają na dosłownym dopasowaniu. „K8s" i „Kubernetes" to dla systemu dwa różne słowa, podobnie „JS" i „JavaScript". Przy pierwszym wystąpieniu warto podać obie formy, dalej wystarczy jedna.
Opis projektów: kontekst, rola, efekt
Najczęstszy błąd to lista obowiązków bez śladu tego, co z nich wynikło. „Rozwój aplikacji webowej w Javie" pasuje do dziesięciu tysięcy osób. Trzy elementy zmieniają ten opis w informację.
- Kontekst: co to za system, dla kogo, jaka skala. Na przykład „platforma B2B dla firm logistycznych, około 4 tysięcy użytkowników dziennie".
- Twoja rola: co było Twoje, a co zespołu. „Odpowiadałem za moduł rozliczeń i integrację z systemem płatności" mówi więcej niż „praca w zespole nad rozwojem systemu".
- Efekt: co się zmieniło. Czas odpowiedzi, liczba błędów, czas wdrożenia, koszt. Bez wymyślania liczb, jeśli ich nie znasz.
Gdy nie masz twardych liczb, opisz decyzję techniczną i jej powód: „przeniesienie raportów na kolejkę asynchroniczną, bo generowanie blokowało główny wątek przy większych klientach". To pokazuje sposób myślenia, a właśnie tego szuka osoba techniczna.
Czego nie warto wstawiać
Pasków postępu przy technologiach
Wykres pokazujący „Java 80 procent" nie niesie treści, bo nikt nie wie, czym jest te osiemdziesiąt procent. Do tego elementy graficzne bywają nieczytelne przy odczycie maszynowym. Lepiej podać lata doświadczenia albo poziom słowem.
Zdjęcia i grafik zamiast treści
Szablony z kolumnami i ikonami wyglądają dobrze na ekranie, a rozsypują się przy parsowaniu. Jeśli zależy Ci na wyglądzie, trzymaj układ jednokolumnowy z czytelną hierarchią nagłówków.
Listy wszystkich kursów
Kilkanaście kursów z platform online zajmuje miejsce, którego brakuje potem na projekty. Zostaw te, które faktycznie coś wnoszą albo są wymagane w ogłoszeniu.
Projekty własne i open source
Przy osobach na starcie kariery to często najmocniejsza część dokumentu, bo jedyna, w której widać kod. Podaj link do repozytorium i dopisz dwa zdania o tym, co robi projekt i co było w nim trudne. Samo „projekt zaliczeniowy na studiach" nie zachęca do kliknięcia.
Jeśli linkujesz repozytorium, upewnij się, że da się je otworzyć bez logowania i że w środku jest opis. Puste README przy dziesięciu commitach działa gorzej niż brak linku.
Sprawdź, jak Twoje CV wypada przy ofercie
Wgraj dokument i zobacz, które wymagania spełniasz, a czego brakuje. Wynik dostajesz w około 30 sekund.
Sprawdź za darmo →Ile stron i w jakiej kolejności
Przy stażu do pięciu lat jedna strona wystarcza. Przy dłuższym dwie są w porządku, pod warunkiem że druga nie jest wyliczanką technologii sprzed dekady. Starsze projekty można skrócić do jednej linii.
Kolejność sekcji przy doświadczonej osobie: technologie, doświadczenie, wykształcenie. Przy osobie na starcie odwrotnie, bo wtedy studia i projekty własne niosą więcej niż krótka lista narzędzi.
Dopasowanie do konkretnej oferty
Jedno CV wysyłane wszędzie działa słabo, ale przepisywanie go za każdym razem od zera nie ma sensu. Wystarczy zmieniać dwie rzeczy: kolejność technologii, tak żeby te z ogłoszenia były widoczne od razu, oraz kolejność projektów, żeby najbardziej zbliżony do oferty stał najwyżej.
To zajmuje kilka minut, a przesuwa dokument z grupy „może pasuje" do „warto porozmawiać".
FAQ: pytania, które wracają najczęściej
Czy w CV podawać lata doświadczenia przy każdej technologii?
Czy pisać CV po polsku czy po angielsku?
Co wpisać, gdy nie mam komercyjnego doświadczenia?
Czy dodawać link do GitHuba i LinkedIn?
Czy rekrutacja w IT też używa systemów filtrujących?
Podsumowanie
CV w IT musi zadowolić dwóch czytelników naraz. Rekruterowi daj czytelną, pogrupowaną listę technologii z latami doświadczenia. Osobie technicznej daj projekty opisane przez kontekst, Twoją rolę i efekt. Odpuść paski postępu, wielokolumnowe szablony i listę wszystkich kursów. Przed wysyłką przestaw kolejność tak, żeby to, czego szuka oferta, było widoczne w pierwszych sekundach.