De koe bij de horens vatten met codeertests in natuurlijke omgeving [case study]

Gepubliceerd: Laatst bijgewerkt:

Na het publiceren van een post over de meest voorkomende don'ts van het inhuren van programmeurs kregen we een aantal vragen over programmeertaken en de manier waarop we coderingsvaardigheden moeten controleren.

Op basis van mijn langdurige werkervaring heb ik veel advies gegeven over het rekruteringsproces van programmeurs in enkele van de grootste IT-bedrijven, voornamelijk gevestigd in Centraal-Oost-Europa.

We hebben veel geschreven over technische interviews. Kijk eens naar De ultieme gids voor het technische interview.

Uitdagingen bij het interviewen van ontwikkelaars

Toen ik begon met het interviewen van ontwikkelaars was er geen tijd voor actieve programmeer- en codetests. We hadden veel kandidaten, dus we moesten ons houden aan een uur limiet voor elke kwestie - zachte en technische beoordeling en financiële onderhandelingen. Uiteindelijk hebben we ongeveer 5% van de eerste kandidaten aangenomen. Na de proefperiode ongeveer 90% van hen bleef werken. Het was vrij goed conversiepercentage.

Nogal...

Maar na het berekenen van de kosten die veroorzaakt werden door verkeerde aanwervingsbeslissingen realiseerden we ons dat we veel geld verspilden. Salaris, HR, kantoor, notebooks, tijd van senior ontwikkelaars voor kick-start, enz. De kosten bovenop het salaris verdubbelden gemiddeld bijna de uiteindelijke kosten.

Er waren drie belangrijke redenen om na de proefperiode geen ontwikkelaars in dienst te nemen:

  1. zij niet in staat waren in het team te werken,
  2. hadden ze alleen theoretische kennis,
  3. werkten ze veel langzamer dan verwacht.

De reden waarom we niet in staat waren om al die nadelen te achterhalen was het overslaan van actieve coderingstesten tijdens het interview. Software ontwikkelaars inhuren zonder na te gaan of ze echt snel en slim kunnen coderen is vergelijkbaar met een auto kopen zonder na te gaan of de motor werkt.

Dus hoe konden we al deze zwakheden in slechts 60 minuten controleren?

Het antwoord is simpel - dat konden we niet! We moesten het interviewproces met ten minste twee uur verlengen. Maar voordat we dat konden doen, moesten we eerst het aantal kandidaten beperken. We besloten een 15 minuten durende telefonische screening uit te voeren door 10-15 technische vragen te stellen en hun salarisverwachtingen te leren kennen. Op basis daarvan nodigen we kandidaten opnieuw uit of niet. Door de screening konden we het aantal volgende gesprekken met bijna 40% verminderen, wat een slechter resultaat was dan we hadden verwacht, maar goed genoeg om de tijd van elk gesprek te verlengen.

We hebben geprobeerd een oplossing te vinden om na te gaan of elke kandidaat op dezelfde golflengte zit met het team en of ze de programmeertalen kunnen gebruiken die we gewoonlijk dagelijks gebruiken. Los van de vereiste codeervaardigheden bij programmeurs leggen we de nadruk op de manier waarop ze denken, vooral omdat die van invloed is op hun vermogen om met anderen te communiceren.

Is pair programming een oplossing?

Het idee was om aan pair programming te doen! Cool. Dan krijgen we het beste van twee werelden. De veronderstelling was juist voor ongeveer 70% van onze kandidaten. Het resultaat was dat een codeersessie van een uur volstond om te zien hoe iemand in onze veeleisende en specifieke omgeving zal handelen - zowel in het gebruik van verworven kennis in de praktijk, het gebruik van het vermogen om snel informatie te verwerken, flexibiliteit en ook als teamwerker, die soms gedwongen wordt compromissen te sluiten om de doelstellingen van het bedrijf te bereiken.

Tegelijkertijd konden wij zien hoe zij gereedschappen gebruiken, maar in de eerste plaats - hoe zij SOLID-principes in de praktijk kunnen toepassen, enz. Maar wat met de andere 30%? In feite waren dit mensen die helemaal niet in paren kunnen programmeren. Het was totaal onnatuurlijk voor hen. Is het een groot probleem? Als je je realiseert dat je in de praktijk 5-10% van de tijd besteedde aan pair programming moet je eens goed doordenken of je met zulke medewerkers kunt leven op de positie die je invult 🙂

Hoe kunnen we hun codeervaardigheden controleren? Laat ze gewoon doorgaan met de taak die we zijn begonnen. Maar alleen. Zonder interviewers die over hun schouder meekijken en elke regel van de code becommentariëren.

Wat ook belangrijk is, is dat we voor elke ontwikkelaar natuurlijke omstandigheden creëren - favoriete IDE geïnstalleerd, toegang tot StackOverflow.com, documentatie enz. Als een kandidaat vraagt om zijn eigen notebook te gebruiken, moet het antwoord altijd zijn: "Voel je vrij. Doe alles wat je nodig hebt om je comfortabel te voelen bij het coderen". Een natuurlijke omgeving is een absolute must voor alle soorten tests die coderingsvaardigheden verifiëren, zowel in pair programing als in individuele interviews.

Post delen

Meer informatie over het inhuren van tech

Abonneer u op onze Learning Hub en ontvang nuttige inzichten rechtstreeks in uw inbox.

Verifieer en ontwikkel coderingsvaardigheden naadloos.

Zie DevSkiller producten in actie.

Beveiligingscertificeringen & naleving. Wij zorgen ervoor dat uw gegevens veilig en beveiligd zijn.

DevSkiller logo TalentBoost logo TalentScore logo