Jak rekrutować programistów?

szkolić programistów jak mają rekrutować innych programistów

Moim zdaniem nie ma takiej potrzeby. Chyba programista (a także każdy inny fachowiec) sam najlepiej oceni, jak mu się z daną osobą pracuje. Raczej nikt sobie nie weźmie do drużyny kogoś, kto będzie spowalniać pracę i nie będzie ogarniać tematów. Podczas takiego spotkania można ocenić, czy dany pacjent jest komunikatywny, dać mu jakieś proste zadanie do rozwiązania, żeby zobaczyć, w jaki sposób pracuje, jak podchodzi do tematu itp. Raczej nie ma sensu zawalić kandydata serią pytań z gwiazdką, podchwytliwych i szukających dziur w całym ani pytać jakim warzywem by chciał być w sałatce jarzynowej, albo komu by ustąpił miejsca w tramwaju - staruszce, kobiecie w ciąży czy inwalidzie ;)

często narzucają procesy stworzone przez jakieś HRowe zespoły, które z programistami mają niewielką styczność

Zgadza się, ale to jest zło i strata czasu. Zarówno czasu kandydatów, jak i samej firmy, która musi taki HR utrzymać, opłacić itp. Moim zdaniem jedynymi osobami, które mają znaczenie w rekrutacji, powinny być osoby techniczne. To tak, jakby ktoś z nas dostał polecenie wybrania kogoś do pracy jako grafik. Możemy zapytać o warstwy w Photoshopie, o profile ICM czy dać jakiś prosty obrazek do obrobienia. Ale raczej nie będzie to merytoryczna ocena. Tak samo jest z ocenianiem programistów przez dział HR albo jakichś pośredników - mogą pewne proste rzeczy sprawdzić, ale raczej ich ocena nie będzie miała większej wartości.

cerrato napisał(a):

szkolić programistów jak mają rekrutować innych programistów

Moim zdaniem nie ma takiej potrzeby. Chyba programista (a także każdy inny fachowiec) sam najlepiej oceni, jak mu się z daną osobą pracuje.

W sumie poruszyłeś tutaj ciekawy aspekt, który mnie osobiście strasznie drażni. Ostatnio w firmach nasila się trend rekrutowania osoby do firmy a nie do zespołu (czyli daną osobę rekrutuje dwójka randomowych programistów z firmy i dopiero po rekrutacji taka osoba jest przydzielona do jakiegoś zespołu), więc z automatu ta perspektywa chociaż słuszna praktycznie traci rację bytu, bo możesz tylko powiedzieć czy z danym kandydatem Tobie się będzie dobrze pracować a nie ziomkom do których zespołu taki człek trafi.

trend rekrutowania osoby do firmy a nie do zespołu

I to nie jest fajne. Bo tak, jak piszesz - człowiek powinien pasować do danej ekipy/paczki i to ta ekipa powinna podjąć decyzję, czy on im pasuje, czy będzie się dobrze pracować itp. Oczywiście - nie ma co przeginać, ale zdanie ludzi, do których ma kandydat trafić, moim zdaniem jest znacznie ważniejsze, niż jakaś tabelka wypełniona przez panienkę z działu kadr. Sorry - teraz to się nie nazywa "kadry" ale HR ;)

Tutaj trzeba rozdzielić dwa wątki, oczekiwania firmy + proponowana pensja, oraz oczekiwania zespołu, ty możesz se rekrutować i przepytywać, jak firma ma kiepski budżet i opinię to raczej próżne nadzieje, a wręcz i frustracja po obu stronach ;)

Tak, ale z drugiej strony na aspekty finansowe (oraz owocowe środy) nie masz wpływu. Moim zdaniem ten wątek dotyczy raczej sposobu oceny kandydatów, a to, czy później dojdzie do zawarcia umowy to zupełnie inna sprawa.

dobry programista rozpozna dobrego - wystarczy parę zadań programistycznych i wiadomo z kim mamy do czynienia.

cerrato napisał(a):

Moim zdaniem ten wątek dotyczy raczej sposobu oceny kandydatów,.

