Przygotowanie do rozmowy

Programista Backend: pytania i odpowiedzi na rozmowę

Rozmowa na stanowisko Programisty Backend weryfikuje, jak projektujesz API, pracujesz z bazami danych, dbasz o wydajność i utrzymanie usług pod obciążeniem. Liczą się też decyzje techniczne, współpraca z zespołem i gotowość do pracy w środowisku produkcyjnym.

Written & reviewed by the CVWon Editorial Team · Updated lipiec 2026

Utworzyć CV

Pytania i odpowiedzi

Pytania rekrutacyjne i wzorcowe odpowiedzi

Warto przygotować się na te częste pytania, korzystając ze szczegółowych wzorcowych odpowiedzi.

Dlaczego pada to pytanie

To pokazuje, czy myślisz o API jak o długoterminowym kontrakcie, a nie tylko o zestawie endpointów.

Wzorcowa odpowiedź

Zaczynam od potrzeb konsumenta, a nie od struktury bazy. Projektuję spójne, przewidywalne endpointy, dbam o czytelne nazewnictwo, jednolity format błędów i sensowne statusy HTTP. Wprowadzam versioning, preferuję zmiany addytywne zamiast breaking changes i dokumentuję kontrakt, najlepiej w OpenAPI. Od początku myślę też o paginacji, idempotency i rate limiting.

W odpowiedzi wspomnij o backward compatibility i o tym, jak minimalizujesz ryzyko dla istniejących integracji.

Dlaczego pada to pytanie

Rekruter chce zobaczyć, czy potrafisz diagnozować problem na podstawie danych, a nie intuicji.

Wzorcowa odpowiedź

Najpierw szukam danych: metryk, logów, trace'ów i profilu zapytań. W jednej sytuacji endpoint zwalniał przez N+1 query, więc zamiast setek małych odwołań zrobiłem jedno zbiorcze zapytanie i dodałem indeks na filtrowanej kolumnie. Czas odpowiedzi spadł z kilku sekund do kilkudziesięciu milisekund. Zawsze naprawiam przyczynę, a nie tylko objaw.

Podaj konkretne narzędzie, którego użyłeś, np. APM, profiler, slow query log.

Dlaczego pada to pytanie

To pytanie sprawdza, czy rozumiesz trudne realia systemów rozproszonych i ich kompromisy.

Wzorcowa odpowiedź

Najpierw pytam, czy naprawdę potrzebujesz strong consistency, bo często wystarczy eventual consistency. Przy operacjach między usługami unikam distributed transactions, a zamiast tego stosuję saga, outbox lub asynchroniczną komunikację przez queue. Operacje projektuję jako idempotentne, żeby retry były bezpieczne. Tam, gdzie to potrzebne, dodaję reconciliation jobs i monitoring rozjazdów danych.

Pokaż, że rozumiesz trade-off między prostotą, spójnością i odpornością na awarie.

Dlaczego pada to pytanie

Firma chce wiedzieć, czy budujesz usługi operowalne, a nie tylko takie, które 'działają na Twoim komputerze'.

Wzorcowa odpowiedź

Rozróżniam błędy przewidywalne, które obsługuję kontrolowanym response'em, od nieoczekiwanych, które loguję z kontekstem potrzebnym do diagnozy. Stosuję structured logging, metryki i distributed tracing, żeby szybko odpowiedzieć na pytania: co padło, gdzie i kogo to dotyczy. Alerty opieram na symptomach odczuwanych przez użytkownika, czyli error rate, latency i dostępności, a nie na hałaśliwych wskaźnikach pomocniczych.

Wspomnij, że alerty mają chronić użytkownika i biznes, a nie tylko dawać sygnał techniczny.

Dlaczego pada to pytanie

Bezpieczeństwo jest obowiązkową częścią pracy backendowej, więc rekruter sprawdza, czy jest u Ciebie odruchowe.

Wzorcowa odpowiedź

