Nasza strona używa cookies. Dowiedz się więcej o celu ich używania i zmianie ustawień w przeglądarce. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Bez ,,zadań domowych’’ - czyli kilka słów o dobrej rekrutacji

Rafał Kotusiewicz Co-Owner / nexonIT
Rozmowa rekrutacyjna to nie egzamin, a szansa na dialog dwóch osób.
Bez ,,zadań domowych’’ - czyli kilka słów o dobrej rekrutacji

Tytułowe ,,zadanie domowe”, o którego wykonanie bywasz poproszony przy pierwszym kontakcie z firmą (rzadziej rekruterem) jest złem niekoniecznym. Postaram się tę tezę udowodnić kilkoma argumentami i w dalszej części przedstawić moim zdaniem lepszy proces.


„Zadanie domowe” to najczęściej niewielki projekt do zaimplementowania. Zwykle zajmuje kilka do kilkunastu godzin. Zastanawiałem się ostatnio nad tym zjawiskiem - nie jest ono wcale rzadkie i programiści coraz częściej zostają postawieni w sytuacji, gdy zamiast pójść do kina muszą zostać w domu i dodatkowo pracować. Dość regularnie prowadzę rozmowy weryfikujące techniczne umiejętności kandydatów. Na początku rozważałem ,,zadania domowe” jako element procesu, taki szybki sprawdzian przed rozmową. Po przemyśleniu uznałem jednak, że nie jest to dobre, a właściwie - jest nawet złe. Z kilku powodów.

Po pierwsze - sprytny kandydat może zlecić to zupełnie innej osobie (najsprytniejsi znajdą kogoś w Indiach, Chinach czy gdziekolwiek indziej, kto zrobi to za kilka, kilkanaście dolarów). To świadectwo prawdziwej zaradności, ale w rekrutacji programisty chodzi o coś zupełnie innego. Po drugie - kandydat może być osobą zapracowaną i najzwyczajniej w świecie nie mieć czasu na implementację. Trudno zmuszać kogoś (choćby nie wprost) do poświęcenia jednego, dwóch lub więcej wieczorów na wykonanie zadania, które tylko potencjalnie może przynieść korzyści. Po trzecie - moim zdaniem jest to oznaka braku szacunku.

Mocne, prawda? A więc wyjaśniam. Kandydat ,,zmuszony” jest do poświęcenia swojego czasu, nie mając nawet odrobiny pewności, że ktoś “pochyli się” nad jego pracą i ile czasu temu poświęci. Zaburza to partnerskie relacje pracownik-pracodawca jeszcze zanim dojdzie do współpracy. Tym bardziej, że jeśli przeczytamy CV kandydata to mniej więcej wiemy, jakich umiejętności możemy się spodziewać. Każdą z nich możemy sprawdzić w trakcie weryfikacji technicznej. I tak właśnie należy to zrobić. Rozmowa techniczna nie może być krótka. Nie może polegać na odczytaniu pytań z kartki i zaznaczeniu odpowiedzi udzielonej przez kandydata. W dalszej części przedstawiam moją wizję jej idealnej wersji.

Rozmowy rekrutacyjne nie są krótkie... te idealne trwają jeszcze dłużej.

Rozmowa łącznie trwa kilka godzin. To kawał czasu, byłoby więc dobrze, gdyby obie strony wyniosły z niej korzyści - niezależnie od ostatecznego wyniku.

Na początek zastanówmy się, jaka powinna być idealna rozmowa. Pozostańmy dla uproszczenia przy jej części technicznej, ale dotyczy to każdego aspektu i każdego etapu, co w zasadzie przekłada się na cały proces rekrutacji.

Moim zdaniem jej idealna wersja posiada kilka poniższych cech:

  • sympatyczna
  • interesująca
  • inspirująca
  • fabularyzowana

Przy pierwszym czytaniu lista wygląda dziwnie. I żadna z wymienionych cech nie kojarzy się z rozmową weryfikacyjną, raczej z książkami, filmami i rodzinnymi spotkaniami :) Przyjrzyjmy się więc jej punkt po punkcie.

Sympatyczna