Tak, ale żeby mieć kogo oceniać to musisz mieć najpierw porządnych kandydatów, a często jest tak, że oferta przygotowana przez hr, ma sie nijak do oczekiwań zespołu i samego kandydata, który dostaje serię pytań o kilka poziomów wyżej.

Odbijając piłeczkę to zbyt często rekrutacje wyglądają jak walki kogutów. Żeby dobrze rekrutować potrzeba:

• przeczytać dokładnie CV kandydata, łącznie z linkami w jego CV - Przeglądanie Githuba przed rozmową o pracę
• być na tyle dobrym, żeby móc ocenić umiejętności kandydata, zadawać pytania kandydatowi i unikać domysłów na jego temat,
• trzeba umieć wpasować kandydata w drabinkę płacową firmy i być z nim szczerym na temat tego ile można w danej firmie zarobić z danymi umiejętnościami,
• trzeba zapoznać się z osobistymi celami kandydata, w jakim kierunku chce się rozwijać, ale również podpowiedzieć mu inne możliwe opcje w danej firmie, być może ktoś chce się przekwalifikować?
• trzeba być szczerym z kandydatem na temat jakości projektów w firmie, zadań, które się chce mu powierzyć oraz celów, które można osiągnąć w firmie,
• rekrutujący nie powinni atakować kandydatów, atakowanie i obrażanie kandydatów to jest oznaka słabości rekrutującego,
• każdy kandydat ma prawo wiedzieć dlaczego firma nie decyduje się na jego usługi,
• każdy kandydat powinien mieć możliwość oceny procesu rekrutacji,
• rekrutacja powinna być jednocześnie możliwie krótka i możliwie wnikliwa, jeżeli rekrutujesz kogoś na konkretną pozycję to po co robić etap z jakimiś bzdurami, których znajomość wynika z CV (i linków powiązanych), a pytania nie są powiązane z danym stanowiskiem?

Mysle ze tak jak kazdego innego wykwalifikowanego pracownika. Szczerze przeszedlem kiedys rekrutacje do firmy (jedna z pierwszych w karierze) ktora polegala jedynie na napisaniu wielkiego testu o C++. Jakies pytania czy cos sie skompiluje, jak zrobic to, jak zrobic siamto, napisac jakis kod, przeanalizowac jakis kod na 2 kartki a4.... wszystko na papierze. Niby mialem jeden z lepszych wynikow - i na podstawie tego mnie przyjeto - ale warunki pracy, sposoby jej rozliczania i wspolpraca w teamie byla dla mnie tragedia. Jaki z tego wniosek? No nie pasowalem do tej firmy - i to mysle nie wina samej firmy, a po prostu rozbieznych oczekiwan moich i pracodawcy co do stanowiska. Dlatego nie skupialbym sie jedynie na technikaliach, bo ich ogarniecie to nie wszystko. Moze po drugiej stronie stolika mamy ukrytego napoleona, ktory technicznie ogarnia, ale chcialby zostac zaraz prezesem spolki, a oferujemy mu stanowisko w 100% techniczne? Albo na odwrot, stanowisko wymaga relacji z klientami, wspomagania teamow sprzedazowych, a rozmawiamy z introwertykiem ktory lubi w spokoju pisac kod? Takie rzeczy wychodza dopiero w rozmowie z gosciem, i fakt zawsze moze ktos sciemniac - ale wtedy sam pakuje sie na mine pracy ktora i tak go nie bedzie zadowalac. W dzisiejszych czasach jest tyle stanowisk i miejsc ze lepiej pojsc na cos co sie chce robic niz pakowac sie na sile w prace ktorej sie nie lubi.

twoj_stary_pijany napisał(a):