Stosuję defense in depth: autoryzacja i uwierzytelnianie na każdym wrażliwym endpointcie, walidację wejścia, parameterised queries i zasadę least privilege dla kont serwisowych oraz bazy. Sekrety trzymam poza kodem, najlepiej w vault, a zależności aktualizuję i patchuję na bieżąco. Przy operacjach wrażliwych dokładam rate limiting, audyt i ślady aktywności zgodne z wymaganiami RODO.

Nie mów ogólnie o 'dbaniu o bezpieczeństwo' — wymień konkretne praktyki i mechanizmy.

Techniczne

Rozmowa kwalifikacyjna: Programista Backend – jakie pytania techniczne padają najczęściej?

Na rozmowie kwalifikacyjnej warto spodziewać się tych pytań technicznych, typowych dla danego stanowiska.

ACID oznacza Atomicity, Consistency, Isolation i Durability. Atomicity mówi, że transakcja wykonuje się w całości albo wcale, Consistency utrzymuje bazę w poprawnym stanie, Isolation ogranicza wzajemne wpływanie równoległych transakcji, a Durability gwarantuje trwałość zatwierdzonych danych mimo awarii. Dzięki temu wieloetapowe operacje są bezpieczniejsze przy współbieżności i błędach.

Message queue wybierasz, gdy chcesz rozdzielić producenta i konsumenta, odciążyć synchronizację i poradzić sobie ze skokami ruchu. To dobre rozwiązanie dla zadań asynchronicznych, retry i procesów, które nie muszą odpowiedzieć natychmiast. Bezpośrednie API ma sens, gdy potrzebujesz natychmiastowej odpowiedzi i akceptujesz silniejsze sprzężenie.

Pessimistic locking blokuje rekord w trakcie odczytu lub aktualizacji, żeby nikt inny nie zmienił go równocześnie, co zmniejsza konflikty, ale może obniżać throughput. Optimistic locking zakłada, że konflikty są rzadkie, sprawdza wersję rekordu przy zapisie i odrzuca update, jeśli ktoś zmienił dane wcześniej. W systemach read-heavy optimistic locking zwykle skaluje się lepiej.

Caching trzyma często używane dane bliżej aplikacji, żeby zmniejszyć latency i odciążyć źródło danych. Główne ryzyka to stale data i trudna cache invalidation, która bywa jednym z najtrudniejszych problemów w backendzie. Pomagają sensowne TTL, invalidation przy zapisie oraz świadomy wybór między cache-aside a write-through w zależności od wymagań spójności.

Idempotency oznacza, że wielokrotne wykonanie operacji daje ten sam efekt co pojedyncze. Ma to znaczenie, bo sieć bywa zawodna, a klienci retry'ują żądania, więc bez idempotency można podwójnie obciążyć konto, duplikować rekordy albo wykonać operację dwa razy. Idempotency keys pozwalają serwerowi wykrywać i bezpiecznie deduplikować powtórzone requesty.

Sytuacyjne

Rozmowa kwalifikacyjna: Programista Backend – jak przygotować się do pytań sytuacyjnych?

Scenariusze behawioralne i sytuacyjne, które mogą pojawić się na rozmowie.

Wykonałem migrację, która dodała kolumnę NOT NULL bez defaultu do dużej tabeli i zablokowała zapisy. Przerwałem migrację, żeby szybko zdjąć lock i przywrócić service. Potem rozbiłem zmianę na bezpieczne kroki: dodanie kolumny jako nullable, backfill partiami i dopiero na końcu constraint. Od tamtej pory zespół korzysta z checklisty bezpiecznych migracji.

W jednym przypadku kampania marketingowa zwiększyła ruch dziesięciokrotnie i usługa zaczęła odrzucać requesty. Szybko skalowałem stateless instancje, dodałem tymczasowy cache przed najgorętszym endpointem odczytowym i włączyłem rate limiting, żeby chronić bazę. System się ustabilizował, a później przygotowaliśmy load test pod taki scenariusz.

