Dlaczego ten etap waży więcej, niż programiści się spodziewają
Większość programistów przesadnie przygotowuje się z algorytmów, a rozmowę behawioralną traktuje jak luźną pogawędkę. Komisje rekrutacyjne robią odwrotnie: etapy z kodowaniem to bramki typu zaliczone albo niezaliczone, a o poziomie stanowiska i o wyborze między wyrównanymi kandydatami decydują dowody z części behawioralnej. Oceniający nasłuchują konkretnych sygnałów: ownershipu wykraczającego poza własny ticket, osądu w warunkach niepewności, sposobu, w jaki przetrawiasz porażkę, i tego, czy praca z tobą dodaje energii, czy ją wysysa. Każde z poniższych pytań odpowiada jednemu z nich.
Odpowiedzi buduj metodą STAR (sprawdzone proporcje opisujemy w naszym centrum przygotowań): dziesięć sekund wprowadzenia, działania w pierwszej osobie, rezultaty z liczbami.
Pytania o spory techniczne
„Opowiedz o sporze z osobą z zespołu o podejście techniczne”. „Tech lead wybrał rozwiązanie, które twoim zdaniem było błędne. Jak wyglądała twoja reakcja?”
Pułapką jest historia, w której po prostu racja była po twojej stronie. Rekruterzy szukają sygnału, jak wygląda twoja niezgoda: czy rozumiesz drugie stanowisko na tyle dobrze, by uczciwie je przedstawić? Czy zamieniasz opinię w dowód, taki jak benchmark, prototyp albo spisany scenariusz awarii? Czy lojalnie realizujesz decyzję, gdy zapadnie nie po twojej myśli?
Mocny układ: „Moim zdaniem lepsze było X, zdaniem drugiej strony Y. Y miało realną zaletę, co od razu przyznaję: [podaj ją]. Mój mały benchmark, zrobiony po to, by sprawdzić tę obawę, pokazał [liczba]. Wybraliśmy zmodyfikowane Y, które obsługiwało gorącą ścieżkę (hot path). Co z tego wynoszę: zamiana sporu w eksperyment zajęła jedno popołudnie i oszczędziła trzy tygodnie dyskusji”.
Pytania o incydenty i porażki
„Opowiedz o tym, jak produkcja padła z twojej winy”. „Opisz swoją najgorszą awarię”. „Twój błąd trafił na produkcję i uderzył w użytkowników. Opowiedz, co się działo”.
Każdy senior ma na koncie awarię produkcji, a udawanie, że jest inaczej, wygląda na brak doświadczenia albo nieszczerość. Ocenie podlega wyłącznie twój stosunek do porażki:
- Weź na siebie cały łańcuch decyzji. „Pominięcie wdrożenia kanarkowego to była moja decyzja, bo diff wyglądał na trywialny” brzmi lepiej niż „system wdrożeń na to pozwolił”.
- Pokaż dyscyplinę pracy przy incydencie: wykrycie, najpierw ograniczenie skutków, potem przyczyna źródłowa, komunikacja z zespołami, których to dotknęło.
- Zakończ poprawką systemową: klasa testów, która teraz istnieje, alert, który teraz się odpala, punkt na checkliście, który teraz blokuje wdrożenie. Kultura blameless post-mortem to hasło, a poprawka systemowa to dowód, że naprawdę nią żyjesz.
Pytania o ownership i inicjatywę
„Opowiedz o czymś, co udało ci się ulepszyć, choć nikt o to nie prosił”. „Sytuacja, w której wychodzisz poza swoją rolę”.
Mida od seniora odróżnia zakres odczuwanej odpowiedzialności: własny ticket, wyniki zespołu czy kierunek całej organizacji. Dobry materiał na historię: naprawa niestabilnego zestawu testów, która odblokowała wszystkich, migracja zaproponowana i doprowadzona przez ciebie do końca, runbook dla on-calla spisany po bolesnym dyżurze, rozplątana zależność między zespołami. Dodaj nieefektowny koszt („poszły na to dwa moje piątki”), bo właśnie szczegóły o kosztach, za które nikt nie zapłacił, uwiarygodniają opowieści o inicjatywie.
Pytania o osąd techniczny
„Opowiedz o trudnej decyzji technicznej”. „Sytuacja, w której »wystarczająco dobre« wygrało u ciebie z »zrobionym jak należy«”. „Opisz kompromis, który okazał się błędem”.
Te pytania sprawdzają, czy myślisz kompromisami, czy absolutami. Odpowiedź na poziomie seniora wprost nazywa osie (opóźnienie czy koszt, termin dostarczenia czy dług techniczny, budować czy kupić), wskazuje ograniczenie, które przeważyło, i opisuje proces podejmowania decyzji: co trafiło do prototypu, z kim były konsultacje i co zmieniłoby twoje zdanie. Jeśli pytanie dotyczy błędnej decyzji, wniosek musi być operacyjny („teraz przed podjęciem decyzji zapisuję kryteria, przy których się z niej wycofam”), a nie sentymentalny („wiem już, że trzeba uważać”).
Pytania o współpracę i code review
„Co robisz, gdy autor kodu nie zgadza się z twoimi uwagami w review?” „Sytuacja, w której dostajesz ostry feedback”. „Jak wdrażasz juniora?”
- Konflikt w code review: oddziel uwagi blokujące (poprawność, bezpieczeństwo) od preferencji (styl), a w sprawie preferencji ustępuj wprost. Samo nazwanie tego rozróżnienia na głos jest sygnałem senioralności.
- Przyjmowanie feedbacku: wybierz historię, w której feedback zabolał i był słuszny. Przebieg: początkowa postawa obronna → weryfikacja → zmiana zachowania poparta dowodami.
- Mentoring: konkretne mechanizmy są warte więcej niż ogólne wrażenia: stały rytm pair programmingu, „pierwszy PR w pierwszym tygodniu”, stopniowo rosnący zakres zadań, oddanie juniorowi incydentu z tobą jako zabezpieczeniem.
Bank 15 pytań do ćwiczeń
Ćwicz na głos i ze stoperem: nagrywając się albo podczas próbnej rozmowy z asystentem AI do rozmów kwalifikacyjnych, który ją transkrybuje i omawia z tobą wynik. Celuj w sześć historii wielokrotnego użytku, które pokryją całą tę listę:
- Spór z tech leadem, w którym racja nie była po twojej stronie.
- Spór, w którym racja była po twojej stronie. Jak udało ci się przekonać resztę?
- Twój najgorszy incydent na produkcji, od początku do końca.
- Projekt z dużym opóźnieniem. Jaka była twoja reakcja, gdy pojawiły się pierwsze oznaki poślizgu?
- Coś, co powstało z twojej inicjatywy, choć nikt o to nie prosił. Czy było warto?
- Najtrudniejsza decyzja techniczna w twojej karierze.
- Sytuacja, w której szybkość wygrała u ciebie z jakością. Czy dziś decyzja byłaby taka sama?
- Fatalny kod w spadku po poprzednikach. Jakie były twoje faktyczne działania?
- Ostry feedback pod twoim adresem i to, co się po nim zmieniło.
- Wątek komentarzy w code review, w którym zrobiło się gorąco.
- Jak wyglądała twoja pomoc osobie z zespołu, która sobie nie radziła.
- Sytuacja, w której trzeba było odmówić Product Managerowi.
- Praca, z której masz największą satysfakcję, i jej największy kompromis.
- Ważna rzecz, która umknęła ci w code review.
- Dlaczego chcesz zmienić pracę i dlaczego właśnie u nas? (Tę odpowiedź miej w małym palcu. Ogólny schemat znajdziesz w centrum przygotowań.)
Twoje historie, ostre nawet pod presją.
ChadFlow słucha rozmowy, podsuwa ci osadzone w twoim kontekście pierwsze zdanie, gdy pada pytanie, a potem służy coachingiem na podstawie transkrypcji. Pozostaje przy tym niewidoczny przy udostępnianiu ekranu.
Pobierz ChadFlow