Jak powinna wyglądać rozmowa rekrutacyjna?

Na zakończenie cyklu wpisów o rozmowach rekrutacyjnych będzie odmiana: tym razem będzie pozytywnie. Opowiemy sobie w tym odcinku jak powinna (i jak czasem wygląda) właściwa, pozytywna rozmowa o pracę na stanowisko programisty.

1. Rozmowa powinna dać coś obu stronom.

Najlepiej by było, gdyby po rozmowie kandydat został zatrudniony. Wtedy wiadomo: win-win.

Jednak jeśli tak z jakichś powodów kandydat nie zostałby zatrudniony (albo sam by zrezygnował ze współpracy), nie wszystko stracone. Dalej można wyciągnać jakąś obopólną korzyść.

a) Kandydat może nauczyć się czegoś nowego.

Nie znał algorytmu sortowania? To po wyjściu z rozmowy już będzie znał. Nie słyszał nigdy o frameworku X? To na rozmowie usłyszy i przegoogluje sobie w domu o co chodzi z X. Mylił się w pewnej sprawie? To na rozmowie zostanie naprowadzony na lepsze podejście.

Oczywiście przy założeniu dobrej woli rekrutera i chęci do dawania feedbacku.

Nie ma nic gorszego niż rekruter, który tego feedbacku nie kwapi się dać, odpytując jedynie kandydata i zachowując twarz pokerzysty.

b) Rekruterzy czy ogólnie firma także może skorzystać na rozmowie, która nie zakończyła się zatrudnieniem.

Na przykład mogą sobie kontakt do niego wziąć na przyszłość. Kto wie czy później taki kandydat nie zostanie zatrudniony w kolejnej rekrutacji w danej firmie.

A jeśli kandydat jest sensowny, to sama rozmowa może być inspirująca. Rekrutujący go programiści też mogą się dowiedzieć czegoś nowego od kandydatów. Porownać jakoś swój punkt widzenia z punktem widzenia kandydackim. Dowiedzieć się czegoś o technologiach, których używa kandydat, albo o projektach, które robi (mnie zdarzało mi się opowiadać o tym co zrobiłem wcześniej, np. o swojej grze czy o tworzonym przeze mnie narzędziu do analizy kodu).

2. Rozmowa powinna być dialogiem a nie monologiem kandydata 

I tu pieję do rekruterów, którzy mało cokolwiek mówią od siebie, a głównie odpytują kandydata ("opowiedz coś o A") skłaniając go do produkowania się i monologów na temat A.

Monologów, bo rekruter nie przerywa, nie polemizuje, nie przytakuje, nie parafrazuje. Tylko słucha i "zbiera wywiad", od czasu do czasu zadając kolejne pytanie, dotyczące albo kolejnego tematu (lecimy tematami A, B, C, D), albo wciąż tematu A, ale w takim typowym tonie sprawdzenia czy kandydat nie kłamie.

Sorry, ale co to? Przesłuchanie? Matura ustna?

Taka rada: jeśli rekrutujesz programistę - mów. Nawet jak nie możesz wszystkiego powiedzieć, to mów co możesz. Dawaj feedback. Dyskutuj. Polemizuj. Zgódź się z poglądem rozmówcy. Cokolwiek, żeby nie być antypatycznym mrukiem.

3. Coś co zachęca

I próbuj zachęcić jakoś programistę do swojej firmy (bo nie oszukujmy się: rozmowa o pracę to rozmowa kwalifikacyjna dla obu stron. Jeśli zastanawiasz się czy zatrudnić programistę, to również programista zastanawia się czy wejść we współpracę akurat z twoją firmą).

Czemu mam wejść we współpracę z firmą, o której wiem tyle, co mają napisane na swojej stronie domowej, i podjąć się projektu, o którym nie wiem praktycznie nic, z ludźmi, których nie znam, pracując jakąś bliżej nieokreśloną metodą?

Potrzebny jest haczyk. A ten zależy od programisty.

- wysokie wynagrodzenie?
- praca w zwinnych zespołach? (zamiast waterfallu)
- dobre praktyki, testy, dobra architektura?
- sympatyczni i kompetentni ludzie?
- ciekawe technologie?
- interesujące zadania? (a nie klepanie templatek)
- interesujący projekt jako taki? (np. ciekawy start-up)
- możliwość pracy zdalnej?

Różni są ludzie, różne są haczyki. Jedna osoba może gonić za wieloma haczykami naraz. Ale jeśli nie zarzucasz haczyka, to tylko desperat zgodzi się pracować. Albo junior, który szuka pierwszej pracy.


4. Lokalne maksimum zaufania

"Lokalne maksimum", bo o prawdziwym zaufaniu to można mówić już jak się współpracuje z kimś jakiś czas. Tym niemniej już na rozmowie powinno się szukać pewnej nici porozumienia i szansy na współpracę.

To czego nie powinno być to nieufność. Czyli pytamy kandydata o rzecz/technologię X, a potem (nie mając logicznych argumentów) okazujemy niedowarzenie, podważamy to co mówi, czy deprecjonujemy czyjeś doświadczenia.

Nie wiem skąd się to bierze. Myślę, że to może być jakaś cecha polskiej mentalności.

Oczywiście, można a nawet trzeba sprawdzać jakoś kandydatów, ale od tego lepsze są testy kompetencji albo ogólna dyskusja (z logicznymi argumentami i konkretnymi pytaniami technicznymi), a nie to, co rekruterowi się rzekomo wydaje.

5. Brak płytkich osądów

a) brak wykształcenia informatycznego nie oznacza, że ktoś nie umie programować. Ba, nawet studiowanie humanistycznego kierunku nie zaprzecza tego, że ktoś może być dobrym programistą.

Oceniajmy po skillach, panowie. I panie. A nie po rasie, płci czy wykształceniu.

b) krótkie doświadczenie w pracy na etacie nie oznacza wcale krótkiego doświadczenia w programowaniu. Poza etatem też jest życie. Też są projekty. Zarówno komercyjne, jak i niekomercyjne. Szczególnie te ostatnie często potrafią dać więcej doświadczenia niż klepanie czegoś w firmach.

c) to, że ktoś nie zna technologii X, nie znaczy, że nie może się tego nauczyć w kilka dni po rozpoczęciu pracy. Technologie to pikuś, jeśli mają sensowną dokumentację.


6. Do your homework

- rekruter powinien przeczytać CV kandydata jako tako przed rozmową, a nie dopiero w trakcie czytać pierwszy raz, jak to się często zdarza.

- fajnie byłoby też wykazać się jakąś inicjatywą i jeśli w CV jest link do Githuba, twittera czy bloga, to wejść w dany link i zobaczyć, czym dany kandydat się zajmował przez ostatni czas.

To takie trudne?