Jak przygotować się do rozmowy kwalifikacyjnej na junior developera: praktyczny przewodnik dla początkujących w IT

Zanim wyślesz CV: czy naprawdę jesteś gotowy na rozmowę?

Ocena punktu wyjścia – gdzie jesteś dziś?

Zanim klikniesz „Aplikuj”, odpowiedz sobie szczerze na jedno pytanie: na jakim poziomie jestem teraz? Nie za pół roku, nie „gdy skończę kurs”, tylko dziś. Bez tego trudno ułożyć sensowny plan przygotowania do rozmowy kwalifikacyjnej na junior developera.

Najpierw doprecyzuj cel. Czego szukasz:

• stażu / praktyk – gdy dopiero zaczynasz, masz głównie projekty z kursów i uczelni,
• pierwszej pracy jako junior developer – gdy potrafisz już samodzielnie coś napisać od zera,
• pierwszej pracy po przebranżowieniu – gdy masz doświadczenie w innej branży i kilka własnych projektów IT.

Zadaj sobie proste pytania: jaki masz cel na najbliższe 3 miesiące? Czy mierzenie od razu w „pełnego” juniora jest realne, czy mądrzejszym krokiem będzie staż lub rola „junior/trainee”? Jeśli na większość ogłoszeń reagujesz myślą: „prawie nic z tego nie umiem”, zacznij od lżejszych pozycji i budowania fundamentów.

Zrób krótką inwentaryzację kompetencji. Weź kartkę lub notatnik i wypisz cztery obszary:

