Jak wygląda rozmowa techniczna?

Jak wspominałem we wpisie opisującym ogólnie proces rekrutacyjny, rozmowa techniczna może mieć część teoretyczną i praktyczną. Forma zadań, z jakimi się spotkałem w części praktycznej to między innymi:

• pisanie ręczne
  • kodu na kartce
  • pseudokodu na kartce
  • kodu na tablicy
• tworzenie projektu na komputerze
  • z rekruterem siedzącym obok
  • kiedy rekruter wyszedł na określony czas
  • bez dostępu do internetu
  • z dostępem do internetu
• pair programming z rekruterem

W tym tekście opiszę ogólny format rozmów technicznych, po czym omówię pokrótce każdy ze wspomnianych wyżej scenariuszy.

Razem czy osobno?

Pierwszą możliwą różnicą między różnymi rozmowami jest to, czy część techniczna jest przeprowadzana w obecności osoby zajmującej się HR. Zdarzały mi się rekrutacje, gdzie miałem rozmowy w cztery oczy najpierw z osobą techniczną, a potem z kimś od HR. Czasem kolejność była odwrotna, a czasem te osoby siedziały razem ze mną przez całą rozmowę.

Poziom trudności

Jak pisałem w tekście o procesie rekrutacyjnym, różnie może też być z poziomem trudności zadań i pytań teoretycznych. Niektórzy rekruterzy mają przygotowane pytania dostosowane do poziomu stanowiska i zadają tylko te pasujące do aktualnej oferty.

Inni w rozmowie idą od pytań najłatwiejszych, juniorskich, aż do momentu w którym sięgną Twojego limitu. Znaczy to, że na rekrutacji na juniora możesz dostać pytanie, które było przygotowane dla seniorów. Pozwala im to spojrzeć na Ciebie szerzej, niż tylko z perspektywy poziomu, na który aplikujesz.

W temacie poziomu trudności widziałem kiedyś ciekawą dyskusję. Niektórzy kandydaci narzekali na trudność rozmów rekrutacyjnych, a jedna osoba miała inne zdanie. Stwierdziła, że gdyby rekrutacja była zbyt prosta, to nie podjęłaby pracy w tej firmie. Przy łatwej rekrutacji można łatwo się dostać i uważa, że to źle. Znaczy to bowiem, że nawet jeśli Ty jesteś na wysokim poziomie, to Twoi współpracownicy mogą prezentować poziom utrudniający wam pracę.

Sprawdzanie teorii

Na większości rozmów, jakie miałem, rekruterzy techniczni sprawdzali zarówno teorię, jak i praktykę. Były jednak rekrutacje, gdzie poruszaliśmy tylko tematy ściśle teoretyczne.

Najczęstszym sposobem na sprawdzenie teorii jest bezpośrednie zadawanie pytań. Spodziewaj się wtedy, że zostaną poruszone zarówno tematy związane z danym stanowiskiem, jak i nawiązania do Twojego CV. Jak wspominałem w poradniku rekrutacyjnym, przejrzyj swoje CV przed rozmową. Powtórzenie sobie informacji o tym, co w nim masz, pomoże Ci zmniejszyć stres w trakcie rekrutacji.

Poza samą rozmową teoria może zostać sprawdzona przy użyciu testu z pytaniami otwartymi i zamkniętymi. Dostałem kiedyś do wypełnienia taki test i był on bazą do dalszej rozmowy i punktem wyjścia dodatkowych pytań.

Pisanie ręczne

Pisanie kodu długopisem znane jest zapewne większości osób, które studiowały informatykę. HRejterzy mają nawet film przedstawiający wykład z programistyki, który dobrze odzwierciedla tę metodę nauczania. Większość kandydatów na programistów z kolei przekonało się już, że to podejście już dawno zawitało też do rekrutacji.

Kod vs pseudokod

Rozwiązywanie zadań programistycznych na kartce jest często stosowaną praktyką rekrutacyjną. Konkretne oczekiwania wobec Twojego rozwiązania mogą być jednak różne na różnych rozmowach.