1 - zgoda, ale nie zawsze jest na to czas, szczególnie jak masz 50 cv na stole
2 - z tym raczej nie ma problemów, chyba, że to tylko moje doświadczenie, ale zawsze wpadałem na osoby bardzo doświadczone
3 - firma chce na Tobie zarobić, a nie dać Ci jak najwięcej po samej rozmowie rekrutacyjnej
4 - znaczy lubisz pytania gdzie się widzisz za 5 lat
5 - zgoda, ale często rozmowa jest prowadzona z osobą która tylko wie, że dany projekt jest a nie ma informacji jaki jest stack technologiczny itd
6 - a to coś takiego się zdarza? w drugą stronę 'ja mam miesiąc doświadczenia ale 15k się należy' to w zasadzie norma
7 - to kandydat powinien wywnioskować po samej rozmowie gdzie dał ciała, ale żeby dostać feedback to jednak zdarza się raz na 20 rozmów, ale odrzuć ofertę to dostaniesz milion pytań dlaczego nie chcesz
8 - bez znaczenia, raczej byłoby to samo co na goworku itd... tylko niezadowoleni/odrzuceni by coś wysyłali
9 - to co jest w cv nie świadczy o tym co kandydat potrafi, papier przyjmie wszystko

Ja bym zrobił tak
1)Krótka rozmowa przez telefon - dosłownie 2-3 pytania typu z podstaw np. czym sie różni RuntimeException od Exception albo co to Autocloesable + krótka rozmowa o samych potecjalnych warunkach zatrudnienia (główinie oczekiwania finansowe)
2)Zadanie do zrobienia - czy to w domu na 2 dni czy w firmie podczas rozmowy na godzinę czy pół, ale tylko na kompie
3)Rozmowa o doświadczeniu, wiedzy kandydata i podejściu do programowania (np jak radzić sobie z błędnymi danymi wejściowymi)
Przy czum nie chciałbym kolejnych typowych udnych pytań, tylko np. jak ogólnie działa Garbage Collector

1 - zgoda, ale nie zawsze jest na to czas, szczególnie jak masz 50 cv na stole

Rozumiem, że na pozycję juniora jest tylu chętnych, ale z aż 50 cv, ale przecież łatwo przefiltrować do np. 15. Każdy wie na czym polega hackowanie CV. Musisz podać jak najwięcej technologii, żeby wpasować się do klucza, ale takich, żebyś był w stanie o nich opowiedzieć na rozmowie. Staranność wykonania CV też ma znaczenie, proste literówki (nie mówię o takich trudnych do znalezienia, ale jeżeli znajdziesz ich 5 w jednym cv to jest to powód do odrzucenia), linki (w szczególności linki do własnych projektów). CV ma znaczenie i nie mówmy, że jak ktoś wysłał CV do firmy to z automatu ma przyjść na rozmowę bo to jest absurd. Szanujmy swój czas i nie zarzucajmy się spamem.

2 - z tym raczej nie ma problemów, chyba, że to tylko moje doświadczenie, ale zawsze wpadałem na osoby bardzo doświadczone

To znaczy, że mało zadajesz pytań na rozmowach w stylu: "a jakie jest twoje zdanie na ten temat?" lub "a jakiej odpowiedzi oczekiwałbyś na to pytanie?". Często rekruterzy odpowiadają: "nie jestem z tego ekspertem i jeszcze szukam poprawnej odpowiedzi".

3 - firma chce na Tobie zarobić, a nie dać Ci jak najwięcej po samej rozmowie rekrutacyjnej

Tak, jeżeli jesteś traktowany jak trybik. Jeżeli jesteś traktowany jako partner biznesowy to firma będzie chciała, żebyś czuł się komfortowo z tym ile prowizji na tobie zdzierają i podzielą się nadwyżką.

4 - znaczy lubisz pytania gdzie się widzisz za 5 lat

Tak, lubię. Każdy nowy projekt musi mi coś dawać oprócz pieniędzy w długim terminie. Oczywiście pytanie o sztywne 5 lat to karykatura, ale warto moim zdaniem na rozmowie rekrutacyjnej obie strony muszą dobrze poznać swoje potrzeby.

5 - zgoda, ale często rozmowa jest prowadzona z osobą która tylko wie, że dany projekt jest a nie ma informacji jaki jest stack technologiczny itd

Czyli z nieodpowiednią osobą.

6 - a to coś takiego się zdarza? w drugą stronę 'ja mam miesiąc doświadczenia ale 15k się należy' to w zasadzie norma

