fbpx
Rozmowa kwalifikacyjna - wywiad
Wywiad

Wyrzuć strusia przez okno – czyli jak zrobić dobre wrażenie na rozmowie kwalifikacyjnej [Wywiad]

O tym jak wygląda rozmowa kwalifikacyjna z punktu widzenia rekrutera, co zrobić, aby nawet nie znając odpowiedzi na pytanie pokazać się z jak najlepszej strony i jakie są skutki uczenia się definicji na pamięć – rozmawiałam niedawno z Krystyną Ślusarczyk – programistką .NET na poziomie Seniora, która do tej pory przeprowadziła już ponad osiemdziesiąt rozmów kwalifikacyjnych.

Zapraszam Was do przeczytania naszej rozmowy!


Krystyna, czy mogłabyś na początku powiedzieć coś o sobie? Czym się zajmujesz jako programistka i jak to się stało, że zostałaś rekruterką?

Jestem programistką z sześcioletnim doświadczeniem. Pracowałam już w czterech firmach, a aktualnie pracuję dla jednego z największych banków inwestycyjnych na świecie. Moje stanowisko ma dość nietypową nazwę – quant developer, co oznacza po prostu programistę, który musi posiadać również wiedzę na temat modeli matematycznych używanych w finansach.

Żeby wyjaśnić jak zostałam rekruterką muszę nakreślić pokrótce mój model zatrudnienia. Jestem kontraktorem – czyli inaczej mówiąc jestem zatrudniona na B2B (business to business – czyli model, w którym programista świadczy usługi jako firma [dopisek Marta]). Bardzo częstą praktyką w takich modelach zatrudnienia jest bycie zatrudnionym przez firmę pośredniczącą – czyli pomiędzy mną, a bankiem, dla którego pracuję, jest jeszcze jedna firma, która zajmuje się właśnie pośrednictwem przy zatrudnianiu programistów. Ta firma przeprowadza również pierwszy etap rekrutacji dla klientów – czyli potencjalni kandydaci do bycia zatrudnionymi przez bank najpierw przechodzą rozmowę kwalifikacyjną w firmie pośredniczącej, i dopiero jeśli dobrze im pójdzie, to są rekomendowani do banku.

I to ty te rozmowy prowadzisz?

Tak. Jako, że jestem na poziomie seniorskim, to zostałam zapytana, czy nie chciałabym weryfikować kandydatów. A że uważam, że to całkiem ciekawe zajęcie i przy okazji mogę się też sporo nauczyć – zgodziłam się.

Z jakich technologii prowadzisz rekrutacje i na jakie poziomy?

Rekrutuję głównie z .NET, ale czasami również weryfikuję wiedzę kandydatów z Front-endu i z baz danych. Jeśli chodzi o poziom, to zależy od docelowego klienta. Najwięcej kandydatów, którzy do mnie trafiają, aplikuje na poziom seniorski. Zdarzają się też midzi (mid developerzy – poziom pomiędzy Juniorem a Seniorem [dopisek Marta]), a czasami, jeśli kandydatowi na mida brakuje trochę wiedzy, ale zrobił na mnie dobre wrażenie, to rekomenduję go jako potencjalnego Juniora.

To powiedz mi może jak wygląda typowa przeprowadzona przez ciebie rozmowa kwalifikacyjna? Czy masz jakąś stałą procedurę postępowania, czy podchodzisz inaczej do każdej osoby?

Zacznijmy od tego, że prowadzę rozmowy przez telefon. Zarówno ja, jak i kandydat siedzimy wtedy przy swoich komputerach i ja udostępniam mu swój ekran. Dzięki temu mogę pokazywać kod, który widzimy oboje, i który chcę omawiać.

Jeśli chodzi o pytania – to mam gotowy zestaw, w którym znajduje się bardzo wiele pytań i w trakcie rozmowy dostosowuję je do kandydata, tego na jaki poziom jest rekrutowany, ale też tego jaką wiedzę wykazuje. Przykładowo: jeśli kandydat odpowiedział mi już na kilka trudnych pytań to wiem, że nie ma sensu zadawać mu tych prostszych, bo zapewne sobie z nimi poradzi. A jeśli kandydat słabo sobie radzi to wtedy zadaję mu pytania łatwiejsze, żebyśmy mieli o czym rozmawiać.