Część rekruterów chce sprawdzić tylko Twoje myślenie algorytmiczne, więc poprawność składniowa nie ma dla nich znaczenia. Czasem nawet mogą jasno zaznaczyć, że możesz przedstawić swoje rozwiązanie w formie pseudokodu.

Inni z kolei skupiają się na Twojej znajomości języka i uważają pisanie kodu na kartce za najlepszy sposób sprawdzenia jej. Będą Cię więc prosić o pisanie w konkretnym języku i zachowywanie wszystkich zasad, które w nim panują. Na jednej rekrutacji, usłyszałem, że jak rekruter zeskanuje tę kartkę i wrzuci do Visual Studio, to ma się skompilować. Było to niby półżartem stwierdzenie, że liczy się dla niego poprawność składniowa.

Czasem rekruterowi nie zależy na idealnej dokładności, ale na sprawdzeniu Twojej znajomości języka w dość ogólny sposób. Jeśli zapomnisz jak brzmi jakieś słowo kluczowe, ale powiesz o tym, to będzie w tej sytuacji w porządku.

Polecam przed pisaniem zapytać rekrutera jakie są jego oczekiwania. Jeśli nie wiesz jak to zrobić, to proponuję Ci takie pytania:

• Mogę pisać w pseudokodzie?
• Uwzględniać takie szczegóły, jak średniki?
• Czy mam uwzględniać rzucanie i łapanie wyjątków?
• Napisać tylko metodę rozwiązującą dany problem, czy całą klasę, w której ona jest?

Pisanie na tablicy

Jeśli stresuje Cię myśl o pisaniu kodu na kartce, to pisanie na tablicy może być dla Ciebie jeszcze trudniejsze. Mam poczucie, że siedząc przy biurku, masz minimalnie większą możliwość, żeby się skupić na rozwiązaniu zadania. Kiedy piszesz na tablicy, to rekruterzy siedzą, a Ty stoisz plecami lub bokiem do nich. Ciężej może być wtedy myśleć o czymś innym niż to, że wszyscy na Ciebie patrzą.

Dodatkowym stresowym elementem może być źle przygotowane „stanowisko”. Kilka problemów, jakie przychodzą mi do głowy, na które warto zwrócić uwagę przy pisaniu na tablicy:

• markery niezmywalne zamiast tablicowych
• same ledwo piszące markery
• brak miejsca do pisania – ktoś zapisał tablicę markerem niezmywalnym i ciężko to zmazać

Jeśli kiedykolwiek ktoś poprosi Cię o pisanie kodu na tablicy, to polecam Ci sprawdzenie tych rzeczy zanim zaczniesz pisać. Oszczędzi Ci to trochę stresu i przy okazji możesz pokazać się jako osoba sprawdzająca środowisko pracy przed podjęciem się zadania.

Tworzenie projektu na komputerze

Na części rozmów technicznych może pojawić się zadanie do rozwiązania na komputerze. Poziom skomplikowania tego zadania może być bardzo różny – od prostego problemu algorytmicznego, aż do bardziej złożonego projektu z testami. Poza samą treścią i trudnością, sposób podejścia do zadania zależy od warunków przedstawionych przez rekruterów.

Obecność rekrutera

Niektórzy rekruterzy zostawiają kandydata na ten czas, ale zdarza się, że cały czas siedzą obok i obserwują jak pracujesz. W pierwszej sytuacji istotny może być sam efekt końcowy. W drugiej zaś rekruter może chcieć wiedzieć jak podchodzisz do problemów i jak sobie radzisz z sytuacjami stresującymi.

Dostęp do internetu

Na jednej rekrutacji dostałem laptopa bez dostępu do internetu, a rekruter wyszedł zaraz po przedstawieniu mi zadania. Miałem użyć elementu języka, z którego jeszcze nie korzystałem, ale na szczęście nie samym internetem żyje człowiek. To był chyba pierwszy i ostatni raz, kiedy korzystałem z pomocy offline dostępnej w Visual Studio.

