Należy bardzo poważnie rozważyć instrukcje człowieka, który stworzył, między innymi takie marki jak StackOverflow czy Trello. Posiada własną firmę pod nazwą Fog Creek Software. Wcześniej był jednym z głównych twórców Excela w Microsoft.

W tym poście spisałem wskazówki dotyczące prowadzenia rozmów kwalifikacyjnych na stanowisko programisty jakie przeczytałem w książce „Programista poszukiwany” Joel’a Spolsky. Książka jest bardzo zwięzła i krótka, a poniżej jeszcze krótsze streszczenie.

§0

Szukamy tylko najlepszych pracowników. Nie należy obniżać standardów, niezależnie od tego jak trudno jest znaleźć dobrego kandydata. Bardzo dobrzy programiści są średnio od trzech do dziesięciu razy wydajniejsi od przeciętnych, a kosztują zaledwie 20 do 30 procent więcej. Co więcej, bez trudu osiągają to, co dla innych jest poza zasięgiem.

§1

Odrzucenie dobrego kandydata jest o wiele mniej inwazyjne dla firmy niż zatrudnienie kiepskiego. Zły kandydat nie tylko będzie kosztował firmę masę pieniędzy, ale też będzie zabierał czas pozostałym pracownikom. Odrzucając dobrego kandydata można by się zastanawiać czy to jest etyczne. Jeśli dany kandydat na prawdę jest bardzo dobry, to i tak prędzej czy później znajdzie sobie dobrą pracę – jesteśmy usprawiedliwieni.

§2

Zawsze należy podjąć próbę zaangażowania przynajmniej sześciu osób do procesu rekrutacji, z czego pięć powinno pochodzić z grupy potencjalnych pracowników. Patrząc z punktu widzenia kandydata, rozstrzygnięcie na swoją korzyść jednej rozmowy kwalifikacyjnej jest po prostu zbyt łatwe.

§3

Jeśli przynajmniej dwóch z sześciorga pracowników prowadzących rozmowę uważa, że dany kandydat nie zasługuje na zatrudnianie – nie zatrudniamy go. W praktyce oznacza to, że już po dwóch rozmowach możemy zakończyć rekrutację nie tracąc więcej czasu i pieniędzy. Nie odrzucamy kandydata sugerując się opinią tylko jednego programisty biorącego udział w rekrutacji.

§4

Należy unikać prowadzenia rozmowy jednocześnie z kilkoma potencjalnymi programistami. To po prostu jest nieuczciwe. Zaznaczam tutaj słowo „programistów”. Istnieją stanowiska gdzie podczas rozmowy należy sprawdzić zachowania w grupie, umiejętność ubierania czapeczki lidera, itp. Jednak poszukując programistów możemy sobie taką rekrutacją tylko zaszkodzić uwypuklając nieistotne umiejętności, które mogą być potrzebne na innych stanowiskach, nie sprawdzając przy tym umiejętności programistycznych.

§5

W czasie rozmowy mamy do czynienia z trzema typami kandydatów:

• Kandydaci, których wartość dla firmy jest praktycznie zerowa – brakuje im podstawowych kompetencji do pracy.
• Prawdziwi geniusze programowania, gwiazdy piszące kompilatory dla zabawy w wolnym czasie.
• Mnóstwo kandydatów do rozważenia, których przydatność do tworzenia danego projektu nie jest na pierwszy rzut oka oczywista.

§6

Po przeprowadzeniu rozmów kwalifikacyjnych, musimy podjąć decyzję: zatrudniamy albo nie zatrudniamy. Nigdy nie może być trzeciej odpowiedzi, takiej jak np. zatrudniamy ale za pół roku, lub zatrudniamy ale nie do mojego zespołu.

§7

Jeśli mamy kandydata, który pasowałby do zadań w naszym zespole i na daną chwilę byłby dla nas przydatny, ale wiemy, że w innym zespole lub za jakiś czas gdy projekt się zmieni, ta osoba nie sprawdzałaby się, to odpowiedź brzmi: nie zatrudniamy. W świecie programowania, technologie tak często się zmieniają, że potrzebujemy ludzi którzy skutecznie potrafią zając się dowolnym zagadaniem programistycznym. Osoba, która dzisiaj znakomicie zna się na XAML’u powinna potrafić równie świetnie poradzić sobie w przyszłości z JavaScript.

