Jak przygotować się do rozmowy technicznej w IT krok po kroku

Po co w ogóle jest rozmowa techniczna i czego firma na niej szuka

Różnica między rozmową HR a rozmową techniczną

Rozmowa z HR to zwykle pierwszy filtr. Sprawdza się tam ogólną motywację, komunikację, dopasowanie kulturowe, oczekiwania finansowe i dostępność. Padają pytania o to, dlaczego zmieniasz pracę, jak pracujesz w zespole, jak reagujesz na feedback. Na tym etapie nikt poważny nie wymaga szczegółowych definicji z podręcznika sieci komputerowych.

Rozmowa techniczna to już zupełnie inna gra. Zamiast „czy pasujesz do firmy?”, inżynierów interesuje „czy zrobisz robotę i nie rozwalisz produkcji?”. Zespół techniczny chce się upewnić, że:

• rozumiesz technologie, których używasz – nie tylko kopiujesz z Stack Overflow,
• potrafisz samodzielnie myśleć o problemach, a nie tylko odtwarzać tutoriale,
• umiesz rozmawiać o kodzie, architekturze i decyzjach technicznych,
• dasz się włączyć do istniejącego projektu bez wielomiesięcznego „rozruchu”.

Rozmowa techniczna to nie egzamin akademicki, tylko praktyczny test: „czy za trzy miesiące będziesz realnym wsparciem dla zespołu”. Ta perspektywa mocno zmienia sposób przygotowania – mniej teorii dla teorii, więcej praktycznych przykładów i ćwiczenia umiejętności rozmowy.

Jakie ryzyka stara się ograniczyć firma

Każda rekrutacja jest dla firmy ryzykiem. Zatrudnienie złej osoby kosztuje: czas zespołu, spadek jakości kodu, opóźnione projekty. Rozmowa techniczna jest po to, żeby ograniczyć kilka typowych zagrożeń:

• Brak realnych umiejętności – kandydat ma ładne CV, dużo nazw technologii, ale w zadaniu live coding nie potrafi napisać prostego filtra po liście obiektów. Rozmowa techniczna weryfikuje, czy to, co jest na papierze, istnieje w praktyce.
• Brak samodzielności – osoba jest w stanie coś zrobić, ale tylko przy prowadzeniu za rękę. W pytaniach o projekty i w złożonych zadaniach widać, czy potrafisz sam podjąć decyzję, zdebugować problem, zaproponować rozwiązanie.
• Trudna współpraca – kandydat jest technicznie dobry, ale nie słucha, przerywa, ignoruje sugestie, broni z góry swojego kodu. Live coding i rozmowy o architekturze świetnie pokazują styl komunikacji i to, jak reagujesz na wyzwania.
• „Papierowy” kandydat – teoretyk, który zna wszystkie definicje, ale w praktycznych pytaniach (logi, monitoring, konkretne bugi) kompletnie się gubi. Pytania sytuacyjne typu „co zrobisz, jeśli…” wyciągają na wierzch realne doświadczenie.

Mit, że rozmowa techniczna to „test z IQ i pamięci”, robi sporo szkody. W rzeczywistości rekruterzy techniczni chcą odpowiedzieć sobie na proste pytanie: „czy będę chciał z tą osobą siedzieć przy jednym problemie przez kilka godzin i czy razem go dowieziemy?”.

Rozmowa techniczna to nie egzamin z całego IT

Popularne przekonanie: „muszę znać wszystko – od assemblera, przez Kubernetes, aż po GraphQL i machine learning, bo inaczej odpadnę”. Taka narracja prowadzi do panicznego, chaotycznego uczenia się wszystkiego po trochu, bez żadnej głębi.

Rzeczywistość jest inna: większość rozmów technicznych skupia się na kilku kluczowych obszarach, przewidywalnych dla danej roli. Typowy zakres to:

• podstawy programowania w konkretnym języku (składnia, typy, kolekcje, obsługa błędów),
• typowe struktury danych i kilka prostszych algorytmów,
• logika biznesowa podobna do tej, z którą będziesz pracować na co dzień (np. operacje na danych, walidacje, integracje),
• wybrane elementy infrastruktury: baza danych, REST/HTTP, podstawy chmury albo konteneryzacji – w zależności od stanowiska,
• przegląd jednego–dwóch projektów: jak były zbudowane, co dokładnie robiłeś, jak rozwiązywałeś problemy.

Mit kontra rzeczywistość: nie przegrywasz rozmowy dlatego, że nie pamiętasz marginalnej opcji CLI Dockera. Przegrywasz, gdy nie potrafisz wytłumaczyć, jak Twoja aplikacja zapisuje dane do bazy albo jak zdebugowałeś trudny błąd.

Typowe formy rozmów technicznych

Proces techniczny zwykle składa się z kilku etapów. Znajomość form pomaga się przygotować konkretnie, a nie „na oślep”. Najczęściej spotykane elementy to:

• Technical screening (telefoniczny / online) – 20–45 minut, seria krótkich pytań: podstawy języka, bazy danych, HTTP, proste mini-zadania logiczne. Celem jest szybkie odsianie kandydatów, którzy odstają od wymagań.
• Zadanie domowe (home assignment) – mniejszy projekt do napisania w domu: proste API, aplikacja frontendowa, skrypt, testy automatyczne. Sprawdza styl kodu, organizację projektu i umiejętność doczytania dokumentacji.
• Live coding z rekruterem – wspólne programowanie na ekranie. Może to być zadanie algorytmiczne, drobna funkcjonalność biznesowa albo refaktoryzacja istniejącego kodu. Tu wyłazi sposób myślenia, radzenie sobie ze stresem, komunikacja.
• System design / architektura – zwykle dla mid/seniorów. Rozmowa o tym, jak zaprojektowałbyś system: logowanie użytkowników, system kolejkowania, serwis z dużą liczbą zapytań. Liczy się uporządkowanie myśli i rozsądne kompromisy.
• Code review / omówienie zadań – przegląd Twojego kodu z zadania domowego albo z GitHuba. Padają pytania: „dlaczego tu wybrałeś taki wzorzec?”, „co byś poprawił, gdybyś miał jeszcze dzień?”.

