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