Jak idziesz do sklepu i widzisz koszulę za 1000 zł to zaczynasz obrażać producenta czy po prostu dziękujesz za ofertę?

7 - to kandydat powinien wywnioskować po samej rozmowie gdzie dał ciała, ale żeby dostać feedback to jednak zdarza się raz na 20 rozmów, ale odrzuć ofertę to dostaniesz milion pytań dlaczego nie chcesz

Czasami nie popełnisz na rozmowie żadnego błędu albo jesteś odrzucany przez szczegóły w stylu, że zawahałeś się przy odpowiedzi. Albo też odpowiedziałeś, że nie wiesz do końca czy lubisz daną technologię i oni to interpretują w stylu: "nie lubi, nie chce pisać w tej technologii". Feedback daje ci możliwość polepszania samego siebie nie tylko z wiedzy technicznej, ale też tego jak odpowiadać, żeby twoje odpowiedzi pasowały do oczekiwań drugiej strony. Rekrutujący ma wizję poprawnych odpowiedzi i często nie dopuszcza innych odpowiedzi do swojej głowy. Na koniec, feedback daje ci możliwość też oceny poziomu reprezentowanego przez rekrutującego, który odrzucił cię z powodu jakiegoś nieznaczącego szczegółu.

8 - bez znaczenia, raczej byłoby to samo co na goworku itd... tylko niezadowoleni/odrzuceni by coś wysyłali

Tak jak @WeiXiao zaznaczył. To jest opinia zwrotna kandydata do osób rekrutujących. Rekrutujący powinien móc ocenić proces. Czy ten proces pokazał jego wszystkie umiejętności? Być może kandydat czuje, że rekrutacja zeszła z tematu, którego oczekiwał na rozmowie i nie pokazała jego największych atutów. Można to też spróbować zaznaczyć w odpowiedzi.

9 - to co jest w cv nie świadczy o tym co kandydat potrafi, papier przyjmie wszystko

Ad punkt 1.

Gdzie wy macie te 50 cv na stole :P chyba przy rekrutacji juniorów. Od mida w górę, to już tak nie jest.
Moje doświadczenie jest takie, że TRZEBA dawać zadania i to takie na 4h+. Ostatnio miałem na rekrutacji gościa z małym doświadczeniem, ale teorie miał wykutą na 100%. Tak odpowiedział na wszystkie pytania, że dałem mu jakieś zadanie na 15 minut. Takie zadanie niestety pozwala tylko sprawdzić, czy ktoś zna składnie języka. Najgorsze było to, że trzeba mu było na koniec miesiąca za jego szkodliwą pracę zapłacić. Gość zrobił 5% przydzielonych mu zadań dobrze, 10% źle, a reszty nie zdążył. Ogólnie cudów się nie spodziewałem, github był taki "tutorialowy", poprawny, ale nie wierzyłem, że można zrobić taki syf.
Co do bezrobocia na rynku IT. Ogólnie techniczne weryfikuje rekrutacje i często mam takie sytuacje, że NIKT sensowny nie przychodzi za rynkową stawkę (oczywiście stawki 5 cyfrowe, nie zatrudniamy juniorów) i ostatecznie decydujemy się na kogoś poniżej oczekiwań. Dzwonimy do niego za dwa dni, a tam informacja "sorry, mam już kontrakt".
Jak się zdarza kozacki github (co jest 10x ważniejsze niż CV), to zwykle kandydat nie zdąży przyjść na rozmowę, albo na rozmowie mówi, że ma pracę i "bada rynek", ewentualnie, że był już na paru rozmowach i ma wstępną pozytywną decyzję i oczywiście do telefonu już go nie ma na rynku.
Sam już nie wiem, co zrobić, żeby kogoś dobrego do zespołu znaleźć, może trzeba szukać na jakichś hackatonach? Dawać szanse mniej doświadczonym i dawać testy na inteligencje?

renderme napisał(a):

Gdzie wy macie te 50 cv na stole :P chyba przy rekrutacji juniorów. Od mida w górę, to już tak nie jest.
Sam już nie wiem, co zrobić, żeby kogoś dobrego do zespołu znaleźć, może trzeba szukać na jakichś hackatonach? Dawać szanse mniej doświadczonym i dawać testy na inteligencje?

