Een expert legt in detail uit wat de beste test is voor selectieprocedures waarmee een bedrijf het beste inzicht krijgt in wie de beste professional is.
Sollicitatiegesprekken zijn essentieel om het talent aan te trekken dat je bedrijf nodig heeft, en er zijn veel manieren om ze zo goed mogelijk te voeren. Vandaag bekijken we een test die veel wordt besproken op forums en sociale media om ontwikkelaars aan te werven.
De test wordt ‘bug squash’-interview genoemd en heeft als voordeel dat hij een beeld geeft van de dagelijkse softwareontwikkeling die iemand uitvoert. Dat wil zeggen dat de kandidaat fouten moet corrigeren met behulp van verschillende programmeertalen en zich niet moet beperken tot slechts enkele.
Het onderwerp was al besproken op Reddit, maar een publicatie van Jake Zimmerman, een software-engineer die heeft gewerkt bij bedrijven als Stripe en Dropbox en nu universitair docent is, op zijn blog heeft dit idee voor een sollicitatiegesprek onder de aandacht gebracht en het wordt nu gedeeld op netwerken als LinkedIn.
Hoe werkt dit interview?
Zimmerman legt uit dat je minstens één vraag nodig hebt voor elke taal waarin je mensen het interview wilt laten doen. Je kunt beginnen met een paar zoals JavaScript, Python, Java en C++, maar het is waarschijnlijk beter om later uit te breiden naar C#, Objective-C, Ruby, Go, Rust, enz. Als je kandidaten vraagt om een taal te kiezen en ze moeten een taal kiezen waarmee ze niet vertrouwd zijn, is het moeilijker om hun prestaties te beoordelen.
Een “foutcorrectie”-interview is een interview waarbij een software-engineer wordt gevraagd om fouten in onbekende coderepositories te identificeren en te corrigeren, waarbij realistischere scenario’s worden gesimuleerd dan bij traditionele codeeruitdagingen.
Deze optie lijkt aan populariteit te winnen, omdat men vindt dat deze meer aansluit bij wat een software-engineer daadwerkelijk doet in zijn werk, dus hoe meer ervaring je hebt, hoe beter je waarschijnlijk zult presteren.
Een foutcorrectie-interview: de positieve kanten
Volgens Zimmerman “zijn er veel redenen waarom ik dit interview leuk vind”. Het weerspiegelt bijvoorbeeld de dagelijkse softwareontwikkeling; het is leuk (“omdat het corrigeren van autonome fouten zoals deze voor velen van ons het leukste aspect van software-engineering is”, voegt hij eraan toe); het is gemakkelijk voor de kandidaat om zijn eigen voortgang te beoordelen, omdat hij objectief kan zien of hij kan doen wat er van hem wordt gevraagd, en nog veel meer.
“Als iemand volledige controle heeft over zijn tools, komt dat in dit interview beter tot uiting dan in welk ander interview dan ook.” Om te slagen, moet je de interviewer ervan overtuigen dat de techniek die je hebt gebruikt om de fout te vinden, herhaalbaar en enigszins ‘wetenschappelijk’ is. Hij concludeert ook dat “kandidaten die goed zijn in dit interview, dat zijn omdat ze over een vaardigheid beschikken die ze hun hele carrière lang dag in dag uit hebben geoefend”.
De kandidaten lijken deze aanpak ook leuk te vinden, omdat het leuker is dan een traditionele “codeeruitdaging”. Het enige nadeel voor de personeelsmanager lijkt de tijd te zijn die het kost om het script met fouten te maken (het mag niet te moeilijk en niet te makkelijk zijn) en de testomgeving in te richten en te onderhouden.
De nadelen van dit soort processen
Een van de grootste problemen die experts zien, is dat het veel tijd kost om deze interviewvragen zo te formuleren dat ze ideaal zijn en dat het niet te veel moeite kost om de fout op te lossen, maar ook niet te gemakkelijk is.
Bovendien zullen degenen voor wie het gemakkelijker is om de fout op te lossen, waarschijnlijk de resterende minuten die de interviewer hen geeft willen gebruiken om te onderzoeken en al hun capaciteiten te laten zien, zoals deze expert uitlegt.
Er is ook minstens één vraag nodig voor elke taal die je wilt dat de kandidaten gebruiken. Als de test zich beperkt tot een paar talen, loopt het bedrijf mogelijk talent mis van mensen die veel beter zijn in talen die niet in de test zijn opgenomen.
