Rekrutacja od strony deva. Jak chciałbym zostać zrekrutowany

22 sierpnia 2018 Mariusz Walczak

Jakiś czas temu zostałem poproszony o przeprowadzenie rekrutacji od technicznej strony. Kiedy się o tym dowiedziałem, zadałem sobie jedno, kluczowe pytanie: jak ten proces powinien wyglądać? Zrozumiałem wtedy, że błędnie postawiłem pytanie, bo powinno ono brzmieć: jak chciałbym być sprawdzany, aby nie poczuć się pokrzywdzony?

Mariusz Walczak. Tech lead w Softfin. Absolwent Warszawskiej Wyższej Szkoły Informatycznej. Pasjonat inżynierii oprogramowania, swoje aplikacje tworzy w PHP i językach opartych na ES6/7. Prywatnie miłośnik futrzanych czworonogów, oraz winiarstwa i nalewkarstwa.

Na początku wyeliminowałem kilka metod sprawdzenia umiejętności kandydata: test na kartce, pytania z kartki, pisane kodu na kartce, zadania typu ciekawe czy się domyśli, że tutaj jest błąd…

Ogólnie nie ma dla mnie nic gorszego jak zadanie testowe na kartce. Po pierwsze, niczego ono nie sprawdza, po drugie tylko frustruje, po trzecie pokazuje, że firma nie chce mnie bliżej poznać. Co jeszcze gorsze: wszyscy dostają te same zadanie, choć mają różne doświadczenia. Taki test nie pozwala na pokazanie się z dobrej strony, często zawarte w nim są pułapki, a najgorzej, kiedy osoba sprawdzająca jeszcze żąda konkretnego rozwiązania.

Testy na komputerze oceniam podobnie. Kiedyś dostałem test, w którym miałem wyliczyć średnią dla każdej osoby z listy. Zadanie trywialne, ale był haczyk, o którym dowiedziałem się po teście: rozwiązanie nie mogło zostać wykonane foreach’em. Test oblałem i byłem wdzięczny za to, bo waliłbym głową w ścianę, kiedy poprawiałbym zadanie po raz enty, bo mam to zrobić bez ifa.

Kolejną rzeczą jaka mnie zawsze bolała, to nieznajomość CV. Skoro poświęciłem godzinę na napisanie CV, to niech ktoś poświęci 5 minut na przeczytanie go. Co więcej, nie ma nic gorszego jak odpytka z rzeczy jakie nie są uwzględnione w CV. Skoro czegoś nie pisałem, to znaczy, że nie chce być z tego odpytywany, bo nie potrafię, bo nie chce w tym pracować, bo cokolwiek.

Mając te doświadczenia, do pierwszego kandydata podszedłem tak jak bym chciał, aby rekruterzy podchodzili do mnie. Przeczytałem jego CV, wynotowałem wszystko co ważne, przygotowałem pytania na poziomie jaki zadeklarował kandydat i kilka trochę trudniejszych oraz łatwiejszych, na wypadek gdyby się przecenił, lub nie docenił. Stwierdziłem, że kandydat musi na początku poczuć wiatr w skrzydłach, bo na pewno będzie się stresował spotkaniem, dlatego miałem pod ręką pulę pytań rozgrzewkowych. Dodatkowo stwierdziłem, że jeżeli czegoś nie będzie wiedział to i tak podam mu prawidłową odpowiedź – niech się uczy przy takich rozmowach.

W końcu doszło do sprawdzenia moich założeń i o dziwo – sprawdziły się. Pytania zadawałem z pamięci na zasadzie rozmowy, nie były one ani podchwytliwe, ani złośliwe. Kandydat otrzymywał od razu odpowiedzi. Pracy niestety nie dostał, miał niskie kompetencje, ale za wysokie wymagania. Natomiast byłem zadowolony z przeprowadzonej rozmowy, bo kandydat został odpytany z tego, co zadeklarował, że umie na jego poziomie.

Później wraz z kolejnymi rekrutacjami, miałem swoje zestawy pytań. Pamiętam, jedną rozmowę, w której miałem mały dylemat. Agnieszka, bo tak miała na imię kandydatka, nie doceniła swoich umiejętności. Była bardzo zdenerwowana, a ja miałem chęć wejść z pytaniami na etap mega hardcorowy. Zatrzymałem się na chwilę, by zastanowić się, jak to zrobić, by nie poczuła się… głupia? Uprzedziłem ją więc, że to jest grupa pytań, na które niewiele osób potrafi odpowiedzieć. Na początku nie chciałem odkrywać kart, ale wiedziałem, że jeżeli tego nie zrobię, to pozostawię kandydatce niepewność, a dziewczyna naprawdę świetnie ogarniała wszystko. Na pytania z tej grupy odpowiedziała 2/10 i to oznaczało, że wymiata. W rezultacie została zatrudniona.

