Dobre frontend developer cv ma jeden cel: w kilka sekund pokazać, że potrafisz budować interfejsy, pracować z konkretnym stackiem i dowozić mierzalny efekt. W tym artykule rozkładam to na części: od układu dokumentu, przez opisy projektów i doświadczenia, aż po portfolio, dopasowanie do ogłoszenia i ostatnią checklistę przed wysłaniem aplikacji. Piszę z perspektywy tego, co naprawdę pomaga przejść selekcję, a nie tylko dobrze wygląda na ekranie.
Najważniejsze elementy, które decydują o skutecznym CV front-end developera
- Najpierw pokaż stack, zakres odpowiedzialności i efekt pracy, a dopiero później ogólny opis siebie.
- Najbezpieczniejszy układ to: profil, doświadczenie, projekty, umiejętności, edukacja, linki.
- W opisie stanowisk najlepiej działają 3-5 punktów na rolę, zapisanych jako wynik działania, nie lista obowiązków.
- Portfolio i GitHub są dla front-endu równie ważne jak sam dokument, zwłaszcza na poziomie junior i mid.
- W polskich procesach rekrutacyjnych warto też pilnować formatu PDF, czytelności dla ATS i aktualnej klauzuli RODO, jeśli firma jej wymaga.
Jak rekruter czyta CV front-end developera
Ja zwykle patrzę na takie CV w trzech krokach: najpierw sprawdzam, czy kandydat pasuje do roli, potem czy ma odpowiedni stack, a dopiero na końcu wchodzę w detale. W praktyce rekruter ma na to około kilkunastu sekund, więc nie wygrywa najdłuższy dokument, tylko taki, który od razu odpowiada na pytanie: czy ta osoba naprawdę robi front-end na poziomie, którego potrzebujemy?
To oznacza, że na górze dokumentu powinny się znaleźć rzeczy, które można zweryfikować od razu: stanowisko, podsumowanie doświadczenia, główne technologie, link do portfolio albo GitHuba oraz lokalizacja lub informacja o pracy zdalnej. Jeśli w pierwszym ekranie widać tylko ogólniki typu „pasjonuję się technologią”, CV traci tempo. W rekrutacji technicznej ogólniki nie są problemem estetycznym, tylko sygnałem, że kandydat nie umie jeszcze pokazać efektu swojej pracy.
Najbardziej liczą się trzy pytania: co budowałeś, na czym budowałeś i co to zmieniło. Gdy te informacje są rozproszone, dokument wydaje się słabszy, niż jest w rzeczywistości. Dlatego warto zbudować go tak, żeby odpowiedź była widoczna bez przeklikiwania się przez ścianę tekstu. To prowadzi mnie do układu, który naprawdę pomaga w selekcji.
Układ CV, który szybko przechodzi selekcję
Najbezpieczniejszy układ jest prosty i przewidywalny. Rekruter nie powinien zgadywać, gdzie schowałeś doświadczenie, a gdzie projekty. Jeśli aplikujesz na stanowisko front-endowe, ja układałbym dokument w takiej kolejności:
| Sekcja | Co wpisać | Po co to działa |
|---|---|---|
| Profil zawodowy | 2-3 zdania o specjalizacji, stacku i rodzaju projektów | Ustawia kontekst od pierwszego spojrzenia |
| Doświadczenie | 3-5 punktów na rolę, najlepiej z liczbami i efektem | Pokazuje realną pracę, nie tylko zakres obowiązków |
| Projekty | 2-4 najmocniejsze realizacje z linkiem i technologiami | W front-endzie projekty często ważą prawie tyle samo co etat |
| Umiejętności | Podział na języki, frameworki, testy, narzędzia i UX/accessibility | Łatwiej przechodzi przez szybkie skanowanie i ATS |
| Edukacja i certyfikaty | Krótko, bez rozpisywania wszystkiego po kilka linijek | Wspiera obraz kandydata, ale nie powinno dominować |
Jeśli jesteś juniorem albo zmieniasz branżę, projekty mogą wejść wyżej niż doświadczenie. Jeśli masz już kilka lat praktyki, doświadczenie powinno prowadzić narrację, a portfolio tylko ją wzmacniać. Prosty układ nie jest nudny. Jest skuteczny, bo pozwala skupić się na treści. A kiedy układ jest już jasny, trzeba zapełnić go konkretem.
Jak opisać doświadczenie, żeby pokazać efekt, nie tylko obowiązki
Najczęstszy błąd widzę wtedy, gdy kandydat przepisuje zakres obowiązków z umowy albo opis stanowiska. To nie działa, bo nie pokazuje skali ani odpowiedzialności. Lepszy zapis odpowiada na cztery rzeczy naraz: co zrobiłeś, w jakiej technologii, dla kogo i jaki był efekt.
Dobry punkt do CV front-endowego często wygląda jak połączenie czasownika, zakresu i wyniku. Jeśli da się, dodaj liczbę: procent, czas, liczbę komponentów, liczbę ekranów, liczbę użytkowników albo spadek błędów. W front-endzie sens mają zwłaszcza wskaźniki takie jak LCP, CLS i INP. To są miary wydajności i stabilności interfejsu, które pokazują, czy strona ładuje się szybko i nie „skacze” w trakcie wczytywania.
| Słaby zapis | Lepszy zapis | Dlaczego to działa lepiej |
|---|---|---|
| Tworzyłem komponenty w React. | Zbudowałem bibliotekę 14 wielokrotnego użytku komponentów w React i TypeScript, co skróciło wdrażanie nowych widoków o 30%. | Widać skalę, technologię i efekt biznesowy. |
| Pracowałem przy stronie firmy. | Przeprojektowałem kluczowy flow formularza w Next.js, ograniczając liczbę porzuceń na etapie rejestracji o 18%. | Jest wynik, a nie tylko opis zadania. |
| Pomagałem przy testach. | Wprowadziłem testy e2e w Playwright, dzięki czemu wykrywaliśmy regresje przed wdrożeniem zamiast po zgłoszeniach od użytkowników. | Pojawia się konkretna wartość i narzędzie. |
Jeśli nie masz twardych liczb, nie wymyślaj ich. Zamiast tego użyj skali projektu: liczby widoków, typów użytkowników, zespołu, czasu wdrożenia albo zakresu odpowiedzialności. Rekruter często lepiej reaguje na precyzyjny opis pracy niż na sztucznie dosypane procenty. To samo podejście świetnie działa też w portfolio, gdzie można pokazać więcej niż jedno zdanie.
Jak pokazać projekty i portfolio, kiedy nie masz wielkiego doświadczenia
W front-endzie portfolio bywa ważniejsze niż rozbudowana historia zawodowa, zwłaszcza na początku kariery. Ja polecam pokazać 2-4 projekty, ale tylko takie, które naprawdę coś wnoszą. Lepiej mieć trzy dopracowane realizacje niż dziesięć podobnych aplikacji z kursu.
Każdy projekt opisz w prostym układzie: co to było, jaką rolę pełniłeś, na czym pracowałeś i co jest w tym rozwiązaniu ciekawe. Jeśli projekt ma demo, podlinkuj demo. Jeśli ma repo, dopilnuj, żeby README tłumaczyło, jak uruchomić aplikację, jaki był cel i jakie decyzje podjąłeś po drodze. To szczególnie ważne, bo rekruter techniczny często zerka na repo szybciej niż na dekoracyjny opis.
- Wybieraj projekty z różnym zakresem: panel admina, e-commerce, dashboard, aplikacja z API, komponenty UI.
- Pokazuj rzeczy, które są bliskie realnej pracy: formularze, filtrowanie, stan aplikacji, obsługę błędów, responsywność.
- Jeśli używasz projektu kursowego, dopisz własne ulepszenia, bo sama kopia tutorialu niewiele mówi o samodzielności.
- Na GitHubie przypnij 3 najlepsze repozytoria i zadbaj o krótkie opisy, screeny oraz czytelne commity.
To właśnie w portfolio najlepiej widać różnicę między osobą, która potrafi odtworzyć interfejs, a osobą, która umie go zbudować i domknąć produktowo. Gdy to masz, warto zadbać o sekcję umiejętności, bo ona często decyduje o pierwszym filtrowaniu aplikacji.
Jak dobrać sekcję umiejętności, żeby nie wyglądała jak lista haseł
Umiejętności w CV mają pomagać w szybkim skanowaniu, a nie tworzyć katalog wszystkiego, czego kiedykolwiek dotknąłeś. W praktyce najlepiej działa układ pogrupowany, bo jest czytelniejszy i lepiej współpracuje z ATS, czyli systemem do wstępnej automatycznej selekcji CV. Taki system zwykle lepiej rozumie prosty tekst niż kreatywną grafikę, ikonki czy układ z wieloma kolumnami.
| Grupa | Przykłady | Na co uważać |
|---|---|---|
| Języki i frameworki | JavaScript, TypeScript, React, Next.js, Vue, Angular | Wpisuj tylko to, czego naprawdę używasz lub czego szukasz w danej roli |
| Stylowanie i UI | CSS, SCSS, Tailwind, Styled Components, design system | Nie mnoż haseł, jeśli różnią się tylko nazwą |
| Testowanie | Jest, React Testing Library, Cypress, Playwright | Warto pokazać, jeśli realnie piszesz lub utrzymujesz testy |
| Narzędzia pracy | Git, Vite, Webpack, CI/CD, Storybook, Figma | Nie mieszaj narzędzi używanych codziennie z tymi, które znasz tylko pobieżnie |
| Dostępność i jakość | WCAG, ARIA, performance, responsive design | To mocny atut, jeśli potrafisz pokazać go na przykładzie projektu |
Ja zwykle ograniczam tę sekcję do 8-12 naprawdę trafnych pozycji albo kilku grup, a nie rozlanej listy 30 technologii. Taki katalog wygląda dojrzalej i jest po prostu bardziej wiarygodny. Jeśli w ogłoszeniu pojawiają się konkretne narzędzia, warto do nich wrócić w doświadczeniu lub projektach, ale tylko wtedy, gdy faktycznie je znasz. To prowadzi mnie do ważnego rozróżnienia: inne CV działa na start, a inne po kilku latach pracy.
Jak różni się CV juniora, mida i seniora
Nie ma jednego idealnego wzoru dla wszystkich. To, co działa u juniora, może wyglądać zbyt lekko u seniora, a to, co dobrze brzmi u doświadczonej osoby, bywa po prostu zbyt ciężkie dla kogoś na początku drogi. Ja patrzę na to tak: im mniej masz historii zawodowej, tym mocniej powinieneś opierać dokument na projektach, a im więcej doświadczenia, tym bardziej liczy się wpływ na produkt i zespół.
| Poziom | Co powinno wybrzmieć | Na co nie tracić miejsca |
|---|---|---|
| Junior | Projekty, praktyka, stack, samodzielne dowożenie małych zadań | Długi opis kursów i szkolnych detali |
| Mid | Odpowiedzialność za fragment produktu, współpraca z UX i back-endem, stabilność i jakość | Lista podstawowych technologii, które są oczywiste na tym etapie |
| Senior | Architektura, decyzje techniczne, mentoring, wpływ na produkt, optymalizacja | Przesadny poziom szczegółowości na poziomie pojedynczych zadań |
Junior powinien pokazać, że potrafi budować i kończyć małe rzeczy. Mid ma pokazać, że umie brać odpowiedzialność za fragment produktu. Senior ma dowieźć wpływ na zespół i jakość systemu. Dlatego długość CV też się zmienia: jedna strona zwykle wystarczy na start, dwie strony mają sens dopiero wtedy, gdy naprawdę masz czym je wypełnić. To rozróżnienie pomaga potem lepiej dopasować dokument do oferty.
Jak dopasować CV do konkretnej oferty bez przepisywania wszystkiego
Dobre dopasowanie nie oznacza pisania dokumentu od zera za każdym razem. Wystarczy kilka precyzyjnych zmian, które pokazują, że rozumiesz ofertę i umiesz się pod nią ustawić. Ja robię to w praktyce w czterech krokach.
- Zmieniam nagłówek profilu tak, aby odpowiadał realnej roli, na przykład na React Developer, Front-End Developer albo UI Engineer.
- Wybieram z ogłoszenia 3-5 kluczowych technologii i sprawdzam, czy są widoczne w sekcji umiejętności i w opisie doświadczenia.
- Przesuwam na górę te projekty, które najlepiej pasują do produktu, branży albo stosu technologicznego firmy.
- Podmieniam 1-2 punkty w doświadczeniu tak, by akcentowały dokładnie te kompetencje, których szuka pracodawca.
Jeśli ogłoszenie wymaga pracy z Next.js, nie chowaj tej informacji na końcu dokumentu. Jeśli firma pisze o dostępności, pokaż przykład pracy z WCAG albo ARIA. Jeśli w opisie pojawiają się testy end-to-end, a ty rzeczywiście ich używasz, wpisz to jasno, zamiast liczyć, że ktoś się domyśli. Najgorsze, co można zrobić, to kłamać o stacku. W front-endzie takie rzeczy wychodzą bardzo szybko podczas rozmowy technicznej.
Przy aplikowaniu do firm w Polsce dochodzi jeszcze jedna warstwa praktyczna: dokument musi być wygodny do otwarcia, wydrukowania i przekazania dalej. To niby detal, ale właśnie detale potrafią zatrzymać dobre CV albo je osłabić.
Ostatni przegląd, który oszczędza błędnych aplikacji
Przed wysłaniem zrobiłbym krótki audyt. To zajmuje 5-10 minut, a potrafi wyłapać rzeczy, które później bardzo trudno odkręcić. W polskich procesach rekrutacyjnych warto sprawdzić przede wszystkim:
- czy plik jest zapisany jako PDF i otwiera się poprawnie na telefonie oraz na komputerze,
- czy nazwa pliku jest konkretna, na przykład w formacie
Imię_Nazwisko_Frontend_Developer.pdf, - czy wszystkie linki do portfolio, GitHuba i LinkedIna działają bez błędu,
- czy dokument mieści się na 1 stronie przy mniejszym doświadczeniu albo maksymalnie 2 stronach przy bogatszym dorobku,
- czy zdjęcie dodane do CV faktycznie pomaga, zamiast tylko zajmować miejsce,
- czy w stopce znajduje się aktualna klauzula RODO, jeśli pracodawca jej wymaga,
- czy nie ma literówek w technologiach, nazwach firm i datach zatrudnienia.
To właśnie taki finalny przegląd odróżnia dokument przygotowany szybko od dokumentu przygotowanego dobrze. Jeśli mam zostawić jedną zasadę, to tę: w CV front-endowca liczy się nie dekoracja, tylko dowód pracy. Gdy pokażesz konkretny stack, sensowny układ, dopracowane projekty i jasny efekt, reszta zaczyna działać na twoją korzyść.
