Sekcja umiejętności w CV programisty: jak ułożyć skille pod ofertę

Sekcja umiejętności w większości CV programistów wygląda tak samo: alfabetyczna ściana wszystkich technologii, których kandydat kiedykolwiek dotknął. Od Angulara, przez Docker i Git, po Webpack i YAML. Wygląda imponująco przez sekundę, a potem nic nie mówi.

Bo rekruter, który czyta tę sekcję pod konkretną ofertę, nie szuka kompletności. Szuka zgodności z ogłoszeniem. Skanuje, czy widzi technologie z oferty i czy są na wierzchu, czy zakopane między dwudziestoma innymi. Lista trzydziestu pozycji nie ułatwia mu tego zadania, tylko utrudnia.

Dobra sekcja umiejętności to nie zrzut wszystkiego, co umiesz. To ułożony pod ofertę zestaw, w którym najważniejsze rzeczy są pierwsze i widoczne. Poniżej, jak go ułożyć.

Kolejność wg istotności, nie alfabetycznie

Alfabetyczna lista traktuje wszystkie umiejętności jak równe. Nie są równe. Pod ofertę backendową Node.js znaczy więcej niż znajomość Excela, a kolejność na liście ma to oddawać.

Ułóż skille w kolejności istotności dla tej konkretnej oferty. Na górze technologie, które ogłoszenie wymienia jako must-have i które masz. Niżej to, co wspiera, a nie jest rdzeniem. Na końcu reszta, mniejszą wagą. Rekruter ma w pierwszych pozycjach zobaczyć dokładnie to, czego szuka, bez przewijania i bez polowania.

To oznacza, że pod różne oferty kolejność będzie inna. Ta sama baza umiejętności, inny pierwszy plan. Jak czytać ofertę, żeby wiedzieć, co wynieść na górę, rozkładamy w jak wyciągnąć słowa kluczowe z oferty IT.

Rdzeń, wsparcie i reszta

Pomocnie jest myśleć o umiejętnościach w trzech warstwach, zamiast jednym płaskim ciągiem.

• Rdzeń: technologie, na których opiera się rola z oferty. Język, główny framework, baza danych. To, w czym musisz być naprawdę dobry.
• Wsparcie: narzędzia, które realnie używasz wokół rdzenia. Testy, CI/CD, konteneryzacja, narzędzia buildowe. Ważne, ale nie bohaterowie.
• Reszta: wszystko, co znasz, ale co nie decyduje o tej roli. Niżej, mniejszą wagą, a często w ogóle do wycięcia.

Granica między rdzeniem a wsparciem przesuwa się z ofertą. Pod ofertę DevOps Docker i Kubernetes są rdzeniem. Pod ofertę frontendową to co najwyżej wsparcie. Ta sama technologia, inna waga.

Hard kontra soft skills: co naprawdę liczy w sekcji skills

„Komunikatywność", „praca w zespole", „nastawienie na cel". Soft skille wpisane jako gołe hasła w sekcji umiejętności nie przekonują nikogo, bo każdy je wpisuje i nikt ich tam nie weryfikuje.

W sekcji umiejętności technicznych liczą się hard skille: konkretne technologie, narzędzia, języki. To one są pierwszym filtrem zgodności z ofertą. Soft skille mają wartość, ale nie jako lista przymiotników. Pokazujesz je tam, gdzie są wiarygodne: w opisie projektu, w którym prowadziłeś temat, mentorowałeś juniora albo dogadywałeś wymagania z biznesem. „Współpracowałem z product ownerem nad zakresem" mówi więcej niż „komunikatywność" w punktorze.

Trzymaj sekcję techniczną dla technologii. Soft skille niech wynikają z opisu doświadczenia, a nie z deklaracji.

Poziomy zaawansowania: podawać czy nie

Kuszące jest dorzucenie do każdej technologii paska postępu albo etykiety „expert", „advanced", „basic". Problem w tym, że taka samoocena jest subiektywna i prawie nikt jej nie czyta jako twardej informacji. Twój „zaawansowany React" i cudzy „zaawansowany React" to dwa różne poziomy.