W końcu trafiłem na kandydata, który pochwalił się kodem na githubie. Nie wahałem się, po co mam go pytać o inne rzeczy, skoro mogę poczytać i zobaczyć co potrafi. Jak pomyślałem, tak zrobiłem. Zobaczyłem strasznie zaniedbany kod, z błędami logicznymi, ale zobaczyłem też, że ten developer wie o co w tym wszystkim chodzi, czym są namespace’y, obiektowość itd.. Miałem już jego wyobrażenie. Przygotowałem więc kilka pytań bezpośrednio dot. napisanego kodu. Gdy odpaliłem pokazałem go na rzutniku, uśmiechnął się i powiedział, że chyba go zna. Widać było, że forma prowadzenia rozmowy bardzo mu odpowiadała.

Pierwsze o co zapytałem, to czy może coś opowiedzieć o tej klasie. Wybrałem ją celowo, bo była napisana w sposób straszny. Odpowiedź mnie zaszokowała. Kandydat powiedział, że była tak zła, że z niej zrezygnował, napisał nową, a trzyma ją w kodzie dlatego, że kończy tą nowszą wersję i nie chce niczego przegapić. Zrobiło to na mnie duże wrażenie, przecież oceniam jego pracę, a on sam przyznaje, że ma błędy tu i tam. Ocena pozytywna, został zatrudniony.

Raz na rekrutacji, miałem do czynienia z osobami, które uważały że zjadły wszelkie rozumy. W szczególności jedna sytuacja utkwiła mi w głowie. Kandydat z 15-letnim doświadczeniem napisał grę w PHP, opublikował ją na githubie. Myślę sobie czemu by nie sprawdzić jak ona działa, ale najpierw zajrzę do kodu? Widzę sieczkę, poważnie, pod względem jakości masakra, klasy mają ponad 1000 linijek kodu, maksymalne zagłębienie to poziom 37. Logiki nie da się normalnie odczytać. Popatrzyłem na tę masakrę jeszcze chwilkę i przygotowałem się na rozmowę. Przyszedł facet, około 40 lat. Niski, krępy, lekko niechlujny w „paździochowym” sweterku. Ogólnie wyglądał jakby właśnie wrócił z całonocnego pilnowania osiedlowego parkingu. No cóż, nie oceniaj Mariusz po wyglądzie, Ty też nie chodziłeś w garniakach na rozmowy.

Zacząłem od kodu, pokazałem mu go i zapytałem, co by w nim zmienił. On na to, że nic. Tutaj zapaliła mi się czerwona lampka, popełnił wszelkie istniejące w słowniku błędy jakie można popełnić i odkrył ich tuzin więcej, a on nadal uważał, że jest ok. No dobrze. Zadawałem mu kolejne pytania, dlaczego to jest tak, a nie np. tak, lub tak. Widziałem, że coraz bardziej złości się. Zadałem więc pytanie ostatecznej rozwałki. Czemu mamy require i use tego samego pliku w tej samej klasie linijka po linijce. Kandydat walnął pięścią w stół, wstał, zagotował się i wygarnął mi, bo niby jak to ma działać. Gdy zapytałem o autoloader, usiadł wyrzucając mi, że to zbędne zawalanie zasobów systemu. Pociągnąłem dalej temat, on wstawał i siadał, był bardzo arogancki i niemiły. Dostałem od koleżanki z HR tajny sygnał: „kończ z nim”. Postąpiłem więc totalnie nieprofesjonalnie, zadałem mu serię pytań złośliwych, dosłownie jak karabin maszynowy sypały się – w sumie w ciągu dwóch następnych minut poszło tych pytań ze 40. Widząc pustkę, przechodziłem do następnego. Kandydat sam wyszedł i urwał się z nim kontakt.

W poprzedniej historii wspomniałem o tajnych sygnałach. To fajna sprawa, bo w ten sposób można dowiedzieć się, że za długo odpytuje, że za krótko, jaka jest moja opinia itd. Ustalając kilka podstawowych zasad, mamy możliwość sprawniejszego przeprowadzenia rozmowy kwalifikacyjnej.