Przed rozpoczęciem zadania możesz zapytać rekrutera, czy możesz korzystać z internetu. Warto o to zapytać nawet, jeżeli sam komputer nie jest podłączony do sieci. W takim wypadku zostaje Ci po prostu szukanie informacji na telefonie.

Umiejętność znalezienia odpowiednich informacji jest moim zdaniem jedną z najcenniejszych cech dobrego programisty. Pytając czy możesz korzystać z internetu do rozwiązania zadania dowiadujesz się przy okazji czy rekruter chce tę cechę też sprawdzić.

O co jeszcze mogą zapytać?

Zadania do wykonania na kartce lub tablicy, czy pytania teoretyczne mogą być tylko częścią rozmowy technicznej. Bardzo często rekruterzy dopytują o szczegóły poprzedniego doświadczenia i o projektu, którymi możesz się pochwalić.

Jeżeli kod któregoś z Twoich projektów jest dostępny, to przygotuj się o pytania z nim związane. Choć może to brzmieć absurdalnie, rekruter może pokazać Ci konkretne linijki i zapytać czemu coś jest tak napisane. Rekruter na rekrutacji znajomego wydrukował nawet w tym celu fragment jego kodu z GitHuba.

Padają też czasem pytania o książki, czy artykuły specjalistyczne, które się ostatnio czytało. Część rekruterów sprawdza w ten sposób, czy zdobywasz wiedzę na własną rękę.

Różnorodność rozmów technicznych

Rozmowa techniczna może wyglądać inaczej w każdej firmie, a nawet w każdym zespole w tej samej firmie. Zależeć to może od odgórnych firmowych ustaleń, specyficznych potrzeb danego zespołu, czy od preferencji samego rekrutera technicznego.

Wymieniłem tylko część możliwych scenariuszy, bo nie sposób zebrać wszystkie. Najważniejsze jest nauczyć się adaptować do sytuacji, która wystąpi na konkretnej rekrutacji. Dlatego polecam Ci chodzenie na rozmowy tak często, jak to możliwe. Jeśli dopiero szukasz pierwszej pracy, to pomoże Ci to zobaczyć co możesz jeszcze dopracować. A jeśli już pracujesz, to czasem warto przejść rozmowę techniczną, żeby nie wyjść z wprawy.

Jest jakiś ważny Twoim zdaniem element rozmowy technicznej, którego nie poruszyłem? Podziel się nim w komentarzu, żebyśmy wszyscy mogli dowiedzieć się czegoś więcej.

Podsumowanie

Rozmowa techniczna zazwyczaj składa się ze sprawdzania teorii i umiejętności praktycznych kandydata. Czasem rekruterzy techniczni prowadzą ją samodzielnie, ale często bierze w niej udział osoba od HR.

Teoria jest sprawdzana głównie przez rozmowę i pytania od rekrutera. Możesz dostać też do wypełnienia test z pytaniami otwartymi i zamkniętymi.

Umiejętności praktyczne sprawdzane są zazwyczaj przez pisanie kodu na rozmowie technicznej. Ręczne pisanie na kartce, czy tablicy, jest często stosowaną praktyką. Niektórzy rekruterzy oczekują pełnej poprawności składniowej, a inni chcą sprawdzić tylko sposób myślenia i wystarczy im pseudokod.

Część rozmów technicznych opiera się na pisaniu kodu na komputerze. Czasem rekruter wychodzi na ten czas, ale często zostaje i obserwuje. Przed podjęciem się zadania warto zapytać, czy możesz korzystać z internetu.

W trakcie rozmowy rekruter często pyta o Twoje doświadczenie i projekty, może pytać o konkretne linijki z Twojego GitHuba.

Rozmowa techniczna może wyglądać różnie nawet w różnych rekrutacjach do tej samej firmy. Poza wymagań na dane stanowisko wpływają na to też preferencje rekrutera. Dlatego ważne jest nauczyć się adaptować do konkretnej sytuacji.

Podziel się w komentarzach swoimi przemyśleniami o rozmowach technicznych.