Na rozgrzewkę lubię zadawać pytanie, które jest dość proste, ale wiem, że kandydat słyszał je już wcześniej, ponieważ zanim taka osoba trafi do mnie, jest jeszcze wstępnie przepytywana przez nasz dział HR. Zaczynam od tego, ponieważ jeśli kandydat mi na takie pytanie nie odpowie, to dowiaduję się bardzo ważnej rzeczy: wiem, że pomiędzy tymi dwoma rozmowami nie chciało mu się sprawdzić odpowiedzi na pytanie, z którym na wcześniejszym etapie sobie nie poradził. A coś takiego robi na mnie bardzo złe wrażenie.

Czyli testujesz w ten sposób nie tylko wiedzę, ale też podejście kandydata.

Tak. Moją rolą jest nie tylko ocenianie wiedzy. Oczywiście, wiedza jest najważniejsza, ale zdarzało mi się rekomendować kandydatów, którzy byli trochę poniżej oczekiwanego poziomu – ale miałam przesłanki, aby sądzić, że są zdolni, będą się szybko uczyć i są zainteresowani programowaniem. To zresztą też łatwo wyłapać i są pytania, które zadaje specjalnie pod tym kątem.

Jakie?

Na przykład zdarza mi się zadać pytanie, o którym wiem, że jest bardzo trudne i praktycznie nikt nie zna na nie odpowiedzi. Obserwuję w ten sposób, jak kandydat reaguje w takiej sytuacji. Najgorszym co może zrobić – to ściemniać, próbować udawać, że zna odpowiedź. Pechowo dla takich osób ja znam ten temat bardzo dobrze i potrafię przepytać ich w taki sposób, żeby dowiedzieć się, czy faktycznie znają odpowiedź, czy tylko udają. A jeśli udają, to cóż, jest to dla mnie próba oszustwa i to również robi bardzo złe wrażenie. 

Czyli jakiego zachowania oczekujesz od kandydata, który nie zna odpowiedzi na pytanie?

Może powiem jakie reakcje robią najlepsze wrażenie przy takim pytaniu. Jeśli kandydat, mimo, że nie zna odpowiedzi, stara się zarysować kontekst wokół tematu i w pewien sposób zbudować podstawę do odpowiedzi – nawet jeśli jej nie zna. Poza tym dobre wrażenie robi na mnie stwierdzenie: “nie wiem, ale chciałbym się dowiedzieć” – ja zawsze takim osobom chętnie wytłumaczę jaka jest poprawna odpowiedź. Czasem bywa tak, że w trakcie mojego tłumaczenia kandydat ma “oświecenie” i resztę dopowiada już za mnie.

Źle wygląda natomiast, jeśli kandydat nie zna odpowiedzi, ale też widać, że ona go kompletnie nie interesuje. Po prostu mówi “nie wiem, idźmy dalej”. Albo co gorsza stwierdza, że pytam go o nieistotny detal techniczny i on nie uważa, że powinien znać się na takich rzeczach.

I co wtedy odpowiadasz?

Przytaczam jedną, albo dwie historie z pracy, gdzie nieznajomość tego detalu spowodowała… duży problem.

Mam wrażenie, że chciałaś powiedzieć “fakap” [śmiech].

Tak [śmiech], ale pomyślałam, że to nie pasuje do wywiadu.

Okej. Czyli wiemy już, że zaczynasz rozmowę prostym pytaniem i wiemy, co chcesz przetestować bardzo trudnym pytaniem. Jakie masz jeszcze inne, nazwijmy to – triki, albo metody jakie stosujesz podczas rozmowy?

