Nie da się ukryć, że żyjemy w czasach, w których rekrutowanie programisty to nie jest łatwa sprawa. Braki na rynku są ogromne, dobrzy programiści są rozchwytywani, stawki rosną, a “internety” donoszą o roszczeniach w stylu 30k na rękę, ale nie ma darmowych kanapek, to nie bierę. Wszystko to prawda, no może poza tymi kanapkami ;). Jak w takim razie jak (nie) (z)rekrutować programistę?

Odpowiedź wydaje się oczywista: skutecznie! No dobrze ale co to znaczy w praktyce? Ano tyle, że każdy wypracowuje swoje własne podejście, które oczywiście ewoluuje, ma zalety i pewnie wady. Nie mniej jest etap rekrutacji programisty, który wszyscy musimy przejść – to weryfikacja techniczna kandydata.

Na początek zajmiemy się tym czego programiści w weryfikacji technicznej nie lubią. Na tę okoliczność zapytaliśmy naszego Kowalskiego, czego on nie lubi w weryfikacji technicznej. Jak by na to nie patrzeć jest on programistą i kilka razy w życiu był już rekrutowany. Jego odpowiedź była oczywiście bardzo długa i więcej niż wyczerpująca – cały Kowalski :).

Nasz Kowalski zwrócił uwagę na dość ciekawy aspekt weryfikacji technicznej, którego osobiście najbardziej nie cierpi, a mianowicie są to zadania testowe. Mają one na celu zweryfikowanie wiedzy kandydata. Zadania te są różne i w różny sposób są organizowane: jedni wysyłają je przez strony w stylu Codility, czy HackerRank; inni w postaci opisu tego co kandydat ma zaprogramować wraz z terminem realizacji, niekiedy dodają do tego kod który trzeba rozwinąć.

Jak twierdzi nasz Kowalski, oba podejścia są poniekąd bez sensu, z co najmniej dwóch powodów.

Podstawowy to prozaiczny: brak czasu.

Umówmy się, że dobrzy programiści to przeważnie ludzie, którzy: mają kilka lat doświadczenia, na koncie przynajmniej kilka projektów, są inteligentni, mają jakieś pasje lub hobby (wiadomo trzeba się rozwijać) i najczęściej rodziny. Wolny czas spędzają zatem albo na zajmowaniu się swoim hobby albo z rodzinami.

Wiedzą też, że tworzenie oprogramowania to proces wymagający czasu, i że nie bardzo się da wymyślić genialne rozwiązanie 2 zadań z Codility/HackerRank w półtorej godziny, do tego spełniające zadaną złożoność w notacji O. No chyba, że się te zadania już przerabiało wcześniej i po prostu się zna odpowiedź.

Tudzież nie bardzo się da zaprojektować w 3 wieczory rozwiązania zadania testowego, które powali oceniającego na kolana. Bo wieczór w sumie jest od tego żeby odpocząć i się zrelaksować, a oceniający zawsze się do czegoś przyczepi. A to “nie ma testów jednostkowych”, a to “Pan dodał zależności do obiektu przez ServiceLocator’a, a my wstrzykujemy przez parametry konstruktora”. Co prawda w treści zadnia nikt o testach jednostkowych i niechęci do ServiceLocator’a nie wspomniał, no ale:
– “…kaman, wszyscy piszą testy jednostkowe co nie? My piszemy i mamy pokrycie kodu testami na poziomie 98%. A ServiceLocator’a używają tylko lamerzy – wiadomo nie?”
No wiadomo. Gratulujemy też tych 98% – to chyba rekord światowy tak swoją drogą. Szkoda tylko, że w swojej świetności ktoś zapomniał o precyzyjnym określeniu wymagań. Skoro nie ma precyzyjnych wymagań, to cholera wie co chcą.

Co zatem robią programiści? Jeśli im zależy na potencjalnej pracy, to wymęczą rozwiązanie w te 3 wieczory, przeważnie idąc linią najmniejszego oporu. Jak im nie zależy – to najczęściej odpuszczają: Przecież jutro napisze na LinkedIn’ie następna HR’ówa, to co ja się będę męczył, poza tym mają w CV link do mojego GitHub’a, nie? A w ogóle to zaraz mecz, bo środa. Ewentualnie przeciągają oddanie rozwiązania w nieskończoność i znikają.

