Rekruter otwiera trzydzieste CV tego ranka, skanuje stack i dwa projekty, po czym zamyka plik, zanim zdąży dojść do sekcji o kursach. Kandydat ma za sobą miesiące nauki, a odrzucenie przychodzi bez feedbacku i bez rozmowy technicznej. [2]
Znikające aplikacje w procesach rekrutacyjnych: dlaczego dobre portfolio przegrywa w kilkanaście sekund
Chwila uwagi zamiast lektury całego dokumentu
Na popularne ogłoszenie juniorskie i midowe spływa często kilkaset zgłoszeń. Osoba z HR albo sourcer nie czyta CV jak specyfikacji. Szuka w pierwszej kolejności zgodności roli, języka, frameworka i dowodu, że kandydat już coś dowieźć potrafi. Sekcja projektów i stacku jest w tym momencie całym argumentem. Jeśli jest nieczytelna, reszta dokumentu nie dostaje szansy.
Kandydat mierzy wysiłek: godziny kursu, liczbę commitów, listę technologii, które „liznął”. Rekruter mierzy ryzyko zatrudnienia. Szuka sygnału, że osoba umie nazwać problem, wybrać narzędzie i obronić decyzję. Wysiłek bez tego sygnału wygląda jak aktywność, nie jak kompetencja.
Schematyczne CV — długi pasek ikon, trzy klony znanych aplikacji, stack skopiowany z roadmapy — wpada do tej samej szuflady. Odrzucenie bywa automatyczne, zanim dokument trafi do Tech Leada. Nie dlatego, że ktoś „nie lubi juniorów”, tylko dlatego, że profil nie daje podstawy do telefonu screeningowego.
Co rekruter techniczny i non-tech sprawdzają w innej kolejności
Rekruter bez backgroundu programistycznego dopasowuje słowa z ogłoszenia: język, framework, baza, chmura, testy. Tech Lead, jeśli w ogóle dostaje CV, sprawdza, czy te słowa mają pokrycie w projekcie: architektura, zakres, trudniejsze decyzje, jakość opisu. Jeden profil musi wytrzymać obie lektury. Encyklopedia narzędzi zadowala parser słów kluczowych na sekundę, a potem psuje zaufanie osoby technicznej. [4]
Mini-wniosek: CV programisty przegrywa nie przez brak wiedzy, tylko przez brak dowodu w miejscu, w którym dowód jest szukany — w stacku i w projektach.
Architektura sekcji stacku technologicznego – błędy, które dezorientują rekrutera
1. Syndrom encyklopedii: upychanie każdej dotkniętej technologii w jednym ciągu
Lista czterdziestu pozycji u osoby z kilkoma miesiącami nauki albo z jednym komercyjnym projektem budzi sceptycyzm, nie podziw. HTML, CSS, JavaScript, TypeScript, React, Vue, Angular, Next, Nest, Express, Django, Flask, Spring, .NET, Docker, Kubernetes, AWS, Azure, GCP, Terraform, Kafka, Redis, Mongo, Postgres, MySQL, GraphQL, gRPC — taki ciąg mówi: „dotknąłem wielu rzeczy”, nie: „umiem dowieźć produkt w konkretnym zestawie”.
Programista oceniający profil zakłada, że głębokość jest odwrotnie proporcjonalna do szerokości, dopóki CV nie pokaże inaczej. Junior z encyklopedią wygląda na kogoś, kto nie odróżnia znajomości składni z tutoriala od pracy z kodem produkcyjnym: obsługi błędów, migracji, testów, code review, ograniczeń wydajności. Mid, który wymienia wszystko od asemblera po narzędzia designerskie, wygląda na osobę bez specjalizacji.
Selekcja jest prosta i brutalna. Zostaw technologie, w których potrafisz napisać komercyjny albo porządny projektowy kod i obronić decyzje: dlaczego ta biblioteka, jak wygląda struktura modułów, co byś zmienił przy drugim podejściu. Resztę przenieś do „znałem w projekcie uczelnianym” albo usuń. Jedno zdanie przy stacku wiodącym („React i TypeScript w dwóch aplikacjach z testami i CI”) waży więcej niż dwadzieścia ikon.
Wyjątek dotyczy ról wyraźnie szerokich, na przykład platform engineering albo full-stack w małym zespole, gdzie ogłoszenie samo wymienia wiele warstw. Nawet wtedy encyklopedia bez hierarchii szkodzi. Szerokość ma sens dopiero wtedy, gdy widać, co jest rdzeniem, a co narzędziem okazjonalnym.
2. Brak hierarchii i rozróżnienia na technologie wiodące oraz poboczne
Git, Jira, Slack, Figma i Postman postawione na równi z Javą i Springiem zmuszają rekrutera do zgadywania. Narzędzia współpracy są oczekiwane prawie wszędzie. Nie wyróżniają kandydata i zabierają miejsce technologiom, po których ATS oraz człowiek filtrują zgłoszenia. Chaos jest szczególnie drogi, gdy ogłoszenie szuka jednej pary: na przykład Python i Django albo C# i .NET.
Rekruter non-tech nie będzie rozszyfrowywał, czy „znajomość Dockera” oznacza napisany Dockerfile i compose, czy obejrzany film. Jeśli wszystko jest na jednym poziomie, zakłada najsłabszą interpretację albo pomija profil, bo dopasowanie do słów kluczowych ogłoszenia nie jest oczywiste w pierwszych linijkach.
Działa podział oparty na użyciu, nie na dumie:
- Primary — język i framework, w których napisałbyś zadanie rekrutacyjne bez ściągi i które widać w projektach.
- Secondary — baza, testy, CI, podstawy chmury używane regularnie, ale niebędące osią roli.
- Familiar — rzeczy poznane na tyle, by czytać cudzy kod i nie blokować zespołu, bez udawania produkcji.
Etykiety mogą być po polsku: wiodące, wspierające, orientacyjnie. Ważne, żeby kolejność i grupowanie mówiły to samo co treść projektów. Jeśli w Primary jest Kubernetes, w projektach musi być ślad: manifesty, helm, opis środowiska, nie sama nazwa.
3. Eksponowanie narzędzi przestarzałych lub nieadekwatnych do roli
Biblioteka bez wsparcia, framework z innej epoki albo nisza z zupełnie innego ogłoszenia na szczycie sekcji tworzy wrażenie, że profil nie był aktualizowany. jQuery jako pierwsza pozycja przy aplikowaniu na Reacta, WinForms nad .NET przy ofercie o mikroserwisach, PHP 5 w nagłówku przy współczesnym Laravelu — to sygnał, że kandydat nie czyta rynku, na który aplikuje. [1]
Stary stack nie jest wstydem, jeśli to była realna praca i potrafisz opowiedzieć o utrzymaniu, migracji albo ograniczeniach. Problemem jest kolejność i brak kontekstu. Technologia sprzed lat na górze mówi „to mój aktualny poziom”. Ta sama technologia w opisie projektu z datą i zdaniem o tym, co zostało zastąpione, mówi „znam dług techniczny”.
Nieadekwatność bywa subtelniejsza niż „przestarzałe”. Data scientist z TensorFlow na szczycie, aplikujący na backend Java, wygląda na osobę, która wysyła jedno CV wszędzie. Osoba od embeddowanego C z listą zaczynającą się od React Native myli role. Dopasuj górę stacku do ogłoszenia. Resztę zostaw niżej albo w osobnej wersji CV, jeśli naprawdę celujesz w dwie ścieżki — nie w jednej ścianie tekstu.
| Sygnał w stacku | Jak czyta to selekcja | Co zamiast tego |
|---|---|---|
| 30+ technologii bez grup | Brak specjalizacji, ryzyko ściemy | 6–12 pozycji w trzech warstwach |
| Git i Jira obok języka głównego | Szum, trudne dopasowanie do ogłoszenia | Narzędzia współpracy w jednej krótkiej linii na dole |
| Martwa biblioteka na górze | Profil nieaktualny | Kontekst daty albo przeniesienie niżej |
| Primary bez śladu w projektach | Niespójność, możliwa odrzucenie po 20 sekundach | Albo projekt, albo obniżenie poziomu deklaracji |
Sekcja projektów, która nie broni deklarowanego stacku
4. Projekty opisane jak lista tutoriali, bez problemu, decyzji i rezultatu
„Aplikacja ToDo w React”, „klon Netflixa”, „sklep z kursu” — rekruter widział to dziesiątki razy w tym samym tygodniu. Sam fakt ukończenia kursu nie jest błędem. Błędem jest opis, który nie odróżnia Twojej pracy od szablonu instruktora. Brakuje problemu użytkownika, ograniczenia, decyzji i tego, co poszło nie tak.
Porównaj dwa opisy tego samego zakresu. Słaby: „Sklep internetowy, React, Node, MongoDB, logowanie, koszyk”. Mocniejszy: „Sklep dla małego katalogu produktów; koszyk trzymany po stronie serwera, bo zależało mi na jednym źródle prawdy przy odświeżeniu; płatności zasymulowane, walidacja zamówienia w testach API; świadomie bez panelu admina, żeby domknąć ścieżkę zakupu”. Drugi tekst pokazuje myślenie. Pierwszy pokazuje stack z karty kursu.
Każdy projekt w CV programisty da się zmieścić w czterech liniach: kontekst, Twoja rola, 1–2 decyzje techniczne, efekt albo ograniczenie. Efekt nie musi być przychodem firmy. U projektu własnego wystarczy: czas ładowania listy, pokrycie testami krytycznej ścieżki, liczba encji, obsługa błędów sieci, migracja schematu. U projektu zespołowego: co było Twoje, a co wspólne. Przypisywanie sobie całego produktu, gdy robiłeś jeden widok, wychodzi na rozmowie i psuje wiarygodność wcześniej, jeśli opis jest zbyt szeroki. [3]
Trzy projekty różne rodzajowo bronią kandydata lepiej niż osiem podobnych CRUD-ów. Jeden z formularzem i walidacją, jeden z integracją zewnętrznego API i obsługą błędów, jeden z prostym modelem danych i zapytaniami — to już materiał na pytania techniczne. Osiem kopii tej samej struktury mówi, że nauka zatrzymała się na pierwszym schemacie.
Przy planowaniu kolejnych kroków pomocny może być tekst: Przebranżowienie na data analyst: plan nauki na 90 dni.
5. Stack w nagłówku rozjeżdża się ze stackiem użytym w projektach
Najczęstsza niespójność: na górze „Kubernetes, AWS, microservices, Kafka”, w projektach trzy repozytoria frontendowe bez infrastruktury. Albo odwrotnie — projekty w Pythonie, a aplikacja idzie na ogłoszenie Java, bo w stacku dopisano „Java — podstawy” bez ani jednej linijki kodu. Rekruter techniczny nie składa z tego komplementu. Składa zarzut.
Spójność jest kryterium, nie ozdobą. Każda technologia z warstwy Primary powinna pojawić się w co najmniej jednym projekcie albo w doświadczeniu komercyjnym z konkretem: moduł, odpowiedzialność, okres. Secondary może być węższe: „Postgres w projekcie X, indeksy pod wyszukiwanie, bez replikacji”. Familiar nie wymaga osobnego repozytorium, ale nie powinno otwierać sekcji.
Jeśli uczysz się nowego języka i jeszcze nie masz projektu, nie wstawiaj go do Primary „na zapas”, żeby przejść ATS. Osobna wersja CV pod inną rolę albo jedno zdanie w sekcji nauki („od dwóch miesięcy Java i Spring, pierwszy serwis w toku, repo prywatne do wglądu”) jest uczciwsze i rzadziej kończy się kompromitacją na live codingu. Selekcja CV przez rekruterów IT premiuje dopasowanie, ale rozmowa premiuje prawdę. Profil, który przejdzie tylko pierwszy filtr, i tak odpada drożej — Twoim czasem.
6. Puste repozytoria, martwe linki i kod, którego nie da się ocenić
Link do GitHuba bez README, z ostatnim commitem sprzed roku, z sekretami w historii albo z jednym plikiem „index.html” nie jest portfolio. Jest dowodem, że sekcja projektów została dopisana dla objęcia miejsca. Rekruter, który klika — a część klika, zwłaszcza przy juniorach — wyciąga wniosek w kilkadziesiąt sekund.
Minimum, które da się obronić: aktualny link, README z celem projektu, stackiem, sposobem uruchomienia i zakresem, który jest Twój. Nie trzeba produkcyjnego deployu. Trzeba, żeby osoba techniczna zrozumiała, co uruchamia i czego nie obiecywałeś. Gałąź z niedokończonym eksperymentem oznacz jako eksperyment. Domyślna gałąź niech pokazuje wersję, którą chcesz pokazać.
Osobny problem to repozytoria-śmietniki: dwadzieścia forków, kursowe commity o treści „lesson 12”, brak własnych wiadomości commitów. To nie dyskwalifikuje człowieka, ale dyskwalifikuje link w CV, jeśli nie wskażesz 2–3 repozytoriów pinem albo wprost w dokumencie. Resztę zostaw w profilu. CV nie jest indeksem całego konta.
7. Projekty bez skali, dat i granicy Twojej pracy
Rekruter, który w kilkanaście sekund szuka dowodu seniority, nie odczyta z samego tytułu „system zamówień” ani „panel analityczny”, czy to był weekendowy szkic, czy pół roku w zespole pięciu osób. Brak dat, wielkości i zakresu odpowiedzialności spłaszcza juniora, mida i osobę po stażu do jednej, nieweryfikowalnej etykiety. Przy krótkim skanie wygrywa kandydat, u którego widać ciężar pracy, nie ten z dłuższą listą nazw.
Przyczyna jest prosta: opis powstaje z perspektywy autora, który pamięta kontekst. Selekcja go nie ma. „Duży projekt”, „złożona logika”, „odpowiedzialność za backend” bez liczb i bez zdania, co było Twoje, a co zespołu, brzmi jak ozdobnik. Na rozmowie i tak padnie pytanie o skalę. Jeśli w CV jej nie ma, część rekruterów nie dojdzie do tego pytania.
Wystarczą trzy konkrety przy każdym wpisie, także przy pracy komercyjnej objętej NDA:
- okres i forma: „03–08.2024, zespół 4 osób, ja: jeden serwis i kolejka zadań”;
- skala, którą wolno podać: liczba użytkowników wewnętrznych, encji, endpointów, środowisk, częstotliwość wdrożeń — nie przychód firmy, jeśli go nie znasz;
- granica: „nie dotykałem płatności ani uprawnień admina” albo „przejąłem moduł raportów po odejściu kolegi, bez przepisywania całości”.
Czego unikać: „zbudowałem cały system” przy jednej karcie w Jirze, procentów bez mianownika („o 40% szybciej” — względem czego i na jakim zbiorze) oraz dat ukrytych tak, że nie wiadomo, czy technologia jest aktualna. Efekt może być skromny. „Skróciłem czas ręcznego eksportu z dwóch godzin do kilkunastu minut dla zespołu księgowości, ok. 12 osób” jest mocniejsze niż „zoptymalizowałem procesy”. Jeśli liczb nie masz, napisz ograniczenie wprost. Uczciwy brak skali jest lepszy niż skala wymyślona.
8. Opis, którego nie da się zeskanować: żargon, nazwy wewnętrzne i ściana akapitów
Drugi filtr odpada nie przez brak umiejętności, tylko przez tekst, który w pierwszym przebiegu nic nie mówi. „Clean architecture, scalable microservices, best practices, ownership, synergy ze stakeholderami” bez jednego rzeczownika domenowego nie odróżnia Cię od ogłoszenia, z którego te słowa zostały przepisane. Z drugiej strony skróty znane tylko w poprzedniej firmie — „moduł FENIX”, „flow KRK-2”, „ticket type QJ” — są dla osoby spoza zespołu puste. Rekruter nie zgaduje słownika pracodawcy, którego już nie ma na rynku.
To nie jest ten sam błąd co tutorialowy opis bez decyzji. Tu decyzja czasem jest, ale tonie. Trzy gęste akapity na projekt, mieszanka polskiego z wklejonymi frazami z JD i lista dwunastu bibliotek pod każdą pozycją sprawiają, że zgodność z rolą nie mieści się w pierwszym ekranie. ATS może zaliczyć słowa kluczowe. Człowiek, który ma porównać dwadzieścia CV przed standupem, zamyka dokument, bo nie widzi, co kandydat robił w praktyce.
Układ, który przechodzi skan: jedna linia tytułu z technologią wiodącą tej pracy, potem najwyżej cztery krótkie zdania albo wypunktowania — problem, Twoja decyzja, ograniczenie, rezultat albo skala z punktu 7. Nazwę wewnętrzną zastąp funkcją: nie „FENIX”, tylko „kolejka przeliczeń nocnych dla raportów magazynowych”. Żargon zostaw, jeśli niesie treść („outbox przy zapisie zamówienia, bo event gubił się przy restarcie brokera”), wyrzuć, jeśli da się go skreślić bez straty znaczenia.
Pułapka odwrotna: CV tak ogólnikowe, że pasuje do każdej oferty. Jedna wersja pod backend nie powinna otwierać się projektem od design systemu w Figmie tylko dlatego, że to brzmi nowocześnie. Dopasuj pierwsze dwa projekty do ogłoszenia, resztę skróć do jednej linii. Jeśli po wyrzuceniu przymiotników zostaje pusto, opis nie był dowodem — był wypełniaczem. Zostaw w dokumencie tylko to, co obronisz na pierwszym pytaniu technicznym bez zaglądania w notatki.
Co zostawić w CV, zanim wyślesz aplikację
Po ośmiu poprawkach zostaje decyzja, nie kolejna lista technologii. Rekruter nie nagradza kompletności archiwum. Nagradza dokument, z którego w pierwszym ekranie da się odczytać rolę, ciężar pracy i jedną rzecz, o którą warto dopytać.
Kryterium wyboru jest brutalnie krótkie: zostaw wpis, jeśli w 20 sekund widać, do jakiej oferty pasuje, co było Twoje i jakiego rzędu był to wysiłek. Resztę skróć do linii albo wyrzuć z tej wersji CV. Osobna wersja pod inną rolę jest tańsza niż jedno CV, które próbuje być wszystkim.
Pułapka na końcu: poprawić sekcję projektów, a stack na górze zostawić sprzed trzech lat — albo odwrotnie, uporządkować technologie i zostawić opisy, których nie obronisz bez notatek. Oba bloki muszą opowiadać tę samą historię.
- Każdy projekt: okres, granica Twojej pracy, jedna decyzja, skala albo uczciwe ograniczenie.
- Pierwsze dwa wpisy zgodne z ogłoszeniem; reszta w jednej linii.
- Nazwy wewnętrzne zamienione na funkcję; przymiotniki, które nic nie zmieniają, skreślone.
- Link, który wkładasz do CV, otwiera się i da się z niego zrozumieć zakres — bez obiecywania deployu, którego nie ma.
- Żadnej liczby, której nie potrafisz rozłożyć na mianownik na pierwszym pytaniu.
Wyślij wersję, którą da się przeczytać na stojąco, z telefonu, między dwoma innymi CV. Jeśli po tym skanie zostaje rola, technologia wiodąca i jeden konkret, dokument robi swoją robotę. Jeśli zostaje tylko chmura słów z ogłoszenia, selekcja już podjęła decyzję za Ciebie.
Najczęściej zadawane pytania (FAQ)
Ile technologii warto wymienić w sekcji stacku?
Najlepiej ograniczyć listę do technologii, które rzeczywiście potrafisz wykorzystać w projekcie i obronić podczas rozmowy. W artykule jako przykład uporządkowanej listy wskazano 6–12 pozycji podzielonych na trzy warstwy.
Czym różnią się technologie Primary, Secondary i Familiar?
Primary to technologie wiodące, używane samodzielnie w zadaniu i widoczne w projektach. Secondary obejmuje narzędzia wspierające, używane regularnie, a Familiar — technologie znane orientacyjnie, bez udawania doświadczenia produkcyjnego.
Jak opisać projekt programistyczny w CV?
Warto uwzględnić kontekst, własną rolę, jedną lub dwie decyzje techniczne oraz efekt albo ograniczenie projektu. Sam tytuł aplikacji i lista technologii nie pokazują sposobu myślenia.
Czy można wpisywać do CV technologie poznane tylko na kursie?
Można je wymienić ostrożnie, ale nie powinny trafiać do głównej warstwy stacku bez potwierdzenia w projekcie. Lepiej zaznaczyć ich edukacyjny charakter albo usunąć je z najważniejszej części sekcji.
Co zrobić z przestarzałą technologią w CV?
Jeśli była używana zawodowo, warto dodać kontekst, datę oraz informację o utrzymaniu, migracji lub ograniczeniach. Nieaktualna technologia nie powinna jednak otwierać stacku, gdy nie pasuje do roli.