Lubię pytać nie wprost o pewne rzeczy. Na przykład mogłabym zapytać co oznacza literka D w zasadach SOLID (SOLID – zasady dobrych praktyk w programowaniu obiektowym [dopisek Marta]). Ale jeśli zapytam wprost, to jest duża szansa, że kandydat udzieli mi odpowiedzi z pamięci – nie mam jednak gwarancji, że naprawdę to rozumie. Wolę więc napisać fragment kodu i zapytać jaki kandydat widzi w nim problem. Jeśli odpowie mi wtedy “tu jest złamana zasada D z SOLID” to mam pewność, że naprawdę rozumie, co ta zasada oznacza.

Bardzo lubię też pytania, które narastają. Pytam o jedną rzecz, a potem wchodzę w coraz większe szczegóły i badam, w którym momencie rozmówca przestaje nadążać. Pozwala mi to dość precyzyjnie określić na jakim jest poziomie. Jeśli odpadnie na początku – to nie jest dobrze, jeśli w połowie – to nadaje się na mida, a jeśli dotrzyma mi tempa do końca – to zwykle mam kandydata na seniora, bo ostatnie pytanie z serii jest zwykle bardzo trudne.

Jakie były statystyki prowadzonych przez ciebie rekrutacji? Ilu osobom dałaś zielone światło, a ile odrzuciłaś?

To zależy od klienta. Rekrutuję głównie dla dwóch dużych banków, nazwijmy je Bank A i Bank B. Bank A chce zatrudniać tylko najlepszych z najlepszych, więc rekomenduję im kandydatów, którzy w mojej sześciostopniowej skali dostali sześć. Z małymi wyjątkami – czasem też przepuszczam kogoś, kto dostał pięć, ale bardzo dobrze się zapowiadał. A do banku B rekomenduję kandydatów już na poziomie czwórki minus.

I jakie były statystyki? 

Do banku A rekomenduję około jednego na dziesięciu kandydatów. Więc tu faktycznie jest ciężko. Do banku B rekomenduję mniej więcej 50-60% kandydatów. Każdy kandydat jest później weryfikowany dodatkowo przez klienta, więc teoretycznie jeszcze na tym etapie może mu się nie powieść.

Wspomniałaś, że nie patrzysz tylko na samą wiedzę, ale też na całokształt kandydata. Jestem więc ciekawa jakie cechy, jakie zachowanie podczas rozmowy powodują, że nawet jeśli osoba ma braki techniczne, to dajesz jej rekomendację dalej. I analogicznie, czy są jakieś cechy, które powodują, że odrzucisz nawet dobrego technicznie kandydata?

Jeśli chodzi o pozytywne cechy, to przede wszystkim dobre wrażenie robi na mnie to, że kandydat interesuje się programowaniem. Że jeśli nie zna odpowiedzi na jakieś pytanie, to chce ją poznać. Albo prosi mnie, żebym dała mu sekundę, bo chce je zapisać i później sprawdzić. To jest dla mnie zawsze plus. Również to, że jeśli powiem kandydatowi jaka jest odpowiedź na dane pytanie, to on dopytuje dalej i widzę, że chce dokładnie zrozumieć to czego wcześniej nie wiedział. 

Dobrze wygląda również, kiedy nawet jeśli kandydat nie zna odpowiedzi na pytanie, to potrafi powołać się na jakiś przykład –  z własnego projektu lub z pracy – gdzie na podobny problem natrafił. Widzę więc wtedy, że przynajmniej rozumie kontekst. 

Źle oceniam natomiast reakcję polegającą na tym, że ktoś mówi po prostu “nie wiem” i widzę, że odpowiedź go nie interesuje i najchętniej przeszedłby do kolejnego pytania. 

A odnośnie tego czy zdarza mi się nie rekomendować kandydata, który był dobry, ale mi się nie spodobał, to nie… ale jeśli mam przeczucie, że ta osoba z jakiegoś powodu może nie sprawdzić się w pracy pomimo posiadanej wiedzy, to piszę to jako, nazwijmy to, post scriptum do raportu z rozmowy.

Co na przykład może spowodować dopisanie takiego post scriptum?

Podam kilka przykładów. Raz, kiedy kandydat na rozmowie był ewidentnie pod wpływem alkoholu…

Żartujesz?!

Nie. Uznałam, że o tym zdecydowanie będę musiała wspomnieć w raporcie.