§8

Jeśli nie jesteśmy wstanie ocenić kandydata i nie wiemy jaka jest poprawna decyzja wówczas odpowiedzieć brzmi: nie zatrudniamy. Gdy mówimy: „… ten kandydat jest naprawdę dobry ale nie jestem pewien czy …:”, wówczas odpowiedź brzmi: nie zatrudniamy. Tego typu podejście znacznie podnosi jakość zatrudnionych osób.

§9

Szukamy osób które:

• są inteligentne,
• doprowadzają sprawy do końca.

Krótka rozmowa kwalifikacyjna nie jest wstanie dostarczyć więcej informacji na temat kandydata. Osoby inteligentne ale pozbawione umiejętności doprowadzania spraw do końca nierzadko mogą się szczycić doktoratami i zatrudnieniem w wielkich korporacjach, w których nikt z ich zdaniem się nie liczy. Zamiast dostarczać na czas gotowe rozwiązania, grzęzną w bezproduktywnych rozważaniach akademickich.

Pracownicy z umiejętnością doprowadzanie spraw do końca, ale nieinteligentni podejmują głupie decyzje. Takie osoby sprawiają wrażenie osób działających bez zastanowienia, a ich błędy muszą być poprawiane przez innych pracowników. Jednym z czynników, które mogą zdradzać, że rozmawiamy z inteligentnym kandydatem to brak konieczności wielokrotnego wyjaśniania tej samej kwestii. Rozmowa z inteligentną osobą przebiega sprawnie.

§10

Dajemy się wypowiedzieć. Nie zadajemy pytań na które kandydat może tylko podpowiedzieć: „tak to prawda”, „tak to jest najlepsze rozwiązanie”.

§11

Najgorszą opcją jest przeprowadzanie quizów. Inteligencja nie jest tożsama z umiejętnością pamiętania mnóstwa faktów. Pytania typu: „Jaka jest różnica między typem varchar a varchar2 w systemie Oracle 8i?” jest przykładem najbardziej debilnego pytania. Gdy podczas pracy, dany inteligentny pracownik będzie potrzebował poznać odpowiedź na to pytanie to sprawdzi ją w czasie 15 sekund w internecie. Umiejętność odpowiadania na tego typu pytania nic nie wnoszą do oceny, nie przybliżają kandydata do określenia go mianem bardzo dobrego programisty. Każdy zbiór umiejętności jakim dysponuje kandydat w momencie rozmowy kwalifikacyjnej będzie przestarzały za kilka lat. Wiedza encyklopedyczna sprawdzona za pomocą quizów stanie się wówczas nieprzydatna.

§12

Najlepszym sposobem na rekrutację jest umożliwienie kandydatowi mówienia. Należny zadać otwarte pytanie lub wskazać jakiś ogólny problem do rozwiązania.

§13

Przed rozmową notujemy plan rozmowy, który może wyglądać tak jak poniżej:

• Wprowadzenie
• Pytanie o ostatni projekt realizowany przez kandydata
• Proste pytanie związane z programowaniem
• Pytanie na temat wskaźników lub rekurencji
• Czy jesteś zadowolony?
• Czy masz jakieś pytania?

§14

Nie należny wyrabiać sobie opinii o kandydacie przed rozmową z nim. Nie należny sugerować się tym, że pochodzi z takiego czy innego regionu lub, że studiował na takiej czy innej uczelni, lub sugerować się opinią innych osób, które nie są niedopowiedziane za podjęcie decyzji, a które skłonne są do wyrażania opinii na podstawie, np. znajomości. Jeśli ulegniemy tej pokusie, wówczas poprowadzimy rozmowę nieobiektywnie na korzyść lub niekorzyść kandydata.

§15

Faza: „Wprowadzenie” ma na celu rozluźnić atmosferę. Pada pytanie o podróż oraz później poświęcamy 30 sekund na przedstawianie się.

§16