Każdy z tych etapów testuje trochę inną rzecz. Zamiast próbować być „dobrym we wszystkim naraz”, łatwiej zaplanować osobno przygotowanie pod screening, pod live coding i pod rozmowę o architekturze.

Jak czytać opis stanowiska i procesu rekrutacji

Opis ogłoszenia i mail od rekrutera zawierają zaskakująco dużo informacji o tym, jak będzie wyglądała rozmowa techniczna. Trzeba tylko nauczyć się to czytać.

• Jeśli widzisz w ogłoszeniu frazy: zadania algorytmiczne, znajomość struktur danych – przygotuj się na LeetCode’owe zadania (sortowanie, wyszukiwanie, drzewka, grafy).
• Jeśli nacisk jest na microservices, REST, message queue, event-driven architecture – spodziewaj się pytań o integracje, przepływ danych, skalowanie, a mniej o formalne algorytmy.
• Przy CI/CD, Docker, Kubernetes, monitoring, observability – istotne będą praktyczne aspekty wdrażania i utrzymania systemu.
• Opis etapu: „rozmowa architektoniczna”, „system design interview” – prawie gwarantowany blok o większym obrazie systemu.

Dobry nawyk: po otrzymaniu opisu procesu z HR-em, wypisz sobie wszystkie słowa-klucze związane z techniką, a obok każdego dopisz pytania: „co bym odpowiedział, gdyby ktoś mnie o to zapytał?”, „jaki przykład z projektów mogę tu przywołać?”. To naturalnie przekształca ogłoszenie w listę tematów do powtórki.

Diagnoza startowa – z czym wchodzisz na rozmowę

Realna ocena poziomu: junior, mid czy senior

Poziomu nie określa liczba lat w CV, tylko rodzaj zadań, które jesteś w stanie samodzielnie dowieźć. Prosty podział praktyczny wygląda tak:

• Junior – potrafi napisać mniejszą funkcjonalność, gdy dostanie jasne wymagania i wsparcie w projekcie. Dobrze znosi code review, dużo się uczy, nie projektuje jeszcze architektury.
• Mid – sam ogarnia większy moduł od A do Z, rozumie kontekst biznesowy, potrafi dobrać bibliotekę, napisać testy, zaproponować prostą architekturę. Przy złożonych problemach potrzebuje konsultacji, ale ogólny kierunek trzyma sam.
• Senior – widzi cały system, projektuje, przewiduje skutki decyzji, wspiera innych, prowadzi technicznie projekty. Bierze odpowiedzialność nie tylko za kod, ale za jakość i stabilność rozwiązania.

Zadaj sobie kilka uczciwych pytań:

• Jakie zadania w aktualnej/poprzedniej pracy robiłeś całkowicie sam, od początku do końca?
• Czy ktoś mógł na Tobie „zawiesić” kluczowy fragment projektu, czy raczej dostawałeś wydzielone, prostsze części?
• Czy inni przychodzą do Ciebie po pomoc techniczną, czy to Ty częściej prosisz o wsparcie?

Mit, który psuje przygotowania: „jak napiszę w CV mid/senior, to dostanę lepszą ofertę”. Fałsz. Jeśli poziom jest zawyżony, rozmowa techniczna bardzo szybko to ujawni, a Ty dostaniesz znacznie trudniejsze pytania niż potrzebujesz. Szczera diagnoza ułatwia dobranie zakresu nauki i obniża stres.

Analiza ogłoszenia: must have, nice to have i obszary ryzyka

Ogłoszenia są przeładowane buzzwordami, ale da się z nich wyciągnąć konkrety. Dobrze zrobiona analiza sprowadza się do prostego rozbicia wymagań:

• Must have – technologie, bez których nie da się pracować na tym stanowisku. To tu będą najgłębsze pytania.
• Nice to have – rzeczy „fajne, jeśli znasz”. Mogą paść pytania poglądowe, ale brak wiedzy nie skreśla, jeśli reszta się zgadza.
• „Buzzwordy PR-owe” – czasem nazwy, które w praktyce mają małe przełożenie na codzienną pracę. Tu zwykle pytania są bardzo powierzchowne lub wcale ich nie ma.

Weź konkretne ogłoszenie i zrób tabelkę:

Następnie przerób to na konkretne działania: must have z oceną „słabo / średnio” to priorytet na najbliższe tygodnie. Nice to have z oceną „zero” – do ogarnięcia na poziomie koncepcyjnym, żeby chociaż wiedzieć, o czym rozmawiasz.

Tworzenie szczerej listy luk kompetencyjnych

Braków nie da się idealnie nadrobić w dwa tygodnie, ale da się zrobić jedną bardzo ważną rzecz: zbudować świadomość. Rekruter szybciej zaufa komuś, kto mówi: „znam to tylko na podstawowym poziomie, ale mogę opisać, jak tego używałem” niż kandydatowi, który udaje eksperta.

Prosty sposób na „rachunek sumienia” techniczny:

1. Wypisz wszystkie technologie z ogłoszenia plus te, które wpisałeś w CV.
2. Przy każdej z nich odpowiedz sobie na trzy pytania:
   • Co bym powiedział, gdyby zapytali „co to jest i do czego służy”?
   • Jaki konkretny przykład z projektu mogę podać, gdzie tego użyłem?
   • Jakie trudniejsze problemy z tym związane rozwiązywałem (debug, optymalizacja, projekt)?