Wy serio prowadzicie biznesy bez podstawowej wiedzy jak zdobyć pracownika?
Albo dajesz widełki + 10/20/... % stawki rynkowej, albo zatrudniasz juniora i go przyuczasz. Finalnie zapłacisz tyle samo.

Moje doświadczenie jest takie, że TRZEBA dawać zadania i to takie na 4h+. Ostatnio miałem na rekrutacji gościa z małym doświadczeniem, ale teorie miał wykutą na 100%. Tak odpowiedział na wszystkie pytania, że dałem mu jakieś zadanie na 15 minut. Takie zadanie niestety pozwala tylko sprawdzić, czy ktoś zna składnie języka. Najgorsze było to, że trzeba mu było na koniec miesiąca za jego szkodliwą pracę zapłacić. Gość zrobił 5% przydzielonych mu zadań dobrze, 10% źle, a reszty nie zdążył. Ogólnie cudów się nie spodziewałem, github był taki "tutorialowy", poprawny, ale nie wierzyłem, że można zrobić taki syf.

Dla mnie to wygląda jak źle zrobiona rekrutacja, gdzie nie byliście wstanie zweryfikować człowieka / albo nie macie predyspozycji aby oceniać ludzi ich zdolności, i wtopiliście.
Dużo lepiej jest poszukać studentów, który dobrze rokują i szybko się uczą. Za niewielki wkład (głównie czas + nauka) bardzo często będą dużo lepiej pracować niż ludzie junior-senior.
Podaj proszę jakie masz "zadanie" i jak je oceniasz i co chcesz zweryfikować - inaczej nie da się tego ocenić.

Dzwonimy do niego za dwa dni, a tam informacja "sorry, mam już kontrakt".
Jak się zdarza kozacki github (co jest 10x ważniejsze niż CV), to zwykle kandydat nie zdąży przyjść na rozmowę, albo na rozmowie mówi, że ma pracę i "bada rynek", ewentualnie, że był już na paru rozmowach i ma wstępną pozytywną decyzję i oczywiście do telefonu już go nie ma na rynku.

To może trzeba decyzje podejmować szybciej? ;)

renderme napisał(a):

Najgorsze było to, że trzeba mu było na koniec miesiąca za jego szkodliwą pracę zapłacić.

Ale to normalne ryzyko przy zatrudnianiu nowego pracownika. Od tego jest okres próbny.

Gość zrobił 5% przydzielonych mu zadań dobrze, 10% źle, a reszty nie zdążył. Ogólnie cudów się nie spodziewałem, github był taki "tutorialowy", poprawny, ale nie wierzyłem, że można zrobić taki syf.

Sam go przyjąłeś (jak rozumiem), więc do siebie pretensje miej. Zrzucanie winy na juniora za to, że jest słaby, jest trochę niepoważne.

Moje doświadczenie jest takie, że TRZEBA dawać zadania i to takie na 4h+.

To niekoniecznie pomoże. Ja jak mi daje ktoś takie zadanie, to zwykle go nie robię (najlepsze jest jak niby np. na 2-4 godziny zadanie, a rozpisany na ileś stron opis i tyle rzeczy do zrobienia, ile normalnie byłoby robione przez cały sprint). Przypuszczam, że większość kandydatów po prostu nie zrobi takiego zadania. Co najwyżej najbardziej zdesperowani.

A może najpierw zastanowić się dlaczego w ogóle firma myśli o rekrutacji i dlaczego nie wychodzi szukanie.
Dlaczego firma szuka programistów?

1. Firma szuka ludzi, bo chce stworzyć kod
2. Chce wykonać szybciej punkt 1

Dlaczego jest problem ze znalezieniem programistów?
Firma nie chce dać kandydatom tego, co chcą
Dlaczego jest problem z weryfikacją kandydatów?
Rozmowa kwalifikacyjna często nie pozwala na dobrą komunikację; na przyjmowanie ludzi, żeby ich sprawdzić, firma nie chce się zgodzić.