Pytamy tylko o ostatni projekt, a jeśli jest to absolwent to pytamy o pracę dyplomową lub o ulubiony przedmiot na studiach.

§17

Jeśli spada tempo wypowiadania się, należny zadawać dodatkowe pytania w stylu: „Powiedz coś więcej na ten temat.” Niech kandydat mówi jak najwięcej, a my tylko słuchamy.

§18

Warto sprowokować kandydata do obrony swoich racji – to proste – wystarczy poczekać aż powie coś w 100% prawdziwego i powiedzieć: „To niemożliwe!”. Wówczas kandydat zacznie bronić swoich racji.

§19

Szukamy dowodów pasji, zaangażowania. Inteligentni programiści wkładają serce w wytwarzanie i rozwijanie oprogramowania. Tacy kandydaci mówią płynnie, szybko i żywo gestykulują. Dobrze gdy kandydat reagują podobnie omawiając negatywne aspekty poprzedniej pracy. Kiepscy programiści nie wykazują większego zainteresowania swoją pracą.

§20

Nieumiejętność opowiedzenia o danym projekcie na odpowiednim poziomie szczegółowości, jest sygnałem do odrzucenia kandydata. Inteligentny programista powinien potrafić opowiedzieć o wytwarzanym oprogramowaniu, zarówno osobie która kompletnie nie zna się na programowaniu, jak innemu programiście. Aby to sprawdzić należny poprosić kandydata o to, żeby opowiedział o swoim ostatnim projekcie w taki sposób jakby opowiadał o nim swojej ciotce.

§21

Należy sprawdzić czy kandydat w opisywanym przez siebie projekcie wykazywał predyspozycje do osiągania pozycji nieformalnego lidera. Możemy zapytać kogo inicjatywą był wybór tych technologii oraz poprosić o wyjaśnienie dlaczego ten wybór był najlepszy. Jeśli kandydat uważa, że nie był najlepszy to należny zapytać czy lobbował za innymi technologiami. Można wprost zapytać o ostatni projekt, w którym kandydat brał udział w roli lidera.

§22

Większa część rozmowy kandydata powinna być poświęcona stwarzaniu kandydatowi możliwości dowiedzenia, że potrafi pisać kod.

§23

Proste pytanie związane z programowaniem – należy wybrać zadanie, które przeciętnemu programiście nie powinno zająć więcej niż jedną minutę. Jest to bardzo szybki sposób wstępnego odrzucania kandydatów którym nie warto poświęcać więcej czasu i pieniędzy. Przykładem takich pytań są:

• Napisz funkcję określającą, czy łańcuch rozpoczyna się od wielkiej litery z przedziału od A do Z.
• Napisz funkcję obliczającą pole powierzchni koła o danym promieniu.
• Zsumuj wszystkie wartości tablicy.

Jeśli nie jesteśmy wstanie poruszać się w świecie prostych zagadnień z prędkością 100 km/h, nigdy nie odnajdziemy się wśród bardziej złożonych problemów.

§24

Zadajemy pytanie, w którym kandydat musi się wykazać rozumieniem referencji i wskaźników. Po 15 latach doświadczenia w rekrutowaniu Joel Spolsky doszedł do wniosku, że rozumienie wskaźników i referencji nie należy traktować jako umiejętność – to raczej kwestia talentu.

Z jakiegoś powodu większość programistów (w tym duża część programistów, która wydaje się być dobra) rodzi się bez ośrodka w mózgu odpowiedzialnego za rozumienie wskaźników. Najlepsi kandydaci bez trudu radzą sobie w rozumieniu zagadnienia na różnych poziomach abstrakcji, co pozwala na implementację algorytmów rekurencyjnych lub złożonych algorytmów operujących na wskaźnikach.

Aby sprawdzić, czy dany programista posiada ten rodzaj talentu, należy zadać pytanie gdzie użycie wskaźników pozwala rozwiązać zadanie. Takie przykładowe zadanie to: napisz kod odwracający kolejność elementów tablicy.

Wszystkich tych, którzy uważają że w C# czy w Java lub w innych językach nie będących językami C/C++ ten rodzaj talentu nie jest wymagany odsyłam do książki „Programista poszukiwany”, do rozdziału „Podręczna instrukcja prowadzenia rozmów kwalifikacyjnych”.