A dobrze mu szło?

Nie bardzo [śmiech]. Ale chyba czuł się pewnie, bo cały czas mi przerywał i nie dał dokończyć jednego zdania.

A inni?

Kilka razy zdarzyło się, że kandydat był po prostu bardzo niemiły. Na przykład – zadałam raz pytanie o bardzo znany algorytm wyszukiwania binarnego, a kandydat odpowiedział mi, że gdyby on się znał na takich rzeczach, to nie szukałby pracy tylko napisał książkę naukową.

Przecież to chyba najważniejszy algorytm w całym programowaniu! Powinni go znać nawet kandydaci na Juniorów.

No właśnie. Nawiasem mówiąc, pytanie o ten algorytm to jedno z najczęstszych pytań jakie zadaję. Jest na tyle prosty, że nawet jeśli ktoś go nie za, to jest szansa, że wymyśli go w locie.

Są jeszcze jakieś powody odrzucenia kandydata?

Tak, jest jeszcze jeden częsty powód, choć wtedy to nie jest moja decyzja, a decyzja działu HR. Chodzi o sytuacje, w których kandydat umawia się na rozmowę na konkretną godzinę, ja do niego dzwonię, a on nie odbiera telefonu, albo odbiera i mówi, że nie może teraz rozmawiać bo jest na przykład w sklepie, albo właśnie jedzie samochodem i chce żebym zadzwoniła później.

I co robisz w takiej sytuacji?

Jeśli ma sensowną wymówkę, to mówię, żeby odezwał się do działu HR bo być może rozmowa zostanie przełożona na inny termin. Ale są tacy, którzy po raz drugi również nie odbierają telefonu, albo nie mają czasu. Taki kandydat, choćby był Elonem Muskiem, już nie zostanie dalej rekomendowany.

Staram się wyciągnąć z tego co mówisz taką esencję wiedzy, którą mogłybyśmy przekazać czytelnikom mojego bloga, którzy w większości będą kandydować na Juniorów. A więc oczywistą sprawą jest, że trzeba mieć wiedzę techniczną, ale to co mogą zrobić dodatkowo, aby zwiększyć swoje szanse, to jest: szanować czas rekrutera i być dostępnym na rozmowę w terminie, na który się umówili, być miłym – wydaje się to naturalne, ale z tego co mówisz nie dla wszystkich, być trzeźwym [śmiech], być zainteresowanym pytaniami i nawet jeśli nie zna się odpowiedzi, to dopytywać o nią, notować pytanie i pomiędzy kolejnymi etapami rekrutacji sprawdzać to, czego się nie wiedziało. Co jeszcze?

Doradziłabym jeszcze sprawdzić najczęściej zadawane pytania z danego języka. Są pytania, które – przyznaję, są mocno teoretyczne i czasami jest mała szansa, że wykorzystamy wiedzę w nich zawartą w pracy. Ale są to pytania, które przewijają się przez prawie każdy zestaw jaki możemy znaleźć w Internecie. A więc, jeśli zadam takie pytanie i kandydat nie zna na nie odpowiedzi – to oznacza, że nie chciało mu się przed rozmową wpisać w Google “.NET pytania rozmowa kwalifikacyjna”. Jest to dla mnie raczej zły znak – bo wynika z niego, że ta osoba w ogóle nie przygotowywała się do rozmowy. No chyba, że jest geniuszem i nie musi się przygotowywać…

Ale gdyby była geniuszem, to znałaby odpowiedź na to pytanie…

No właśnie. Zresztą, kandydaci, którzy nie znają odpowiedzi na te popularne pytania, zazwyczaj nie radzą sobie też z innymi.

Czy masz jeszcze jakieś porady?

Niech pomyślę. Zawsze dobre wrażenie robi na mnie powołanie się podczas odpowiedzi na jakieś własne doświadczenia. Zresztą, często też dobieram pytania w pod tym kątem. Na przykład pytaniem, które często zadaje jest: “czym jest refleksja w C# i kiedy Pan (albo Pani) jej ostatnio używał?”. Dla niektórych kandydatów refleksja jest na tyle abstrakcyjnym mechanizmem, że choć potrafią podać definicję, to nigdy nie użyli jej w praktyce – zazwyczaj dotyczy to Juniorów.