Kto moim zdaniem dobrze sprawdzi się jako osoba do rekrutacji? Techniczni, którzy najlepiej z zespołu umieją się dogadywać. A jeśli oni mają za mało doświadczenia, niech będzie dwóch technicznych: jeden umie się dogadać a drugi jest biegły w technologii.
Najlepiej dać człowiekowi się wykazać w zadaniach typowych na danym stanowisku. Atmosfera podczas rozmowy nie powinna być zbyt sztywna. Kandydat i tak się stresuje i może się zdarzyć, że coś chlapnie. Robienie z rozmowy relacji pan- niewolnik to głupota. Jeśli szukałbym kogoś do swojego zespołu, to chcę pokazać mu jak jest na co dzień.

Tymczasem co robią liderzy branży z dynamicznymi, młodymi zespołami? Wydają się kompletnie nie rozumieć tematu i tłumaczą się tym, że to oni ustalają trendy. No jasne, teraz trendy są takie, że ludzie nie lubią HRów. Tu nie ma takiej filozofii jak chcieliby liderzy branż. Czasem mam wrażenie, że cały ten kołczingowy bełkot jest specjalnie po to, żeby manipulować ludźmi.

LukeJL napisał(a):

renderme napisał(a):

Moje doświadczenie jest takie, że TRZEBA dawać zadania i to takie na 4h+.

To niekoniecznie pomoże. Ja jak mi daje ktoś takie zadanie, to zwykle go nie robię (najlepsze jest jak niby np. na 2-4 godziny zadanie, a rozpisany na ileś stron opis i tyle rzeczy do zrobienia, ile normalnie byłoby robione przez cały sprint). Przypuszczam, że większość kandydatów po prostu nie zrobi takiego zadania. Co najwyżej najbardziej zdesperowani.

Jestem dumny z tego, że nigdy nie zrobiłem domowego zadania rekrutacyjnego.
Zawsze zanim się ostatecznie do niego zabrałem miałem pracę już gdzie indziej.

może powinien zaistnieć taki zawód programisty - konsultanta od spraw rekrutacji.

To by był gość z mega doświadczeniem w wielu firmach, który niejedno już widział (nie tylko techniczne problemy, ale problemy biznesowe, komunikacyjne itp. itd). I by się wypożyczało takiego gościa na godziny po to, żeby przeprowadził rozmowy o pracę.

I taki gość wszedłby do sali i już by po 10 minutach wiedział, czy ktoś się nadaje czy nie - bo potrafiłby za pomocą krótkiej rozmowy oraz intuicji domyślić się charakteru danego człowieka (bo charakter ma duze znaczenie jednak) oraz oszacować to, w jaki sposób ktoś będzie faktycznie pracować, czy ktoś ma potencjał. I w ciągu 2 godzin by przerobił rozmowy z kilkunastoma kandydatami i od razu by odfiltrował tych, co się nadają, od tych, którzy się nie nadają. Problem solved.

Czyli taki złoty graal rekrutacji. Zamiast długotrwałych rekrutacji, to po prostu jakiś super skuteczny spec od zatrudniania programistów, który by mógł sobie z tego zawód zrobić i pracować na zasadzie krótkotrwałych konsultacji w różnych firmach.

Ale z drugiej strony... tak naprawdę nawet dobry programista w złych warunkach np. źle zarządzany zespół, problemy komunikacyjne w zespole, biurokracja(albo odwrotnie: totalny chaos) wcale nie będzie taki dobry potem. Jak się zastanowić, to rekrutacja to tylko część układanki. Bo potem jest normalna praca i programista jako jednostka jest silnie uzależniony od reszty zespołu. Więc ktoś dobry na rozmowie wchodzi potem do zespołu i okazuje się, że wiele rzeczy go blokuje, niekoniecznie z jego winy nawet.

@LukeJL: Nie opłaca się. Niedługo i tak to wszystko wybuchnie.

Nie zgodzę się z kilkoma punktami:

