CV Java/Spring Developera: jak opisać backend pod ofertę

Typowa oferta na Java Developera wygląda jak spis bibliotek z pom.xml: Spring Boot, Spring Data JPA, Hibernate, REST, SQL, Kafka, Docker, do tego „mikroserwisy” i „skalowalność” jako słowa-wytrychy. Rekruter techniczny czyta to i robi w głowie checklistę. Potem otwiera twoje CV, w którym pod stanowiskiem stoi „Java Developer”, a niżej dokładnie ta sama ściana logotypów. Tylko że z tej ściany nie widać, czy ty te frameworki kiedyś dotknąłeś, czy postawiłeś na nich system, który obsługuje ruch produkcyjny i nie pada pod obciążeniem.

Bo na stanowisku backendowym nie chodzi o to, ile adnotacji Springa znasz na pamięć. Chodzi o to, czy potrafisz zaprojektować serwis, który trzyma latencję pod kontrolą, nie zarzyna bazy i da się go skalować, gdy ruch urośnie dziesięciokrotnie. Lista technologii tego nie pokaże, bo każdy kandydat na Javę ma identyczną. Pokaże to dopiero opis, w którym widać skalę, efekt twoich decyzji i to, że za zapytaniem stoi konkretna liczba, a nie ogólnik „optymalizowałem wydajność”.

Poniżej masz, co wyeksponować nad fold, jak opisać projekt backendowy przez wpływ na latencję, RPS i czas zapytania, i jak ustawić temat mikroserwisów pod konkretną ofertę, zamiast wpisywać je odruchowo.

Co wyeksponować nad fold: Java, Spring, baza

„Nad fold” to ta część CV, którą rekruter widzi bez przewijania. Pod ofertę backendową w Javie ma tam być widać trzy rzeczy: wersję Javy i ekosystem Springa, sposób pracy z bazą i to, jak budujesz API. To rdzeń roli, reszta jest wsparciem.

Ułóż umiejętności w kolejności istotności dla oferty, nie alfabetycznie:

• Rdzeń: Java (z wersją, np. 17 albo 21), Spring Boot, Spring Data JPA / Hibernate, REST, SQL (PostgreSQL, MySQL, ta z oferty na pierwszym miejscu).
• Realne wsparcie: Kafka albo RabbitMQ, Docker, testy (JUnit, Mockito, Testcontainers), Maven albo Gradle, cache (Redis), bezpieczeństwo (Spring Security).
• Reszta: narzędzia CI, monitoring, chmura, niżej i mniejszą wagą.

Jeśli oferta wymienia konkretną technologię, której realnie używasz na produkcji, na przykład Kafkę albo PostgreSQL, ma być widoczna od razu, nie zakopana między dwudziestą a trzydziestą pozycją. Rekruter skanuje pod kątem zgodności z ogłoszeniem, nie kompletności twojej kariery. Wersja Javy też ma znaczenie: „Java 8” i „Java 21” to dla rekrutera sygnał, w jakim kodzie się poruszasz.

Jak opisać projekt backendowy efektem, nie zadaniem

To jest miejsce, gdzie większość CV Javowca się wykłada. Ludzie wypisują, co robili („pisałem endpointy w Spring Boot”, „obsługiwałem bazę przez JPA”), a to są obowiązki, nie dokonania. Nie widać ani skali, ani tego, czy po twojej robocie cokolwiek działało szybciej. Pokaż zmianę i jej efekt, mierzony tym, co w backendzie się liczy: latencja, RPS, czas zapytania, rozmiar danych.

Słaby zapis, który czyta się jak zakres obowiązków:

Pisałem endpointy w Spring Boot i zajmowałem się komunikacją z bazą danych przez Hibernate.

Ten sam fakt, ustawiony pod ofertę backendową:

Zaprojektowałem REST API w Spring Boot obsługujące 1200 RPS przy p99 poniżej 120 ms. Po zdiagnozowaniu problemu N+1 w warstwie Hibernate i dodaniu indeksów oraz cache w Redisie skróciłem czas najcięższego zapytania z 800 ms do 40 ms na bazie z 50 mln rekordów.

Druga wersja opisuje dokładnie to samo, co robiłeś, ale pokazuje punkt wyjścia, zmianę i efekt w liczbach. Widać skalę (1200 RPS, 50 mln rekordów), zmianę (eliminacja N+1, indeksy, cache) i wpływ (czas zapytania z 800 do 40 ms). Tego rekruter szuka, bo to odróżnia kogoś, kto sklejał kontrolery z gotowych tutoriali, od kogoś, kto rozumie, gdzie backend traci czas i pieniądze.

Mocne akcenty pod backend i ich konkrety: latencja (p95, p99 w milisekundach), przepustowość (RPS, liczba zdarzeń na sekundę przez Kafkę), czas zapytania (z X do Y ms po optymalizacji), skala danych (rozmiar bazy, liczba rekordów, partycje), niezawodność (uptime serwisu, liczba błędów po refaktorze).

Mikroserwisy czy monolit: dopasuj do oferty

„Mikroserwisy” to słowo, które kandydaci wpisują odruchowo, bo brzmi nowocześnie. Tymczasem to nie jest plus sam w sobie, tylko decyzja architektoniczna, którą rekruter chce zobaczyć w kontekście. Jedna oferta szuka kogoś, kto rozbije monolit na serwisy i ogarnie komunikację przez Kafkę. Druga, równie często, szuka kogoś, kto utrzyma i rozwinie duży, działający monolit, nie robiąc z niego rozproszonego bałaganu.