§25

Poniżej kilka dodatkowych pytań, które należy zadać po ukończonym zadaniu. Celem tych pytań jest nawiązanie dyskusji.

• Dlaczego zrobiłeś to w ten sposób?
• O czym zapomniałeś?
• Czy jesteś zadowolony z tego kodu?
• Gdzie popełniłeś błąd?

To jest kwintesencja części rozmowy poświęconej otwartemu zadaniu. Bardzo rzadko zdarza się, że programista nie popełnił ani jednego błędu ale nie o to tutaj chodzi. Sprawdzamy umiejętność poprawiania błędów oraz sposób analizy kodu. W tym etapie sprawdzamy również umiejętność bronienia swoich racji.

§26

Na ostatnim etapie rozmowy kwalifikacyjnej sprawdzamy, czy kandydat ma jakieś pytania. Musimy pamiętać, że chociaż to my prowadzimy rozmowę kwalifikacyjną, najlepsi kandydaci mają do wyboru wielu pracodawców i podczas rozmów w naszej firmie sami oceniają, czy chcieliby dla nas pracować.

§27

Nie należy przywiązywać wagi do sensowności zadawanych pytań. Na tym etapie powinniśmy mieć już wyrobione zdanie na temat kandydata.

§28

Zawsze zostawiamy sobie 5 minut na końcu rozmowy aby zaprezentować naszą firmę i jego ewentualne stanowisko pracy. To bardzo ważne, nawet gdy nie planujemy przyjąć danego kandydata. Mamy swój czas aby wypuścić w obieg jak najlepszą opinię o naszej firmie.

§29

Należy unikać łamigłówek typu: „Jak ułożyć cześć zapałek, aby tworzyły dokładnie cztery trójkąty równoboczne. Większość tego rodzaju pytań należy do kategorii „Aha” – zwykle znamy odpowiedź albo nie. Znajomość odpowiedzi na taką łamigłówkę dowodzi tylko, że zetknęliśmy się kiedyś z nią.

§30

Nie należy zadawać pytań, których odpowiedź jest oparta o zgadywanie. Na przykład: „Ilu stroicieli pianin mieszka w Krakowie”. Można zacząć rozkminiać ile jest mieszkańców w Krk, szacować jaki procent ludzi ma pianino i na tej podstawie obliczyć ilu stroicieli pianin mogłoby nasycić rynek. Tego typu pytanie może posłużyć jako test na inteligencję ponieważ pokazuję tok rozumowania, ale pod warunkiem, że sami dysponujemy bardzo dobrymi pytaniami pomocniczymi, które mogą naprowadzić kandydata na poprawną odpowiedź. Jeśli nasza pomoc w rozwiązaniu ma polegać na podaniu poprawnej odpowiedzi wówczas usłyszymy od kandydata odpowiedz: „Aha”.

§31

Optymalny czas na podjęcie decyzji o zatrudnieniu lub nie, to trzy minuty po rozmowie. Każda większa zwłoka w naturalny sposób wymazuje z naszej pamięci coraz więcej szczegółów, co wymusza na nas podjęcie decyzji na podstawie co raz mniejszej ilości informacji o kandydacie.

§32

Musimy być gotowi na poniesienie dodatkowych kosztów niezbędnych do wyeliminowania przeszkód jakie stoją przed zatrudnieniem bardzo dobrego programisty.

• przeprowadzka – zapłacimy Ci za to
• prawnik pomagający w imigracji – zapłacimy Ci za to
• praca dla małżonki / małżonka – pomagamy w znalezieniu
• potrzeba brokera nieruchomości – zapłacimy Ci za to
• chcesz obejrzeć kilka domów – zapłacimy Ci za to

§33

Jeśli jesteśmy zmuszeniu odmówić kandydatowi, powinniśmy zrobić to możliwie szybko i z szacunkiem. Nie mamy obowiązku tłumaczyć kandydatowi swojej decyzji.

Bibliografia:
1. „Programista poszukiwany” Joel Spolsky