Czyli sprawdzasz w ten sposób czy wiedza jest teoretyczna, czy też praktyczna?

Tak, ale też przy okazji czasem próbuję złapać kandydata w sidła. Pytam o scenariusze, o których wiem, że są najczęstszym powodem użycia refleksji. Na przykład takim scenariuszem są Unit Testy, który pisze prawie każdy programista. I jeśli ta osoba odpowie mi, że tak, oczywiście pisała Unit Testy, to wtedy pytam czy pisała taki specjalny atrybut nad klasą testującą, który nazywa się “TestFixture”, i który poprzez refleksję jest odpowiednio rozpoznawany przez mechanizm uruchamiania testów. A więc jeśli kandydat używał tego atrybutu, a mimo tego nie wie, że w ten sposób użył właśnie refleksji – to znaczy, że niespecjalnie interesuje go to, co pisze w kodzie i zadowala się tym, że coś działa, ale nie zadaje sobie pytania jak to działa.

Czyli po części sprawdzasz w ten sposób, czy to nie jest typ programisty, który kopiuje kod ze StackOverflow i nie zastanawia się jak on działa.

Tak. Zawsze dobre wrażenie robi na mnie, jeśli ktoś pokaże, że wgryzł się na przykład w to, jak działa dana struktura danych – czyli coś, od czego na co dzień jesteśmy odcięci. C# jest językiem wysokopoziomowym i dostarcza gotowe do użycia mechanizmy, więc teoretycznie nie musimy za dużo wiedzieć o tym, co się dzieje pod spodem… ale jeśli ktoś pokaże mi, że zdaje sobie sprawę z tych wewnętrznych mechanizmów, to zawsze jest dla mnie duży plus, bo oznacza, że interesuje się językiem.

Ok. Czyli jeszcze raz, podsumowując. Najważniejsze to: być zainteresowanym programowaniem, a nie tylko wykuć na pamięć odpowiedzi. Przygotować się do rozmowy zapoznając się z listami popularnych pytań. Szanować czas rekrutera.

Tak. Podkreślę jeszcze raz, że ważne jest, żeby nie uczyć się odpowiedzi na pamięć. Są takie pytania – na przykład o zasady SOLID, na które wszyscy udzielają prawie identycznych odpowiedzi, bo cytują to, co przeczytali w Internecie. Na przykład w wypadku litery L – zasady podstawienia Liskov – prawie wszyscy tłumaczą ją na przykładzie pól kwadratów i prostokątów.

A powinni poszukać własnego przykładu?

Tak [śmiech]. Ja na jednej rozmowie wytłumaczyłam ją przy użyciu strusia. Zasada ta mówi, że obiekty, które implementują dany interfejs albo dziedziczą z klasy bazowej, powinny zachowywać się rozsądnie – nie robić nic niespodziewanego w momencie, gdy zostają użyte w miejscu obiektu bazowego. Podałam tu więc przykład, że jeśli stoimy na wieży i mamy obiekty implementujące interfejs IPtak – to możemy je wyrzucać przez okno i one będą sobie latać. Wszystko działa świetnie do momentu, kiedy przez okno wyrzucimy strusia [śmiech]. Ponieważ choć struś implementuje interfejs IPtak to zachowuje się zaskakująco i wyrzuca wyjątek, kiedy zostaje, nomen omen, wyrzucony przez okno.

Mój aktualny szef – który wtedy prowadził ze mną rozmowę – po usłyszeniu tej odpowiedzi długo milczał i myślałam już, że uznał mnie za straszną idiotkę, ale potem powiedział, że jeszcze nikt mu nigdy nie wytłumaczył tak dobrze tej zasady. I zaraz potem dowiedziałam się, że jestem zatrudniona.

Dobra historia i też pokazuje, że chyba warto wykazać się pewnym indywidualizmem. Jeśli startujemy na stanowisko, na które obok nas aplikuje dwudziestu innych kandydatów, to być może jeśli wyrzucimy strusia przez okno, mamy szansę zostać lepiej zapamiętani.

