To klasyk na rozmowie Java.

• JVM uruchamia bytecode,
• JRE to środowisko uruchomieniowe (JVM + biblioteki),
• JDK to zestaw dla programisty (kompilator + narzędzia + JRE/JVM).

Najkrócej: piszesz i kompilujesz w JDK, uruchamiasz na JVM.

== porównuje referencje (czy to ten sam obiekt), a equals() zwykle porównuje wartości logiczne obiektu.

Na rozmowie warto od razu dodać przykład ze Stringami i wspomnieć o kontrakcie equals() + hashCode().

String w Javie jest niemutowalny, czyli po utworzeniu nie zmieniasz jego zawartości - każda operacja tworzy nowy obiekt.

To ważne m.in. dla bezpieczeństwa, przewidywalności i współdzielenia stringów (string pool).

Na rozmowie warto wspomnieć, że przy wielu modyfikacjach tekstu lepszy bywa StringBuilder.

To częste pytanie-pułapka:

• final - słowo kluczowe (np. stała referencja / brak dziedziczenia / brak override),
• finally - blok w obsłudze wyjątków,
• finalize - stary mechanizm związany z GC (historycznie, dziś niezalecany).

Na rozmowie najlepiej odpowiedzieć krótko i precyzyjnie.

Oba służą do wydajniejszego składania tekstu niż zwykłe konkatenacje Stringów w wielu operacjach.

Najważniejsza różnica praktyczna: StringBuffer jest synchronizowany (thread-safe), a StringBuilder zwykle szybszy w typowym jednowątkowym użyciu.

Na rozmowie warto odpowiedzieć właśnie przez kontekst użycia, nie samą definicję.

Objects.equals(a, b) ułatwia bezpieczne porównywanie wartości z uwzględnieniem null, bez ręcznych ifów na każdej linii.

Na rozmowie to dobry detal pokazujący praktyczną znajomość standardowej biblioteki Javy i pisanie czytelniejszego kodu.

BigDecimal pozwala precyzyjniej modelować obliczenia dziesiętne niż typy zmiennoprzecinkowe, które mogą wprowadzać błędy reprezentacji.

Na rozmowie warto powiedzieć praktycznie: w finansach/precyzyjnych wyliczeniach unikam double do kwot.

ArrayList zwykle jest lepszym domyślnym wyborem - szybki dostęp po indeksie i dobra wydajność w wielu realnych use case.

LinkedList ma inne właściwości strukturalne, ale w praktyce rzadziej daje realny zysk.

Na rozmowie najlepiej odpowiedzieć przez trade-offy i wzorzec użycia, a nie „ta jest zawsze szybsza”.

HashMap przechowuje elementy bez sortowania i zwykle jest domyślnym wyborem do szybkiego dostępu po kluczu.

TreeMap utrzymuje klucze w porządku (sortowanie), więc używasz go, gdy kolejność ma znaczenie.

Na rozmowie warto dodać, że wybór zależy od potrzeb biznesowych: szybkość vs uporządkowane klucze.

Comparable definiuje naturalny porządek obiektu w samej klasie (np. przez compareTo), a Comparator pozwala zdefiniować sortowanie z zewnątrz.

Na rozmowie warto podkreślić praktykę: Comparator daje większą elastyczność, bo możesz mieć wiele strategii sortowania dla tego samego typu.

To trzy podstawowe typy kolekcji o różnych zastosowaniach:

• List - uporządkowana sekwencja (może mieć duplikaty),
• Set - zbiór unikalnych elementów,
• Map - pary klucz-wartość.

Na rozmowie warto odpowiedzieć prostym językiem i od razu podać praktyczne use case.

Jeśli dwa obiekty są równe według equals(), to muszą mieć ten sam hashCode() - inaczej struktury haszujące (np. HashMap, HashSet) będą działać niepoprawnie.

To klasyczny temat rekrutacyjny w Javie. Dobra odpowiedź pokazuje zrozumienie kontraktu, a nie tylko pamięciowe hasło.

HashSet zwykle służy do szybkiego przechowywania unikalnych elementów bez gwarancji sortowania, a TreeSet utrzymuje elementy w porządku.