Któregoś razu, zamiast pytań postanowiłem dać proste zadanie. Nie podchwytliwe, lecz proste – takie na dwie minuty pracy. Pomyślałem, że dam kandydatom 15 minut na rozwiązanie tego testu i już. Tak też się stało, ściągnąłem gotowy przykład bloga, w pełni działającego napisanego przez twórców frameworka z jakiego odpytywaliśmy i poprosiłem, aby dorobić breadcrumpy. Pierwszy kandydat zawiódł, gdzieś się zgubił, drugi kandydat miał dokończyć to zadanie, znów zawiódł. Dopiero siódmy kandydat naprawił wszelkie błędy i zrobił zadanie poprawnie. Dało mi to pewną myśl, nie może być tak, że oni wszyscy są tacy słabi. To na pewno stres i szukanie podchwytliwości ich zabija. Dlatego też w dalszych rozmowach nie przeprowadzałem tego ćwiczenia. Z resztą sam tego bym nie chciał zrobić.

Po wszystkim, zapytałem osób nowo zatrudnionych jak podobała się im rekrutacja. O dziwo większość powiedziała, że nie czuli się debilami, że wiedzieli co źle powiedzieli i czego muszą się douczyć, oraz że zobaczyli, że ktoś się przygotował na ich przyjście i nie potraktował jako kandydata, tylko Agnieszkę, czy Kubę. Tutaj kolejna rzecz mi się objawiła, mianowicie czego kandydaci dokładnie oczekują od rekruterów. Chcą indywidualnego podejścia, zrozumienia, że się stresują i przygotowania się do rozmowy tak, by nie zostawić poczucia beznadziejności.

Na podstawie przeprowadzonych przeze mnie rekrutacji, wyrobiłem sobie kilka ogólnych grup kandydatów.

Geniusze – czyli osoby, które uważają, że wiedzą wszystko
Kursanci – czyli osoby, które uważają, że po kursach wiedzą wszystko
Wyjadacze – czyli osoby, które rzeczywiście mają wiedzę
Nieśmiali wyjadacze – czyli osoby, które mają wiedzę, ale poją się do niej przyznać
Ściamniacze – czyli osoby, typu co to nie ja potrafię, zapytani o dowolny szczegół giną
Stresoholicy – czyli osoby, które nie radzą sobie ze stresem

Skauci – czyli osoby, które póki co badają na czym polega rozmowa kwalifikacyjna.

Rekrutacje też nauczyły mnie jednego: szef zatrudnia narzędzie, a my szukamy osoby, która ma podstawy na jakich nam zależy, ale przede wszystkim odpowiada nam usposobieniem.

Na deser ostatnia historia

Na podstawie tego agresywnego człowieka z poprzednich historii, opracowałem styl sprawdzenia jak ludzie reagują w sytuacji stresowej. Po rozpoznaniu co kandydat potrafi, a czego nie, postanowiłem zrobić rush pytań. Zasypywałem chłopaka takim gradem pytań, że nie miał czasu na zastanowienie się. Udało mi się wywrzeć na nim bardzo dużą presję. Doszło do tego, że nie potrafił odpowiedzieć na pytania typu jak ma na imię jego pies. W pewnym momencie zaskoczyła mnie jego reakcja. Krzyknął na mnie, abym dał mu się zastanowić do jasnej cholery, opowiedział na kilka zapamiętanych pytań i się wyciszył. Wiedziałem już, że da sobie radę w nerwowej sytuacji. Został później zatrudniony.

Reasumując

Jak mamy prowadzić rozmowy techniczne, zadajmy sobie jedno pytanie, jakbyśmy chcieli, aby była prowadzona ona względem nas. Jest wiele wspaniałych technik, aby tego dokonać, np. poprzez programowanie ekstremalne z kandydatem, lub po prostu rozmowę. Preferuję rozmowę, która pozwala mi poznać kandydata na tyle, na ile jest to możliwe. Staram się podchodzić indywidualnie do każdego, nie wrzucam ich do szablonowego testu, bo to nie jest miarodajne. Sam nie wypełniam żadnych testów i mówię, że takie zabawy to skończyłem na studiach.

Pamiętajmy też, że rozmowa kwalifikacyjna ma być korzyścią dla obu stron, my poznajemy kandydata, a kandydat zasady gry w naszej firmie. Jeżeli wrzucimy go od razu do worka kandydat, to dajemy jasny przekaz: nie interesuje mnie kim jesteś, masz zrobić swoje i tyle, a to nie są dobre warunki do pracy. Dobry zespół to zespół programistów, gdzie każdy jest indywidualnością, a nie zestawem umiejętności.

Zdjęcie główne artykułu pochodzi od HBO.