W poprzedniej części Jak zrekrutować programistę pisaliśmy o tym czego programiści nie lubią w procesie rekrutacji. Poza wspomnianymi poprzednio niedostosowanymi do wymagań i stanowiska zadaniami z weryfikacji technicznej, są jeszcze oczywiste rzeczy:
- Pomyłki w imionach i nazwiskach. Kowalski mówi, że 1 wiadomość na 10 jest pisana niby do niego, ale rekruter używa innego imienia czasem też innego nazwiska.
- Wymagania nie pasujące w żaden sposób do profilu kandydata. Kowalski twierdzi że z tym jest ostatnio lepiej, mniej więcej 2 na 20 ofert proponują mu pracę w technologiach, o których tylko czytał, nic nigdy nie robił i nigdzie nie chwalił się że je zna. No chyba że oferta jest z zagranicy, to wtedy co druga oferta nie pasuje do jego profilu.
- „Atrakcyjne wynagrodzenie” i przysłowiowa „wiodąca na rynku firma”, ewentualnie „lider rynku”. Programiści lubią przejrzyste sytuacje, dużo łatwiej się z nimi rozmawia o potencjalnie nowej pracy, jeśli znają od początku oferowane wynagrodzenie oraz nazwę potencjalnego przyszłego pracodawcy. Najczęściej to znajomość z ich strony skutkuje tym … że z nami rozmawiają. Jeśli wysokość wynagrodzenia i firma nie przekonują kandydata na wstępie, to szanse, że to się zmieni w trakcie są nikłe. Poza tym Kowalski w swej wrodzonej złośliwości zauważył, że nowych pracowników szukają tylko „wiodący liderzy na rynku”. Przeważnie „w związku z dynamicznym rozwojem”, no i najważniejsze do “młodego, ambitnego zespołu”.
- Nierozróżniania lub też nie zrozumienie technologi. Nie będziemy pisać że Java i JavaScript to nie to samo, bo to wszyscy rekrutujący programistów już wiedzą. Faktem jest że nieznajomość technologii, o których się rozmawia z programistami, bardzo ich irytuje.
- Rozmowy i spotkania w sprawie pracy w tzw. „godzinach biurowych”, czyli 9-16.
Te dwa ostatnie aspekty mają też drugą stronę medalu: rekrutujący rzadko kiedy mają wykształcenie kierunkowe, które pozwala im swobodnie porozmawiać czy to z programistą czy też specjalistą CAD. Najczęściej posiłkują się kimś, kto odpowiednią wiedzę posiada (czyli każdy rekruter powinien mieć swojego Kowalskiego, tak jak my mamy ?). Tyle że ciężko niekiedy zapamiętać wszystkie specyficzne wiadomości dotyczące tego czy innego języka programowania, zwłaszcza że rekrutujący powinien znać je wszystkie, bo różnych programistów rekrutuje. A programiści w przeważającej większości są specjalistami w kilku z nich.
Podobnie z godzinami pracy: rekrutujący też pracują między 9-16 i chcieliby rozmawiać z kandydatami w godzinach pracy. W praktyce sprowadza się do jakiego kompromisu.
No dobrze, wiemy czego programiści nie lubią, czas zatem na sprawdzić co jeszcze nie działa lub po prostu nie ma sensu, najczęściej w kontekście weryfikacji technicznej.
Zacznijmy od certyfikatów. Mnóstwo firm oferuje możliwość zdobycia certyfikatów poświadczających znajomość danych technologii, framework’ów, programów lub procedur. Swoje certyfikaty oferuje Oracle, Apple czy też Microsoft. Teoretyczne posiadanie certyfikatu świadczy o znajomości przedmiotu, którego tenże certyfikat dotyczy. Faktycznie dekadę i wcześniej temu, kandydat z dużą liczbą certyfikatów, pasujących do profilu był bardzo dobrze widziany i pożądany. W praktyce jednak ok 2008 roku, rekrutujący zdali sobie sprawę, iż istnieje coś takiego jak osławiony brianzdump.biz, na którym można było znaleźć odpowiedzi na pytania z 90% certyfikatów obecnych na rynku. Zatem zdanie egzaminu na dany certyfikat, to była kwestia nauczenia się na pamięć odpowiedzi. Jaką w takim razie wartość miał taki certyfikat? Oczywiście nie generalizujemy – są firmy których certyfikaty mają renomę (np.: Cisco). Niemniej stron w stylu brainzdump jest sporo, a w przypadku programistów certyfikaty straciły w zasadzie znaczenie. Jeśli pojawiają się w wymaganiach, to tylko w zasadzie jako “nice to have”.
Kolejny temat to zagadki logiczne. Swego czasu (mniej więcej dekadę temu i wcześniej) wiele firm dawało kandydatom na programistów zagadki logiczne do rozwiązania w trakcie rozmowy kwalifikacyjnej. Chyba większość programistów spotkało się z pytaniami o 3 żarówki, owoce w skrzynkach, czy też dlaczego właz studzienki kanalizacyjnej jest okrągły (Kowalski twierdzi że są conajmniej dwie prawidłowe odpowiedzi, a jedna z nich mówi o drugiej pochodnej – cały Kowalski ?). Intencja w zasadzie słuszna: sprawdzić czy i jak kandydat myśli logicznie. Tyle że zagadki logiczne to nie najlepszy sposób realizacji tych intencji. Zagadki logiczne są świetne kiedy …. ma się chwilę na spokojne zastanowienie i rozgryzienie, o co w danej zagadce chodzi. Ciężko o to kiedy człowiek jest na rozmowie o pracę, zestresowany i chce wypaść jak najlepiej. Poza tym większość zagadek logiczny opiera się na jakimś tricku, jednej rzeczy którą wydaje się banalna gdy się ją pozna, a która prowadzi do prawidłowego rozwiązania. Najlepiej kwestię zagadek logicznych podsumowuje słynna, zmyślona rozmowa o pracę w Microsoft Richard’a Feynmana. Żeby było śmieszniej, firmą która lubowała się przez lata w zadawaniu zagadek kandydatom na rozmowach był …. właśnie Microsoft.
Jak zatem sprawdzić predyspozycje kandydata? Jest kilka możliwości:
- prośba o rozwiązanie pozornie niemożliwego zadania, np.: policzyć ile jest drzew w Krakowie
- test psychologiczny lub IQ
W przypadku tego pierwszego pomysłu, nie oczekujemy że kandydat faktycznie te drzewa policzy. Intencją jest, aby pokazał w jaki sposób podejdzie do rozwiązania nietrywialnego problemu.
Wiemy już czego programiści nie lubią, wiemy o co nie pytać w trakcie rekrutacji programisty, pora zatem dowiedzieć jak powinien wyglądać proces rekrutacji programisty, który będzie dostosowany do wymagań związanych ze stanowiskiem oraz da nam pewność, że kandydat posiada wiedzę adekwatną do deklarowanej w CV. O tym w następnej części naszego cyklu.
p.s.
Wracając na moment do programistów. Wydawać by się mogło, że być rekrutowanym do pracy na stanowisko programisty to sama przyjemność i w zasadzie nie ma taki kandydat co narzekać, a jeśli to robi to wychodzi z niego rozpuszczony roszczeniowiec. Niby tak, ale z drugiej strony rekrutacja może zajmować sporo czasu