Na rozmowie warto połączyć odpowiedź z use case: jeśli potrzebujesz porządku/sortowania, wybierasz strukturę z kosztem tej funkcjonalności.

W nowoczesnej Javie do implementacji stosu/kolejki często preferuje się ArrayDeque zamiast starego Stack.

Na rozmowie warto odpowiedzieć praktycznie: znam strukturę danych i wybieram współczesne, sensowne API z kolekcji Javy.

HashMap nie gwarantuje kolejności, a LinkedHashMap zachowuje przewidywalną kolejność iteracji (np. kolejność wstawiania).

Na rozmowie warto dodać praktyczny use case: gdy chcesz mapę z szybkim dostępem po kluczu, ale kolejność ma znaczenie np. przy renderowaniu/serializacji.

Tablica ma stały rozmiar i prostszą strukturę, a ArrayList daje dynamiczny rozmiar i wygodne API kolekcji.

Na rozmowie dobra odpowiedź to trade-off: prostota i niski narzut vs wygoda i elastyczność pracy na kolekcji.

Java jest językiem mocno obiektowym, więc warto umieć opisać filary OOP: enkapsulacja, dziedziczenie, polimorfizm, abstrakcja.

Na rozmowie dobrze zrobić to praktycznie - np. interfejs jako kontrakt, klasa implementująca różne strategie, ukrywanie szczegółów implementacji.

Interfejs definiuje kontrakt (co obiekt ma umieć), a klasa abstrakcyjna pozwala współdzielić część implementacji i stanu.

Na rozmowie dobra odpowiedź to nie tylko teoria, ale kiedy czego użyć: interfejs do ról/kontraktów, abstract class gdy masz wspólne zachowanie dla rodziny klas.

Default methods pozwalają dodać domyślne zachowanie do interfejsu bez łamania wszystkich implementacji.

Na rozmowie warto powiedzieć, że to przydatne narzędzie ewolucji API, ale nie powinno zamieniać interfejsu w „ukrytą klasę bazową” z dużą ilością logiki.

Java używa wyjątków do obsługi błędów runtime i sytuacji wyjątkowych.

W praktyce na rozmowie warto pokazać, że rozumiesz:

• łapanie konkretnych wyjątków,
• różnicę checked vs unchecked exceptions,
• finally / try-with-resources do cleanupu.

Dobra odpowiedź to też wzmianka, że nie należy „połykać” wyjątków bez logowania i reakcji.

Checked exceptions są sprawdzane przez kompilator i zwykle wymagają obsługi lub deklaracji throws. Unchecked exceptions (dziedziczące po RuntimeException) nie mają tego wymogu.

Na rozmowie dobra odpowiedź to nie tylko definicja, ale też sensowne podejście projektowe: nie nadużywać checked wyjątków tam, gdzie utrudniają API bez realnej wartości.

try-with-resources automatyzuje zamykanie zasobów (np. streamów, readerów, połączeń), które implementują AutoCloseable.

To bezpieczniejsze i czytelniejsze niż ręczne zamykanie w finally.

Na rozmowie warto powiedzieć, że to domyślne podejście przy pracy z zasobami I/O.

Blok finally zwykle wykonuje się niezależnie od tego, czy wyjątek wystąpił, ale na rozmowie warto zaznaczyć, że istnieją szczególne sytuacje, w których program może zostać przerwany inaczej (np. brutalne zakończenie procesu).

Dobra odpowiedź jest praktyczna: używam finally do cleanupu, ale przy zasobach preferuję try-with-resources.

To nie tylko kwestia składni, ale też projektowania API między warstwami.

Na rozmowie warto pokazać, że rozumiesz trade-off: checked exceptions wymuszają jawność, ale mogą zwiększać boilerplate; unchecked bywają wygodniejsze, ale wymagają dobrej dyscypliny obsługi błędów.

Garbage Collector w Javie automatycznie zwalnia pamięć obiektów, do których nie ma już referencji.

Na rozmowie ważniejsze od szczegółów konkretnego GC jest zrozumienie skutków praktycznych: mniejsze ryzyko ręcznych błędów pamięci, ale nadal trzeba uważać na wycieki przez referencje i zły lifecycle obiektów.

