Rozmowa techniczna na staż w IT - Co naprawdę sprawdza rekruter?

Rozmowa techniczna na staż bywa mniej egzaminem z encyklopedycznej wiedzy, a bardziej sprawdzianem tego, czy potrafisz myśleć logicznie, tłumaczyć decyzje i nie gubić się, gdy ktoś dopyta o podstawy. Poniżej pokazuję, jak przygotować się do rozmowy technicznej na staż w IT: co naprawdę sprawdza rekruter, jak ułożyć sensowny plan nauki, jak odpowiadać na pytania i jak uniknąć błędów, które najczęściej psują dobre pierwsze wrażenie.

Co naprawdę sprawdza rozmowa techniczna na staż

Na poziomie stażowym rozmowa techniczna rzadko ma sprawdzić, czy znasz zaawansowane wzorce projektowe albo potrafisz rozwiązać trudny algorytm z pamięci. Z mojego doświadczenia częściej chodzi o trzy rzeczy: czy rozumiesz podstawy, czy umiesz logicznie dochodzić do rozwiązania i czy potrafisz mówić o swojej pracy bez chaosu.

W praktyce rekruter patrzy też na to, czy nie wpadasz w panikę przy prostych dopytaniach. Początkujący kandydat często myśli, że musi umieć wszystko, a to nie jest prawda. Lepiej wypada osoba, która wie, czego jeszcze nie wie, umie to nazwać i potrafi powiedzieć, jak by to sprawdziła.

Jeśli aplikujesz na front-end, większą wagę mogą mieć JavaScript, DOM, podstawy Reacta i praca z API. W backendzie częściej wracają HTTP, SQL, REST, debugowanie i podstawy bezpieczeństwa. Niezależnie od specjalizacji liczy się jednak ten sam fundament: czy potrafisz porządkować myślenie i wyciągać wnioski z prostych przykładów.

Jeśli to dobrze zrozumiesz, przestaniesz traktować rozmowę jak egzamin z encyklopedii. Następny krok to plan przygotowań, który nie rozjedzie Ci całego tygodnia.

Plan przygotowań, który nie przytłacza

Najgorszy plan to ten, który wygląda ambitnie na papierze, a po dwóch dniach przestaje istnieć. Lepiej rozłożyć pracę na krótkie, konkretne bloki: po 45-60 minut dziennie przez 5-7 dni zwykle daje lepszy efekt niż jeden długi zryw w niedzielę.

• Dzień 1 - przejrzyj ofertę, stack technologiczny i wymagania; wypisz 5 tematów, które najpewniej padną.
• Dzień 2 - powtórz fundamenty języka i narzędzi: zmienne, funkcje, tablice, obiekty, Git, podstawy terminala.
• Dzień 3 - skup się na technologii związanej z rolą, na przykład HTTP, SQL, DOM albo podstawach testów.
• Dzień 4 - opowiedz na głos o jednym projekcie od A do Z, najlepiej bez zaglądania do notatek.
• Dzień 5 - zrób próbę rozmowy z kimś znajomym albo sam nagraj odpowiedzi na telefon.
• Jeśli masz tylko 2 dni - priorytetem są fundamenty, projekt, pytania do firmy i jedna próbna symulacja.

Jeśli masz więcej czasu, przejdź taki cykl dwa razy i za każdym razem skracaj notatki do coraz prostszej wersji. To ważne, bo na rozmowie nie masz czasu szukać odpowiedzi w głowie; masz ją podać sprawnie i po ludzku. A skoro plan jest już ustawiony, warto przejść do pytań, które padają najczęściej.

Jakie pytania padają najczęściej i jak na nie odpowiadać

Na rozmowach dla początkujących pytania zwykle krążą wokół fundamentów i sposobu myślenia, a nie wokół najtrudniejszych tematów z produkcyjnych systemów. Chodzi o sprawdzenie, czy potrafisz wytłumaczyć proste pojęcia i nie gubisz się, kiedy rozmowa schodzi z poziomu teorii na praktykę.

Pytania o podstawy

Możesz usłyszeć rzeczy typu: czym różni się tablica od listy, co robi git pull, do czego służy GET i POST, czym jest zmienna, funkcja albo pętla. Nie chodzi o definicję z podręcznika, tylko o krótką, jasną odpowiedź z przykładem. Jeśli umiesz powiedzieć: „GET pobiera dane, a POST zwykle wysyła nowe dane do serwera”, to już jest odpowiedni poziom na wiele staży.

Pytania o projekt

Tu najczęściej pada: co zrobiłeś, dlaczego wybrałeś akurat to rozwiązanie, co było trudne i co zrobiłbyś inaczej. Zamiast opowiadać wszystkiego po kolei, wybierz 2-3 decyzje, które naprawdę coś pokazują. Dobrze działa prosta struktura: problem, rozwiązanie, efekt, ograniczenie. To brzmi naturalnie i pozwala rekruterowi szybko zobaczyć, czy rozumiesz własny projekt.

Przeczytaj również: Czy po stażu trzeba zatrudnić? Poznaj prawne obowiązki pracodawcy

Pytania sytuacyjne

Na przykład: co zrobisz, jeśli coś nie działa, jak sprawdzisz błąd albo skąd weźmiesz brakującą wiedzę. Na takie pytania nie ma jednej poprawnej odpowiedzi. Ja zawsze doradzam tę samą rzecz: mów głośno, jak myślisz, i nie udawaj, że znasz rozwiązanie, jeśli go nie znasz. O wiele lepiej brzmi: „sprawdziłbym logi, odtworzył problem i porównał zachowanie z dokumentacją”, niż strzelanie na chybił trafił.