Zamiast paska podaj coś sprawdzalnego: ile lat komercyjnie używasz danej technologii. „TypeScript, 3 lata komercyjnie" niesie więcej niż pasek na cztery piąte. A najmocniejszy dowód poziomu i tak jest w opisie projektu, nie przy nazwie skilla.

Jeśli upierasz się przy poziomach, ogranicz je do prostego podziału na rdzeń (to, w czym pracujesz na co dzień) i znajomość (czego dotknąłeś). Bez dziesięciostopniowych skal, które tylko zaśmiecają.

Umiejętność jako dowód w projekcie, nie sama nazwa na liście

Tu jest sedno całej sekcji. Nazwa technologii na liście to deklaracja. Ta sama technologia w opisie projektu, z kontekstem i efektem, to dowód. Rekruter ufa dowodowi, nie deklaracji.

Lista mówi „znam PostgreSQL". Projekt mówi, gdzie i po co go użyłeś, i co z tego wyszło. Pierwsze można wpisać bez pokrycia. Drugiego nie zmyślisz wiarygodnie.

Sama lista: PostgreSQL, Redis, Node.js, Docker, Kafka, RabbitMQ, MongoDB, Elasticsearch, GraphQL, gRPC... (i jeszcze dwadzieścia pozycji). >Rdzeń plus dowód: Node.js i PostgreSQL na górze sekcji, a w projekcie: „Zoptymalizował zapytania i dołożył indeksy w PostgreSQL, skracając czas najcięższego raportu z 9 s do 1,2 s przy tym samym wolumenie danych."

Drugi wariant wymienia mniej technologii, a robi większe wrażenie, bo jedną z nich pokazuje w akcji. To jest różnica między „mam to na liście" a „umiem tego użyć". Pokaż rdzeń w sekcji skills i udowodnij go w dwóch, trzech opisach projektów.

Częste błędy

• Ściana technologii. Lista trzydziestu pozycji nie pokazuje, w czym jesteś dobry, tylko rozmywa rdzeń. Rekruter nie wie, na czym ci naprawdę zależy.
• Kolejność alfabetyczna. Sortowanie od A do Z traktuje wszystkie skille jak równe i chowa to, czego szuka oferta, między rzeczami nieistotnymi.
• Skille bez dowodu. Technologia na liście, której nie widać w żadnym projekcie, wygląda jak wpisana na zapas. Jeśli to ważny skill, ma mieć pokrycie w doświadczeniu.

Jak ułożyć umiejętności w ZłóżCV

Pod konkretną ofertę ZłóżCV czyta wymagania z ogłoszenia, układa twój stack w kolejności istotności (rdzeń na górze, wsparcie niżej) i przepisuje opisy projektów tak, żeby kluczowe technologie były w nich pokazane dowodem, nie samą nazwą. Wklejasz link do oferty, dostajesz dopasowane CV w PDF. Złóż CV dopasowane do oferty, dwa pierwsze za darmo, bez karty. Cały proces dopasowania masz w jak dopasować CV do oferty.

Najczęstsze pytania

Ile technologii wpisać w sekcji umiejętności? Tyle, ile realnie wspiera daną ofertę, z rdzeniem na górze. Lepiej osiem trafionych i poukładanych niż trzydzieści wrzuconych alfabetycznie. Reszta, której oferta nie dotyczy, tylko rozmywa obraz.

Czy podawać poziom zaawansowania przy każdej technologii? Paski i etykiety w stylu „expert" są subiektywne i mało kto je czyta. Lepiej podaj lata komercyjnego użycia albo po prostu rozdziel rdzeń od znajomości. Najmocniejszy dowód poziomu jest i tak w opisie projektu.

Gdzie wpisać soft skille? Nie jako gołe hasła w sekcji umiejętności technicznych. Pokaż je w opisie doświadczenia: prowadzenie tematu, mentoring, współpraca z biznesem. Soft skill z kontekstem jest wiarygodny, soft skill z punktora nie.

Czy układać skille inaczej pod każdą ofertę? Tak. Ta sama baza umiejętności, inna kolejność i inny rdzeń zależnie od tego, co wymienia ogłoszenie. Pod jedną ofertę rdzeniem jest Docker, pod inną to tylko wsparcie. Jak rozłożyć ten sam materiał pod różne role, pokazujemy w jeden projekt, cztery role.