Przeczytałem niedawno krótki tekst, w którym pewien brytyjski rekruter IT wskazał na 5 najlepszych, jego zdaniem, pytań jakie powinno się zadawać programistom na rozmowach rekrutacyjnych. Ciekawe to pytania, ale na pewno nie określiłbym ich mianem najlepszych. Niektórych pewnie nie zadałbym w ogóle…
Co to za pytania?
1) “Nad jakimi projektami pracujesz w domu?” (Ma rzekomo sprawdzić, czy programista rzeczywiście ma pasję, której to oznaką będą domowe projekty i programowanie po godzinach).
2) “Z jakimi wersjami beta programów bawisz się?” (Zdaję sobie sprawę, że głupio brzmi w moim tłumaczeniu z angielskiego to pytanie, ale nie wpadłem na lepsze. W oryginale brzmiało “What beta toys are you playing with?” (nieco erotycznie). Pytanie ma za zadanie zbadać, czy programista nadąża za nowinkami technologicznymi, czy jest na bieżąco).
3) “Z jakich systemów kontroli wersji korzystasz?” (Dzięki temu pytaniu powinniśmy dowiedzieć się nt. praktyk programistycznych kandydata).
4) “Jakie jest twoje podejście do dokumentacji?” (j.w.)
5) “Podaj mi przykład projektu, który kompletnie się nie udał?” (Pytanie ma zbadać, jak kandydat reaguje w trudnych sytuacjach oraz jak naprawdę zachowuje się w miejscu pracy).
Właściwie zasadność każdego z tych pytań byłbym w stanie poddać sensownej krytyce. Tu skupię się na dwóch pierwszych, które wprawdzie są całkiem do rzeczy, ale chyba tylko tyle – daleko im do “top 5”?
Zasadność pytania nr 1 w sprawdzeniu, czy na rozmowie rekrutacyjnej mamy do czynienia z dobrym programistą, opiera się na założeniu, że dobry programista to programista z pasją; taki, dla którego programowanie jest nie tylko zawodowym, ale i życiowym powołaniem; taki, który programuje nie tylko w pracy, ale i po pracy. Jeśli ma jakieś hobby, to jest nim głównie programowanie. Rzeczywiście, trudno odmówić takiej osobie pasji do programowania. Czy jednak oznacza to koniecznie, że jest taki ktoś dobrym programistą? Fakt, spędza więcej czasu nad kodem, ma styczność z większą liczbą technologii. Ale co jeśli kiepsko przy tym myśli, nie “dowozi” rzeczy do końca i ma złe praktyki programistyczne?
Podstawowy jednak problem z tym pytaniem mam taki, że programiści-pasjonaci, spędzający znaczną część czasu wolnego na programowanie to chyba mimo wszystko mniejszość programistów. Większość ludzi, niezależnie od wykonywanego zawodu, ma jakieś rodziny, jakieś obowiązki domowe, lubi obejrzeć film czy poczytać książkę, pójść na piwo ze znajomymi, pouprawiać jakiś sport. Zostaje mało czasu na coś więcej. Dodatkowo, wielu programistów, po intensywnej intelektualnej pracy 8 godzin dziennie, woli najzwyczajniej odpocząć. Czy są gorszymi programistami niż ci kodujący również w domu? Niekoniecznie.
Oczywiście, zajmowanie się własnymi projektami “domowymi” może przynieść programiście wiele korzyści. Może być np. dobrym sposobem na poznanie technologii, z którymi nie ma się szansy styczności w pracy. Każdy czas spędzony z kodem jest dla developera cenny. Jednak sam fakt spędzania wolnego czasu na programowanie to moim zdaniem zdecydowanie zbyt mało, by mogło być kluczowym atutem w dowiedzeniu swoich kompetencji na rozmowie rekrutacyjnej. Programiści zaczynający po godz. 17 “życie pozakodowe” często są równie dobrymi specjalistami jak ci programujący także po godzinach.
Stąd pytanie “Nad jakimi projektami pracujesz w domu?”, jakkolwiek nie najgorsze – gdyż może powiedzieć co nieco o pasjach kandydata – nie jest na pewno pytaniem “top 5”.
O pozostałych pytaniach w kolejnym wpisie (też mam życie poza rekrutacją 🙂
_______
(Visited 21 times, 1 visits today)
> 1) "Nad jakimi projektami pracujesz w domu?"
[…]
> Zasadność pytania […] opiera się na założeniu, że dobry programista to […] taki, który programuje nie tylko w pracy, ale i po pracy. Jeśli ma jakieś hobby, to jest nim głównie programowanie. Rzeczywiście, trudno odmówić takiej osobie pasji do programowania. Czy jednak oznacza to koniecznie, że jest taki ktoś dobrym programistą?
To rozumowanie nie idzie zgodnie z kierunkiem związków przyczynowo-skutkowych.
* Przyczyną jest to, że gościu lubi programować; skutkiem jest to, że jest w tym dobry.
* Jeśli lubi programować (znowu przyczyna), to chce również to robić po pracy (skutek). Skoro chce, to prawie zawsze znajdzie czas, choćby na dłubanie w drobnicy.
"Dobry" i "robi to również poza pracą" nie wynikają jedno z drugiego, a jedynie są skorelowane.
Nie widziałem jeszcze dobrego programisty, który w ogóle programować nie lubi, a większość i tak w domu coś jeszcze robi na własny użytek (stworzenie prywatnego odtwarzacza multimediów czy spięcie kuchenki mikrofalowej z budzikiem), z podobnych przyczyn, dla których elektryk przemysłowy zwykle ma w domu przyzwoitą instalację elektryczną: jest w stanie wykonać o własnych siłach, więc po co płacić komuś innemu, a później się zżymać, że sam by zrobił inaczej/lepiej?
Inną sprawą jest czy programista będzie chciał opowiadać o domowych skryptach na sto dwadzieścia linii, gdy na co dzień pracuje z kodem po kilkanaście milionów i więcej.
> Fakt, spędza więcej czasu nad kodem, ma styczność z większą liczbą technologii. Ale co jeśli kiepsko przy tym myśli, nie "dowozi" rzeczy do końca i ma złe praktyki programistyczne?
Programiści z technologiami nie mają do czynienia *w ogóle*. Co najwyżej z frameworkami, bibliotekami i kompilatorami.
I prawdę mówiąc gwarancji nie ma, że osoba pisząca zawodowo i hobbystycznie jest lepsza niż tylko osoba pisząca zawodowo, ale tak samo nie ma gwarancji, że wykształcony elektryk jest lepszy od amatora. Pierwsze w obu przypadkach jest jedynie przesłanką, że jest lepszy.
Moim zdaniem te pytania to całkiem skuteczne narzędzie dla rekrutera (nie czarujmy się, 99% rekruterów nie ma bladego pojęcia o technologiach).
Dodatkowo nie zapominajcie, drodzy rekruterzy, że dobry programista to taki Makgajwer – dasz mu zapałkę, to naprawi czołg. Więc Wasze oczekiwania typu: milion lat doświadczenia w języku C czy znajomość tego a tamtego frameworka są… hmm… nieadekwatne. Dobry programista nauczy się tego bardzo szybko. Znacznie szybciej niż Wam się wydaje.
Zapytajcie też o testowanie i obsługę błędów – obok kontroli wersji to jest bardzo niewdzięczny temat – w książkach jest to najczęściej traktowane po macoszemu i tylko tym sumiennym programistom chce się w to bawić.
Takie moje 3 grosze.
Zaintrygowało mnie tłumaczenie drugiego pytania. Wiadomo, nie da się przetłumaczyć z angielskiego na polski czegoś, aby trafić idealnie, jednak, aby nie miało to wspomnianego skojarzenia, może lepiej było by użyć "Jakimi wersjami beta programów zajmujesz się na co dzień?", lub "Jakimi wersjami beta programów zajmujesz się najczęściej". To moje subiektywne wnioski. Nie czytałam tekstu w oryginale, także zdaję sobie sprawę, że mogę być w błędzie.
Ja również nie poznałem dobrego programisty, który by nie pracował jednocześnie nad czymś własnym.
Ważnym aspektem w życiu programisty jest bycie na bieżąco z nowinkami, czasem w codziennej pracy nie jest to możliwe, np. gdy wylądujemy w długoterminowym projekcie i będziemy pracować przy użyciu tych samych technologii przez co najmniej rok.
Sam gdy ląduje w dłuższym projekcie Androidowym, to w wolnym czasie pracuje nad własnym projektem dla iOSa (i na odwrót), żeby nie wypaść z obiegu, a mimo to mam czas na inne rozrywki ;).
Jak dla mnie trzy żeczy są ważne: Myślenie, motywacja, kompetencje. Żaden z wymienionych punktów z tym specjalnie nie koreluje. Np: Robienie projektów w domu może świadczyć o tym, że kandydat pracę u kogoś traktuje jako zło konieczne ale stara się realizować na swoim. Taka postawa sprawdzi się bardziej w startupie niż kołchozie w którym jedzie się ze szczegółowej analizy technicznej. Sztampowe regułki są fajne ale czesto bezużyteczne.