Po pierwsze atmosfera powinna być partnerska – w żadnym momencie, żadna ze stron nie powinna czuć się jak petent. Obie strony są w trakcie rozmowy równe, potrzebują się wzajemnie i należy o tym cały czas pamiętać. Jeśli spotykamy się w jednym miejscu, należy zadbać o konwenanse oraz być dla siebie miłym i nie oszczędzać uśmiechów (przecież nic nie kosztują). Nie przerywamy sobie nawzajem, słuchamy się, a podczas rozmowy technicznej nie krytykujemy złośliwie zaproponowanych rozwiązań. Nie ma nic złego w zwróceniu uwagi na uchybienia (także drobne), ale zawsze powinno się to odbywać z szacunkiem.

Interesująca

Podczas każdej rozmowy staram się czegoś nauczyć od kandydata, z którym rozmawiam. Niektórzy potrafią naprawdę zaskoczyć mnie swoją drobiazgową wiedzą na dany temat. Nikt z nas nie jest doskonały, nikt nie wie wszystkiego, wiemy tyle, ile potrzebne nam jest do codziennej pracy i osobistego rozwoju (no może przesadziłem, wszyscy interesujemy się wieloma rzeczami i wierzę, że wiemy nieco więcej). Nie ma nic wstydliwego w tym, że kandydat wie coś, o czym my nie mamy pojęcia – to nawet dobra sytuacja, czegoś przecież się uczymy. W każdej rozmowie próbuję zainteresować rozmówcę czymś, co mogę mu przekazać i uważnie słucham tego, co on mi oferuje.

Inspirująca

Co to znaczy w kontekście rozmowy kwalifikacyjnej? Może brzmi to jak pomyłka, jednak upieram się przy tym, że nią nie jest. Dwie osoby spotykają się (zwykle po raz pierwszy) i poświęcają swój czas - nie jest to oczywiście spotkanie towarzyskie, tylko intensywna rozmowa, której celem jest ustalenie czy strony będą, choćby potencjalnie, zadowolone ze współpracy. Rozmówcy słuchają się i wymieniają informacjami oraz pytaniami. Nie przepadam - no dobra, nie lubię - rozmów, podczas których „weryfikator” przepytuje kandydata pytaniami zapisanymi na kartce, czasami poukładanymi w nieoczywistym porządku logicznym, a czasami zupełnie przypadkowo. Lubię, gdy z rozmowy wynikają jakiekolwiek wartościowe przemyślenia dla obu stron, ale właśnie w formie inspiracji:

Hmm... nie wiedziałem do dziś, że (tutaj wstaw nazwę swojego ulubionego narzędzia) może pomóc mi w pracy na tyle różnych sposobów!

albo:

Oooo... to mój język programowania może tak wyglądać? To jest takie proste?

Chodzi o ten rodzaj sugestii, który nie poniża, nie zawstydza, tylko wskazuje interesujące dla obu stron nieznane drogi, stając się w ten sposób inspiracją. Jak sprawić, żeby rozmowa była inspirująca? O ile nie jest to bardzo łatwe, to wydaje mi się wykonalne. Moim zdaniem powinna być po prostu fabularyzowana.

Fabularyzowana

Podzielę się moim „przepisem” na fabułę rozmowy. Zwykle zaczynam od przedstawienia się i opowiedzenia o sobie. Zajmuje to co najmniej kilka minut, czasami dłużej, w zależności od energii rozmowy. Zwykle jestem w lepszej sytuacji niż mój rozmówca, bo miałem okazję kilka razy przejrzeć jego CV. On na wejściu nie wie o mnie nic. Po mojej części, kiedy już – mniej więcej –  wie z kim rozmawia, proszę o rewanż i opowiedzenie o sobie ciekawych rzeczy, które nie wynikają w sposób oczywisty z CV. Rozmowa, wciąż prowadzona profesjonalnie, nabiera nieca osobistego charakteru. Po kilkunastu minutach coś już o sobie wiemy.

Kiedy obie strony (a w szczególności kandydat) są już zrelaksowane, zaczynam od bardzo prostego, ale adekwatnego do całej rozmowy pytania technicznego, które buduje pewność siebie mojego rozmówcy. Zależy mi na tym, żeby zaprezentował się od najlepszej strony. Myślę, że zbudowanie atmosfery zaufania i „podarowanie” pewności siebie ma dobry wpływ na efekt końcowy.