Zdarzyło mi się integrować payment provider'a, którego dokumentacja była niepełna i częściowo błędna. Zbudowałem mały sandbox harness, żeby sprawdzić rzeczywiste zachowanie endpointów i odpowiedzi. Całość owinąłem własnym adapterem, dzięki czemu vendor quirks były zamknięte w jednym miejscu. Integracja weszła na czas, a późniejsze zmiany dostawcy były dużo prostsze.

Zacząłem od analizy query patterns i realnego użycia zasobów, zamiast zgadywania. Dodałem brakujące indeksy, przeniosłem zimne dane do tańszego storage i prawidłowo dopasowałem rozmiar instancji do rzeczywistego obciążenia. Koszty miesięczne spadły wyraźnie, a latency pozostało bez zmian. Najważniejsze było oparcie decyzji o metryki, nie o intuicji.

Przygotowanie

Wskazówki dotyczące przygotowania

Przećwicz projektowanie API i modelu danych na głos: encje, relacje, indeksy, paginacja, błędy i wersjonowanie.

Odśwież SQL: transakcje, izolację, indeksy, plany zapytań, deadlocki oraz różnice między bazą relacyjną a NoSQL.

Przygotuj jedną mocną historię o naprawie problemu produkcyjnego z użyciem konkretnych narzędzi, metryk i efektów.

Powtórz podstawy distributed systems: consistency, retry, queue, idempotency, circuit breaker i outbox.

Zadbaj o kontekst rynkowy: widełki brutto/mies. w PLN, różnice między UoP, zlecenie i B2B (JDG) oraz wpływ ZUS i PIT na realną wypłatę.

Jak odpowiedzieć na pytanie: „Jakie są Pana/Pani oczekiwania finansowe?”

Jeśli pytasz o wynagrodzenie, trzymaj się widełek brutto/mies. w PLN i mów o całym pakiecie, nie tylko o podstawie. Na rynku w hubach IT takich jak Warszawa, Kraków i Wrocław backend developerzy zwykle negocjują inaczej przy UoP, inaczej przy zleceniu i inaczej przy B2B (JDG), bo różnią się ZUS, PIT i koszty prowadzenia działalności. Dla osoby z doświadczeniem w projektowaniu API, pracy z bazami i utrzymaniu usług produkcyjnych sensowne jest podanie przedziału dopasowanego do poziomu, a potem doprecyzowanie oczekiwań po omówieniu zakresu odpowiedzialności, pracy zdalnej lub hybrydowej oraz dyżurów on-call.

FAQ

Najczęściej zadawane pytania

Najczęściej pojawiają się pytania o projektowanie API, bazy danych, transakcje, caching, concurrency, bezpieczeństwo i observability. Coraz częściej rekruterzy sprawdzają też Twoje podejście do deployment, CI/CD, testów i współpracy w scrumie.

Nie musisz, ale warto rozumieć, co daje inny stack i jakie są trade-offy. W praktyce liczy się głębokość w jednym języku i umiejętność przenoszenia wiedzy między frameworkami, a nie samo wyliczanie technologii.

Czasem tak, zwłaszcza jeśli firma szuka mocnych podstaw inżynierskich. Studia licencjackie, inżynierskie czy magisterskie na uczelniach takich jak Politechnika Warszawska albo AGH mogą być plusem, ale zwykle ważniejsze są Twoje projekty, doświadczenie i sposób myślenia.

Oba modele są bardzo popularne, szczególnie w firmach z Warszawy, Krakowa i Wrocławia. Przy role backendowych liczy się przede wszystkim skuteczna współpraca, dostępność na spotkania zespołu i umiejętność pracy w rozproszonym środowisku.

Mów o trade-offach, ryzykach, kosztach i konsekwencjach decyzji, a nie tylko o tym, że coś działa. Dobre sygnały to myślenie o skalowaniu, awariach, audycie, RODO, utrzymaniu i tym, jak rozwiązanie będzie wyglądało za pół roku, a nie tylko dziś.