Java ma rozbudowane wsparcie dla współbieżności: wątki, executory, synchronizacja, kolekcje współbieżne.

Na rozmowie warto mówić praktycznie: tworzenie surowych wątków jest możliwe, ale w aplikacjach częściej używa się ExecutorService / pooli wątków.

Kluczowe tematy to race conditions, synchronizacja i bezpieczeństwo współbieżne.

synchronized to prostszy, wbudowany mechanizm synchronizacji. Lock (np. ReentrantLock) daje więcej kontroli, np. tryLock czy bardziej zaawansowane scenariusze.

Na rozmowie dobra odpowiedź: domyślnie prostsze rozwiązanie, a bardziej zaawansowane narzędzia gdy naprawdę potrzebujesz dodatkowej kontroli.

volatile pomaga w widoczności zmian między wątkami - zapis w jednym wątku ma być widoczny dla innych bez cache'owania w sposób prowadzący do niespójności.

Na rozmowie warto dodać ważne zastrzeżenie: volatile nie zastępuje pełnej synchronizacji dla złożonych operacji (np. inkrementacji z wielu kroków).

ExecutorService pozwala zarządzać pulą wątków i zlecaniem zadań w uporządkowany sposób.

W praktyce daje lepszą kontrolę nad zasobami niż tworzenie wielu surowych Thread ręcznie.

Na rozmowie dobra odpowiedź: w aplikacjach zwykle wybieram wyższy poziom abstrakcji i pule wątków, chyba że mam bardzo specyficzny przypadek.

CompletableFuture pozwala budować i łączyć asynchroniczne operacje w bardziej elastyczny sposób niż proste Future.

Na rozmowie warto wspomnieć o łańcuchowaniu, łączeniu wyników i obsłudze błędów, bo to pokazuje praktyczne użycie, a nie tylko znajomość nazwy.

Obie formy służą do synchronizacji, ale blok daje bardziej precyzyjną kontrolę nad zakresem kodu i obiektem locka.

Na rozmowie dobra odpowiedź: zawężanie sekcji krytycznej zwykle pomaga ograniczyć narzut i ryzyko blokowania zbyt dużej części logiki.

synchronized to ogólny mechanizm synchronizacji sekcji krytycznych, a kolekcje współbieżne dają gotowe, zoptymalizowane struktury danych do pracy wielowątkowej.

Na rozmowie warto pokazać pragmatyzm: jeśli problem dotyczy współdzielonej mapy/kolejki, często lepiej użyć odpowiedniej kolekcji niż pisać całą synchronizację ręcznie.

wait()/notify() to niższy poziom synchronizacji oparty o monitor obiektu. Współcześnie często wygodniej i bezpieczniej używać wyższych abstrakcji z java.util.concurrent.

Na rozmowie warto pokazać pragmatyzm: znam podstawy, ale w praktyce wybieram nowocześniejsze narzędzia, jeśli rozwiązują problem czyściej.

HashMap nie jest bezpieczny współbieżnie, a ConcurrentHashMap jest zaprojektowany do bezpieczniejszej pracy z wieloma wątkami.

Na rozmowie warto podkreślić praktykę: dobierasz strukturę do scenariusza współbieżności zamiast „doklejać synchronized” wszędzie.

Stream API pozwala przetwarzać kolekcje w stylu deklaratywnym (np. filter, map, collect).

Na rozmowie warto podkreślić, że stream nie modyfikuje kolekcji sam z siebie i pomaga pisać czytelniejszy kod dla transformacji danych.

Dobra odpowiedź to też świadomość, że nie każdy stream jest automatycznie „szybszy” od klasycznej pętli.

Optional pomaga jawnie modelować brak wartości i ograniczać część problemów z null.

Na rozmowie warto powiedzieć, że jest przydatny głównie jako typ zwracany z metod, ale nie zawsze ma sens wszędzie (np. jako pole encji / DTO zależnie od kontekstu).

Najważniejsze: rozumiesz po co istnieje, a nie używasz go mechanicznie.