Przez kolejne kilka/kilkanaście minut rozmawiamy o języku programowania (zwykle jest to Java). Nie pytam o rzeczy oczywiste (for/if/try/catch), tylko o ciekawostki - rzadko, ale jednak używane podczas pracy. Po jakimś czasie wiem, czy mam do czynienia z programistą, który uczy się z kodu dostępnego na Stack Overflow i kodu kolegów (niekoniecznie dobrych programistów), czy jednak z osobą, która kierowana ciekawością, zajrzała do oficjalnej dokumentacji lub książek poświęconych programowaniu w tym języku. Staram się jednak nie zawstydzać, bo nie o to chodzi, a wszystkich elementów nieznanych można się przecież nauczyć. Wsłuchując się w reakcję rozmówcy usiłuję wnioskować, czy zajrzy do odpowiednich tekstów, żeby pogłębić wiedzę, czy po prostu zapamięta to, czego dowiedział się podczas rozmowy.

Kolejne etapy siłą rzeczy dotyczą ogólnie inżynierii oprogramowania (testowanie, wzorce projektowe, bazy danych). W trakcie rozmowy na temat wzorców podejmuję dyskusję, najczęściej wybierając dwa wzorce rozwiązujące podobny problem i prosząc o wskazanie różnic. Staram się jednak, żeby zdecydowanie była to dyskusja (kulturalna) a nie odpytywanie. Na tym etapie przechodzimy do implementacji jakiegoś prostego wzorca wraz z rozmową na temat szczegółów.

I tutaj trafiamy w sedno tego artykułu. Implementacja rozwiązania odbywa się podczas rozmowy! Dlaczego? Bo działamy w trybie pracy zespołowej (coś na kształt pair programming); mam wówczas pewność, że kod pisany jest przez kandydata, a nie ściągnięty z sieci i wrzucony gdzieś na GitHub. Jeśli jakieś zaproponowane rozwiązanie wydaje mi się kontrowersyjne (lub niejasne) proszę o wyjaśnienie, czasami zaproponuję coś innego. Pojawia się interakcja, która jest – chyba nie tylko moim zdaniem – niezwykle ważna w tym zawodzie. Oczywiście jest kilka warunków:

  • problem do rozwiązania musi być krótki (maksymalnie kilkanaście minut  - Singleton, Decorator, Template Method)
  • nie może to być problem skomplikowany (nawet w najlepszej atmosferze kandydat ma pewien poziom stresu, który bardzo utrudnia kreatywne myślenie)
  • nie może to być problem trywialny (przez najzwyklejszy szacunek do kandydata)


Nie wybieram nigdy żadnych powszechnie znanych algorytmów (sortowanie, wyszukiwanie), ani problemów wymagających zastosowania jakiegoś frameworka lub szczególnej biblioteki. Znajomość jednego lub drugiego staram się zweryfikować podczas rozmowy – większość bibliotek i frameworków ma jakieś charakterystyczne właściwości dostępne dla programisty na pewnych poziomach poznania. Dość łatwo sprawdzić do jakiego stopnia je poznał.


Pewnego razu podczas rozmowy…

Kandydat, z którym rozmawiałem na pytanie o testy odpowiedział, że zawsze, bez wyjątku pisze testy przed kodem rozwiązania. Daje mu to pewność, że działa szybko i robi tylko to, co jest koniecznie. Przypomniało mi to fragment książki o TDD. Nie podzieliłem się swoimi wątpliwościami, ale gdy wiele minut później skończyliśmy wspólne programowanie i wciąż nie było żadnego testu pozwoliłem sobie zapytac jak to się stało. :) Człowiek był tak zestresowany (mimo, że wydawało się, że nie jest), że zapomniał o niemalże najważniejszej sprawie. Oczywiście testy się szybko pojawiły, a sposób ich napisania jasno wskazywał, że programista wiedział, co robi. Gdybyśmy nie pracowali wspólnie być może nie zrobiłby tego błędu, a być może zrobił i nie miał okazji poprawić.


