Pytania rekrutacyjne na stanowisko programisty
Rozmowa na programistę ma zwykle dwie części: rozmowę o Twoich projektach i część techniczną (pytania z podstaw, zadanie na żywo albo zadanie domowe). Rekruter techniczny sprawdza nie tylko, czy znasz odpowiedź, ale jak myślisz na głos i czy rozumiesz decyzje w swoim kodzie.
8 pytań i przykładowe odpowiedzi
Proszę opowiedzieć o projekcie, który najlepiej pokazuje Pana/Pani umiejętności.
Przykładowa odpowiedź
W sklepie internetowym z 20 tysiącami zamówień miesięcznie odpowiadam za moduł płatności. Płatności zrywały się przy przekroczeniu czasu odpowiedzi bramki. Kolejka z ponawianiem i klucze idempotencji obniżyły odsetek nieudanych transakcji z 2% do 0,3%. Najwięcej nauczyło mnie to o obsłudze błędów w systemach rozproszonych.
Co sprawdza rekruter: Czy opisujesz problem, swoją rolę i mierzalny efekt, i czy rozumiesz, dlaczego wybrano takie rozwiązanie.
Co dzieje się po wpisaniu adresu strony w przeglądarce?
Przykładowa odpowiedź
Przeglądarka ustala adres IP przez DNS, nawiązuje połączenie TCP i uzgadnia szyfrowanie TLS, potem wysyła żądanie HTTP. Serwer odpowiada dokumentem HTML, przeglądarka buduje z niego drzewo DOM, pobiera CSS i JavaScript, liczy układ strony i ją rysuje. W każdym z tych kroków mogę wejść głębiej, np. w cache DNS albo HTTP/2.
Co sprawdza rekruter: Szerokość podstaw. Rekruter często dopyta o jeden krok, żeby sprawdzić, gdzie kończy się Twoja wiedza.
Jak szuka Pan/Pani błędu, który występuje tylko na produkcji?
Przykładowa odpowiedź
Zaczynam od logów i metryk: od kiedy błąd występuje, w której wersji, u jakich użytkowników. Zawężam zakres, w razie potrzeby dodaję logowanie w podejrzanym miejscu. Odtwarzam przypadek lokalnie na danych podobnych do produkcyjnych, piszę test, który go łapie, i dopiero wtedy poprawiam kod.
Co sprawdza rekruter: Metodę zamiast zgadywania oraz to, czy po poprawce zostaje test, który nie pozwoli błędowi wrócić.
Jak pisze Pan/Pani testy i co testuje w pierwszej kolejności?
Przykładowa odpowiedź
Najwięcej testów jednostkowych dla logiki biznesowej, mniej integracyjnych dla bazy i API, kilka testów end-to-end dla najważniejszych ścieżek, np. zakupu. Testuję zachowanie, nie implementację, żeby refaktoryzacja nie psuła testów. Każdy zgłoszony błąd zaczynam od testu, który go odtwarza.
Co sprawdza rekruter: Czy znasz piramidę testów i czy testy są dla Ciebie częścią pracy, a nie dodatkiem na koniec.
Czym jest złożoność obliczeniowa i kiedy ma znaczenie w praktyce?
Przykładowa odpowiedź
To opis tego, jak rośnie czas lub pamięć wraz z wielkością danych, np. O(n) albo O(n²). Przykład z pracy: porównanie dwóch list klientów w podwójnej pętli przy 50 tysiącach rekordów trwało minuty. Zbiór (hash set) zamiast wewnętrznej pętli zmienił złożoność z O(n·m) na O(n+m) i czas spadł do ułamka sekundy.
Co sprawdza rekruter: Czy rozumiesz pojęcie na przykładzie, a nie tylko jako definicję z podręcznika.
Relacyjna baza danych czy NoSQL: jak Pan/Pani wybiera?
Przykładowa odpowiedź
Dla danych powiązanych i wymagających spójności, jak zamówienia i płatności, wybieram bazę relacyjną, np. PostgreSQL: schemat, transakcje, złączenia. NoSQL sprawdza się przy elastycznej strukturze, bardzo dużej liczbie zapisów albo jako cache. W większości projektów zaczynam od bazy relacyjnej, a inne magazyny dokładam przy konkretnej potrzebie.
Co sprawdza rekruter: Czy decyzje techniczne uzasadniasz potrzebami projektu, a nie modą.
Jak wygląda u Pana/Pani code review?
Przykładowa odpowiedź
Wystawiam małe pull requesty z opisem, co i dlaczego się zmienia. W cudzym kodzie patrzę na logikę, czytelność, bezpieczeństwo i testy, a formatowanie zostawiam linterowi. Komentarze formułuję jako pytania albo propozycje. Uwagi do mojego kodu traktuję jako sposób na lepsze rozwiązanie, nie jako krytykę.
Co sprawdza rekruter: Współpracę w zespole i to, czy przyjmujesz uwagi bez obrony za wszelką cenę.
Co Pan/Pani robi, gdy w zadaniu na żywo nie zna odpowiedzi?
Przykładowa odpowiedź
Mówię na głos, co rozumiem z polecenia, i dopytuję o warunki brzegowe. Zaczynam od najprostszego działającego rozwiązania, potem je poprawiam. Jeśli nie pamiętam nazwy funkcji z biblioteki, mówię wprost, czego trzeba szukać w dokumentacji, i idę dalej.
Co sprawdza rekruter: Sposób myślenia i komunikację pod presją. Cisza przez 10 minut wypada gorzej niż niedokończone, ale omówione rozwiązanie.
Jak się przygotować
- Przejrzyj technologie z ogłoszenia i przygotuj do każdej jeden przykład z własnego projektu.
- Przećwicz na głos 2-3 zadania algorytmiczne, komentując każdy krok.
- Otwórz przed rozmową swoje repozytorium lub portfolio i przypomnij sobie decyzje, które w nim podjęto.
- Odśwież podstawy: HTTP, bazy danych, Git, testy, złożoność.
O co zapytać rekrutera
- Jak wygląda droga zmiany od pull requesta do produkcji?
- Ile czasu zespół poświęca na dług techniczny?
- Jak wygląda wdrożenie nowej osoby w pierwszym miesiącu?