record to zwięzły sposób definiowania klas przechowujących dane, z automatycznie generowanymi elementami typu konstruktor, equals, hashCode, toString.

Na rozmowie warto powiedzieć, że to świetne narzędzie do DTO i prostych modeli danych, ale nie zamiennik każdej klasy domenowej.

Optional pomaga jawnie komunikować możliwość braku wyniku, co poprawia czytelność API.

Na rozmowie warto odpowiedzieć praktycznie: najczęściej jako typ zwracany z metody, ale niekoniecznie wszędzie (np. pola encji/DTO zależnie od kontekstu i frameworka).

parallelStream() może przyspieszyć część operacji, ale nie jest automatycznie lepszy od zwykłego streama.

Na rozmowie warto podkreślić koszty narzutu, charakter operacji (CPU/I/O), thread-safety i konieczność mierzenia efektów zamiast zgadywania.

Obie metody dostarczają wartość domyślną, ale różnią się sposobem jej tworzenia. orElseGet() przyjmuje supplier i bywa lepsze, gdy przygotowanie wartości domyślnej jest kosztowne.

Na rozmowie to dobry przykład znajomości praktycznych niuansów API, a nie tylko samego istnienia Optional.

Kolekcje tworzone przez List.of(...) są niemutowalne, co bywa bardzo przydatne do bezpiecznego przekazywania danych i ograniczania przypadkowych zmian.

Na rozmowie warto podkreślić praktykę: rozumiesz kiedy potrzebna jest mutowalność, a kiedy lepiej jej uniknąć.

Nowoczesne API comparatorów pozwala budować sortowanie w bardziej deklaratywny i czytelny sposób niż ręczne, rozbudowane implementacje.

Na rozmowie dobra odpowiedź pokazuje, że znasz narzędzia języka i potrafisz pisać krótszy, czytelniejszy kod bez utraty kontroli.

To różne typy do różnych zastosowań: data bez czasu, data+czas bez strefy oraz punkt w czasie.

Na rozmowie warto odpowiedzieć przez semantykę i use case, bo błędy w modelowaniu czasu to częsty problem produkcyjny.

Spring to ekosystem frameworków dla Javy, który mocno upraszcza budowę aplikacji backendowych (szczególnie web/API).

Popularność wynika m.in. z dojrzałego ekosystemu, integracji, konfiguracji i narzędzi takich jak Spring Boot.

Na rozmowie warto odpowiedzieć pragmatycznie: Spring daje strukturę i przyspiesza development, ale trzeba rozumieć co dzieje się pod spodem, a nie tylko „klikać adnotacjami”.

Dependency Injection to przekazywanie zależności do klasy z zewnątrz zamiast tworzenia ich w środku przez new.

To poprawia testowalność, modularność i separację odpowiedzialności.

Na rozmowie warto podać prosty przykład serwisu zależnego od repozytorium i powiedzieć, że kontener (np. Spring) zarządza tworzeniem i wstrzykiwaniem obiektów.

@Transactional służy do zarządzania transakcją wokół operacji, najczęściej w warstwie serwisowej.

Na rozmowie warto pokazać praktyczną świadomość: granice transakcji, rollback na wyjątkach i to, że adnotacja nie rozwiązuje magicznie wszystkich problemów (np. zły podział logiki, wywołania wewnętrzne/proxy w pewnych scenariuszach).

Spring tworzy bean, wstrzykuje zależności, wykonuje inicjalizację, a przy zamykaniu kontekstu może wykonać cleanup.

Na rozmowie nie trzeba recytować całej sekwencji krok po kroku, ale warto pokazać, że rozumiesz lifecycle i wpływ scope/init/destroy na działanie aplikacji.

Technicznie wszystkie służą do oznaczania beanów, ale semantycznie komunikują rolę komponentu w architekturze.

Na rozmowie warto powiedzieć, że to poprawia czytelność projektu i czasem wiąże się też z dodatkowymi zachowaniami/framework conventions (np. warstwa dostępu do danych).

Constructor injection zwykle daje lepszą testowalność, jawność zależności i łatwiej wspiera niemutowalność komponentów.