3. Zaznacz na kolor albo w skali 1–3, jak pewnie byś się czuł, odpowiadając na pytania.

Lista, która wyjdzie, nie ma być powodem do wstydu, tylko mapą przygotowań. Świadomy kandydat mówi: „te obszary znam bardzo dobrze, tu mam średnią praktykę, a tu dopiero zaczynam – ale już uczę się X i Y”. Mit, że przyznanie się do braków automatycznie eliminuje, jest szkodliwy. Firmy wolą kogoś, kto zna swój ograniczenia, niż osoby, które „wiedzą wszystko”, dopóki nie trzeba napisać trzech linii kodu.

Przegląd swoich projektów jako źródło przykładów

Rozmowa techniczna to w dużej mierze rozmowa o tym, co już zrobiłeś. Projekty komercyjne, uczelniane, hobbystyczne – wszystko to jest materiałem na bardzo konkretne odpowiedzi.

Przygotuj sobie 2–4 projekty, o których możesz mówić z detalami. Do każdego zanotuj:

• cel projektu w dwóch, trzech zdaniach (co, dla kogo, po co),
• stos technologiczny (język, framework, baza, narzędzia),
• Twoją konkretną rolę (co dokładnie zrobiłeś Ty, a nie cały zespół),
• 2–3 większe wyzwania, które pojawiły się po drodze, i jak je rozwiązaliście,
• rzeczy, które dzisiaj zrobiłbyś inaczej.

Przećwiczenie „opowiadania o sobie” przez pryzmat techniki

Na rozmowie technicznej nie odpowiadasz tylko na pytania z listy. Całe Twoje doświadczenie jest filtrowane przez to, jak o nim mówisz. „Opowiedz o sobie” często jest pierwszym, ale i jednym z ważniejszych pytań technicznych – bo pokazuje, czy umiesz układać fakty w logiczną całość.

Zrób z tego mini-scenariusz:

• 30–60 sekund o ścieżce zawodowej (skąd się wziąłeś w IT, jakie role pełniłeś).
• 60–90 sekund o ostatnim projekcie – głównie technicznie, z akcentem na Twoją odpowiedzialność.
• 2–3 krótkie „highlighty” – konkretne problemy techniczne, które rozwiązałeś, i czego Cię nauczyły.

Mit: „opowiedz o sobie” to small talk, który trzeba jakoś przetrwać. W praktyce to punkt odniesienia na resztę rozmowy. Jeśli wymienisz konkret: „w ostatnim projekcie przebudowywałem moduł odpowiedzialny za integrację z systemem płatności”, to niemal na pewno padnie prośba o rozwinięcie tego tematu. Lepiej narzucić rozmówcy obszary, w których czujesz się mocny, niż czekać, aż sięgnie po losowy temat.

Fundamenty techniczne, które najczęściej wypływają na rozmowach

Język programowania: nie tylko „znam składnię”