W praktyce najlepiej wypadają odpowiedzi, które pokazują tok myślenia, nie tylko końcowy wynik. Jeśli zrobisz to dobrze, rozmowa przestanie przypominać test pamięci, a zacznie wyglądać jak sensowna rozmowa o pracy. Kolejny krok to przećwiczenie tego w praktyce, bo teoria bez głosu zwykle rozpada się przy pierwszym dopytaniu.

Jak przećwiczyć kodowanie i opowiedzieć o projekcie

Jeśli rekrutacja zawiera zadanie domowe albo mini-projekt, przygotuj się do rozmowy tak, jakbyś miał tłumaczyć własny kod koledze z zespołu. Zacznij od struktury folderów, potem pokaż najważniejszy fragment i dopiero na końcu wejdź w detale. To lepsze niż skakanie po plikach bez ładu.

1. Opisz cel projektu w 1-2 zdaniach.
2. Pokaż decyzje techniczne: framework, biblioteka, sposób przechowywania danych.
3. Powiedz, co poszło trudno i jak to debugowałeś.
4. Wskaż jeden kompromis, na przykład prostsze rozwiązanie zamiast „idealnego”.
5. Na końcu dodaj, co poprawiłbyś przy kolejnym podejściu.

Warto też przećwiczyć małe zadanie na tablicy albo w edytorze bez autouzupełniania. Nie po to, by symulować stres za wszelką cenę, tylko żeby sprawdzić, czy potrafisz myśleć krok po kroku, kiedy nikt nie podpowiada składni. Jeśli dostaniesz pytanie o złożoność czasową, wystarczy podstawowe rozumienie, czyli czy rozwiązanie rośnie liniowo, kwadratowo czy stałym kosztem wraz z ilością danych.

Jeżeli masz tylko szkolny albo własny projekt, to też jest w porządku. Ważniejsze jest nie to, jak „duży” był, ale czy umiesz obronić swoje decyzje i uczciwie opowiedzieć, czego się przy nim nauczyłeś. To właśnie odróżnia sensowne przygotowanie od mechanicznego wkuwania.

Po takim ćwiczeniu łatwiej zauważysz też błędy, które najczęściej psują wynik, nawet gdy wiedza sama w sobie nie jest zła.

Najczęstsze błędy kandydatów na staż

Najczęściej problemy zaczynają się nie od braku wiedzy, tylko od sposobu jej pokazania.

• Uczenie się definicji bez kontekstu - brzmi dobrze w głowie, ale rozsypuje się przy dopytaniu.
• Za długie odpowiedzi - jeśli mówisz trzy minuty o prostym pytaniu, rekruter traci wątek.
• Uciekanie od „nie wiem” - lepiej powiedzieć, czego nie pamiętasz, i dodać, jak byś to sprawdził.
• Nieznajomość własnego projektu - nawet prosty projekt trzeba umieć obronić decyzjami i ograniczeniami.
• Brak pytań do firmy - to sygnał, że kandydat idzie w ciemno.
• Przesadny perfekcjonizm - na stażu liczy się postęp i gotowość do nauki, nie udawanie seniora.

Ja zwykle patrzę na to tak: rozmowa dla początkującego ma pokazać potencjał, a nie bezbłędność. Jeśli ten potencjał widać, błędy są dużo łatwiejsze do wybaczenia. Zostaje już tylko domknięcie organizacyjne, bo ono potrafi zaskoczyć bardziej niż same pytania.

Dzień przed rozmową i w dniu spotkania

Dzień przed rozmową zrobiłbym trzy rzeczy: przypomniał sobie ofertę, przejrzał własne notatki i sprawdził sprzęt. To wystarczy, żeby nie marnować energii na drobiazgi w ostatniej chwili.

• Sprawdź technikalia - kamera, mikrofon, internet, ładowarka, słuchawki i link do spotkania.
• Przygotuj dokumenty - CV, portfolio, repozytorium, opis projektu i ewentualne zadanie domowe.
• Powtórz autoprezentację - 60-90 sekund o tym, kim jesteś, czego się uczysz i czego szukasz.
• Zrób krótką próbę odpowiedzi - najlepiej na głos, nie tylko w głowie.
• Wyśpij się - zmęczenie naprawdę obniża tempo myślenia i pewność wypowiedzi.

W dniu spotkania przyjdź kilka minut wcześniej, miej pod ręką wodę i notatki, ale nie czytaj z nich jak z kartki. Jeśli rozmowa jest zdalna i coś się psuje, powiedz to od razu spokojnie - techniczny problem jest normalny, chaos organizacyjny już nie. Po takim przygotowaniu łatwiej wejść w rozmowę bez napięcia.

Co zrobić po rozmowie, żeby kolejną przejść pewniej

Po rozmowie nie zamykam tematu od razu. Zapisuję pytania, na których się potknąłem, i te, które poszły dobrze, bo z jednych i drugich da się wyciągnąć konkretne wnioski.

• Spisz pytania i luki - nawet pięć punktów wystarczy, żeby zobaczyć, czego brakuje.
• Uzupełnij jeden obszar - na przykład SQL, Git, HTTP albo opowiadanie o projekcie.
• Porównaj kilka rozmów - szybko zobaczysz, które pytania wracają najczęściej.
• Poproś o feedback - jeśli firma go daje, skorzystaj z niego bez obrony i tłumaczenia się.

To podejście działa lepiej niż przypadkowe dokształcanie się po omacku. Każda kolejna rozmowa staje się wtedy nie testem szczęścia, tylko coraz lepiej opanowanym procesem, a właśnie tego potrzebuje ktoś, kto startuje w IT i chce wejść na staż z większym spokojem.