Na rozmowie dobra odpowiedź to nie tylko „co działa”, ale dlaczego preferujesz jawne zależności zamiast ukrytego wstrzykiwania do pól.

Najczęściej sensownym miejscem jest warstwa serwisowa, gdzie spinasz operacje biznesowe w jedną transakcję.

Na rozmowie dobra odpowiedź pokazuje, że rozumiesz granice odpowiedzialności i nie wrzucasz transakcyjności przypadkowo do każdego miejsca.

Warto rozróżniać testy jednostkowe logiki biznesowej od testów integracyjnych (np. baza, web, framework).

Na rozmowie dobrze powiedzieć, że mocki są przydatne do izolacji zależności, ale nie zastępują testów integracyjnych, które sprawdzają realną współpracę komponentów.

Dobra odpowiedź to balans, a nie „same unit testy” albo „same integracje”.

Dobra odpowiedź to nie „jedna reguła”, tylko zestaw praktyk: sensowne nazewnictwo, spójne kontrakty, przewidywalne wyjątki, czytelne typy zwracane i ograniczenie zbędnej złożoności.

Na rozmowie warto pokazać, że myślisz o użytkowniku API (innym programiście), a nie tylko o tym, żeby kod działał dziś.

Warto myśleć o tym od początku: paginacja, sensowne indeksy w bazie, ograniczenie zwracanych pól, stabilne sortowanie i walidacja parametrów.

Na rozmowie dobra odpowiedź pokazuje, że łączysz warstwę aplikacji z realiami bazy danych i wydajności, a nie patrzysz tylko na kontroler.

Warto mieć spójny sposób mapowania wyjątków na odpowiedzi HTTP i czytelny format błędu dla klienta.

Na rozmowie dobra odpowiedź to myślenie o kodach statusu, komunikatach, logowaniu i centralizacji obsługi (zamiast rozrzucania wszystkiego po kontrolerach).

Trzeba myśleć o timeoutach, retry policy, idempotencji i observability, a nie tylko o „wywołaniu klienta HTTP”.

Na rozmowie dobra odpowiedź pokazuje, że rozumiesz realia systemów produkcyjnych: integracje zawodzą i trzeba projektować odporność.

Warto oddzielać model API od modelu bazy/domeny, żeby uniknąć ciasnego sprzężenia i łatwiej kontrolować kontrakt endpointów.

Na rozmowie dobra odpowiedź pokazuje, że myślisz o bezpieczeństwie, utrzymaniu i ewolucji API, a nie tylko o szybkim „wystawieniu encji”.

Warto rozróżnić walidację formatu/wejścia (np. DTO requestu) od reguł biznesowych, które często należą do warstwy domenowej/serwisowej.

Na rozmowie dobra odpowiedź pokazuje, że nie wrzucasz całej logiki biznesowej do kontrolera tylko dlatego, że „przyszła z requestem”.

Dobre logowanie to poziomy logów, sensowny kontekst (np. request ID), brak wrażliwych danych i czytelne komunikaty, które pomagają odtworzyć problem.

Na rozmowie warto powiedzieć, że logi są narzędziem diagnostycznym, a nie zrzutem wszystkiego jak leci.

Przy operacjach modyfikujących dane warto myśleć o tym, co stanie się przy retry lub duplikacji requestu.

Na rozmowie dobra odpowiedź pokazuje zrozumienie realiów integracji (timeouty, powtórzone żądania) i projektowania odpornych endpointów.

Najpierw trzeba zrozumieć bottleneck i charakter danych: czy są często odczytywane, jak często się zmieniają, jaki jest koszt odświeżania.

Na rozmowie dobra odpowiedź pokazuje, że cache to narzędzie z trade-offami (spójność, invalidacja), a nie „magiczne przyspieszenie”.

Kontroler powinien obsługiwać warstwę HTTP, serwis logikę biznesową i orkiestrację, a repozytorium dostęp do danych.

Na rozmowie dobra odpowiedź pokazuje, że rozumiesz ten podział jako sposób utrzymania czytelności i testowalności, a nie tylko „regułkę frameworka”.