Cel rozmowy technicznej: co tak naprawdę jest sprawdzane
Techniczna rozmowa to nie egzamin z książki
Rozmowa techniczna w IT rzadko polega na mechanicznym odtwarzaniu definicji. Dobrze przygotowany rekruter sprawdza przede wszystkim sposób myślenia, umiejętność rozwiązywania problemów i komunikację. Twarde umiejętności techniczne są oczywiście istotne, ale są tylko częścią układanki.
Techniczny interviewer chce zobaczyć, jak poradzisz sobie z sytuacją, gdy:
masz niepełne wymagania i musisz dopytać o szczegóły,
twój pierwszy pomysł nie działa i trzeba go zmodyfikować,
pojawia się ograniczenie – czasu, pamięci, technologii – i trzeba pójść na kompromis,
musisz wytłumaczyć swój kod lub decyzję komuś innemu.
Osoba po drugiej stronie nie szuka „encyklopedii IT”. Szuka kogoś, z kim będzie dało się efektywnie pracować na produkcyjnym kodzie, pod presją czasu i przy ograniczonych informacjach.
Najpopularniejsze formaty rozmów technicznych
Różne firmy stosują różne kombinacje formatów. Każdy z nich eksponuje inne błędy kandydata i wymaga trochę innego przygotowania.
Screening techniczny – krótka rozmowa (często online) z inżynierem lub technicznym rekruterem. Sprawdzane są podstawy: znajomość technologii z CV, doświadczenie projektowe, ogólne rozumienie zagadnień (np. HTTP, bazy danych, git). Błędy na tym etapie to najczęściej chaos w odpowiedziach i słaba znajomość własnych projektów.
Live coding – rozwiązywanie zadania programistycznego na żywo (w edytorze, czasem w środowisku firmy). Celem jest poznanie twojego procesu: jak analizujesz problem, jak piszesz kod, jak testujesz i poprawiasz błędy. Tu najszybciej wychodzi brak głośnego myślenia i stres związany z „pisaniem pod publikę”.
Whiteboard interview / tablica – projektowanie algorytmu lub fragmentu systemu na tablicy albo wirtualnym odpowiedniku. Rzadziej chodzi o idealną składnię, częściej o strukturę rozwiązania, złożoność i uzasadnienie wyborów.
System design / architektura – rozmowa o projektowaniu większego systemu: API, system rekomendacji, system logowania, kolejkę zadań, monitoring. Tutaj liczy się umiejętność uproszczenia problemu, zidentyfikowania kluczowych wymagań i rozsądnych trade-offów (kompromisów).
Code review – analizujesz istniejący kod i mówisz, co jest nie tak, co można poprawić, jakie będą konsekwencje zmian. Ten format pokazuje dojrzałość techniczną i praktyczne podejście do jakości kodu.
Zadania domowe – projekt do wykonania w domu, wysyłany do oceny. Tu wychodzą na wierzch inne błędy: brak testów, chaotyczna struktura repozytorium, słaby README, ignorowanie wymagań z opisu zadania.
Junior, mid, senior – różne oczekiwania, inne pułapki
Poziom stanowiska mocno zmienia to, jak rekruter interpretuje twoje odpowiedzi. Te same słabości mogą być dla juniora „do przeżycia”, a dla seniora – czerwonym alarmem.
Junior – sprawdzane są podstawy: rozumienie fundamentów języka, prostych struktur danych, podstawowych wzorców pracy (git, testy, debugowanie). Duży nacisk kładziony jest na potencjał do nauki: jak przyjmujesz feedback, jak myślisz na głos, czy nie boisz się przyznać do niewiedzy. Najgroźniejszy błąd na tym poziomie to udawanie eksperta.
Mid – oczekuje się samodzielności przy typowych problemach. Kandydat mid powinien umieć podjąć sensowną decyzję techniczną, uzasadnić ją, ogarnąć task od A do Z. Błędy, które często ich dyskwalifikują, to brak świadomości złożoności, ignorowanie kwestii wydajności czy jakości kodu oraz zbyt wąskie myślenie (tylko w kontekście jednego pliku, nie całego modułu).
Senior – tutaj rozmowa techniczna mocno zahacza o architekturę, skalowanie, bezpieczeństwo, praktyki zespołowe. Senior musi umieć zaprojektować rozwiązanie „end to end”, wytłumaczyć je i obronić. Najpoważniejsze błędy: brak umiejętności priorytetyzacji wymagań, rzucanie buzzwordami bez zrozumienia oraz brak odpowiedzialności za decyzje (zrzucanie wszystkiego na „architekta” czy „zespół”).
Skąd biorą się „dziwne” pytania
Wiele osób frustrują pytania, które wydają się oderwane od codziennej pracy: implementacja drzewa, dziwna zagadka logiczna, pytanie o szczegóły GC, których nie dotykasz na co dzień. Część z nich jest po prostu słabo dobrana przez firmę. Ale spora grupa takich pytań ma swój sens.
jak reagujesz na problem, którego nie znasz z tutoriala,
czy umiesz uprościć zadanie i wyciągnąć z niego istotę,
jak radzisz sobie ze stresem i presją czasu,
czy nie blokujesz się, gdy nie ma „idealnego” kontekstu z realnego projektu.
Zamiast oburzać się na jakość pytania, lepiej zadać sobie pytanie: co próbuje zobaczyć osoba po drugiej stronie i jak mogę jej to ułatwić?. Ta zmiana perspektywy mocno redukuje stres i ogranicza liczbę błędów popełnianych pod wpływem emocji.
Szkodliwe mity o rozmowie technicznej, które utrudniają przygotowanie
Mit: „Wystarczy wykuć odpowiedzi z LeetCode’a i blogów”
LeetCode i podobne serwisy są przydatne, ale traktowanie ich jako jedynego źródła przygotowania to klasyczny przepis na rozczarowanie. Rozmowa techniczna w praktyce zawiera zwykle:
pytania o konkretne technologie z twojego CV,
dyskusję o projektach, które robiłeś,
zadanie algorytmiczne albo zadanie zbliżone do realnych problemów biznesowych,
pytania o architekturę i decyzje projektowe (szczególnie na poziomie mid/senior).
„Wykute” rozwiązania zadań algorytmicznych pomagają, ale nie zastąpią rozumienia mechanizmów. Dobry interviewer szybko odróżni kogoś, kto rozumie złożoność czasową, strukturę danych i potrafi dostosować podejście, od osoby, która „na pamięć” klepie znane wzorce.
Mit: „Juniorom wszystko wolno, ważny jest zapał”
Wielu początkujących zakłada, że sam entuzjazm i „chęć nauki” wystarczą, a brak wiedzy zostanie w całości wybaczony. Rzeczywistość jest mniej romantyczna. Owszem, juniorowi wybacza się mniej doświadczenia, ale:
oczekuje się dobrego opanowania podstaw (np. pętle, kolekcje, wyjątki, podstawowy SQL, git),
sprawdza się, czy faktycznie uczyłeś się samodzielnie i potrafisz połączyć fakty,
sprawdza się, czy potrafisz mówić o tym, czego nie wiesz, bez ściemniania.
Mit „wszystko wybaczą” prowadzi do niechlujnego przygotowania: kandydat nie powtarza podstaw, nie robi kilka razy małych projektów, nie trenuje rozmowy o własnym CV. Potem pada na banalnym pytaniu o różnicę między tablicą a listą czy o to, jak zdebugował ostatni bug.
Mit: „Jak nie odpowiem idealnie, to po wszystkim”
Perfekcjonizm jest jedną z głównych przyczyn paraliżu na rozmowie technicznej. Kandydat myśli: „Albo od razu powiem idealnie, albo lepiej nic nie mówić, żeby się nie skompromitować”. To prosta droga do zacięć, długich pauz i odpowiedzi „nie wiem” nawet tam, gdzie coś potrafisz wyprowadzić logicznie.
Na większości rozmów technicznych liczy się proces, a nie to, czy od razu trafisz w „klucz odpowiedzi”. Rekruter wie, że działasz bez Google’a, Stack Overflow i IDE. Dlatego:
drobną pomyłkę można skorygować,
półpoprawną odpowiedź można poprawić poprzez dodatkowe pytania,
brak znajomości szczegółu można nadrobić dobrym rozumieniem mechanizmu.
Odpowiedź idealna, ale wymuszona po 2 minutach milczenia, robi gorsze wrażenie niż szczere „nie jestem pewien, jak to dokładnie wygląda, ale rozumiem ogólny mechanizm…”.
Mit: „Muszę udawać, że wiem wszystko”
Udawanie wszechwiedzy jest jednym z najdroższych błędów reputacyjnych. Z technicznym rekruterem trudno wygrać „na blefie”. Jeśli próbujesz improwizować odpowiedź z dziedziny, której nie znasz, zwykle kończy się to serią dodatkowych pytań, po których wychodzi, że brniesz na siłę.
Doświadczeni interviewerzy są wyczuleni na takie sygnały:
używanie wielu ogólników zamiast konkretów („tam jakoś to się buforuje”),
mieszanie pojęć z różnych obszarów (np. mylenie load balancera z reverse proxy),
brak umiejętności podania prostego przykładu, choć używasz skomplikowanych słów,
unikanie doprecyzowania pytania, żeby nie wyszło, że czegoś nie rozumiesz.
Konsekwencje ściemniania są poważniejsze niż zwykłe „nie wiem”. Pojawia się brak zaufania: jeśli teraz fibrujesz przy drobnostkach, co zrobisz, gdy pójdziesz na produkcję? Dla wielu firm to natychmiastowa dyskwalifikacja, niezależnie od innych mocnych stron.
Jak mity zaburzają przygotowanie
Wierzenie w powyższe mity prowadzi do złego ustawienia priorytetów podczas przygotowania do rozmowy technicznej:
godziny nad „top 100 LeetCode” zamiast przerobienia własnych projektów i kodu z CV,
lekceważenie podstaw języka / frameworka, bo „to się przecież klika na co dzień”,
brak ćwiczeń mówienia na głos o kodzie, architekturze i decyzjach projektowych,
ignorowanie miękkich aspektów rozmowy: parafrazowanie pytania, dopytywanie, przyznawanie się do niewiedzy.
Skuteczniejsze podejście to: mocne fundamenty + rozumienie swoich doświadczeń + trening komunikacji technicznej. Dopiero na tym fundamencie zadania algorytmiczne i listy pytań z blogów mają realną wartość.
Błąd nr 1 – Chaos w odpowiedziach na pytania techniczne
Jak wygląda brak struktury w praktyce
Najczęstszy problem to odpowiedzi przypominające strumień świadomości. Kandydat słyszy pytanie, np. „Czym różni się REST od GraphQL?” i zaczyna:
„No generalnie REST to taki styl w sumie, że tam jest HTTP i mamy metody GET, POST, a GraphQL to jest coś innego, bo tam się body wysyła i w sumie jest szybciej, szczególnie w frontendzie, bo mniej requestów i to w sumie zależy, ogólnie to my w projekcie używaliśmy REST-a, ale myśleliśmy o GraphQL…”.
Taka odpowiedź ma kilka problemów:
brak jasnego początku – rekruter nie dostaje krótkiej definicji,
skakanie po przykładach bez zaznaczenia, dlaczego są istotne,
brak puenty – po minucie mówienia nadal nie wiadomo, czy rozumiesz sedno różnicy.
Jak rekruter techniczny ocenia odpowiedź
Osoba prowadząca rozmowę nie szuka wyłącznie poprawnej definicji. Ocenia kilka rzeczy naraz:
Tok rozumowania – czy układasz odpowiedź logicznie, od ogółu do szczegółu,
Priorytety – czy wyciągasz na wierzch to, co w danym pytaniu najważniejsze,
Świadomość ograniczeń – czy potrafisz wskazać, kiedy dane podejście nie zadziała,
Umiejętność podsumowania – czy potrafisz zamknąć wypowiedź jednoznaczną konkluzją.
Gdy odpowiedź jest chaotyczna, rekruter często musi zastanawiać się, czy problemem jest brak wiedzy, czy tylko brak umiejętności jej uporządkowania. Dla wielu firm to za duże ryzyko, szczególnie na poziomie mid/senior.
Struktura odpowiedzi na pytanie teoretyczne
Prosty, ale skuteczny schemat:
Definicja w jednym–dwóch zdaniach – co to jest, jaka jest główna idea.
Krótki przykład – najlepiej zahaczający o praktykę.
Ograniczenia / trade-offy – kiedy to działa dobrze, a kiedy nie.
Przykład: pytanie „Czym różni się REST od GraphQL?”
Możliwa odpowiedź uporządkowana:
„REST to styl komunikacji oparty na zasobach, gdzie każdy endpoint reprezentuje konkretny zasób, a operacje wykonuje się za pomocą standardowych metod HTTP (GET, POST itd.). GraphQL to język zapytań do API, w którym klient sam określa strukturę odpowiedzi.
Przykładowa odpowiedź krok po kroku
Rozpisując poprzedni przykład zgodnie ze schematem, możesz powiedzieć:
Definicja:
„REST to styl projektowania API oparty na zasobach dostępnych przez standardowe metody HTTP. GraphQL to specyfikacja i język zapytań do API, w którym klient sam definiuje, jakie dane chce otrzymać.”
Przykład z praktyki:
„W REST zwykle mamy kilka endpointów, np. /users/123, /users/123/orders, a każdy zwraca z góry zdefiniowaną strukturę. W GraphQL mamy jeden endpoint, np. /graphql, a klient wysyła zapytanie typu: { user(id: 123) { name orders { id total } } }, dostając dokładnie te pola, o które poprosił.”
Trade-offy:
„REST jest prostszy w integracji i łatwiej go cachować po URL-ach. GraphQL daje dużą elastyczność klientowi i redukuje underfetching/overfetching (za mało / za dużo danych), ale jest trudniejszy w cachowaniu i wymaga bardziej przemyślanej warstwy backendowej.”
Taka odpowiedź pokazuje, że rozumiesz pojęcia, odwołujesz się do kodu/prawdziwych endpointów i widzisz plusy oraz minusy – bez zbędnego ględzenia.
Jak ćwiczyć strukturę przed rozmową
Zamiast czytać dziesiątą listę pytań, lepiej wziąć pięć–dziesięć zagadnień z własnego CV i na każde odpowiedzieć na głos według schematu: definicja → przykład → ograniczenia. Przykładowe tematy:
„Garbage collector w JVM – po co jest i jak działa w uproszczeniu?”
„Różnica między LEFT JOIN a INNER JOIN w SQL.”
„Po co stosuje się dependency injection w Springu / Angularze?”
„CQRS – co to jest i kiedy ma sens?”
Tip: nagraj 2–3 odpowiedzi telefonem. Odsłuchanie siebie na chłodno bardzo szybko ujawnia:
czy wchodzisz w dygresje po 10 sekundach,
czy na końcu jest jedno zdanie, które faktycznie zamyka odpowiedź,
czy nie uciekasz w żargon bez przykładów.
Błąd nr 2 – Zbyt agresywne lub zbyt uległe „nie wiem”
Dwa skrajne style, oba szkodliwe
„Nie wiem” samo w sobie nie jest problemem. Problemem jest to, jak je komunikujesz. W praktyce widać najczęściej dwa ekstremalne style:
Agresywne „nie wiem” – podane z frustracją lub oburzeniem, często z podtekstem „to głupie pytanie”,
Uległe „nie wiem” – wypowiadane z automatu, przy byle trudniejszym pytaniu, bez próby podejścia do tematu.
Obie wersje wysyłają bardzo nieciekawe sygnały o tym, jak będziesz działać w zespole i na produkcji.
Jak wygląda agresywne „nie wiem”
Przykładowe reakcje:
„Nie wiem, nigdy tego nie używałem i raczej nie będę, bo to jest bez sensu.”
„Nie wiem, my od tego mamy DevOpsów / architektów / seniorów.”
„Nie wiem, nikt normalny tego nie pamięta z głowy.”
Uwaga: czasem ton głosu i mowa ciała robią więcej szkody niż same słowa. Nawet neutralne „nie wiem” wypowiedziane z przewróceniem oczu lub nerwowym śmiechem wygląda słabo.
Z punktu widzenia rekrutera takie zachowanie może znaczyć:
trudno będzie z tobą rozmawiać o rzeczach, których nie znasz,
bronisz ego zamiast szukać rozwiązania,
możesz przerzucać odpowiedzialność na innych („to nie moja działka”).
Jak wygląda uległe „nie wiem”
Drugi biegun to kandydat, który przy niemal każdym trudniejszym pytaniu od razu się wycofuje:
„Nie wiem, chyba nie umiem tego wytłumaczyć.”
„Nie wiem, nie kojarzę, przejdźmy dalej.”
„Nie wiem, nigdy tego nie robiłem, więc nie ma sensu żebym zgadywał.”
Po kilku takich odpowiedziach rekruter nie ma z czym pracować. Nawet jeśli teoretycznie coś wiesz, nie pokazujesz procesu myślenia. Tworzysz obraz osoby, która łatwo się poddaje i boi się pomyłki bardziej niż braku odpowiedzi.
Zdrowe „nie wiem” – jak je formułować
Najbezpieczniejsza wersja „nie wiem” ma trzy elementy:
jasne przyznanie się – bez kręcenia i bez usprawiedliwień,
zakotwiczenie w tym, co jednak wiesz – powiązanie z podobnym zagadnieniem,
propozycja kierunku – jak byś to sprawdził lub jak próbowałbyś podejść do problemu.
Przykłady:
„Szczerze mówiąc, nie znam szczegółów implementacji garbage collectora w Go. Na co dzień pracowałem z JVM, więc mogę powiedzieć, jak działa tam: mamy generacje, minor i major GC… Podejrzewam, że w Go są podobne koncepcje, tylko inaczej zaimplementowane. W realnej sytuacji zacząłbym od dokumentacji runtime’u i ewentualnie profili pamięci.”
„Nie pamiętam dokładnej sygnatury tego polecenia w Dockerze, bo zwykle mam ściągę, ale rozumiem, co musimy osiągnąć: wystawić port, podpiąć wolumen i ustawić zmienne środowiskowe. Mogę opisać, jak by wyglądał docker-compose.yml dla takiego przypadku.”
Taka odpowiedź pokazuje, że nie udajesz, ale jednocześnie nie składasz broni. Dla wielu rekruterów to plus większy niż sucha znajomość polecenia z pamięci.
„Nie wiem”, gdy pytanie jest naprawdę z kosmosu
Zdarza się, że pada pytanie skrajnie niszowe albo spoza twojego poziomu. Zamiast irytacji lepiej pokazać, że potrafisz kulturalnie to obsłużyć:
„To dla mnie obszar dość zaawansowany. Nie miałem jeszcze okazji z tym pracować, więc nie będę improwizował. Mogę natomiast opowiedzieć, jak rozwiązywałem problemy z wydajnością w kontekście, który znam, np. przy optymalizacji zapytań SQL.”
Często wtedy rekruter faktycznie zmienia temat na coś bliższego twojemu doświadczeniu, zamiast „grillować” cię dalej.
Źródło: Pexels | Autor: Tima Miroshnichenko
Błąd nr 3 – Brak głośnego myślenia przy zadaniach (live coding, whiteboard)
Dlaczego „kod w ciszy” jest problemem
Na zadaniach typu live coding wielu kandydatów zapomina, że rekruter nie widzi, co się dzieje w ich głowie. W efekcie wygląda to tak:
kandydat czyta zadanie,
przez 5 minut panuje cisza, słychać tylko klawiaturę,
po czym pojawia się gotowe rozwiązanie albo… zacięcie i nerwowe kasowanie kodu.
Z perspektywy osoby po drugiej stronie taki scenariusz jest ryzykowny. Nie wiadomo:
czy rozumiesz treść zadania i ograniczenia,
czy analizujesz złożoność, czy po prostu „klepiesz na pałę”,
czy masz plan, czy błądzisz i liczysz na łut szczęścia.
Jak wygląda dobre głośne myślenie
Nie chodzi o komentowanie każdego znaku, tylko o odsłanianie kluczowych kroków:
„Najpierw spróbuję zrozumieć dane wejściowe: mamy listę… Jeśli dobrze rozumiem, dane są już posortowane / mogą być duplikaty?”
„Myślę o dwóch podejściach: brute force O(n²) oraz rozwiązaniu z jedną pętlą i dodatkową strukturą danych. Zacznę od prostszego, żeby upewnić się, że dobrze rozumiem problem.”
„Najpierw napiszę wersję, która działa, potem zobaczymy, jaką ma złożoność i czy da się to poprawić.”
Takie komentarze dają rekruterowi możliwość wejścia w interakcję: dopytać, coś zasugerować, skorygować błędne założenie. To bardziej przypomina pracę w parze niż egzamin ustny.
Jak mówić na głos, gdy nie lubisz „gadać do siebie”
Wielu introwertyków ma opór przed głośnym myśleniem, bo wydaje im się to sztuczne. Da się to obejść w naturalny sposób:
mów tak, jakbyś tłumaczył rozwiązanie młodszemu koledze po code review,
nie musisz budować pełnych, długich zdań – mogą być krótkie komunikaty typu: „tu sprawdzam warunek brzegowy”, „tu pilnuję złożoności O(n)”,
skup się na przejściach między etapami, nie na detalach implementacyjnych.
Przykład płynnego przejścia: „OK, mamy już policzone sumy częściowe. Teraz potrzebuję struktury, która pozwoli szybko sprawdzić, czy widziałem już tę wartość – użyję do tego słownika / mapy.”
Symulacja live codingu przed rozmową
Najprostszy trening: odpal edytor, włącz nagrywanie ekranu + dźwięku i rozwiąż 2–3 krótkie zadania, mówiąc na głos to, co robisz. Następnie obejrzyj nagranie i sprawdź:
czy przed pisaniem kodu streszczasz zadanie własnymi słowami,
czy mówisz, jakiego rozwiązania szukasz (proste vs optymalne),
czy na końcu testujesz kod na kilku przypadkach i głośno to komentujesz.
Nie chodzi o perfekcyjną narrację. Wystarczy, że z zewnątrz będzie jasne, gdzie jesteś w procesie: analiza → plan → implementacja → test.
Błąd nr 4 – Skupienie wyłącznie na kodowaniu, ignorowanie projektowania i architektury
Dlaczego „umie pisać kod” to za mało
Na poziomie mid i wyżej sam skill „napisać feature” to za mało. W realnym projekcie istotne są pytania:
jak to się wpiśnie w istniejącą architekturę,
jak to będzie działało przy większej liczbie użytkowników,
jak łatwo będzie to rozwijać i utrzymywać.
Rozmowy techniczne odzwierciedlają tę rzeczywistość: pojawiają się pytania o modułowość, zależności, granice serwisów, podejście do błędów, logowania, skalowania. Kandydaci, którzy trenowali wyłącznie zadania algorytmiczne, często się na tym wywracają.
Typowe objawy ignorowania architektury
Podczas rozmowy słychać wtedy rzeczy w tym stylu:
„Zrobimy jedną klasę serwisu, która to ogarnie, a potem się zobaczy.”
„Można wrzucić wszystko w jeden endpoint i parametrem sterować, co ma zrobić.”
„Skalowanie? W sumie nie myśleliśmy o tym, ale jak coś, to się doda kolejny serwer.”
Dla rekrutera to sygnał, że myślisz głównie na poziomie pojedynczej funkcji lub klasy, a nie całego systemu. To bywa akceptowalne na mocnego juniora, ale już nie na mida, który ma brać odpowiedzialność za większe kawałki aplikacji.
Jak pokazać myślenie projektowe, nawet przy prostym zadaniu
Nawet przy prostym zadaniu typu „zaprojektuj prostą listę zadań (todo) z API” możesz pokazać, że ogarniasz całość:
„Podzieliłbym to logicznie na warstwę API, warstwę biznesową i persystencję. API przyjmowałoby DTO, a logika domenowa żyłaby w osobnych klasach…”
„Na początek wystarczy jedna tabela tasks, ale od razu dodałbym pola pod przyszłe rozszerzenia: np. due_date, priority.”
„W kwestii błędów: odróżniłbym błędy walidacyjne od technicznych, żeby klient API miał jasny komunikat.”
Nie musisz budować pełnego diagramu UML. Wystarczy, że pokazujesz, iż widzisz więcej niż tylko „napiszę endpoint i zapiszę coś do bazy”.
Przygotowanie architektoniczne „pod rozmowę”
Zamiast czytać książkę o microservices tydzień przed rozmową, praktyczniejsze są krótkie ćwiczenia na własnych projektach:
Weź swój projekt z GitHuba i odpowiedz na głos na pytania:
Jak byś podzielił tę aplikację na moduły / serwisy, gdyby miała urosnąć x10?
Gdzie są potencjalne single point of failure (jednopunktowe miejsca awarii)?
Jak dorzuciłbyś logowanie i monitoring, żeby sensownie diagnozować błędy?
Przerób kilka klasycznych case’ów system designu w wersji „lite”, np.:
prosty system logowania użytkowników
moduł wysyłania maili z aplikacji
moduł uploadu plików
Na rozmowie często padają właśnie takie „codzienne” przykłady, a nie pełny system jak Twitter czy Netflix.
Błąd nr 5 – Słaba znajomość własnego CV i projektów
Dlaczego CV to nie jest „marketing”, tylko zestaw obietnic
Dla wielu rekruterów CV i profil na LinkedIn są listą tematów do pogłębienia. Jeśli wpisujesz:
„Wdrożenie architektury mikroserwisowej”,
„Optymalizacja wydajności zapytań SQL”,
„Projektowanie i implementacja systemu kolejkowania”,
to nie są ozdobniki. To zaproszenie do pytań w stylu: „Opowiedz, jak wyglądała ta architektura?”, „Jak zmierzyłeś poprawę wydajności?”, „Jaki broker kolejki i dlaczego?”. Jeśli na tym etapie pojawia się pustka, tłumaczenia typu „bardziej w tym uczestniczyłem, niż robiłem” podkopują wiarygodność.
Typowe „wtopy” związane z własnym CV
Przy problemach z przygotowaniem słychać powtarzające się schematy:
kandydat nie pamięta, jakiej bazy danych używali w kluczowym projekcie,
nie potrafi narysować (nawet z grubsza) przepływu żądania przez system, który podobno „projektował”,
mówi ogólnikami: „użyliśmy microservices, Kafka, Kubernetes”, ale bez konkretów typu:
jak wyglądała komunikacja między serwisami (REST, gRPC, kolejka?),
kto produkował, a kto konsumował wiadomości,
jakie były największe problemy przy wdrożeniu.
To wszystko wysyła sygnał: „Albo nie robił, albo nie rozumiał, co robi”. Na rozmowie technicznej to dużo gorsze niż przyznać, że czegoś dopiero się uczysz.
Jak „przepalić” swoje projekty przed rozmową
Przygotowanie warto zrobić na kilku poziomach głębokości, zaczynając od ogółu, a kończąc na konkretach technicznych.
Najpierw zrób sobie listę 2–4 kluczowych projektów z CV. Przy każdym projekcie odpowiedz (najlepiej na głos) na poniższe pytania:
Cel biznesowy: co ten system miał osiągnąć, jaki problem klienta rozwiązywał?
Twoja rola: za co konkretnie byłeś odpowiedzialny, a czego tylko dotykałeś „przy okazji”?
Stack: jakie technologie były krytyczne, a jakie poboczne?
Największe wyzwanie: jeden problem, który zapamiętałeś, i dokładny sposób, w jaki go rozwiązałeś.
Potem dorzuć warstwę techniczną:
prostym schematem narysuj (choćby na kartce) architekturę: komponenty, bazy, kolejki, integracje z zewnętrznymi systemami,
przejdź ścieżkę jednego typowego żądania end-to-end: co się dzieje, gdy użytkownik kliknie „zapisz zamówienie” / „wyślij formularz”,
spisz 2–3 przykłady decyzji technicznych, w których brałeś udział: wybór technologii, zmiana struktury bazy, refaktoryzacja modułu.
To później procentuje, bo na większość pytań o doświadczenie odpowiadasz z pamięci, bez nerwowego szukania słów.
Jak mówić o projekcie, gdy nie był „idealny technicznie”
Wiele osób wstydzi się swoich realnych projektów („monolit bez testów”, „legacy na starej wersji frameworka”) i próbuje je pudrować. Paradoks: seniorzy często wolą usłyszeć szczerą historię z legacy niż wyidealizowany greenfield.
Można to sprzedać tak, żeby pokazać dojrzałość:
„System był dużym monolitem, bez testów automatycznych. Zaczęliśmy od wprowadzenia testów wokół najbardziej krytycznych ścieżek, żeby później móc bezpieczniej refaktoryzować.”
„Migracja do nowszej wersji frameworka była rozciągnięta w czasie, więc musieliśmy chwilowo żyć z dwiema wersjami. Zadbaliśmy o logger wspierający oba warianty, żeby nie zgubić metryk.”
Uwaga: jeśli coś było słabym rozwiązaniem, możesz tak to nazwać. Liczy się, co z tym zrobiłeś lub czego się nauczyłeś.
Jak odpowiadać, gdy pytają o coś, czego w projekcie „nie robiłeś sam”
Niemal w każdym zespole są obszary, w których byłeś raczej obserwatorem niż głównym wykonawcą. Kluczem jest jasne rozróżnienie:
„Za to byłem odpowiedzialny osobiście” vs
„W tym uczestniczyłem / wspierałem / obserwowałem.”
Przykładowa uczciwa odpowiedź:
„Nie projektowałem całej architektury mikroserwisowej, to była decyzja tech leada. Natomiast sam implementowałem dwa serwisy: płatności i powiadomień. Mogę szczegółowo opowiedzieć, jak te serwisy komunikowały się z resztą systemu i jakie problemy mieliśmy z idempotencją przy ponawianiu eventów.”
Taka precyzja zwiększa zaufanie. Rekruter widzi, że nie zawyżasz kompetencji, ale w swoim obszarze siedzisz mocno.
Przygotowanie „checklisty pytań o projekt”
Żeby się nie rozjechać na prostych rzeczach, dobrze mieć z tyłu głowy własny zestaw, na które masz gotową odpowiedź dla każdego projektu z CV:
Jakie były główne moduły systemu?
Jak wyglądała komunikacja między modułami / serwisami?
Jak wyglądało środowisko produkcyjne (ile instancji, jaki deployment, monitoring)?
Jak radziliście sobie z błędami (retry, dead-letter queue, fallback)?
Jak testowaliście (unit, integration, end-to-end)?
Tip: jeśli masz repozytoria tych projektów (nawet prywatne), przeleć je przed rozmową. Krótkie odświeżenie kodu potrafi przywrócić sporo detali, które na spotkaniu mogą zrobić różnicę.
Błąd nr 6 – Brak pytań do rekrutera lub zadawanie przypadkowych
„Nie mam pytań” jako czerwona flaga
Na koniec większości rozmów pada: „Czy masz do nas jakieś pytania?”. Sporo kandydatów odpowiada: „Chyba nie, wszystko jasne”. Dla rekrutera to często sygnał, że:
nie zastanawiałeś się, czy ta rola naprawdę do ciebie pasuje,
nie interesuje cię, jak pracuje zespół,
traktujesz ofertę jak jedną z wielu, bez głębszego researchu.
Osoba, która poważnie myśli o zmianie, prawie zawsze ma pytania o projekt, procesy, kulturę techniczną. Brak jakichkolwiek pytań bywa odbierany jako bierność.
Jakie pytania robią dobre wrażenie technicznie
Chodzi o pytania, które pokazują sposób myślenia inżynierskiego, a nie tylko interesują się benefitem i stackiem z ogłoszenia. Konkretne przykłady:
„Jakie są obecnie największe wyzwania techniczne w tym projekcie?”
„Jak wygląda proces przeglądu kodu? Kto robi code review, jak szybko dostajecie feedback?”
„Czy macie monitoring i alerting z prawdziwymi metrykami technicznymi, czy raczej eventy biznesowe? Na czym głównie opieracie diagnozowanie problemów w produkcji?”
„Jaką macie typową ścieżkę: od pomysłu na feature do wdrożenia na produkcję? Kto podejmuje decyzje techniczne po drodze?”
Takie pytania pomagają też tobie: dowiadujesz się, czy to środowisko, w którym będziesz się rozwijać, czy raczej „gaszenie pożarów bez refleksji”.
Czego nie pytać na pierwszej rozmowie technicznej
Są obszary, które lepiej zostawić na etapy HR / ofertę, albo przynajmniej nie zaczynać od nich.
Benefity i szczegóły finansowe – jeśli widełki są znane, drążenie detali (karta sportowa, multisport, ilość owoców w kuchni) w trakcie rozmowy technicznej potrafi zdominować wątek techniczny.
Pytania „sprawdzające” rekrutera w agresywnym tonie, np.: „A ile commitów pan ostatnio zrobił?”. Techniczna ciekawość jest OK, ale da się ją ubrać w normalne, partnerskie pytanie o rolę rekrutera w projekcie.
Bardzo szczegółowe pytania o technologię, której na razie nie używają, typu: „Czy macie w planach migrację na Event Sourcing?”. Jeśli tak – sami o tym opowiedzą. Lepiej najpierw dobrze zrozumieć aktualny stan.
Jak przygotować sobie „pakiet startowy” pytań
Żeby uniknąć nerwowego wymyślania na żywo, można opracować uniwersalny zestaw, który później tylko lekko dostosujesz do firmy.
Podziel pytania na trzy kategorie:
Architektura i technologia – np. „Co jest single point of failure w waszym systemie i jak to mitigujecie?”, „Jak wygląda proces wprowadzania zmian w schemacie bazy na produkcji?”.
Procesy inżynierskie – „Czy macie regularne retrospektywy techniczne?”, „Jak podejmujecie decyzje o refaktoryzacji vs dowożenie nowych feature’ów?”.
Rozwój techniczny – „Jakie są możliwości pracy nad obszarami innymi niż mój core stack?”, „Czy były sytuacje, gdy osoba z zespołu zmieniała zakres odpowiedzialności (np. backend → DevOps)?”.
Przed rozmową wybierz z każdej kategorii 1–2 pytania najbardziej pasujące do konkretnej firmy lub projektu, o którym czytałeś w ogłoszeniu.
Źródło: Pexels | Autor: Anna Shvets
Błąd nr 7 – Zbyt defensywna postawa wobec feedbacku na rozmowie
Gdy zadanie idzie nie po twojej myśli
Na rozmowach technicznych rekruterzy często świadomie „podważają” fragment rozwiązania, żeby zobaczyć, jak reagujesz. Problem zaczyna się, gdy kandydat:
automatycznie się broni („To jest OK, przecież działa”),
od razu się wycofuje („To głupi pomysł, zróbmy inaczej”), bez zastanowienia,
odbiera uwagę jako atak personalny i zaczyna się spinać.
W normalnej pracy review kodu też bywa bezlitosne. Rekruter chce zobaczyć, czy potrafisz rozmawiać o jakości rozwiązania, a nie o własnym ego.
Jak reagować na krytyczne pytania o kod i decyzje
Dobre podejście jest bardzo podobne do pracy przy code review. Kilka schematów, które się sprawdzają:
„Masz rację, tu nie pomyślałem o edge case’ach. Możemy dopisać testy pod te sytuacje i zobaczyć, jak się zachowa.”
„Świadomie to uprościłem, żeby skupić się na głównym flow. Gdybym miał więcej czasu, rozbiłbym to na dwie metody / dodałbym obiekt konfiguracji.”
„Widzę dwie opcje: bardziej rozbudowana walidacja po stronie serwera, albo mocniejsze założenia na dane wejściowe. Które podejście wolicie w waszych projektach?”
Tym sposobem pokazujesz, że:
umiesz przyznać się do niedoskonałości rozwiązania,
jesteś gotów je poprawić, zamiast go bronić za wszelką cenę,
traktujesz uwagi jako okazję do doprecyzowania wymagań, a nie atak.
Symulacja code review „na sucho”
Dobrze działa proste ćwiczenie: weź jedno ze swoich repozytoriów i poproś znajomego developera, żeby zrobił ci brutalnie szczere code review na callu. Twoim celem nie jest „wygrać dyskusję”, tylko:
parafrazować uwagi („Czyli problem widzisz głównie w tym, że ta klasa ma za dużo odpowiedzialności?”),
proponować alternatywy („Możemy wydzielić to do osobnego serwisu albo wprowadzić wzorzec strategii – co byłoby prostsze w utrzymaniu?”),
przyznawać: „Tu faktycznie poszedłem na skróty, bo…” – i dodawać, co byś zrobił dobrze mając więcej czasu.
Po jednym czy dwóch takich treningach rozmowa techniczna zaczyna bardziej przypominać zwykłe spotkanie projektowe.
Błąd nr 8 – Ignorowanie kontekstu biznesowego i użytkownika
Kod nie istnieje w próżni
Na części rozmów, szczególnie na poziomie mid/senior, zadania są „business driven”: masz zaprojektować funkcję, moduł albo API dla konkretnego przypadku użycia. Kandydaci skupieni wyłącznie na technologii często:
projektują nadmiarowo (z góry microservices tam, gdzie wystarczy prosty moduł),
optymalizują zbyt wcześnie (cache, sharding, kiedy nie ma jeszcze ruchu),
ignorują UX/API design (interfejs trudny w użyciu, niezrozumiałe błędy).
Dla doświadczonego rekrutera to sygnał, że możesz pisać dobry kod, ale niekoniecznie rozumiesz, po co on powstaje.
Jak dopytywać o kontekst bez „przekombinowania”
Przy zadaniu projektowym zadaj kilka prostych pytań, zanim wejdziesz w diagramy:
Najważniejsze punkty
Rozmowa techniczna nie jest testem z definicji, tylko sprawdzianem sposobu myślenia, rozwiązywania problemów i komunikacji pod presją ograniczeń (czas, wymagania, technologia).
Różne formaty rozmów (screening, live coding, whiteboard, system design, code review, zadanie domowe) testują inne kompetencje, więc wymagają osobnego przygotowania i świadomości typowych wpadek w każdym z nich.
Poziom stanowiska zmienia oczekiwania: u juniora liczy się potencjał i uczciwość co do swojej wiedzy, u mida – samodzielność i świadomość złożoności, u seniora – myślenie architektoniczne i branie odpowiedzialności za decyzje.
Niestandardowe lub „dziwne” pytania mają zwykle sprawdzić reakcję na nieznany problem, umiejętność upraszczania zadania i radzenia sobie ze stresem, a nie pamięciowe odtworzenie idealnego rozwiązania.
Rekruter szuka partnera do pracy nad realnym kodem, dlatego mocno obserwuje, czy potrafisz dopytywać o wymagania, modyfikować podejście, uzasadniać kompromisy i tłumaczyć swoje decyzje innym.
Ślepe „wkuwanie” zadań z LeetCode bez rozumienia struktur danych, złożoności i kontekstu biznesowego prowadzi do rozczarowania – liczy się elastyczne użycie wiedzy, a nie pamięć do gotowych schematów.
Typowe błędy (udawanie eksperta, myślenie w skali jednego pliku, rzucanie buzzwordami) wynikają z nastawienia „muszę błyszczeć”, zamiast „muszę pokazać realny sposób pracy i procesu myślenia”.
Źródła informacji
Cracking the Coding Interview: 189 Programming Questions and Solutions. CareerCup (2015) – Przykłady formatów rozmów technicznych i typowych błędów kandydatów
Programming Interviews Exposed: Coding Your Way Through the Interview. Wiley (2019) – Praktyczne omówienie live codingu, whiteboard i oczekiwań na różnych poziomach
System Design Interview: An Insider's Guide. Byte Code LLC (2020) – Zakres i kryteria oceny rozmów z obszaru system design i architektury
Interviewing.io Engineering Interview Data Reports. Interviewing.io – Analizy zachowań kandydatów i typowych przyczyn niepowodzeń na rozmowach technicznych
The Google Resume: How to Prepare for a Career and Land a Job at Apple, Microsoft, Google, or any Top Tech Company. McGraw-Hill (2011) – Oczekiwania wobec junior/mid/senior i rola projektów oraz rozmów technicznych