Ostatni etap rozmowy to sprawdzenie zdolności rozmówcy do świadomej, samodzielnej nauki (wypracowane, bądź wyuczone, metody poznawcze). Pytam również o książki, które czyta, oraz inne źródła pozyskiwania informacji o nowościach w branży (blogi, serwisy itd.). Chętnie dzielę się także swoimi przemyśleniami oraz podejmuję dyskusję, by wzajemnie się czegoś nauczyć i zainspirować. Niektórym czytanie książek wyda się kontrowersyjne. :) Parę razy usłyszałem, że człowiek ma tyle pracy, że nie ma na to czasu. Jednak moim zdaniem odpuszczenie tego aspektu sprawia, że trudno być kompetentnym inżynierem i w pewien subtelny sposób spowalnia rozwój.

Ostatnie pytanie to prawie zawsze: 

Co powinienem zrobić, żeby kolejna rozmowa była lepsza?

Wyciągam wnioski z każdej uwagi i staram się je możliwie szybko wdrożyć w życie. Czasami ta część się przedłuża, gdy okazuje się, że udało się w jakiś sposób zainspirować rozmówcę. Wymieniamy się wtedy tytułami książek wartych przeczytania, polecamy sobie kanały na YouTube, itd. ...

Zwykle cała rozmowa trwa dwie do trzech godzin, czyli cały wieczór. Ale wdrożenie trybu fabularnego sprawia, że ten czas mija dość szybko i naprawdę tylko raz lub dwa usłyszałem, że trwało to trochę za długo. :)

Podsumowując

Zadanie domowe nie buduje nawet potencjalnych więzi z kandydatem. Wspólne programowanie podczas rozmowy daje mu pewność, że jesteśmy zainteresowani tym, co ma do zaoferowania. Możemy na bieżąco korygować, wskazywać swoje oczekiwania, zmieniać kierunek implementacji. Budowanie dobrych relacji (nawet jeśli nie dojdzie do współpracy) uważam za kluczowe. Niektórzy nazywają to candidate experience, dla mnie to po prostu okazanie szacunku. Z wieloma osobami, z którymi przeprowadzałem rozmowy, utrzymuję kontakt mimo, że nie doszło do współpracy. Kilku osobom starałem, bądź staram się pomóc osiągnąć poziom zadowalający do podjęcia współpracy. Jak to robię? Na cztery różne sposoby:

  • motywuję
  • pokazuję kierunek i metody rozwoju
  • wspomagam dobrym słowem podczas rozmowy
  • spoglądam w pisany przez niego kod i robię review


Mam nadzieję, że choć trochę ,,czynię świat lepszym”. :)

📚📚📚
UWAGA: Wygraj książkę "Hakerzy i malarze. Wielkie idee ery komputerów". Opisz w komentarzu na fb doświadczenie z rozmowy rekrutacyjnej, które najbardziej utwiło Ci w pamięci. Masz czas do 1 kwietnia, wybierzemy wtedy jedną osobę, do której wyślemy tę księżkę.
📚📚📚


Na sam koniec

Naucz się programować w Lispie/Clojure. Więcej o tym w kolejnym tekście.

Podziękowania

Oczywiście winien jestem podziękowania. Także i tym razem kieruję je do Mai i Dominika, oraz do wszystkich moich rozmówców – mam nadzieję, że miło wspominacie nasze rozmowy, a te przydługie wieczory nie utkwiły w Waszej pamięci jako strata czasu. Mam nadzieję, że w jakiś sposób Was zainspirowałem i zmotywowałem, Wy mnie tak! Dziękuję za Wasze ciepłe słowa i opinie.

I na koniec - pewnie najważniejsze – podziękowania dla mojej żony i córki za cierpliwość, gdy spędzałem kolejne wieczory rozmawiając przez Skype z zupełnie obcymi osobami (dla mnie już nie), zamiast spędzać je z Nimi.

 

Zobacz więcej na Bulldogjob

Masz coś do powiedzenia?

Podziel się tym z 100 tysiącami naszych czytelników

Dowiedz się więcej
Rocket dog