Drugi powód: sensowność zadań.

Statystyka jest nieubłagana: ponad 75% projektów, którymi zajmują się rekrutowani programiści to systemy spadkowe, czyli takie nad którymi pracowały już dziesiątki osób i zawierają dziesiątki tysięcy linii kodu, a kod jest pisany tak że nóż się w kieszeni otwiera. Co więcej są to przeważnie systemy biznesowe, które muszą najczęściej zapisać dane w bazie, pozwolić na ich edycję i wyświetlić je w taki czy inny sposób, najlepiej przy użyciu kontrolek firmy X. A to wszystko na tyle bezpiecznie, żeby przysłowiowa “pani Halinka” nie wywaliła wszystkich danych w kosmos, no bo coś “klikła i znikło”.

Jaki zatem jest sens wysyłać kandydatowi do takiego projektu zadanie, w którym ma rozwiązać problem 8 hetmanów albo napisać algorytm, który znajdzie najdłuższą sekwencję zer w binarnej reprezentacji dowolnej liczby całkowitej?
Najprawdopodobniej taki, że menadżerowie zespołów programistów i twórcy serwisów w stylu Codility/HackerRank wyszli z założenia, że programiści jak jeden mąż czytają tylko Cormen’a. Zamiast nowych odcinków ulubionego serialu oglądają tylko wideo kurs “Algorytmy i Struktury danych” z MIT. A poza tym nie potrafią wyszukać rozwiązań zadań na GitHub’ie.
Zapytany o to Kowalski potwierdził, że faktycznie czyta tylko Cormen’a (ma wszystkie wydania te polskie i zagraniczne). Poza tym, ogląda tylko wideo kurs z MIT, a na koniec zmiażdżył pytaniem: “to ludzie wrzucają rozwiązania zadań na GitHub’a?”

Co robić? Jak żyć? Jak wysyłać zadania programistom?

Tak poważnie: warto się zastanowić co chcemy naszym zadaniem sprawdzić, czy wysłane zadanie jest dostosowane do przyszłych obowiązków kandydata w projekcie, i czy wysyłanie zadania ma w ogóle sens.

Zaczynając od końca: jeśli dla naszego kandydata oferowana praca, to praca marzeń, albo przynajmniej taka na której mu zależy to znajdzie czas na zdanie testowe. Jednak jeśli to kolejne stanowisko w “młodym, dynamicznym zespole”, to zadania nie ruszy i święto lasu jak da znać, że tego nie zrobi.

Jeśli projekt do którego rekrutujemy, to coś na miarę oprogramowania do SpaceX lub przynajmniej system telco, który rejestruje 7 milionów transakcji na minutę, to faktycznie rozwiązanie przez kandydata problemu 8 hetmanów może mieć sens. Jednak w przypadku rekrutacji do projektu zajmującego się utrzymaniem systemu spadkowego, większy sens będzie w zrobieniu przez kandydata krótkiego code review, albo refaktoring kodu z zachowaniem zasad SOLID.

Wreszcie pierwsza kwestia: co chcemy sprawdzić naszym zadaniem. Jeśli celem jest weryfikacja znajomości danego języka programowania, to zadanie algorytmiczne tego nie gwarantuje. Nie pokaże również jak kandydat podchodzi do rozwiązywania problemów, które natrafi w projekcie. Już lepiej poprosić o implementację metody wyznaczającej silnię dla danego n, albo implementację tego nieszczęsnego singleton’a :). Zajmie to kandydatowi góra 10 minut i najlepiej zrobić to na spotkaniu. Zawsze można wtedy porozmawiać z kandydatem na bieżąco o tym co napisał, a to może prowadzić do ciekawej dyskusji i lepszego poznania jego umiejętności.

Jak zatem sprawdzić umiejętność rozwiązywania problemów? To temat na cześć następną.

p.s.
Gdyby się ktoś zastanawiał dlaczego “część 0” a nie “część 1”, przecież normalnie liczymy od 1 a nie od 0. Fakt, normalnie liczebniki porządkowe są od 1 – to prawda, ale wpis dotyczył programistów czyż nie? 😉