Rekruter mnie bije - o rozmowach technicznych zespołu MockIT

Intro

Rozmowy techniczne… prędzej czy później każdy kto planuje rozpocząć pracę w IT na nie trafi. Jak wyglądają takie rozmowy? Co zrobić żeby pierwsza rozmowa nie była zderzeniem ze ścianą? Jak odpowiednio się do niej przygotować? Co może być powodem niepowodzeń? Czy wybranie odpowiedniej godziny lub dnia tygodnia na rozmowę może mieć wpływ na jej wynik? Na te i inne pytania odpowiadamy w tym blog poście w formie wywiadu z naszym founderem, który dzieli się swoimi doświadczeniami, spostrzeżeniami i radami.

Masz spore doświadczenie jako Software Developer ale czy pamiętasz jeszcze jak wyglądały początki? Zacznijmy może od pierwszych ofert na które aplikowałeś. Gdzie ich szukałeś?

Tak, świetnie pamiętam ten etap. Z ofertami na staż nigdy nie było zbyt kolorowo więc samo znalezienie odpowiedniej oferty wymagało sporo pracy. Tutaj trzeba wspomnieć o świetnej robocie jaką robi Politechnika Wrocławska organizując parę razy w roku targi pracy gdzie takie oferty faktycznie się pojawiają. To właśnie do firm z targów pracy rozesłałem swoją śmiesznie biedną wtedy CVkę. Brałem potem udział w 2 procesach rekrutacyjnych.

A jak wyglądały same procesy rekrutacyjne na staż? To była zwykła formalność bo to jednak tylko staż czy wręcz przeciwnie?

To trochę zależy. Nawet nie trochę. Rekrutacja na staż do jednej firmy to była najdłuższa przeprawa ze wszystkich rekrutacji jakie miałem w całej karierze. Składała się aż z 5 etapów i trwała ponad miesiąc. Na początku musiałem zmierzyć się z rozbudowanym testem online który sprawdzał znajomość sqla, frontendu, algorytmów i powiedzmy ogólnej znajomości JavaScriptu. Test był w formie zadań znanych z serwisu codewars czy leetcode. Co prawda wszystkie zadania poza SQLem były dosyć proste ale ten SQLowy…no jak na poziom stażysty to był delikatną przesadą. Taki poziom 5 kyu w codewars. Później była rozmowa miękka i rozmowa po angielsku. Co ciekawe od tego etapu wszystkie następne etapy były prowadzone w całości po angielsku. No i wreszcie rozmowa techniczna. Była długa i szczegółowa. Pojawiły się pytania typowo wiedzowe i szablonowe ale też w stylu “co byś zrobił w danej sytuacji”. Miałem też wątpliwą przyjemność zmierzyć się z tzw. “live codingiem” gdzie dane mi zadanie musiałem rozwiązać podczas rekrutacji. Był to raczej prosty algorytm opierający się na operacjach na stringach i tablicach. Ostatnim etapem była miękka rozmowa z CEO. Bez głębszej historii. Polegała na bliższym poznaniu mojej osobowości, sprawdzeniu wymagań finansowych itd. Cały proces przeszedłem pozytywnie i dostałem tę pracę.

Zupełnie inaczej wyglądał proces w drugiej firmie. Tam był tylko jeden etap. Rozmowa miękka połączona z dwoma pytaniami technicznymi i tyle :) A stawka była taka sama (chyba tutaj nawet ciut lepsza)! Czemu nie wziąłem tej oferty? Cóż, czułem, że w pierwsza rekrutacja kosztowała mnie tyle pracy, że musiałem tam pójść. Dzisiaj wiem, że trzeba lepiej przeanalizować wszystkie za i przeciw :)

Rozmowa techniczna może mieć kilka postaci. Mogą to być same pytania wiedzowe, live coding, połączenie jednego i drugiego lub jeszcze inna formuła. Jaki typ tej rozmowy był dla ciebie najtrudniejszy i dlaczego?

Dla mnie zawsze rozmowy z live codingiem algorytmu były szczególnie wymagające. Po pierwsze, jest to bardzo stresujące. Często polega to na wpadnięciu na odpowiedni pomysł i zastosowaniu kilku predefiniowanych metod z danego języka programowania. Stres na pewno nie pomaga wpaść na właściwy pomysł przez co często ratujesz się jakimiś nie optymalnymi rozwiązaniami byle tylko rozwiązać zadanie. Po drugie, osobiście nie widzę sensu tego typu live codingu podczas rozmów technicznych. W zasadzie nic użytecznego to nie sprawdza. Chyba, że odporność na stres ale chyba nie to jest celem takich zadań.

