Code review bij IT-aanwerving - waarom en hoe moet u het gebruiken?

Gepubliceerd: Laatst bijgewerkt:

Een van de belangrijkste maar nog steeds genegeerde aspecten bij het aanwerven van een software-ontwikkelaar is na te gaan hoe de kandidaat met de code omgaat en of hij in staat is zijn gedachten uit te drukken in een bepaalde programmeertaal. Meestal doen we dat bij IT recruitment door de kandidaat te vragen code te schrijven om een bepaald probleem op te lossen. De kandidaat kan dit alleen doen of in een duo met de recruiter (De koe bij de horens vatten met codeertests in natuurlijke omgeving [case study]). We doen het omdat het schrijven van code een van de belangrijkste dingen is die ontwikkelaars dagelijks doen. We mogen echter niet vergeten dat ontwikkelaars veel vaker de broncode lezen dan schrijven. We mogen dus niet vergeten om na te gaan of de kandidaat in staat is om snel enkele stukjes code te analyseren en te begrijpen. We kunnen gewoon enkele code-afdrukken tonen of (nog beter) IDE geven met een of ander project en vragen stellen over wat hier gebeurt. Dat is waar de code review uitdaging echt nuttig is.

Hoe controleer je de programmeervaardigheden van een kandidaat tijdens een technisch interview?

Met betrekking tot wat hierboven is gezegd, zien we dat de meeste tijd tijdens het technisch interview / assessment wordt besteed aan het controleren of de kandidaat in staat is om een aantal programmeeruitdagingen of -problemen op te lossen. De kandidaat concentreert zich op het begrijpen en analyseren van het probleem om vervolgens een goede oplossing te vinden. We kunnen ons echter realiseren dat de kandidaat gedwongen wordt om meer na te denken over "wat te doen" dan over "hoe te doen". Wanneer we de kandidaat vragen om een code te schrijven die in staat is om een stoel te reserveren voor een vlucht in bepaalde omstandigheden, is het doel om de juiste functionaliteit te leveren, en meestal als gevolg van stress en tijdsbeperking is dat alles wat de kandidaat in staat is te doen. Is er een mogelijkheid om deze situatie om te keren en de kandidaat te laten focussen op "hoe"? Ja! Gedurende de vele jaren dat ik actief betrokken was bij IT sourcing en het inhuren van ontwikkelaars of architecten maakte ik gebruik van code reviews.

Wat is code review?

Code herziening is een proces waarbij programmeurs elkaars code controleren om mogelijke problemen, fouten of afwijkingen van best practices op te sporen (als u meer wilt weten ga dan naar Wikipedia). De laatste jaren is code review een must-have element geworden in het software delivery proces. Het geeft ons een grote controleerbaarheid en een betere kwaliteit van de code, maar het maakt het ook mogelijk om geweldige kennis te delen - mensen kunnen nu onderwijzen en leren op hetzelfde moment, door het delen van ervaringen. Maar ik wil je niet overtuigen om code-reviews op te leggen in je ontwikkelingsproces (wat je trouwens zou moeten heroverwegen als je het nog niet gebruikt) maar je tonen waarom en hoe je code-reviews kan gebruiken tijdens een technisch interview.

Hoe kunt u code review gebruiken in het IT-aanwervingsproces?

Door de kandidaat code te tonen die al geschreven is en (meestal) werkt zoals verwacht, laten we hen focussen op de kwaliteit van de oplossing. Door het stellen van de eenvoudige vraag "Zo, wat denk je van deze code?" veranderen we de kandidaat in een read-only modus. Wat belangrijk is om te vermelden is dat sommige ontwikkelaars gewend zijn aan dergelijke taken die ze nemen tijdens examens, certificeringen, enz. en ze kijken uit naar een aantal domme, opzettelijke fouten zoals ontbrekende puntkomma's, onjuiste parameters, verkeerde klassen, enz. Naar mijn mening moeten we een andere aanpak gebruiken. Ik heb altijd werkende code gebruikt die correct compileert. Ik benadruk in het begin dat er geen "certificatie-achtige" fouten zijn en dat de kandidaat zich moet concentreren op de beste praktijken, enkele veel voorkomende problemen die moeilijk worden opgemerkt door automatische hulpmiddelen en die ernstige problemen kunnen veroorzaken bij de productie.

Voorbeeld van code review uitdaging

In Java kan dat bijvoorbeeld het aanroepen van thread.run() zijn in plaats van thread.start(), wat correct compileert, tests slagen, maar we starten geen nieuwe thread, wat de uiteindelijke prestaties kan verslechteren. We kunnen ook nagaan of kandidaat zal opmerken dat een of andere transactionele methode wordt aangeroepen buiten het transactionele aspect, wat ernstige consistentieproblemen in een database kan veroorzaken.

Hoe programmeervaardigheden beoordelen op basis van code review?

Op basis van de eerste indruk van de kandidaat kunnen we zijn/haar benadering van de kwaliteit beoordelen. Als de code voor ons echt lelijk is en vol problemen zit en de kandidaat zegt iets als "ziet er goed uit voor mij" dan kunnen we aannemen dat hij niet zal helpen bij het verbeteren van de kwaliteit van de code in ons bedrijf en deze zelfs zal degraderen. Het is ook vrij eenvoudig om de ervaring van de kandidaat te beoordelen. Bijvoorbeeld, in 60 regels broncode waren junior ontwikkelaars in staat om ongeveer 4-5 problemen te vinden. Ontwikkelaars met 8+ jaar ervaring waren in staat om er 10 te vinden. En de beste kandidaten waren rond de 15-20 problemen. De beste kandidaat wees me op 2 problemen waar ik niet van op de hoogte was, en toen ik de code aan het schrijven was waren er meer dan 30 problemen opgenomen.

Wat mogen we van de kandidaten verwachten? Het belangrijkste zijn de hierboven genoemde punten - problemen die bij een bepaalde technologie vaak voorkomen en niet op het eerste gezicht zichtbaar zijn. Het volgende is de leesbaarheid. De code moet schoon zijn, goed gestructureerd en goed benoemd zodat andere ontwikkelaars (niet alleen de auteur) het kunnen begrijpen en wijzigen. Dus namen van methodes of variabelen - zijn ze zinvol, niet te lang, enz. Zijn methodes niet te groot en bevatten ze niet te veel logica? Zijn de technologieën die in het knipsel gebruikt worden een goede keuze om een bepaald probleem op te lossen (als onze code bijvoorbeeld string-operaties gebruikt om een XML op te bouwen, kunnen we kandidaat-ontwikkelaars verwachten die ons erop wijzen dat er veel bibliotheken zijn die gemaakt zijn om dit op een betere manier te doen).

Code review in DevSkiller beoordelingscampagnes

Bij DevSkiller geloven we dat het beoordelen van code een onderdeel moet zijn van het beoordelen van programmeervaardigheden. Dat is waarom de meeste van onze assessment campagnes dat soort probleem bevatten om op te lossen. We moedigen bedrijven ook aan om hun eigen codeer tests te bouwen die code review uitdaging bevatten. Dat is voor de meeste bedrijven erg handig, omdat u uw oude code base kunt gebruiken om zo'n taak voor te bereiden. Praat er gewoon over met uw IT-afdeling en neem het op in uw rekruteringsproces.

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