Dla większości stanowisk bazą jest jeden główny język (Java, C#, JavaScript/TypeScript, Python itp.). W pytaniach rzadko chodzi o egzotyczne konstrukcje, częściej o zrozumienie mechaniki i konsekwencji.

Lista obszarów, które regularnie się przewijają:

• Model wykonania – jak kod jest uruchamiany, co dzieje się „pod spodem” (np. garbage collector w Javie/C#, event loop w Node.js, GIL w Pythonie).
• Typy i kolekcje – jak działają listy, mapy, sety, czym różni się mutable od immutable, kiedy który typ ma sens.
• Błędy i wyjątki – jak je obsługujesz, kiedy łapiesz, kiedy propagujesz wyżej, jak nie zabijać stack trace’a.
• Podstawy programowania obiektowego/funkcyjnego – dziedziczenie, kompozycja, interfejsy, wysokopoziomowe funkcje, lambdy.

Dobre przygotowanie to nie „wkuć na blachę definicje”, tylko móc powiedzieć: „użyłem tu takiej konstrukcji, bo…”. Jeśli jesteś w stanie na prostym fragmencie kodu pokazać, o co Ci chodzi, jesteś przed większością kandydatów, którzy operują hasłami.

Struktury danych i złożoność: poziom praktyczny, nie akademicki

Struktury danych nie są tylko dla olimpijczyków. Nawet jeśli nie robisz na co dzień zadań z grafami, podstawy i tak przenikają do zwykłego kodu aplikacyjnego.

Co warto mieć ułożone:

• Różnica między lista / tablica / mapa / zbiór w Twoim języku – jak są zaimplementowane i jakie dają złożoności (przynajmniej na poziomie „tutaj jest O(1) średnio, tu O(n)”).
• Jak działają sortowania w standardowej bibliotece – nie musisz znać wszystkich szczegółów, ale przyda się wiedza, czy są stabilne, oraz kiedy mogą „zaboleć” wydajnościowo.
• Proste kolejki / stosy / priorytety – często wychodzą przy zadaniach typu „obsługa requestów”, „symulacja”.

Mit: trzeba odręcznie wyprowadzać wzory na złożoność, inaczej polegniesz. W większości firm wystarczy, że umiesz porównać dwie wersje rozwiązania i świadomie powiedzieć: „ta wersja jest liniowa względem liczby elementów, tamta jest kwadratowa, dlatego przy 100k rekordów zacznie się problem”.

Bazy danych i SQL: wspólny mianownik wielu rozmów

Jeśli w ogłoszeniu pojawia się SQL lub jakakolwiek relacyjna baza, pytania o dane są niemal pewne. Czasem w formie teoretycznej, częściej – przez zadania lub omawianie projektów.

Zakres, który daje solidne oparcie:

• Podstawowe SELECT/INSERT/UPDATE/DELETE, filtrowanie, sortowanie, paginacja (LIMIT/OFFSET lub odpowiednik).
• JOIN-y – inner, left, right – umiejętność wytłumaczenia na małym przykładzie, co do czego się łączy.
• Podstawy indeksów – po co są, kiedy pomagają, a kiedy szkodzą.
• Różnica między transakcją a zwykłym zapisem, ogólne pojęcie o izolacji.

Dobry trening: weź jedną swoją tabelę z projektu (np. użytkownicy, zamówienia) i przygotuj 5–10 zapytań, które rozwiązują typowe potrzeby biznesowe. Nie chodzi o sztuczne przykłady, tylko rzeczy w stylu „pokaż ostatnie 10 zamówień użytkownika”. To dużo lepiej wchodzi w głowę niż suche ćwiczenia.

HTTP, API i podstawy komunikacji w sieci

Dla backendu i frontendu HTTP to chleb powszedni. Nie trzeba znać każdego statusu, ale podstawowe mechanizmy są często sprawdzane.

Sprawdź, czy potrafisz jasno opowiedzieć o:

• Różnicy między GET/POST/PUT/PATCH/DELETE na poziomie semantyki, nie tylko „są takie metody”.
• Znaczeniu podstawowych statusów 2xx, 3xx, 4xx, 5xx i kiedy których używasz.
• Podstawach autentykacji/autoryzacji – token, sesje, OAuth (choćby na poziomie koncepcji).
• Różnicy między REST a „JSON-over-HTTP”, oraz gdzie w to wszystko wchodzą np. GraphQL czy gRPC.

Mit: żeby dostać pracę, musisz perfekcyjnie wyrecytować definicję REST-u. Dużo ważniejsze jest, czy umiesz zaprojektować sensowne endpointy i uzasadnić, dlaczego akurat tak przesyłasz dane, a nie inaczej.

Testowanie: nie tylko „czy pisałeś testy?”, ale jakie i po co

Pytania o testy często zaczynają się banalnie, a kończą całkiem głęboko. Warto przygotować się na poziomie konkretnych przykładów.

• W jakich sytuacjach piszesz testy jednostkowe, a kiedy integracyjne?
• Jak tworzysz testowalny kod – zależności przez konstruktor, podział odpowiedzialności, unikanie „bogów” static.
• Co robisz, gdy testy są niestabilne (flaky) – czy umiesz podać przykład z życia i rozwiązanie?

Dobry sposób przygotowania: wybierz jeden moduł z własnego projektu i odpowiedz sobie pisemnie na pytania: „jakie są tu najważniejsze ścieżki biznesowe?” oraz „które z nich testuję i dlaczego?”. Takie ćwiczenie zmusza do myślenia jak rozmówca techniczny.

Zadania algorytmiczne, coding challenge i live coding – podejście krok po kroku

Cel zadań: nie chodzi tylko o „dobrą odpowiedź”

Wiele osób traktuje zadania algorytmiczne jak egzamin z matematyki: albo zrobisz, albo przepadłeś. Tymczasem dla większości rekruterów kluczowe są inne rzeczy:

• Jak rozbijasz problem na mniejsze kroki.
• Czy komunikujesz na głos, co robisz i dlaczego.
• Jak reagujesz, gdy utkniesz – czy próbujesz inaczej, pytasz o doprecyzowanie, czy milczysz.
• Czy Twój kod jest czytelny, nawet jeśli nie jest optymalny.

Mit: jeśli nie zrobisz zadania do końca, jesteś skreślony. W wielu firmach dużo lepiej wypada kandydat, który uczciwie powie „to rozwiązanie jest poprawne, ale ma kwadratową złożoność, moglibyśmy później spróbować zoptymalizować” i doprowadzi do działającej wersji, niż ktoś, kto na siłę rzeźbi superoptymalne, ale niedziałające podejście.

Jak ćwiczyć zadania – prosty plan tygodniowy

Zamiast chaotycznie klikać kolejne zadania na platformach, lepiej podejść do tematu strukturalnie. Przykładowy plan na 2–3 tygodnie:

1. Dzień 1–3: odświeżanie podstawowych struktur danych (tablice, listy, mapy). Zadania typu:
   • przetwarzanie tablicy (filtracja, agregacja),
   • zliczanie wystąpień elementów,
   • proste problemy z użyciem słownika/mapy.
2. Dzień 4–7: proste algorytmy na ciągach i stringach:
   • odwracanie ciągu,
   • sprawdzanie palindromów,
   • usuwanie duplikatów.
3. Kolejny tydzień: zadania z tablicami posortowanymi, wyszukiwaniem, prostymi drzewami (np. przeszukiwanie DFS/BFS w wersji „na sucho”).

Kluczowe, żeby każde zadanie przećwiczyć w trzech krokach:

1. Rozwiązanie „na spokojnie” z możliwością patrzenia w notatki/dokumentację.
2. Druga próba tego samego typu zadania bez zerkania – żeby utrwalić schemat.
3. Krótka analiza po zadaniu: jaki był wzorzec (two pointers, sliding window, hash map), jak to nazwać słowami.

Strategia rozwiązywania zadania na rozmowie

Sam moment live codingu można sobie poukładać w głowie w kilku krokach. Im częściej je „odgrywasz” na sucho, tym spokojniej zareagujesz w stresie.

1. Parafraza problemu – powtórz własnymi słowami, co trzeba zrobić. To okazja, żeby wyłapać niejasności.
2. Pytania doprecyzowujące – zakres wejścia/wyjścia, skrajne przypadki, oczekiwania co do złożoności.
3. Prosty przykład – przetestuj na kartce/edytorze niewielki case, zanim napiszesz kod.
4. Plan słowny – opowiedz wysokopoziomowo, co zamierzasz zrobić, w 2–4 krokach.
5. Kodowanie – dopiero teraz pisz kod, komentując na głos kluczowe fragmenty.
6. Ręczne testy – sprawdź działanie na kilku przykładach, w tym skrajnych.

Najczęstszy błąd: od razu skakanie do kodu w milczeniu. Dla rozmówcy wygląda to jak „czarne pudełko” – nie wie, czy rozumiesz problem, dopóki nie pojawi się gotowe rozwiązanie. A jeśli nie zadziała, masz dużo trudniej wybronić swój tok myślenia.

Jak ogarniać stres przy live codingu

Nerwy przy programowaniu „na oczach” są normalne, nawet u doświadczonych devów. Da się jednak zbić ich wpływ na jakość kodu.

• Na początku rozmowy uprzedź, że możesz pisać wolniej lub „gadać na głos”, żeby uporządkować myśli. To ustawia oczekiwania.
• Jeśli zapomnisz nazwę funkcji/metody z biblioteki standardowej – powiedz to wprost. Lepiej: „wiem, że jest funkcja, która robi X, nazwę bym sprawdził w dokumentacji”, niż desperackie zgadywanie.
• Ustal z rozmówcą, czy możesz używać pseudokodu w miejscach typu „sortuj listę rosnąco”. Czasem nie jest istotne, jak dokładnie się to nazywa.

Jeśli stres paraliżuje Cię kompletnie, dobrze działa kilka sesji próbnych z kolegą lub samemu, nagrywane np. przez prosty screen recorder. Potem oglądasz i patrzysz, gdzie się „zacinasz” – zwykle to konkretne momenty (np. przy rozpoczęciu zadania, przy pierwszym błędzie kompilacji).

Zadania domowe i platformy online – jak nie utonąć

Coraz częściej firmy wysyłają zadanie domowe albo odsyłają do platformy typu HackerRank. Zamiast połykać setki zadań, lepiej wyciągrać esencję.

• Jeśli masz zadanie domowe: traktuj je jak mini-projekt. Struktura katalogów, czytelne nazwy, README z instrukcją uruchomienia. To wszystko jest oceniane.
• Nie komplikuj architektury na siłę. Prostszy, ale spójny projekt wygląda lepiej niż przekombinowany miszmasz wzorców.
• Na platformach zadaniowych: po rozwiązaniu zadania przeczytaj 1–2 inne rozwiązania, żeby zobaczyć, czego nie wpadłeś. Nie kopiuj – zrozum schemat.

Przygotowanie do rozmowy o konkretnych technologiach i stosie

Focus na „core” stosu, nie na każdy buzzword

Większość ogłoszeń zawiera długie listy technologii. Łatwo zgubić proporcje i uczyć się po trochu wszystkiego. Lepsza strategia: zidentyfikować 3–5 elementów absolutnie kluczowych i to na nich oprzeć przygotowanie.

Przykład dla backendu Java:

• Java + kolekcje + wątkowość (podstawy).
• Spring / Spring Boot – konfiguracja, DI, REST controllers, konfiguracja bazy.

Jak czytać ogłoszenie i ogarniać priorytety technologiczne

Suche listy technologii z ogłoszeń potrafią odstraszyć. Zamiast panikować, podejdź do nich analitycznie – jak do backlogu, w którym trzeba wybrać to, co daje największy zwrot.

• Podkreśl to, co się powtarza – jeśli Java/Spring pojawia się w tytule, w opisie obowiązków i jeszcze raz w wymaganiach, to jest trzon. Pojedyncze wzmianki o „mile widziane: Docker, AWS, Kafka” to raczej dodatki.
• Odróżnij „must have” od „nice to have” po języku: „wymagamy/oczekujemy” to podstawa, „będzie plusem/fajnie jeśli” – bonusy, które zwykle nie decydują o być albo nie być.
• Zastanów się, co już umiesz – przy każdym punkcie z ogłoszenia zapisz sobie: „umiem dobrze / mam styczność / tylko z nazwy”. To pokaże luki, które naprawdę trzeba domknąć.

Mit: trzeba ogarnąć absolutnie wszystkie technologie z ogłoszenia przed rozmową. W praktyce liczy się solidny core i uczciwe pokazanie, że reszty jesteś w stanie się douczyć.

Przygotowanie do backendu na przykładzie Java/Spring

Backend zazwyczaj kręci się wokół trzech osi: język, framework webowy i baza danych. Dobrze jest przygotować konkretny, mały przykład do omówienia.

• Język i kolekcje – odśwież typy kolekcji (List, Set, Map), różnice między nimi, podstawowe metody, a także to, jak działają pętle, lambdy, streamy. Często pytają: „w jakiej sytuacji użyjesz HashMap, a kiedy LinkedHashMap?”.
• Spring Boot – przejdź jeszcze raz ścieżkę: @RestController → @Service → @Repository. Umiej opowiedzieć, jak przepływa request, gdzie co się dzieje i czemu oddzielasz warstwy.
• Konfiguracja i DI – opisz własnymi słowami, czym jest dependency injection, jak Spring tworzy beany i co się dzieje, gdy masz dwa beany tego samego typu.
• Baza danych – podstawy JPA/Hibernate: encje, relacje (OneToMany, ManyToOne), proste zapytania. Nie musisz być ekspertem SQL, ale fajnie wiedzieć, jak wygląda SELECT z JOIN-em, który realnie kiedyś pisałeś.

Dobry trik: przygotuj jeden konkretny endpoint z życia – np. „tworzenie zamówienia” – i przejdź go krok po kroku: co trafia w kontroler, co robi serwis, jak wygląda encja, co ląduje w bazie. To świetny materiał do rozmowy.

Front-end: nie tylko framework, ale też fundamenty przeglądarki

W front-endzie kandydaci często skupiają się wyłącznie na React/Vue/Angular, a rozmówcy wracają do bazowych pytań o to, jak działa przeglądarka.

• JavaScript pod spodem – asynchroniczność (event loop, promisy, async/await), zakresy, hoisting, różnice między var/let/const. To wciąż klasyki na rozmowach.
• DOM i zdarzenia – jak działa propagacja zdarzeń, czym jest bubbling/capturing, jak manipulujesz DOM-em w „czystym” JS, nie tylko przez framework.
• CSS i layout – Flexbox, Grid, responsywność, podstawy specificity. Nie chodzi o projektowanie graficzne, tylko o to, czy potrafisz sensownie ułożyć widok.
• Framework – w React: komponenty funkcyjne, hooks (useState, useEffect), lifting state up, podstawy Context API. Dobrze mieć w głowie choć jeden większy komponent, o którym możesz opowiedzieć.

Rzeczywistość często wygląda tak, że lepiej wypada ktoś, kto solidnie ogarnia JS + DOM i średnio Reacta, niż osoba, która zna 50 hooków, ale nie potrafi wyjaśnić, czemu coś się rerenderuje co sekundę.

Mobile: Android/iOS z naciskiem na praktykę

W świecie mobile często pytają o to, co faktycznie robiłeś w aplikacjach, a nie tylko o suche API.

• Architektura – MVVM/MVP/MVI, czym się różnią, jak rozdzielasz warstwy i gdzie ląduje logika domenowa.
• Życie cyklu ekranu – Activity/Fragment lifecycle w Androidzie lub ViewController lifecycle w iOS: co się dzieje przy rotacji, co przy powrocie z tła.
• Komunikacja z backendem – jak wywołujesz API, jak obsługujesz błędy, time-outy, brak internetu, czy używasz jakiejś formy cache’u.
• Debugowanie – przykładowa sytuacja: aplikacja crashuje „tylko czasem” po powrocie z innej aplikacji. Jak do tego podchodzisz?

Mit: potrzebujesz na pamięć całego SDK. Zwykle ważniejsze jest, czy rozumiesz cykl życia komponentów i potrafisz utrzymać stabilność aplikacji w normalnych, trochę „brudnych” scenariuszach.

DevOps/Cloud: jak przygotować się, gdy ogłoszenie straszy chmurą

Przy rolach z elementami DevOps lub cloudowej infrastruktury łatwo dać się przestraszyć listą: AWS, GCP, Kubernetes, Terraform, CI/CD, monitoring. Da się to jednak rozłożyć na prostsze klocki.

• Model mentalny chmury – różnica IaaS/PaaS/SaaS, co to jest instancja, co to jest managed service (np. RDS, Cloud SQL), czym się różni S3/Blob Storage od klasycznego dysku.
• Podstawy konteneryzacji – co faktycznie daje Docker, czym jest obraz, a czym kontener, jak wygląda prosty Dockerfile dla typowej aplikacji.
• CI/CD – sens pipeline’ów: build, test, deploy. Co byś wrzucił jako kroki, jakie błędy CI widziałeś i jak je naprawiałeś.
• Monitoring i logi – choćby na poziomie: jak logujesz błędy, co to są metryki, dlaczego same logi nie wystarczą.

Jeśli dopiero wchodzisz w cloud, wybierz jednego providera (najczęściej AWS albo GCP) i przygotuj się w oparciu o 4–5 najważniejszych usług, a nie całą ofertę katalogową.

Jak mówić o technologiach, których nie znasz idealnie

Prędzej czy później padnie pytanie o coś, czego dotknąłeś tylko pobieżnie albo wcale. Tu często wywracają się nawet dobrzy kandydaci, bo próbują udawać pewność.

• Przyznaj poziom znajomości – proste: „używałem tego raz w małym projekcie, kojarzę ogólną ideę, ale nie czuję się w tym ekspertem”. Dla doświadczonych rozmówców to sygnał, że można dopytać, ale nie opierać całego panelu na tym temacie.
• Odwołaj się do podobnych narzędzi – jeśli znasz Dockera, a pytają o Kubernetesa, możesz powiedzieć: „Kubernetes kojarzę z poziomu deploymentu kontenerów i podstawowych obiektów, natomiast na co dzień pracowałem głównie na czystym Dockerze i docker-compose”.
• Pokaż, jak się uczysz – krótko opisz, jak wyglądałby Twój plan wejścia w daną technologię. To sygnał, że masz proces, a nie tylko zbiór przypadkowych trików.

Rzeczywistość jest taka, że większość ekip i tak ma w planie onboarding technologiczny. Kluczowe jest, żeby nie stracić zaufania rozmówcy udawaniem, że „znasz wszystko”.

System design, architektura i „bigger picture”

Po co w ogóle pytania o architekturę, skoro jesteś „zwykłym” devem

Rozmowy o system designie często budzą lęk, bo kojarzą się z wielkimi diagramami i tytułem „architekt systemowy”. Tymczasem nawet na poziomie mida rekruterzy chcą zobaczyć, czy wykraczasz myśleniem poza pojedynczą klasę czy funkcję.

Kilka rzeczy, których zwykle szukają:

• Czy widzisz granice między modułami – gdzie kończy się jeden kontekst, a zaczyna drugi.
• Czy rozumiesz podstawowe kompromisy – prostota vs. skalowalność, szybkość dostarczania vs. elastyczność później.
• Czy potrafisz opisać istniejący system w sposób logiczny i zrozumiały.

Mit: pytania o system design są tylko dla seniorów. W praktyce często pojawiają się w lżejszej formie, np. „jakbyś zaprojektował prosty system rezerwacji wizyt”.

Jak przygotować się do system designu na poziomie junior/mid

Nie trzeba od razu projektować globalnego serwisu społecznościowego. Dużo lepiej ogarnąć kilka typowych, mniejszych scenariuszy i rozumieć, jakie decyzje tam podejmujesz.

Trzy przykładowe tematy, które dobrze przećwiczyć:

• System rezerwacji (np. wizyty u lekarza, booking salek) – obsługa slotów czasowych, konflikty rezerwacji, prosta autoryzacja.
• Prosty system kolejkowy (np. przetwarzanie zadań w tle) – kolejka, worker, retry, dead-letter queue w wersji koncepcyjnej.
• System powiadomień – wysyłka maili/SMS/push, planowanie wysyłek, logowanie błędów i retry.

Dla każdego takiego przykładu spróbuj na kartce odpowiedzieć na kilka pytań:

1. Jakie są główne byty (użytkownik, rezerwacja, zasób itd.) i jakie mają relacje?
2. Jakie są kluczowe use case’y – np. „utwórz rezerwację”, „anuluj”, „przenieś”?
3. Co się dzieje, gdy coś idzie nie tak – konflikt, awaria, brak zewnętrznej usługi?
4. Jak byś pociął to na serwisy/moduły, nawet jeśli mówimy o monolicie?

Prosty schemat prowadzenia rozmowy o architekturze

Podobnie jak przy live codingu, można mieć w głowie pewien szkielet rozmowy o system designie. To pozwala nie zgubić się w szczegółach.

1. Dopytaj o wymagania – ilu użytkowników, czy to system globalny czy lokalny, które funkcje są krytyczne, jakie są ograniczenia (np. budżet, czas).
2. Narysuj (choćby w głowie) high-level diagram – frontend → backend → baza/kolejki/serwisy zewnętrzne. Nie chodzi o piękno diagramu, ale o spójną historię.
3. Opowiedz o przepływie jednego scenariusza – np. „co się dzieje, gdy użytkownik tworzy rezerwację” krok po kroku.
4. Wskaż potencjalne problemy – gdzie może powstać wąskie gardło, czy są miejsca single point of failure, co z danymi przy awarii.
5. Zaproponuj ewolucję – krótko, jak można by system rozwinąć, gdyby użytkowników było 10× więcej.

Rozmówcy częściej docenią to, że widzisz ryzyka i mówisz „tu zrobiłbym na początek proste rozwiązanie X, ale przy większej skali rozważyłbym Y”, niż to, że sypiesz nazwami modnych usług cloudowych.

Podstawowe pojęcia architektoniczne, które dobrze mieć „pod ręką”

Nie chodzi o książkowe definicje, tylko o zrozumienie, co dane pojęcie zmienia w praktyce.

• Monolit vs. mikroserwisy – kiedy monolit jest prostszy i sensowny, a kiedy rozbicie na mikroserwisy faktycznie coś rozwiązuje. Warto mieć przykład z własnego projektu lub hipotetyczny.
• Komunikacja synchroniczna vs. asynchroniczna – request-response (HTTP) vs. kolejki/eventy. Co zyskujesz, gdy coś przeniesiesz do przetwarzania w tle.
• Skalowanie pionowe vs. poziome – dokładanie RAM/CPU do jednej maszyny vs. replikowanie wielu instancji. Jak to wpływa na sesje użytkownika, cache, itd.
• Cache – gdzie można cache’ować (frontend, backend, baza, zewnętrzny cache typu Redis), co się dzieje przy nieświeżych danych.
• Spójność danych – różnica między mocną spójnością a eventual consistency na poziomie intuicji, z przykładami typu „licznik lajków”.

Kiedy potrafisz te rzeczy wyjaśnić w prostych słowach, zwykle wystarcza to, żeby spokojnie przejść lżejszą część system designu na poziomie junior/mid.

Jak wykorzystać własny projekt jako materiał do rozmowy o „bigger picture”

Nawet drobny projekt – czy to firmowy, czy prywatny – może być świetnym polem do rozmowy o architekturze. Kluczem jest, żebyś wcześniej ułożył sobie historię, jak go opowiadasz.

Możesz podejść do tego w czterech krokach:

1. Kontekst biznesowy – jedno, dwa zdania: kto używał systemu, do czego służył, jakie było „dlaczego”. Bez slajdów, po prostu logiczna opowieść.
2. Architektura logiczna – jakie moduły/serwisy istniały, jak się ze sobą komunikowały, gdzie była baza danych lub inne magazyny danych.
3. Twoje decyzje – 1–2 konkretne przykłady: dlaczego wybrałeś daną bazę, dlaczego rozdzieliłeś moduł X od Y, czemu coś zrobiłeś synchronicznie, a nie asynchronicznie.

Najczęściej zadawane pytania (FAQ)

Jak wygląda rozmowa techniczna w IT i czym się różni od rozmowy z HR?

Rozmowa z HR skupia się na motywacji, komunikacji, dopasowaniu do kultury firmy, oczekiwaniach finansowych i dostępności. Padają pytania o to, jak pracujesz w zespole, dlaczego zmieniasz pracę, jak reagujesz na feedback. Techniczne detale zwykle są tu bardzo ogólne.

Rozmowa techniczna sprawdza zupełnie coś innego: czy rozumiesz technologie, których używasz, potrafisz samodzielnie myśleć o problemach, umiesz rozmawiać o kodzie i architekturze, a także czy szybko „wejdziesz” w istniejący projekt. Mit jest taki, że to egzamin akademicki; w praktyce to test, czy za kilka miesięcy będziesz realnym wsparciem dla zespołu, a nie tylko ładnym CV.

Jakie pytania padają najczęściej na rozmowie technicznej dla programisty?

Najczęściej przewijają się pytania z kilku stałych obszarów: podstawy języka (typy, kolekcje, obsługa błędów), typowe struktury danych i kilka prostszych algorytmów, praca z bazą danych i HTTP/REST, a także omówienie jednego–dwóch projektów z Twojego doświadczenia. Do tego dochodzą pytania sytuacyjne typu „jak zdebugujesz błąd X?” albo „co zrobisz, gdy serwis zacznie odpowiadać wolniej?”.

Rzeczywistość jest taka, że przegrywa się rozmowę częściej przez brak zrozumienia tego, jak działa własna aplikacja (np. zapis do bazy, obsługa błędów, monitoring), niż przez niepamiętanie rzadko używanej flagi w narzędziu CLI. Rekruterzy techniczni chcą zobaczyć Twoje myślenie, a nie to, czy wyrecytujesz definicje z książki.

Jak najlepiej przygotować się do live codingu na rozmowie technicznej?

Największą różnicą między kodowaniem w domu a live codingiem jest stres i konieczność „myślenia na głos”. Dlatego oprócz samego rozwiązywania zadań warto ćwiczyć tłumaczenie na bieżąco, co robisz i dlaczego. Prosty trening: odpal edytor, włącz nagrywanie ekranu i spróbuj rozwiązać zadanie, komentując każdy krok tak, jakbyś rozmawiał z rekruterem.

Dobrze jest przećwiczyć kilka typowych kategorii: operacje na kolekcjach, sortowanie i filtrowanie danych, prosta logika biznesowa (walidacja danych użytkownika, przetwarzanie zamówienia), a także czytelne nazewnictwo i podstawowe testy. Mit, że live coding to wyłącznie „zadania z olimpiady informatycznej”, zderza się z tym, że w wielu firmach dostajesz raczej mały, życiowy problem bardzo podobny do realnego backlogu.

Czy na rozmowie technicznej muszę znać „całe IT”, żeby nie wyjść na laika?

Nie. To częsty mit, który prowadzi do chaotycznego uczenia się wszystkiego po trochu. Rozmowa techniczna jest zwykle skrojona pod rolę: backend, frontend, DevOps, QA, data – każda z tych ścieżek ma zestaw przewidywalnych tematów. Zamiast próbować ogarniać assembler, Kubernetes i machine learning jednocześnie, lepiej wejść głębiej w to, czym faktycznie masz się zajmować na co dzień.

Dobrym punktem wyjścia jest opis ogłoszenia: wypisz technologie i pojęcia, które się powtarzają, a przy każdym z nich zanotuj, co umiesz o tym opowiedzieć i jaki przykład z projektu możesz podać. Jeśli w ofercie jest nacisk na microservices, REST i message queue, to właśnie tam spodziewaj się pytań, a nie o implementację egzotycznych algorytmów grafowych.

Jak czytać ogłoszenie o pracę, żeby przewidzieć, co będzie na rozmowie technicznej?

Ogłoszenie to w praktyce lista podpowiedzi do rozmowy. Frazy typu „zadania algorytmiczne”, „znajomość struktur danych” sugerują LeetCode’owe zadania. Gdy widzisz microservices, REST, event-driven architecture, message queue – szykuj się na pytania o integracje, przepływ danych, skalowanie i odporność systemu. Przy CI/CD, Docker, Kubernetes, monitoring – przygotuj konkretne przykłady wdrożeń, awarii i ich analizy.

Warto też zwrócić uwagę na opis procesu: „technical screening” oznacza krótką, szeroką serię pytań, „system design interview” – projektowanie większego systemu, a „code review” – rozmowę na bazie Twojego kodu (np. z zadania domowego). Mit, że „proces jest tajemnicą”, zwykle upada po dokładnym przeczytaniu maila od rekrutera – tam często pada wprost, jakie etapy Cię czekają.

Jak ocenić, czy jestem junior, mid czy senior przed rozmową techniczną?

Poziom to nie liczba lat w CV, tylko rodzaj zadań, które dowozisz samodzielnie. Junior zwykle realizuje mniejsze funkcjonalności przy mocnym wsparciu zespołu, mid potrafi ogarnąć cały moduł od A do Z (wraz z testami i prostą architekturą), a senior widzi i projektuje cały system, przewiduje skutki decyzji, wspiera innych i bierze odpowiedzialność za jakość całości.

Przed rozmową zadaj sobie kilka brutalnie szczerych pytań: jakie elementy projektu robiłeś naprawdę sam, od analizy po wdrożenie? czy ktoś mógł na Tobie „zawiesić” kluczowy fragment systemu? czy potrafisz nie tylko napisać kod, ale też uzasadnić wybór bibliotek, wzorców i architektury? Rzeczywistość jest taka, że uczciwa samoocena pomaga dobrać odpowiedni poziom stanowiska i przygotować przykłady, które pokażą Cię w najlepszym świetle.

Jakie są typowe etapy rozmowy technicznej i jak się pod nie przygotować?

Najczęściej spotkasz: krótki technical screening (telefoniczny/online), zadanie domowe, live coding, rozmowę o architekturze/system design oraz code review Twojego kodu. Każdy etap testuje coś innego – od podstawowych umiejętności, przez styl pisania kodu, po sposób komunikacji i myślenia o systemach.

Zamiast próbować „być dobrym we wszystkim naraz”, rozbij przygotowania: pod screening powtórz fundamenty i szybkie pytania, pod zadanie domowe skup się na czytelności, testach i dokumentacji, pod live coding przećwicz myślenie na głos, a pod architekturę – omawianie swoich projektów z perspektywy całości systemu, nie tylko pojedynczych klas czy komponentów.