Wątek ma 1,5 roku, więc postanowiłem wnieść do niego nieco świeżości. Tak się składa, że przeprowadzono badania na ten temat:
https://www.sciencedaily.com/releases/2020/07/200714101228.htm
Wynika z nich, że live coding nie sprawdza umiejętności kandydata, a jedynie poziom stresu :] Nie dość, że kandydaci pod obserwacją osiągali o połowę gorsze wyniki niż bez obserwacji to jeszcze w badanej grupie presja na live codingu wyeliminowała wszystkie kobiety (gdy nie były obserwowane to poradziły sobie dobrze). Każdy kto kiedykolwiek zajmował się badaniami wie, że to praktycznie dyskwalifikujący wynik dla takiej metody rekrutacyjnej.
Zatem wszystkim mądralom, którzy twierdzą, że live coding "to jeden z lepszych sposób sprawdzania kandydatów" albo że "widać jak jest się słabym" - macie na to jakieś dowody czy tak wam się tylko wydaje?
Ogólnie proponuję trochę pokory. Zanim następnym razem stwierdzicie "ten człowiek z 5 latami doświadczenia nie potrafił napisać poprawnie jednej linijki kodu!", pomyślcie, czy to wy sami go nie zestresowaliście :] W IT jest sporo introwertyków, więc za dużo bodźców może ich przerastać. Takie osoby z lekką dozą paranoi mogą jednak produkować lepszej jakości kod - częściej będą do niego wracać, poprawiać go, testować więcej warunków brzegowych itd.
Wiem, że FAANG organizuje rekrutacje z live coding (tak, na pewno nie mogą się mylić, podobnie jak korporacje nie mogły się mylić organizując open space dla pracy wymagającej skupienia albo twierdząc, że przy pracy zdalnej spadnie efektywność ;] ). Wróćmy jednak do tego, jakie są konsekwencje live codingu? Po pierwsze, duża ilość false negative (czyli odrzucenia dobrego kandydata), ale FAANG może sobie na to pozwolić - oni mają wystarczająco dużo chętnych. Krótko mówiąc: nawet jak odrzucą kogoś dobrego to i tak zatrudnią innego dobrego. Po drugie, oni są trendsetterami, więc pisanie odkrywczych algorytmów może tam mieć trochę większe znaczenie niż w przeciętnej firmie tworzącej jakieś API czy webserwis, której z kolei przydałby się bardziej kandydat z umiejętnościami DevOps czy sprawnie poruszający się w obiektówce.
Możecie powiedzieć: "ja nie chcę kandydata, który nie radzi sobie ze stresem". Problem w tym, że to jest zupełnie inny stres niż ten, którego będzie doświadczał w twojej pracy. Tak po prostu się nie pracuje. Jak coś się wysypie na produkcji to menedżer zazwyczaj nie stoi ci nad głową patrząc jak naprawiasz błąd. Presja czasu oczywiście istnieje, ale zazwyczaj masz czas, żeby coś sprawdzić czy przetestować. Rozmowa rekrutacyjna to zupełnie inna stawka. Znacie osoby, które są super otwarte, odważne, radzą sobie doskonale pod presją, a idąc na randkę z dziewczyną z trudnością składają zdanie? No właśnie. Inna sytuacja, inna reakcja, inny poziom stresu.
Z tego co widzę, pozytywne opinie o live coding'u wypowiadają głównie... rekruterzy. Szczególnie tacy, którzy sami nie musieli uczesniczyć w żadnym procesie rekrutacyjnym od ładnych kilku lat ;] Sam fakt, że opinie różnią się głównie od tego, po której stronie biurka się siedzi, powinien zapalić czerwoną lampkę. Dla rekrutera ta metoda jest łatwa i przyjemna: dajesz kandydatowi zadanie i obserwujesz show, od czasu do czasu coś podpowiadając. Super. Jednak pomyśl, czy rekrutację organizujesz dla siebie czy dla kandydata? Czy na pewno pozwalasz mu się pokazać z najlepszej strony?
Ostatnie pytanie: co zamiast? Widzę kilka możliwości:
- Dać kandydatowi wybór: live coding czy zadanie domowe z odpytaniem na rozmowie. Zdarzają się ludzie, którym live coding nie przeszkadza. Są również tacy, którzy nie mają czasu/możliwości poświęcić paru godzin na zadanie domowe.
- Na rozmowie skupić się na wiedzy, sposobie myślenia, na tym czego nie można wygoogle'ować w 2 minuty. Podesłać kod, spytać gdzie jest błąd, jak kandydat by dany kod zoptymalizował. To dużo lepsze rozwiązanie, bo kod czyta się trudniej niż pisze się własny. Jak ktoś umie przeczytać to będzie też umiał napisać.
- Przeanalizować portfolio kandydata i odpytać go z jego projektu.
- Wreszcie, jeśli już musicie zorganizować live coding, warto zrobić to z głową. Po pierwsze uprzedzić, nie zaskakiwać. Na samej rozmowie sprawdzić się może programowanie w parach, na istniejącym kodzie, wspólne rozwiązanie problemu, z możliwością używania Google (warunki bardziej zbliżone do pracy). Po pierwsze, kandydat ma punkt odniesienia, może zacząć działać na istniejącym kodzie, nawet jak ze stresu ma pustkę w głowie. Po drugie, nie ma takiego poczucia, że jest obserwowany i oceniany przez rekrutera, w końcu razem rozwiązujecie ten problem, jak w prawdziwej pracy.
Pewnie są jeszcze inne możliwości, ale jesteście tacy kreatywni to na pewno wymyślicie ;]