1. Ryzykownym jest zatrudnianie kandydata bez praktycznego sprawdzenia czy potrafi programować. Istnieją osoby które świetnie opowiadają o programowaniu, nawet dobrze wypadają na niskopoziomowych pytaniach system design a gdy przychodzi co do czego, nie potrafią kodzić.
   Biorąc pod uwagę punkt 1 należy sprawdzić praktyczną umiejętność programowania. Spotkałem się z trzema podejściami, każde z nich ma plusy i minusy, co ciekawe odmienne z punktu widzenia pracodawcy i kandydata. Poniżej będę wskazywał jedynie wybrane.

a) Zadania algorytmiczne typu Hackerrank, Leetcode. Dla dużych ogranizacji plusem jest niezła skalowalność i jak dane pokazują dobre rezultaty tego podejścia.
b) Zadnia domowe - niektóre firmy, zwłaszcza zdalne, ciekawie podeszły do tego podejścia, np Auth0. Dedykowany kanał na Slacku w czasie rozwiązywania itp. Minus to spore poświęcenie czasu kandydata, często brak gwarancji, że w ogóle dostanie się odpowiedź zwrotną, brak dobrze skonstruowanego problemu itp.
c) Wykonanie praktycznego/lub zbliżonego do praktycznego zdania przy współpracy z rekrutującym. Osobiście uważam, że jest to ciekawe podejście, ale ma pewne wady podpunktu b) i jednak wydaje się bardzo sztuczne zakładając, że rekrutujący zna optymalne rozwiazanie wcześniej.

Rozumiem, że wydawać się może, że dobry programista po 10min rozmowie rozpozna innego dobrego programiste. Jednak dane mówią, że często nie jest to prawda.

Moim skromnym zdaniem trzeba wiedzieć kogo się chce zatrudnić i znać realia rynkowe - pensja jest dla mnie sprawą poboczną (nie ja o niej decyduję), ale zaproszenie juniora świeżo po studiach i prośba o to, żeby np. rozrysował wysokopoziomowy design aplikacji jest błędem, podobnie jak odpytywanie seniora z generowania ciągu Fibonacciego. W praktyce trafiali do mnie ludzie na stanowiskach powyżej juniora i ogólny schemat jest taki, że czytam CV szukając punktów "kontaktowych" z rolą, którą mają pełnić w firmie, potencjalnych kandydatów zaprasza się na rozmowę i leci podstawowy zestaw pytań o to co sami napisali w CV. Jeżeli ktoś twierdzi, że ma doświadczenie w programowaniu w takiej Javie, to dostaje prośbę o zgrubne opisanie projektów w których brał udział i swojej w nich roli. Na tej podstawie leci też parę pytań kontrolnych mających utwierdzić mnie w przekonaniu, że to co napisał w CV jest prawdą. Każde kłamstwo (lub duża przesada) wychwycone na tym etapie właściwie kończy rozmowę. Kolejne pytania są coraz głębsze i chodzi o ustalenie jak szeroka jest wiedza w danym temacie (np. dla popularnego ostatnio Springa pytanie o to jak działa dynamic proxy jest dość częste).
Rzeczy o które nie pytam / nie proszę to banały do wygooglania w minutę. Dla przykładu, zdarza mi się pytać czym są adnotacje w Javie, w jaki sposób można ich użyć w runtime, compile time, czym jest apt, ale nie pytam o takie rzeczy jak np. składnia podczas definiowania nowej adnotacji.
Nie przepadam też za jakimiś zadankami logiczno / algorytmicznymi, bo w warunkach stresu ludzie potrafią sp.... różne rzeczy, a na wyższych poziomach, żeby pozostać na odpowiednim poziomie trudności, trzeba by poświęcić masę czasu. Z powodu ograniczeń czasowych nie przeprowadzam też ćwiczeń praktycznych (weź mi zakoduj coś tam....).

Szacuję, że łącznie przeprowadziłem ponad setkę rozmów z kandydatami, zatrudnionych po nich zostało kilkadziesiąt osób. Nie przypominam sobie jakiejś grubej wtopy, w sensie przemknięcia się przez taką rozmowę osoby kompletnie z innej bajki. Co oczywiste, nie wiem czy nie odrzuciłem jakiegoś wartościowego kandydata.