Poniżej zebraliśmy pytania, które typowo padają na rozmowie o pracę programisty, niezależnie od języka programowania, z przykładami odpowiedzi przygotowanymi przez redakcję. Pytania zgłoszone przez kandydatów z konkretnych firm, w tym zadania techniczne, pojawiają się pod artykułem i w profilach pracodawców w bazie rekrutacji firm.
Jak zwykle wygląda rekrutacja na programistę
Rekrutacja w IT ma zwykle trzy lub cztery etapy. Zaczyna się od krótkiej rozmowy z rekruterem o doświadczeniu i oczekiwaniach, potem jest etap techniczny: zadanie do zrobienia w domu, test online albo programowanie na żywo z udostępnionym ekranem. Następnie odbywa się rozmowa techniczna z członkami zespołu, a na koniec spotkanie z kierownikiem zespołu lub osobą odpowiedzialną za produkt. Cały proces trwa najczęściej od dwóch do pięciu tygodni.
Zadanie domowe zajmuje zwykle od kilku godzin do jednego dnia pracy. Rozmowa techniczna trwa przeważnie 60 do 90 minut. Coraz więcej rozmów odbywa się zdalnie, dlatego warto przeczytać nasz poradnik o rozmowie online.
| Etap | Co sprawdza rekruter | Jak się przygotować |
|---|---|---|
| Rozmowa z rekruterem | Doświadczenie, technologie, oczekiwania, dostępność | Przygotuj dwa zdania o każdym projekcie z CV |
| Zadanie lub test | Jakość kodu, testy, czytelność, czas | Zadbaj o opis uruchomienia i krótkie uzasadnienie decyzji |
| Programowanie na żywo | Sposób myślenia, komunikacja przy problemie | Mów na głos, co robisz, i zadawaj pytania o wymagania |
| Rozmowa techniczna | Architektura, debugowanie, dobre praktyki | Powtórz podstawy i przemyśl swoje błędy z projektów |
| Rozmowa z kierownikiem | Współpraca, samodzielność, motywacja | Przygotuj pytania o zespół, proces i produkt |
O tym, jak podejść do zadań domowych, piszemy w artykule o zadaniu rekrutacyjnym.
Pytania, które padają najczęściej
Opowiesz o projekcie, z którego jesteś najbardziej zadowolony?
Co sprawdza rekruter. Twoją rolę w projekcie, zrozumienie celu biznesowego i decyzji technicznych.
Przykład odpowiedzi. W ostatniej firmie przepisałem moduł raportów, który generował się kilka minut. Przeniosłem obliczenia do zapytań w bazie i dodałem pamięć podręczną, więc raporty zaczęły ładować się w kilka sekund. Najwięcej nauczyłem się przy rozmowach z działem sprzedaży, który z tych raportów korzystał.
Jak dbasz o jakość kodu?
Co sprawdza rekruter. Nawyki: testy, przegląd kodu, czytelność.
Przykład odpowiedzi. Piszę testy do logiki biznesowej i do błędów, które naprawiam, żeby nie wróciły. Dzielę zmiany na małe, czytelne porcje, łatwe do przejrzenia. W przeglądach kodu skupiam się na zrozumiałości, a nie na stylu, który powinien pilnować automatyczny formatter.
Jak szukasz błędu, którego nie umiesz odtworzyć?
Co sprawdza rekruter. Metodę debugowania i cierpliwość.
Przykład odpowiedzi. Zaczynam od logów i danych zgłoszenia: kiedy, u kogo, przy jakich danych wejściowych. Próbuję zawęzić warunki i odtworzyć je lokalnie albo na środowisku testowym. Gdy to się nie udaje, dodaję szczegółowe logowanie w podejrzanym miejscu i czekam na kolejne wystąpienie.
Czym różni się tablica od listy powiązanej?
Co sprawdza rekruter. Znajomość podstaw struktur danych i złożoności.
Przykład odpowiedzi. Tablica przechowuje elementy obok siebie w pamięci, więc dostęp po indeksie jest natychmiastowy, ale wstawianie w środku wymaga przesunięcia elementów. Lista powiązana pozwala szybko wstawiać i usuwać elementy, gdy mam wskaźnik na miejsce, ale dostęp do konkretnego elementu wymaga przejścia po liście.
Jak zaprojektujesz prosty serwis do skracania linków?
Co sprawdza rekruter. Myślenie o architekturze, skali i kompromisach.
Przykład odpowiedzi. Najpierw dopytam o skalę i wymagania, na przykład czy linki mają wygasać. Potrzebuję tabeli z krótkim kodem i adresem docelowym, generowania unikalnego kodu i szybkiego przekierowania z pamięcią podręczną dla popularnych linków. Przy dużym ruchu oddzielę zapis od odczytu i dodam ograniczenie liczby zapytań.
Co robisz, gdy nie zgadzasz się z decyzją techniczną zespołu?
Co sprawdza rekruter. Współpracę i umiejętność rzeczowej dyskusji.
Przykład odpowiedzi. Przedstawiam swoje argumenty z konkretnym przykładem albo krótkim prototypem. Jeśli zespół wybiera inne rozwiązanie, wdrażam je bez oporu i zapisuję wątpliwości w opisie zadania. Po wdrożeniu chętnie wracam do tematu, jeśli dane pokażą problem.
Jak oceniasz czas potrzebny na zadanie?
Co sprawdza rekruter. Realizm i komunikację z zespołem.
Przykład odpowiedzi. Dzielę zadanie na mniejsze kroki i każdy szacuję osobno. Dodaję zapas na niewiadome, zwłaszcza przy integracji z obcym kodem. Gdy w trakcie widzę, że szacunek się nie sprawdzi, informuję o tym od razu, a nie w dniu terminu.
Jakie testy piszesz i dlaczego?
Co sprawdza rekruter. Rozumienie różnych rodzajów testów i ich kosztu.
Przykład odpowiedzi. Najwięcej piszę testów jednostkowych do logiki, bo są szybkie. Dla kluczowych ścieżek, na przykład płatności czy rejestracji, dodaję testy integracyjne, które sprawdzają działanie razem z bazą. Testów przez interfejs piszę niewiele, tylko dla najważniejszych scenariuszy.
Opowiesz o błędzie, który trafił na produkcję przez ciebie?
Co sprawdza rekruter. Odpowiedzialność i to, czego się nauczyłeś.
Przykład odpowiedzi. Wdrożyłem migrację bazy, która na dużej tabeli zablokowała zapis na kilka minut. Wycofałem zmianę, a potem przygotowałem migrację w kilku krokach, bez blokowania tabeli. Od tego czasu każdą migrację sprawdzam na kopii danych o realnej wielkości.
Jak uczysz się nowych technologii?
Co sprawdza rekruter. Samodzielność i sposób rozwoju.
Przykład odpowiedzi. Zaczynam od dokumentacji i małego projektu, w którym używam nowej technologii do konkretnego problemu. Czytam kod przykładowych projektów i notuję różnice w porównaniu z tym, co znam. Najszybciej uczę się w pracy, przy prawdziwym zadaniu pod okiem bardziej doświadczonej osoby.
Jak wygląda u ciebie praca z systemem kontroli wersji?
Co sprawdza rekruter. Praktyczne nawyki w pracy zespołowej.
Przykład odpowiedzi. Pracuję na osobnych gałęziach dla zadań i często aktualizuję je względem głównej. Piszę opisowe wiadomości przy zmianach, żeby po miesiącu było wiadomo, dlaczego coś zmieniłem. Konflikty rozwiązuję razem z autorem drugiej zmiany, gdy nie jestem pewien jego intencji.
Dlaczego chcesz zmienić pracę?
Co sprawdza rekruter. Motywację i dopasowanie do zespołu.
Przykład odpowiedzi. W obecnym projekcie od roku głównie utrzymuję stary system. Chcę pracować przy produkcie, który się rozwija, i mieć wpływ na decyzje techniczne. Wasza oferta i opis zespołu pasują do tego, czego szukam.
Jakie masz oczekiwania finansowe?
Co sprawdza rekruter. Czy oczekiwania pasują do poziomu stanowiska i formy współpracy.
Przykład odpowiedzi. Moje oczekiwania podaję w widełkach dla umowy o pracę i osobno dla współpracy kontraktowej, bo to różne kwoty. Zależą też od zakresu obowiązków i pracy zdalnej. Chętnie poznam widełki przewidziane dla tego stanowiska.
Pytania, które warto zadać pracodawcy
Rozmowa techniczna to też twoja szansa, żeby sprawdzić zespół. Dobre pytania pokazują dojrzałość. Jeśli myślisz o pracy w produkcie bliżej marketingu, zobacz też pytania na specjalistę marketingu.
- Jak wygląda proces od zadania do wdrożenia na produkcję?
- Ile czasu zespół poświęca na dług techniczny?
- Jak często są dyżury i jak wygląda reakcja na awarię?
- Jak wygląda wdrożenie nowej osoby w pierwszym miesiącu?
- Kto podejmuje decyzje o architekturze?
Najczęstsze pytania
Czy na rozmowie na programistę zawsze jest zadanie techniczne?
Prawie zawsze pojawia się jakaś forma sprawdzenia umiejętności: zadanie domowe, test online, programowanie na żywo albo rozmowa o kodzie z poprzednich projektów.
Ile trwa rekrutacja na programistę?
Najczęściej od dwóch do pięciu tygodni. Na stanowiska starsze proces bywa dłuższy, bo obejmuje więcej rozmów technicznych.
Co zrobić, gdy nie znam odpowiedzi na pytanie techniczne?
Powiedz to wprost i pokaż, jak doszedłbyś do rozwiązania. Rekruter ceni sposób myślenia i szczerość bardziej niż zgadywanie.
Czy trzeba znać algorytmy na pamięć?
Nie na pamięć, ale warto rozumieć podstawowe struktury danych i złożoność. W wielu firmach liczy się bardziej praktyczne myślenie o kodzie niż zadania algorytmiczne.