• Język główny (np. JavaScript, Python, Java, C#, PHP, Kotlin) – co konkretnie umiesz: pętle, funkcje, klasy, obsługa błędów?
• Framework / biblioteka (React, Angular, Spring, Django, .NET, Laravel) – z czym miałeś kontakt, co sam konfigurujesz?
• Narzędzia (Git, GitHub/GitLab, IDE, Docker, system kontroli wersji) – czy potrafisz zrobić commit, branch, pull request?
• Podstawy CS (algorytmy, struktury danych, HTTP, bazy danych) – na jakim poziomie rozumiesz, co się dzieje „pod spodem”?

Przy każdym punkcie określ poziom: „umiem użyć”, „umiem wytłumaczyć”, „tylko widziałem na kursie” albo „nie mam pojęcia”. Nie upiększaj, bo to wyjdzie na rozmowie. Pytanie do siebie: co już próbowałeś robić samodzielnie w tym stacku – prostą aplikację, mini API, prostą stronę, skrypt automatyzujący coś w życiu?

Co już umiesz, a czego kompletnie nie ogarniasz

Przygotowanie do rozmowy rekrutacyjnej IT zaczyna się od dopasowania oczekiwań. Junior developer nie musi znać wszystkiego, ale powinien znać swoje braki i potrafić o nich rozmawiać.

Dla uporządkowania możesz użyć prostego podziału:

• Strefa „zielona” – zagadnienia, o których jesteś w stanie opowiadać 5–10 minut, pokazując kod: np. „obsługa formularzy w React”, „CRUD w Django”, „podstawowy serwis w Springu”.
• Strefa „żółta” – coś robiłeś, ale nie czujesz się pewnie: np. unit testy, integracja z API, konfiguracja bazy.
• Strefa „czerwona” – terminy, których nie rozumiesz: np. „dependency injection”, „SOLID”, „CQRS”, „event sourcing”, „asynchroniczność”.

Pytanie kontrolne: gdyby rekruter poprosił cię o wyjaśnienie, co dokładnie dzieje się po wpisaniu adresu w przeglądarce, potrafiłbyś opowiedzieć proces krok po kroku, swoim językiem? Jeśli nie, notujesz to jako temat do ogarnięcia przed rozmową.

W podobny sposób sprawdź swoje umiejętności miękkie: czy umiesz opowiadać o sobie bez jąkania się, czy potrafisz opisać swój projekt w 2–3 zdaniach, czy umiesz przyznać się do błędu i opisać, czego cię nauczył.

Jak sprawdzić „minimum techniczne” na juniora w Twoim stacku

Jeśli dany temat pojawia się w co drugim ogłoszeniu, a ty nie umiesz go użyć ani wytłumaczyć – to kandydat numer jeden do przećwiczenia przed rozmową.

Prosty plan dojścia do „progu rozmowy”

Gdy już wiesz, gdzie jesteś i czego oczekuje rynek, potrzebny jest prosty plan. Masz na przykład 4–6 tygodni przed pierwszymi rozmowami? Ułóż go realistycznie zamiast rzucać się na wszystko naraz.

Plan minimum może wyglądać tak:

• 2–3 małe projekty w jednym stacku (np. jedna aplikacja webowa, jedno API, jeden mini-projekt narzędziowy).
• Opanowane podstawowe narzędzia: Git (commit, branch, merge, pull request), praca z GitHubem, IDE, proste debugowanie.
• Powtórzona podstawowa teoria: typy danych, kolekcje, pętle, funkcje, OOP, HTTP, CRUD na bazie danych.
• Przećwiczona komunikacja: opowieść o sobie, o projektach, kilka odpowiedzi na typowe pytania HR.

Każdy projekt powinien być mały, ale „zamknięty”: uruchamialny, z krótkim opisem w README, najlepiej z linkiem do demo (np. na Heroku, Railway, Vercel, Netlify). Ważniejsze niż ilość jest to, czy umiesz opowiedzieć o decyzjach, które podjąłeś w projekcie.

Zapytaj siebie: gdyby rekruter poprosił „pokaż mi swój kod, z którego jesteś zadowolony”, co byś otworzył? Jeśli nie masz takiego fragmentu – to pierwszy cel na najbliższy tydzień.

Jak czytać ogłoszenie o pracę, żeby przygotować się mądrze

Rozbij ogłoszenie na konkretne wymagania

Ogłoszenie o pracę to ściąga z tego, co prawdopodobnie usłyszysz na rozmowie. Większość kandydatów czyta je powierzchownie. Spróbuj inaczej: usiądź z jednym ogłoszeniem i potraktuj je jak zadanie analityczne.

Weź tekst ogłoszenia i rozbij go na cztery sekcje:

• Technologie must have – lista, którą firma wypisuje jako kluczową (np. „JavaScript, React, Git, REST API, SQL”).
• Technologie nice to have – przydatne, ale niekonieczne (np. „Redux”, „Docker”, „Cypress”).
• Obowiązki – co będziesz faktycznie robił (np. „rozwój frontendu aplikacji SaaS dla klientów B2B”).
• O firmie i produkcie – komu służy produkt, jaki jest rynek, jak wygląda zespół.

Przy każdej technologii z listy must have dopisz pytanie: „Czy potrafię wytłumaczyć i pokazać w kodzie, jak tego używam?”. Jeśli przy czymś odpowiadasz „nie bardzo” – to jeden z priorytetów na przygotowanie.

Jak z ogłoszenia wyciągnąć listę tematów technicznych

Rekruter techniczny zwykle bazuje na ogłoszeniu. Zastanów się: gdybyś sam miał kogoś przepytać pod to ogłoszenie, o co byś zapytał? Z takiego spojrzenia z drugiej strony rodzi się praktyczna lista tematów.

Przykład: ogłoszenie na „Junior Java Developer” zawiera:

• Java 11+
• Spring Boot
• REST API
• Relacyjne bazy danych (PostgreSQL)
• Git

Z tego robisz listę pytań, które „prawie na pewno” padną:

• Podstawy Javy: typy danych, kolekcje, wyjątki, klasy, interfejsy.
• Spring Boot: czym jest, jak tworzy się prosty kontroler, co to jest dependency injection.
• REST API: czym jest, jakie ma zasady, jak wygląda przykładowy endpoint.
• SQL: jak zrobić SELECT, INSERT, UPDATE, DELETE, proste JOINy.
• Git: czym jest commit, branch, merge, pull request, konflikt.

Lista jest gotowa – możesz do każdego punktu dopisać: „przeczytać”, „napisać przykład”, „opowiedzieć na głos”. Przygotowanie staje się konkretne, a nie ogólne „powtórzyć Jave”.

„Must have” a „nice to have” – gdzie postawić granicę

Nie każde wymaganie ma tę samą wagę. Firmy lubią dopisywać wiele technologii „mile widzianych”, żeby zyskać elastyczność, ale na rozmowie skupią się na trzonie.

Jak odróżnić jedno od drugiego?

• Jeśli technologia pojawia się w sekcji „Wymagania” bez słowa „mile widziane” – traktuj jako must have.
• Jeśli stoi w sekcji „Dodatkowym atutem będzie” – to nice to have.
• Jeśli jest powtórzona kilka razy (w opisie technologii, obowiązków, projekcie) – to kluczowy element stacku.

Twój cel: na must have musisz umieć odpowiedzieć spokojnie, bez zgadywania. Na nice to have wystarczy, że kojarzysz pojęcie i umiesz powiedzieć: „Nie używałem tego jeszcze w projekcie, ale wiem, do czego służy i jak zacząć”. Na juniora to wystarcza.

Jak sprawdzić technologię i domenę firmy

Rozmowa techniczna dla juniora to nie tylko suche pytania. Dobrze jest rozumieć, co ta firma robi i w jakim kontekście będziesz pisał kod. Zadaj sobie pytanie: czy wiesz, co dokładnie budują i kto tego używa?

Prosty research przed rozmową:

• Wejdź na stronę firmy: przeczytaj zakładkę „Product” / „Solutions” / „About us”.
• Znajdź ich produkt w sieci: demo, dokumentacja, opinie użytkowników.
• Poszukaj ich profilu na GitHubie – czasem mają otwarte projekty.
• Sprawdź profil firmy na LinkedIn – zobacz, jak opisują technologię i zespół.

Podczas rozmowy możesz odwoływać się do tego kontekstu. Np. jeśli budują aplikację B2B, możesz wspomnieć, że rozumiesz znaczenie stabilności, raportowania błędów, bezpieczeństwa danych. To od razu przenosi cię z poziomu „programuję sobie do szuflady” na „rozumiem, że robię narzędzie dla realnych klientów”.

Ćwiczenie: jedno ogłoszenie, dziesięć rzeczy do ogarnięcia

Weź dowolne ogłoszenie, które cię interesuje, i zrób ćwiczenie przygotowujące do rozmowy:

1. Wypisz wszystkie technologie z ogłoszenia.
2. Przy każdej z nich dopisz jedno konkretne pytanie, jakie może paść.
3. Dodaj minimum 3 pytania o projekt firmy, produkt, sposób pracy.
4. Wybierz 10 punktów, które są dla ciebie najważniejsze lub najtrudniejsze.
5. Do każdego przygotuj krótką odpowiedź (ustnie + ewentualnie kod).

Przykładowa dziesiątka rzeczy do ogarnięcia może wyglądać tak: „Czym różni się let od var w JS?”, „Jak w Spring Boot zrobić endpoint GET?”, „Co to jest JOIN w SQL?”, „Jak rozwiązywałeś konflikt merge w Git?”, „Jak firma monitoruje błędy w produkcji?”.

Zauważysz, że po wykonaniu takiego ćwiczenia kolejne ogłoszenia czytasz już inaczej – od razu widzisz listę tematów do przygotowania zamiast chaotycznej ściany wymagań.

CV i profil online: co musi zobaczyć rekruter, zanim z Tobą pogada

CV początkującego – konkretnie, bez „ściemy”

CV początkującego programisty musi spełnić jeden cel: pokazać, że umiesz coś realnie zrobić, nawet jeśli nie masz komercyjnego doświadczenia. Rekruter techniczny sprawdza głównie: czy kodujesz, w czym kodujesz i jak poważnie do tego podchodzisz.

W CV na junior developera bez doświadczenia komercyjnego zamiast na „Stanowiska pracy” postaw akcent na:

• Projekty – własne, z kursów, open source.
• Umiejętności techniczne – w jawnym układzie, z podziałem na poziom.
• Inicjatywy własne – blog, repozytoria, udział w hackathonach, meetupy.

Jeden projekt opisany konkretnie jest więcej wart niż pięć ogólnikowych. Zamiast pisać: „Aplikacja do zarządzania zadaniami”, pokaż:

• Stack: React, TypeScript, Node.js, Express, MongoDB.

Jak opisać projekty, żeby ktoś naprawdę chciał je kliknąć

Sprawdź swoje CV: czy po przeczytaniu opisu projektu sam miałbyś ochotę wejść w repozytorium? Jeśli nie – przebuduj je. Rekruter ma kilkanaście sekund, żeby zdecydować, czy warto otworzyć Twój GitHub.

Przy każdym projekcie dodaj 4 rzeczy w jasnej formie:

• Cel: jedno zdanie „po ludzku”, co to robi i dla kogo (np. „Prosta aplikacja do śledzenia wydatków dla jednej osoby”).
• Stack: technologie zgrupowane (frontend, backend, baza, narzędzia).
• Zakres Twojej pracy: co zrobiłeś konkretnie (np. „autoryzacja, integracja z API banku, testy jednostkowe”).
• Linki: GitHub + demo, jeśli jest (live lub screeny / GIF w README).

Zamiast „Aplikacja do zadań domowych” napisz:

• Opis: Webowa aplikacja do zarządzania zadaniami z priorytetami i terminami, z widokiem kanban dla jednej osoby.
• Stack: React, TypeScript, Vite (frontend), Node.js, Express (API), MongoDB (baza), Jest (testy).
• Moja rola: pełen projekt: architektura, endpointy API, logika frontendu, wdrożenie na Vercel + Railway.
• Linki: GitHub | Demo

Zadaj sobie pytanie: gdy rekruter przeczyta ten opis, czy będzie wiedział, po co jest projekt i co konkretnie w nim zrobiłeś?

Umiejętności techniczne – jak nie przesadzić z „midem na papierze”

Kuszące jest wpisanie długiej listy technologii. Tylko że na rozmowie każdą z nich ktoś może dotknąć jednym pytaniem. Po co sobie to utrudniać?

Podziel umiejętności na 2–3 poziomy. Prosty układ:

• Komfortowo używam w projektach (główne technologie, z których chcesz być rozliczany).
• Używałem w 1–2 projektach (ogarniesz, ale możesz potrzebować chwili na przypomnienie).
• Dopiero poznaję (tylko jeśli ma związek z ogłoszeniem).

Przykład sekcji dla kandydata na junior fronta:

• Komfortowo używam: JavaScript (ES6+), TypeScript, React, HTML, CSS (Flexbox, Grid), Git, REST API.
• Używałem w 1–2 projektach: Next.js, Redux Toolkit, Jest, Cypress, Docker (lokalne dev-setupy).
• Dopiero poznaję: Node.js, Express, PostgreSQL.

Zapytaj siebie szczerze: gdy ktoś powie „opowiedz mi o tym, jak używałeś X w praktyce”, przy którym poziomie czujesz spokój, a przy którym kombinujesz? To dobre kryterium, gdzie technologię wstawić.

Zamiast zgadywać, czego będzie oczekiwał rekruter, poszukaj realnych punktów odniesienia. Jak?

• Przejrzyj 10–20 ogłoszeń o pracę na juniora / staż w Twojej technologii i zapisz powtarzające się wymagania.
• Przeanalizuj profile juniorów na LinkedIn, którzy już pracują – jakie technologie i projekty prezentują.
• Sprawdź publiczne repozytoria firm (np. biblioteki open source) – zobaczysz, jak wygląda produkcyjny kod w tym stacku.
• Zajrzyj na blogi techniczne, jak praktyczne wskazówki: informatyka, żeby złapać kontekst technologiczny: jak myślą praktycy, jak opisują problemy.

Dobrym źródłem inspiracji są także zadania z bootcampów czy repozytoria „awesome-<technologia>” na GitHubie. Zwróć uwagę, jakie tematy się przewijają: np. routing, autoryzacja, testy, wzorce projektowe, zapytania SQL. To właśnie tworzy „minimum techniczne” na rozmowę techniczną dla juniora.

Profil na LinkedIn i GitHub – dwa miejsca, które pracują na Ciebie 24/7

CV to jedno. Coraz częściej rekruter zaczyna od LinkedIna i GitHuba. Jak wykorzystujesz te dwa miejsca?

Na LinkedIn zadbaj o kilka konkretów:

• Headline: zamiast „Student Informatyki” – „Junior Java Developer (Spring, REST, SQL) | Projekty: API do…”.
• About / Info: krótka historia, co robisz teraz, czego szukasz i w jakich technologiach.
• Projects / Featured: podpięte 2–3 kluczowe repozytoria lub demo.
• Aktywność: od czasu do czasu krótki post o tym, czego się uczysz, link do projektu, mały wniosek z nauki.

GitHub ma pokazywać jedną rzecz: kodujesz regularnie i świadomie. Co możesz poprawić już dziś?

• Czy nazwy repozytoriów coś znaczą (np. expense-tracker-api zamiast projekt1)?
• Czy w ważniejszych projektach masz sensowne README (opis, stack, instrukcja uruchomienia, screen)?
• Czy widać historię commitów – mniejsze kroki, opisy po angielsku lub po polsku, ale z sensem?
• Czy trzymasz śmieciowe repozytoria publicznie, czy wrzuciłeś je w prywatne?

Pomyśl: jeśli rekruter miałby zobaczyć tylko Twój GitHub bez CV, co by zrozumiał o Twoim poziomie i zainteresowaniach?

Portfolio i projekty: o czym rozmawiać, kiedy „nie masz doświadczenia”

Jak wybrać projekty do rozmowy

Nie musisz opowiadać o wszystkim, co kiedykolwiek napisałeś. Lepiej przygotować 2–3 projekty „flagowe” niż 10 przeciętnych.

Jak je wybrać?

• Pasują do stacku z ogłoszenia (np. jeśli aplikujesz na Java + Spring, wybierz projekt w Javie, nawet mniejszy).
• Masz w nich coś do opowiedzenia poza „zrobiłem tutorial” – jakieś decyzje, trudności, refaktoryzacje.
• Potrafisz je uruchomić i pokazać w rozsądnym czasie (lokalnie lub w przeglądarce).

Zadaj sobie pytanie: który projekt najlepiej pokazuje, jak myślisz jako developer, nawet jeśli jest mały?

Struktura opowieści o projekcie

Gdy rekruter mówi: „Opowiedz o jakimś swoim projekcie”, wiele osób zaczyna od technologii. Lepiej zacząć od kontekstu, a dopiero potem wejść w tech.

Prosta struktura, którą możesz przećwiczyć:

1. Problem / cel: co chciałeś rozwiązać, dla kogo to jest.
2. Twoja rola: co konkretnie robiłeś (szczególnie przy projektach zespołowych).
3. Stack i decyzje techniczne: dlaczego wybrałeś te technologie, a nie inne.
4. Największe wyzwanie: co nie działało, co trzeba było zmienić.
5. Co byś dziś zrobił inaczej: pokazujesz rozwój i autorefleksję.

Przykładowe 2–3 zdania do przećwiczenia na głos:

„Zbudowałem prostą aplikację do śledzenia wydatków, bo brakowało mi narzędzia, które działa szybko w przeglądarce i nie wymaga logowania. Zrobiłem frontend w React + TypeScript, backend w Node.js. Największym wyzwaniem było zaprojektowanie walidacji danych po obu stronach. Pierwsza wersja miała sporo duplikacji logiki, więc później wyciągnąłem wspólne schematy do osobnego modułu. Dziś od razu pomyślałbym o tym etapie projektowania.”

Pomyśl: czy umiałbyś w podobny sposób opowiedzieć o jednym ze swoich projektów, bez „yyy”, bez gubienia wątków?

Jak mówić o projektach „z kursu”

Wielu początkujących ma tylko projekty z kursów. To nie problem, pod warunkiem, że pokażesz, że zrobiłeś coś więcej niż instrukcja.

Możesz powiedzieć wprost, że projekt był inspirowany kursem, ale dodaj:

• co zmieniłeś (np. layout, sposób zapisu danych, dodatkowe funkcje),
• co dodałeś samodzielnie po zakończeniu lekcji,
• czego się nauczyłeś ponad to, co było w materiale.

Przykład:

„Projekt powstał na bazie kursu X, ale po ukończeniu lekcji przebudowałem część odpowiedzialną za logowanie – dodałem reset hasła i walidację po stronie serwera. Przeniosłem też stan z lokalnych hooków do Redux Toolkit, żeby przećwiczyć pracę ze storem.”

Zadaj sobie pytanie: czy potrafisz wskazać przynajmniej jedną rzecz, którą zrobiłeś inaczej niż w kursie w każdym z Twoich projektów?

„Brzydki” kod w portfolio – co z tym zrobić

Każdy, kto się uczy, ma projekty napisane „na chama”. Usuwanie ich w panice tuż przed rozmową nie zawsze ma sens. Czasem lepiej pokazać ślad rozwoju.

Możesz podejść do tego tak:

• Zostaw starsze projekty, ale nie eksponuj ich jako główne – niech będą w tle.
• Przy jednym projekcie zrób widoczną gałąź refactor – pokaż, jak zmieniałeś kod.
• Na rozmowie możesz odwołać się do tego, pokazując, jak poprawiasz swój styl pisania.

Przykładowe zdanie:

„Ten projekt jest jednym z pierwszych – widać, że logika komponentów jest mocno pomieszana ze stanem globalnym. Przy kolejnym projekcie zadbałem o wydzielenie logiki do osobnych hooków i kontenerów, mogę pokazać różnicę.”

Pytanie do Ciebie: który projekt mógłbyś potraktować jako pole do pokazania takiego „przed i po”?

Część „miękka” rozmowy: kim jesteś, po co Ci ta praca i czego oczekujesz

Krótka historia o Tobie – bez bajek i bez chaosu

Pytanie „Proszę opowiedzieć coś o sobie” pada prawie zawsze. Jeśli nie masz przygotowanej odpowiedzi, łatwo wpaść w dygresje, opowiadać o całym życiu albo mówić zbyt technicznie.

Ułóż prostą narrację w 3 krokach:

1. Skąd przychodzisz: studia, inna branża, kurs – dwa zdania.
2. Co robisz teraz: nauka, projekty, technologia, w którą celujesz.
3. Dokąd zmierzasz: jaką rolę i środowisko pracy widzisz dla siebie w najbliższym czasie.

Przykład:

„Przez kilka lat pracowałem w obsłudze klienta w branży e-commerce. Od dwóch lat uczę się programowania, skupiłem się na JavaScripcie i React. W wolnym czasie rozwijam dwa własne projekty i biorę udział w meetupach front-endowych. Szukam pierwszej roli jako junior frontend developer w zespole, od którego mogę się uczyć dobrych praktyk pracy z kodem i procesem wytwarzania.”

Zadaj sobie pytanie: czy Twoja historia mieści się w 60–90 sekundach i jest logiczna?

Dlaczego chcesz tę konkretną pracę, a nie „jakąkolwiek w IT”

Odpowiedź „szukam pierwszej pracy w IT” jest zrozumiała, ale mało wyróżnia. Lepiej pokazać, że przemyślałeś wybór firmy i roli.

Przygotuj 2–3 elementy, do których możesz się odwołać:

• technologie, których używają i które pokrywają się z Twoimi projektami,
• domena (np. fintech, edukacja, e-commerce), która Cię interesuje,
• sposób pracy, który opisali (np. code review, pair programming, małe zespoły).

Przykład wypowiedzi:

„Interesuje mnie ta rola, bo pracujecie w stacku React + TypeScript + Node, którego używam w swoich projektach. Dodatkowo działacie w obszarze edukacji online – sam korzystam z podobnych platform i widzę, jakie problemy można tam rozwiązywać. Po opisie ogłoszenia wnioskuję też, że stawiacie na code review i współpracę w małym zespole, co jest dla mnie ważne na początku kariery.”

Pomyśl: czy potrafisz tak odpowiedzieć, odwołując się do konkretnej oferty, a nie do „branży IT” ogólnie?

Jak mówić o swoich mocnych i słabych stronach

Pytanie o plusy i minusy potrafi być niewygodne. Zamiast uniwersalnych haseł w stylu „sumienny, punktualny”, podejdź do tego jak do mini-case’ów.

Przy mocnych stronach:

• wybierz 1–2, które mają znaczenie dla pracy developera (np. systematyczność, dociekliwość, komunikacja),
• podaj krótki przykład zachowania, nie tylko cechę.

„Jestem systematyczny – od ponad roku codziennie po pracy poświęcam 1–2 godziny na kod. Dzięki temu udało mi się dowieźć trzy projekty od zera do działającego demo.”

Przy słabszych stronach:

• nie wybieraj „fałszywych wad” w stylu „jestem zbyt perfekcyjny”,
• pokaż, jak nad tym pracujesz.

„Mam tendencję do zbyt długiego siedzenia nad jednym problemem, zanim poproszę o pomoc. W ostatnim projekcie wprowadziłem zasadę, że po 45 minutach szukania rozwiązania samodzielnie piszę krótkie podsumowanie i proszę bardziej doświadczoną osobę o wskazówkę. Dzięki temu nie blokuję się na godzinami.”

Zadaj sobie pytanie: jakie 2–3 konkretne zachowania pokazują Twoje mocne strony, a przy jakich sytuacjach widzisz u siebie pole do poprawy?

Pytania o oczekiwania finansowe i rozwój – jak odpowiedzieć spokojnie

Temat pieniędzy często stresuje najbardziej. Bez przygotowania łatwo rzucić kwotę „z sufitu” albo zupełnie zablokować rozmowę.

Przed rozmową zrób trzy rzeczy:

• sprawdź widełki w podobnych ogłoszeniach na juniora w Twoim mieście / zdalnie,
• ustal dla siebie zakres: minimalna kwota, przy której praca ma sens, i poziom, z którego będziesz naprawdę zadowolony,

Jak reagować na pytanie o widełki: konkretne przykłady odpowiedzi

Kiedy usłyszysz: „Jakie są Pana/Pani oczekiwania finansowe?”, nie musisz odpowiadać jednym magicznym numerem. Masz kilka opcji – wybierz taką, która pasuje do etapu rekrutacji i Twojej pewności co do rynku.

Jeśli to pierwszy etap i wiesz jeszcze niewiele o zakresie obowiązków:

„Na tym etapie jestem otwarty na standardowe widełki dla junior developera w tym stacku w naszym regionie. Po wstępnym poznaniu zakresu obowiązków i oczekiwań z obu stron chętnie podałbym konkretny przedział.”

Jeśli masz już rozeznanie i znasz widełki rynkowe:

„Na podstawie ogłoszeń na podobne stanowiska i rozmów ze znajomymi z branży celuję w przedział X–Y brutto na umowie o pracę / B2B. Dla mnie ważne są też możliwości rozwoju i mentoring, więc jestem gotów rozmawiać o całości pakietu.”

Jeśli nie chcesz strzelić za nisko, możesz dopytać:

Dobrym uzupełnieniem będzie też materiał: Czemu komputer nie widzi dysku? Diagnoza portów, zasilania i ustawień BIOS — warto go przejrzeć w kontekście powyższych wskazówek.

„Zanim podam konkretną kwotę – czy możecie powiedzieć, jakie widełki przewidujecie na to stanowisko? Będzie mi łatwiej się odnieść, znając ramy budżetu.”

Zatrzymaj się na chwilę: czy umiałbyś odpowiedzieć w jednym z tych trzech wariantów spokojnym tonem, bez tłumaczenia się?

Jak mówić o rozwoju, żeby brzmieć ambitnie, ale realnie

Pytanie „Gdzie widzi się Pan/Pani za 2–3 lata?” nie jest testem jasnowidzenia. Rozmówca sprawdza, czy wiesz, po co Ci ta rola i jak chcesz z niej „wycisnąć” rozwój.

Możesz połączyć trzy elementy:

• obszar techniczny, który chcesz pogłębić,
• rodzaj odpowiedzialności, jaką chcesz brać,
• sposób nauki (mentoring, projekty, szkolenia).

Przykład:

„W ciągu najbliższych dwóch lat chciałbym z juniora stać się samodzielnym frontend developerem, który potrafi zaproponować rozwiązanie, a nie tylko zaimplementować zadanie. Szczególnie interesuje mnie obszar performance i dostępności aplikacji webowych. Liczę, że będę mógł brać udział w code review i stopniowo brać odpowiedzialność za całe moduły.”

Zadaj sobie pytanie: czy Twoja wizja rozwoju jest konkretna (co, jak, w jakim kierunku), czy raczej brzmi jak „chciałbym się rozwijać” bez treści?

Pytania o dyspozycyjność, nadgodziny i tryb pracy

Przy pierwszej pracy łatwo powiedzieć „dostosuję się do wszystkiego”. Tylko że potem to „wszystko” może oznaczać wieczne nadgodziny albo brak szans na spokojną naukę.

Warto wcześniej odpowiedzieć sobie na kilka pytań:

• czy możesz pracować pełen etat od razu, czy łączysz to ze studiami/inną pracą,
• czy szukasz pracy z biura, hybrydowej, czy zdalnej i dlaczego,
• jak reagujesz na nadgodziny: sporadyczne ok, czy kompletnie Ci nie odpowiadają.

Przykładowa odpowiedź, gdy studiujesz:

„Studiuję zaocznie, więc w tygodniu mogę pracować na pełen etat. W piątki po południu i soboty mam zajęcia, ale dotychczas łączyłem to z nauką programowania, więc nie powinno to wpływać na moją dyspozycyjność w godzinach pracy.”

Jeśli nie chcesz regularnych nadgodzin, ale nie chcesz też brzmieć jak ktoś sztywno trzymający się zegarka:

„Standardowo chciałbym pracować w normalnych godzinach, bo po pracy dużo się uczę. Rozumiem jednak, że zdarzają się krytyczne sytuacje, kiedy trzeba zostać dłużej – w takich przypadkach jestem elastyczny.”

Pomyśl: czego na pewno nie chcesz w swoim trybie pracy i czy umiałbyś o tym powiedzieć spokojnie i rzeczowo?

Przygotowanie do części technicznej: teoria, praktyka i… przyznawanie się do niewiedzy

Jak ustalić „bazę” techniczną pod rozmowę

Zanim zaczniesz powtarzać całą dokumentację z wybranej technologii, zadaj sobie jedno pytanie: jaki jest profil tej roli – frontend, backend, fullstack, QA, mobile?

Na tym etapie nie potrzebujesz wszystkiego. Szukaj wspólnego mianownika między:

• ogłoszeniem (stack, wymagania „must have”),
• tym, co masz w projektach,
• tym, co często pojawia się w pytaniach rekrutacyjnych na juniora (łatwo to znaleźć w sieci).

Na tej podstawie zrób krótką listę tematów „na pewno zapytają” – np. dla junior frontendu może to być:

• podstawy HTML/CSS (semantyka, box model, flex/grid),
• JavaScript (typy, zakresy, async/await, this, prototypy na poziomie podstawowym),
• framework (np. React – komponenty, props, state, podstawowe hooki),
• Git i praca z repozytorium,
• proste pytania o HTTP/REST.

Zadaj sobie pytanie: gdyby jutro padło pytanie z każdej z tych kategorii, przy której poczułbyś największy dyskomfort?

Powtórka teorii: jak nie utopić się w notatkach

Zamiast czytać wszystko od zera, potraktuj teorię jak check-listę.

Możesz użyć prostego schematu dla każdego tematu:

1. Definicja własnymi słowami – jedno zdanie, bez kopiowania z dokumentacji.
2. Przykład z kodu – drobny snippet, który pokazuje zastosowanie.
3. Typowy błąd – coś, co często się myli w tym obszarze.

Przykład dla async/await:

• Definicja: „Async/await to składnia upraszczająca pracę z obietnicami, pozwala pisać kod asynchroniczny w stylu zbliżonym do synchronicznego.”
• Przykład – prosta funkcja pobierająca dane z API.
• Błąd – zapominanie o try/catch lub obsłudze błędów.

Przejrzyj swoje notatki lub materiały z kursu i przy każdym temacie zrób takie mini-podsumowanie. Niech to będzie materiał do przejrzenia dzień przed rozmową.

Pomyśl: czy potrafisz jednym zdaniem i jednym przykładem wytłumaczyć kluczowe pojęcia ze „swojego” stacku?

Przygotowanie praktyczne: od zadań zadań algorytmicznych do mini-feature’ów

Większość rozmów technicznych na juniora ma dwa smaki:

• krótkie zadania algorytmiczne / z logiki (np. na kartce, w edytorze tekstu),
• proste zadanie „komercyjne”: dodanie funkcji, poprawienie błędu, mały refactor.

Dobrze jest przećwiczyć oba. Jak to ugryźć?

Przy zadaniach algorytmicznych:

• ćwicz pisanie kodu „na sucho”, bez podpowiedzi IDE (np. w zwykłym notatniku),
• po rozwiązaniu zadania spróbuj wytłumaczyć krok po kroku, co zrobiłeś,
• zwracaj uwagę na czytelność – nazwy zmiennych, komentarze, prosta struktura.

Przy zadaniach zbliżonych do pracy:

• weź jeden ze swoich projektów i spróbuj dodać małą funkcję w ograniczonym czasie, np. 30–45 minut,
• symuluj, że ktoś patrzy – rób commity z sensownymi opisami,
• po zakończeniu zapisz sobie, co sprawiło najwięcej trudności.

Zadaj sobie pytanie: kiedy ostatnio faktycznie mierzyłeś czas przy rozwiązywaniu zadania programistycznego?

Jak odpowiadać na pytania techniczne krok po kroku

Na rozmowie liczy się tok myślenia, a nie tylko poprawna odpowiedź. Nawet przy prostych pytaniach pokaż, jak dochodzisz do wniosków.

Przykładowy schemat odpowiedzi na pytanie teoretyczne:

1. Krótkie zdefiniowanie pojęcia własnymi słowami.
2. Prosty przykład użycia (może być opisowy, nie zawsze musisz mówić kodem).
3. Wspomnienie typowej pułapki lub kontekstu („kiedy bym tego użył / kiedy nie”).

Na pytanie: „Czym różni się let od var w JavaScript?” nie musisz wygłaszać wykładu o hoistingu, ale możesz powiedzieć:

„Oba służą do deklarowania zmiennych, ale let ma zakres blokowy i nie pozwala na ponowną deklarację w tym samym zakresie, a var ma zakres funkcyjny i jest hoistowany w nieintuicyjny sposób. W praktyce używałbym let lub const, a var raczej omijał.”

Pomyśl: czy Twoje odpowiedzi są raczej w stylu „strzelam słowami kluczowymi”, czy potrafisz je ułożyć w 2–3 logiczne zdania?

Kiedy przyznać się do niewiedzy i jak to zrobić dobrze

Nie znasz wszystkiego – to normalne. Rekruterzy to wiedzą. Sprawdzają, jak reagujesz, gdy czegoś nie wiesz.

Najgorsze, co możesz zrobić, to:

• udawać, że wiesz, i plątać się w odpowiedziach,
• zamykać się w jednym zdaniu: „Nie wiem”, bez żadnego rozwinięcia.

Lepszy schemat odpowiedzi, gdy nie znasz tematu:

1. Przyznaj wprost, że nie znasz / nie używałeś.
2. Odnieś się do czegoś podobnego, co znasz (jeśli to ma sens).
3. Opisz, jak byś się tego nauczył lub jak byś podszedł do problemu.

Przykład:

„Szczerze mówiąc, nie pracowałem jeszcze bezpośrednio z Dockerem. Znam jednak podstawy wirtualizacji i rozumiem ideę konteneryzacji – od strony użytkownika korzystałem z gotowych obrazów w projekcie kolegi. Gdybym miał z tego korzystać w pracy, zacząłbym od przejścia oficjalnego tutoriala i stworzenia prostego obrazu dla mojej aplikacji backendowej, żeby zobaczyć cały przepływ.”

Albo przy pytaniu stricte algorytmicznym:

„Nie pamiętam gotowego algorytmu do tego problemu, ale mógłbym spróbować podejścia brute-force, a potem poszukać optymalizacji, np. poprzez sortowanie danych lub użycie struktury typu mapa. Mogę na głos przejść przez swój tok rozumowania.”

Zadaj sobie pytanie: czy potrafisz na spokojnie powiedzieć „nie wiem”, dodając od razu, jak byś tę lukę uzupełnił?

Przygotowanie do zadań „na żywo”: live coding i zadania domowe

Coraz częściej firmy proszą o wykonanie zadania na żywo albo wysyłają zadanie domowe. Oba formaty testują coś więcej niż sam kod: komunikację, organizację pracy, umiejętność zadawania pytań.

Live coding – jak oswoić stres

Live coding przypomina trochę egzamin ustny. Kodujesz, a ktoś patrzy. Da się do tego przygotować.

Do kompletu polecam jeszcze: Jak budować sieć kontaktów w IT bez spamu: grupy, meetupy, wartościowe komentarze — znajdziesz tam dodatkowe wskazówki.

Prosty plan ćwiczeń:

• umów się ze znajomym, który będzie „rekruterem” i poprosi Cię o rozwiązanie prostego zadania,
• koduj, mówiąc na głos, co robisz i dlaczego,
• po 20–30 minutach poproś o feedback: co było niezrozumiałe, gdzie się gubiłeś.

Podczas właściwego live codingu pamiętaj, że:

• masz prawo doprecyzować zadanie („Czy wynik ma być posortowany?”, „Jakie zakresy danych zakładamy?”),
• lepiej mieć działające, proste rozwiązanie niż skomplikowane i nieskończone,
• widoczne poprawki w trakcie są ok – każdy popełnia literówki, chodzi o to, czy umiesz je znaleźć.

Pomyśl: czy masz choć jedną osobę, z którą mógłbyś przećwiczyć takie 30-minutowe live coding „na sucho”?

Zadanie domowe – jak nie wpaść w pułapkę perfekcjonizmu

Zadanie domowe kusi, żeby „zrobić wszystko idealnie” i siedzieć po nocach. W praktyce rekruter ma ograniczony czas na ocenę, więc najczęściej zwraca uwagę na:

• czy zadanie rozwiązuje problem z treści,
• czy kod jest czytelny i spójny,
• czy potrafisz opisać, jak to uruchomić i co zrobiłeś.

Dobrą praktyką jest ustawienie sobie twardego limitu czasu, np. 6–8 godzin łącznie. Podziel to na etapy:

1. zrozumienie wymagań i prosty szkic rozwiązania,
2. implementacja podstawowego przepływu,
3. sprzątanie kodu, dopisanie krótkiego README, ewentualnie kilka testów.

W README możesz też uczciwie napisać, czego nie zdążyłeś:

Najczęściej zadawane pytania (FAQ)

Jak sprawdzić, czy jestem gotowy na rozmowę kwalifikacyjną na junior developera?

Najpierw odpowiedz sobie szczerze: „Na jakim poziomie jestem dzisiaj?”. Nie za trzy miesiące, nie „jak skończę kurs”, tylko teraz. Przejdź po czterech obszarach: język główny (np. JavaScript, Python), framework (np. React, Spring), narzędzia (Git, IDE) i podstawy CS (algorytmy, HTTP, bazy danych). Przy każdym dopisz, czy: umiesz użyć, umiesz wytłumaczyć, tylko widziałeś na kursie, czy w ogóle nie kojarzysz.

Zadaj sobie kilka kontrolnych pytań: czy potrafisz samodzielnie napisać prostą aplikację od zera? Czy umiesz opowiedzieć o jednym projekcie w 2–3 zdaniach? Czy wiesz, jaki masz cel na najbliższe 3 miesiące – staż, rola junior/trainee, czy już „pełny” junior? Jeśli większość ogłoszeń brzmi jak chiński, zacznij od lżejszych pozycji i dopiero potem celuj wyżej.

Jakie minimum techniczne powinien mieć junior developer przed pierwszą rozmową?

Spójrz na swój stack i ogłoszenia, które cię interesują. Jeśli coś pojawia się w co drugim ogłoszeniu (np. REST API, Git, podstawy SQL) i nie potrafisz tego użyć ani wytłumaczyć, to jeszcze nie masz „progu rozmowy”. Minimum techniczne na start to zwykle: solidne podstawy jednego języka, znajomość jednego frameworka na poziomie prostego projektu, Git na poziomie commit/branch/merge oraz proste operacje na bazie danych.

Praktyczny test: czy jesteś w stanie w kilka godzin stworzyć małą aplikację (np. TODO, mini-API, prosty blog), wrzucić ją na GitHuba, dodać README i opowiedzieć, dlaczego zrobiłeś to tak, a nie inaczej? Jeśli tak – możesz spokojnie umawiać się na pierwsze rozmowy.

Jak czytać ogłoszenie o pracę na junior developera, żeby dobrze się przygotować?

Potraktuj ogłoszenie jak check-listę do rozmowy. Rozbij je na cztery części: technologie must have, technologie nice to have, obowiązki oraz informacje o firmie/produkcie. Przy każdej technologii must have dopisz pytanie: „Czy potrafię pokazać to w swoim kodzie i prosto wytłumaczyć?”. Jeśli nie – to temat do przećwiczenia przed rozmową, a nie „może się uda”.

Spróbuj wejść w rolę rekrutera technicznego: mając to ogłoszenie, o co byś zapytał kandydata? Z listy typu „Java, Spring Boot, REST, SQL, Git” zrób konkretne punkty: podstawy Javy, prosty kontroler w Springu, zasady REST, SELECT/INSERT/UPDATE w SQL, workflow z branchem i pull requestem w Git. Do każdego dodaj plan: przeczytać, napisać przykład, opowiedzieć na głos.

Na czym skupić się w przygotowaniach: na teorii, zadaniach zadań czy własnych projektach?

Zapytaj siebie: co najbardziej kuleje – teoria, praktyka czy umiejętność mówienia o tym? Dobry balans na 4–6 tygodni przed rozmowami wygląda tak: 2–3 małe projekty w jednym stacku, powtórka podstawowej teorii (typy danych, kolekcje, pętle, OOP, HTTP, CRUD na bazie danych) oraz ćwiczenie opowiadania o sobie i projektach na głos.

Teoria bez własnego kodu nie wystarczy, ale same projekty bez zrozumienia „co dzieje się pod spodem” też szybko się zemszczą przy pierwszych pytaniach typu „co się dzieje po wpisaniu adresu w przeglądarce?”. Dobrze działający schemat: najpierw mały projekt, potem doczytanie teorii pod to, co właśnie zrobiłeś, na końcu próba wytłumaczenia tego komuś innemu albo chociaż do lustra.

Jak przygotować się do pytań miękkich na rozmowie na junior developera?

Junior nie jest oceniany tylko z kodu. Zadaj sobie pytanie: czy umiesz mówić o sobie bez stresu i chaosu? Przygotuj krótką historię: skąd przyszedłeś, dlaczego programowanie, co już zrobiłeś (kurs, projekty, może freelancing), czego szukasz na najbliższe miesiące. Wystarczą 2–3 spójne minuty, ale przećwiczone kilka razy na głos.

Przygotuj też odpowiedzi na klasyki: „opowiedz o projekcie, z którego jesteś dumny”, „opowiedz o błędzie, którego się nauczyłeś”, „jak pracujesz, gdy czegoś nie wiesz?”. Pomyśl wcześniej o konkretnych sytuacjach. Na rozmowie nie chodzi o to, żebyś był idealny, tylko żebyś pokazał, że potrafisz się uczyć, przyznać do niewiedzy i wyciągać wnioski.

Czy mogę iść na rozmowę, jeśli wielu rzeczy jeszcze „nie ogarniam”?

Pytanie nie brzmi „czy wszystko umiesz”, tylko „czy wiesz, co już potrafisz, czego nie rozumiesz i jak o tym mądrze powiedzieć”. Junior nie musi znać wszystkiego. Potrzebuje za to zielonej strefy tematów, o których może mówić swobodnie, żółtej strefy rzeczy „robiłem, ale nie czuję się mistrzem” oraz świadomości czerwonej strefy – pojęć, których dopiero będzie się uczył.

Jeśli na must have z ogłoszenia większość wrzucasz w czerwoną strefę – jeszcze chwilę poczekaj i dobuduj podstawy. Jeśli masz sensowną zieloną strefę (np. małe projekty w jednym stacku) i potrafisz przyznać: „Tego jeszcze nie używałem, ale wiem, co to jest i jak zacząć”, śmiało umawiaj rozmowy. Same rozmowy też są elementem nauki.

Jak wybrać, czy celować w staż, trainee czy od razu juniora?

Na początek zadaj sobie trzy pytania: czy masz już projekty inne niż tylko z kursu? Czy potrafisz samodzielnie wystartować małą aplikację od zera? Czy większość wymagań z ogłoszeń „junior” brzmi dla ciebie znajomo, czy kompletnie obco? Jeśli dopiero kończysz kurs, nie masz własnych repozytoriów i większość ogłoszeń cię przytłacza, lepszym wyborem będzie staż albo rola trainee.

Jeżeli natomiast masz kilka własnych projektów na GitHubie, umiesz opowiedzieć o decyzjach technicznych i potrafisz korzystać z Gita, API i bazy danych – możesz spokojnie celować w ogłoszenia na juniora. Dobrym kompromisem jest podejście mieszane: równolegle wysyłasz CV na staże, role junior/trainee i pojedyncze oferty na juniora, obserwujesz feedback i po 1–2 miesiącach korygujesz kierunek.

Kluczowe Wnioski

• Zacznij od uczciwej oceny punktu wyjścia: jaki masz dziś poziom, jaki konkretny cel na 3 miesiące (staż, junior, przebranżowienie) i czy Twoje oczekiwania wobec stanowiska nie są o krok za daleko.
• Zrób prostą inwentaryzację kompetencji w czterech obszarach – język główny, framework, narzędzia, podstawy CS – i przy każdym elemencie zaznacz, czy „umiem użyć”, „umiem wytłumaczyć”, „tylko widziałem”, czy „nie mam pojęcia”. Co u Ciebie ląduje w której kolumnie?
• Podziel wiedzę na strefy: zieloną (o tym potrafisz mówić i pokazać kod), żółtą (coś robiłeś, ale niepewnie) i czerwoną (pojęcia bez zrozumienia) – to szybki kompas, co możesz pewnie pokazać na rozmowie, a co wymaga podciągnięcia.
• Sprawdź, czy ogarniasz „minimum techniczne” na juniora w swoim stacku: jeśli dany temat przewija się w większości ogłoszeń, a Ty nie umiesz go użyć ani wyjaśnić, trafia on na listę priorytetów do przećwiczenia przed pierwszą rozmową.
• Ułóż realistyczny plan 4–6 tygodni: 2–3 małe, ale domknięte projekty w jednym stacku (z README i możliwością odpalenia), opanowane podstawowe narzędzia (Git, IDE, GitHub), odświeżona teoria oraz przećwiczona historia o sobie i projektach – co z tego masz już dziś?

Źródła

• Cracking the Coding Interview. CareerCup (2015) – Pytania rekrutacyjne, algorytmy, przygotowanie do rozmów technicznych
• Programming Interviews Exposed: Coding Your Way Through the Interview. Wiley (2019) – Przygotowanie do rozmów, struktury danych, strategie odpowiedzi
• Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall (2008) – Dobre praktyki kodu, omawianie decyzji projektowych na rozmowie
• The Complete Software Developer’s Career Guide. Simple Programmer (2017) – Planowanie kariery, poziomy junior/mid, oczekiwania rynku
• The Tech Resume Inside Out. Gergely Orosz (2021) – Tworzenie CV developera, dopasowanie do ogłoszeń, projekty
• Ace the Software Engineering Interview. Apress (2022) – Struktura rozmów, typowe pytania techniczne i behawioralne
• Interviewing.io blog – Technical Interview Guides. Interviewing.io – Analiza rozmów technicznych, typowe błędy kandydatów juniorów
• Google Students – Technical Development Guide. Google – Podstawy CS: algorytmy, struktury danych, przygotowanie do rozmów
• Microsoft Learn – Prepare for technical interviews. Microsoft – Zakres wiedzy na rozmowy, przykładowe pytania i obszary CS
• Refactoring UI – Designing Beautiful User Interfaces. Refactoring UI (2018) – Opis projektów front‑end, decyzje projektowe przy prezentacji portfolio