Tak, to na pewno.

W takim razie dziękuję Ci bardzo za wywiad i wszystkie rady, jakimi się z nami podzieliłaś. Jestem przekonana, że moim czytelnikom bardzo się one przydadzą.

Ja również dziękuję, i życzę powodzenia na rozmowach!


Mam nadzieję, że dzisiejszy wywiad był dla Was interesujący, i że wykorzystacie rady Krystyny podczas własnych rozmów kwalifikacyjnych.

Chciałbym też Was zapytać o to, jakie są Wasze doświadczenia z programistycznych rozmów kwalifikacyjnych. Macie je już za sobą, czy planujecie ten etap dopiero za jakiś czas? Chcecie podzielić się radą, jak przez taką rozmowę przejść, czy przeciwnie – chcecie się czegoś dowiedzieć od osób, które mają większe doświadczenie? Jestem bardzo ciekawa, co na ten temat sądzicie i mam nadzieję, że napiszecie to w komentarzach.

Jeśli uważasz ten artykuł za interesujący, to będzie super jeśli podzielisz się nim ze swoimi znajomymi!

komentarzy 7

  • Tomek

    Dzięki za wywiad, przydatny. Szykuję się właśnie do rozmowy z c# i sprawdzę sobie te refleksje 😛 Ale przyznam, że trochę bym się bał trafić na panią Krystynę 😛

    • Marta

      A widzisz, nie pomyślałam o tym, że ta konkluzja będzie kolejną wartością dodaną tego wywiadu 🙂 Dzięki więc, za zwrócenie na nią uwagi.
      Przyszedł mi też do głowy mały komentarz: Krystyna prowadzi rozmowy kwalifikacyjne z kandydatami, którzy nie będą z nią w przyszłości współpracowali. Patrzy oczywiście na kompetencje miękkie, ale jednak pewnie łatwiej jej (tak zgaduję) o obiektywną ocenę kandydata, bo wie, że nie będzie razem z nim pracować.
      Ale przecież spora część rozmów kwalifikacyjnych (tych technicznych) prowadzona jest przez osoby, które szukają współpracownika do swojego zespołu. Sama zresztą takie właśnie rozmowy prowadziłam. W tej sytuacji jeszcze ważniejsze jest to czy dany kandydat jest po prostu fajny, czy potrafimy sobie wyobrazić wspólną z nim pracę, czy sprawia wrażenie kogoś, z kim będzie można się pośmiać z żartów i walczyć z błędami, które zaatakują w piątek po południu.
      Rozwinę ten temat za jakiś czas w artykule o Kroku 7 – czyli o rozmowie kwalifikacyjnej.

  • Marek

    No proszę. Uczę się Pythona już pół roku. Przechodziłem różne tutoriale z zadań na rozmowę kwalifikacyjną, ale jeszcze nigdy nie spotkałem się z wyszukiwaniem binarnym. Dobrze o nim wiedzieć!

  • Mateusz H.

    Czesc Marta 👋,

    Fajny wywiad. Dobrze wiedziec ze padaja pytania o SOLID na interview. Ja takze ucze sie Pythona od okolo pol roku i teraz zaczynam sie uczyc Django.

    Nie mialem zbyt duzo rozmow o prace jako programista. Jedna rozmowa zapadla mi w pamiec. Rekrutacje prowadzila firma Selleo uznana w ktoryms roku za najbardziej innowacyjna w prowadzeniu rekrutacji 😌.

    Byla to rekrutacja grupowa na ktorej rozwiazywalismy rozne zadania jak zagadka kryminalna czy zlozenie pojazdu z klockow lego 🤔.

    Niestety nie poszlo mi za dobrze.

    Mysle ze do kazdej rekrutacji trzeba bardzo dobrze sie przygotowac. Przerabiam teraz twoj kurs na Udemy.com i bardzo sobie cenie wiedze ktorej sie ucze dzieki tej nauce.

    Dzieki za swietny content, twoj blog i kurs na Udemy 👏.

    Czesc ✋.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

LinkedIn
Share