Czytaj, czego naprawdę chce ogłoszenie. Jeśli pada „event-driven”, „Kafka”, „bounded context”, „komunikacja między serwisami”, pokaż projekt, w którym dzieliłeś system na serwisy i opisz, ile ich było, jak się komunikowały i co to dało (na przykład niezależny deploy, który skrócił czas wdrożenia funkcji). Jeśli oferta mówi o utrzymaniu dużej domeny, refaktorze legacy albo wydajności jednego serwisu, nie udawaj architekta rozproszonego systemu. Pokaż, że potrafisz utrzymać kod, który już działa na produkcji, i poprawiać go bez psucia reszty.

W obu przypadkach liczy się ta sama mechanika: nie nazwa wzorca, tylko decyzja, jej skala i efekt. Jeden projekt zwykle daje materiał na kilka odcieni tej samej roli: backend produktowy, integracyjny, platformowy. To ten sam projekt, inny pierwszy plan, bez przepisywania historii. Mechanikę pokazujemy w jeden projekt, cztery role.

Słowa kluczowe z ofert Java

Oferty backendowe w Javie powtarzają konkretny zestaw zwrotów: java (z wersją), spring boot, spring data jpa, hibernate, rest api, sql, postgresql albo mysql, kafka albo rabbitmq, docker, kubernetes, junit, mockito, testcontainers, maven albo gradle, mikroserwisy, ci/cd. To są twoje słowa kluczowe. Wyciągnij must-have z konkretnej oferty i sprawdź, które masz pokryte realnym przykładem z projektu, a których lepiej nie wpisywać, bo zweryfikują je na pierwszej rozmowie technicznej w pięć minut. Jak czytać ogłoszenie pod tym kątem, rozkładamy w jak wyciągnąć słowa kluczowe z oferty IT.

Uważaj na pułapkę: wpisanie do skills wszystkiego, co kiedyś przeszedłeś w tutorialu. Rekruter pod backend nie szuka najdłuższej listy, tylko zgodności z must-have i dowodu w projektach. Co zostawić, a co wyciąć pod konkretne ogłoszenie, rozkładamy w jak dopasować CV do oferty IT.

Częste błędy

• Ściana frameworków bez kontekstu. Trzydzieści logotypów ze świata Springa wrzuconych obok siebie nie mówi, czy stawiałeś na nich produkcję, czy przerobiłeś tutorial. Zostaw rdzeń, resztę podaj niżej i pokaż użycie w projektach z konkretnym efektem.
• Brak skali i metryk. „Optymalizowałem zapytania SQL” bez liczb jest puste. Baza na tysiąc rekordów to inna liga niż baza na 50 mln. Dopisz rozmiar danych, RPS, latencję przed i po. Bez liczby to deklaracja, nie dokonanie.
• „Mikroserwisy” jako ozdoba. Wpisanie ich tam, gdzie utrzymywałeś monolit, wychodzi na pierwszym pytaniu o komunikację między serwisami i kosztuje wiarygodność. Opisz architekturę, którą realnie budowałeś, a nie tę, która brzmi modnie.

Jak złożyć CV Java/Spring pod ofertę w ZłóżCV

Pod ofertę backendową ZłóżCV bierze z twojej bazy projekty, w których realnie projektowałeś API, optymalizowałeś bazę i budowałeś serwisy, układa stack pod wymagania ogłoszenia i przepisuje opisy tak, żeby było widać skalę, efekt i decyzje architektoniczne, a nie samą listę bibliotek. Wklejasz link do oferty, dostajesz dopasowane CV w PDF. Złóż CV pod ofertę Java, dwa pierwsze za darmo, bez karty.

Najczęstsze pytania

Mam głównie Spring Boot i CRUD-y, jak pokazać coś więcej niż endpointy? Wyciągnij z tych CRUD-ów decyzje, które miały efekt: dodany indeks, który skrócił zapytanie, walidacja, która zbiła liczbę błędów, paginacja, która odciążyła bazę. Nawet zwykły endpoint ma metrykę: ile rekordów obsługuje, jaki ma czas odpowiedzi. To zamienia „pisałem endpointy” w konkretny wpływ.

Wpisywać wersję Javy i Springa? Tak. „Java 21” i „Spring Boot 3” to sygnał, że pracujesz na aktualnym stacku, a nie utrzymujesz wyłącznie legacy. Jeśli pracowałeś na starszych wersjach, nie kłam, ale pokaż też, gdzie dotknąłeś nowszych, choćby w projekcie pobocznym albo przy migracji.

Oferta wymaga Kafki, a ja robiłem tylko REST, co wtedy? Nie dopisuj Kafki, bo pytanie o partycje i offsety wyłoży to na rozmowie. Pokaż za to pokrewne kompetencje: kolejki, które znasz (RabbitMQ), przetwarzanie asynchroniczne, integracje. Jeśli Kafka jest twardym must-have, a ty jej nie dotykałeś, to po prostu nie jest oferta pod ciebie.

Jak pokazać wydajność, gdy nie mierzyłem dokładnych liczb? Podaj rzędy wielkości, które pamiętasz, zamiast zmyślać precyzję. „Baza rzędu kilku milionów rekordów”, „ruch w tysiącach zapytań na minutę”, „zapytanie z kilku sekund do poniżej sekundy” jest wiarygodne i konkretniejsze niż „poprawiłem wydajność”. Lepszy uczciwy rząd wielkości niż ładnie brzmiąca liczba, której nie obronisz.