Istnieje dużo lepsza metoda na sprawdzenie umiejętności myślenia i kodowania kandydata. Choćby poprzez live coding polegający na rozwoju jakiegoś projektu/problemu. Kiedyś dostałem zadanie polegające na zaimplementowaniu kilku funkcjonalności w projekcie, który udostępnił mi rekruter podczas rozmowy. Krótko wytłumaczył o co chodzi i zaczęliśmy programowanie w parze. Zadanie było dużo bardziej zbliżone do tego co miałbym finalnie robić w firmie a i poziom stresu był niższy bo rekruter też aktywnie uczestniczył w procesie rozwiązywania tego taska. Oczywiście live coding algorytmów byłby pewnie okey gdybyśmy startowali na pozycję stricte związaną w tworzeniem algorytmów ale w 99% przypadków tak po prostu nie jest.

Kończąc ten temat dodam tylko, że jako MockIT musimy dostosować się do wymagań rynku względem rozmów technicznych więc i takie zadania jak live coding algorytmów będą się u nas oczywiście pojawiać.

Czy wszystkie rekrutacje w jakich brałeś udział udało ci się przejść pomyślnie? Jeśli nie, to co było powodem i na jakich etapach odpadałeś?

Niestety nie było tak dobrze. Zdarzały się też niepowodzenia. Najczęściej oczywiście na rozmowie technicznej. Tak jak wspomniałem wcześniej, live coding jest stresujący i może być mocno nieprzewidywalny. Kiedyś przy okazji takiego zadania niestety nie wpadłem od razu na właściwy pomysł i rozwiązywałem problem “na około”. Rozwiązanie zadziałało ale nie było optymalne pod względem złożoności obliczeniowej a taki był wymóg postawiony przez rekrutera. Rekruter też nie pomógł i był raczej mało kontaktowy. Dodatkowo na pytania z wiedzy o JavaScripcie wszystkie moje odpowiedzi kwitował: “Zgadza się. Super” po czym w feedbacku po rozmowie napisał już coś zupełnie innego :) Po tej rozmowie nauczyłem się, że warto odpowiadać na pytania tak bardzo opisowo i wylewnie jak tylko możesz żeby nie było żadnych wątpliwości co do Twojej wiedzy.

Czy masz jakieś nieoczywiste rady dla innych, może mniej doświadczonych osób, jak przygotować się do rozmów rekrutacyjnych?

To co powiem jest tylko moją opinią ale myślę, że nawet tak prosta rzecz jak wybór odpowiedniego dnia tygodnia i godziny ma duże znaczenie. Pomyśl w jakiej porze dnia jesteś najbardziej efektywny i spróbuj umówić rozmowę o takiej godzinie. Pamiętaj tylko, że godziny bardzo wczesne i takie bliżej końca standardowego dnia pracy to raczej nienajlepszy wybór. Rekruterzy są jeszcze zaspani i nie do końca skupieni albo zmęczeni po całym dniu pracy i myślą tylko o zamknięciu służbowego komputera. To samo tyczy się wyboru dnia tygodnia. Lepiej nie umawiać rozmowy w poniedziałek kiedy wszyscy są jeszcze nieszczęśliwi, że weekend właśnie minął i nie do końca skupieni na obowiązkach oraz w piątek gdy weekend jest już tuż tuż. Ja zawsze celuję we wtorek i czwartek.

Oczywiście, żeby odpowiednio się przygotować trzeba przypomnieć sobie całą teorię z danego stacku technologicznego. W sieci jest pełno stron prezentujących najpopularniejsze pytania rekrutacyjne dla danej technologii. Polecam je sobie przejrzeć. To jednak nie wystarczy na live coding. Tutaj polecam np. platformę codewars, która udostępnia tysiące zadań algorytmicznych. Zrobienie kilkudziesięciu z nich powinno wystarczyć żeby się rozgrzać przed live codingiem.

Jeśli chodzi o inne nieoczywiste rady to zdradzę swój protip, którego nigdzie poza tym blog postem raczej nie znajdziecie. Konkretnie: polecam poczytać sobie na serwisie glassdoor komentarze osób, które przechodziły rekrutacje w danej firmie. Często piszą jakiego rodzaju pytania były im zadawane a czasem nawet konkretne pytania. Zakładam, że bardziej rozgarnięte osoby wpadną na ten pomysł. Daję więc jeszcze jeden bonus: przed rozmową zawsze dostajecie maila z informacją kto ma przeprowadzić waszą rozmowę techniczną. Polecam popatrzeć na społecznościówki takiej osoby, przede wszystkim linkedina…i oczywiście githuba! Po co? Szukajcie easter eggów, one tam są. Gwarantuję.