Het idee achter een codeertest is heel eenvoudig: kandidaten die niet over de technische vaardigheden voor de rol beschikken, vroeg in het proces eruit filteren voordat de wervingsmanager en de kandidaat allebei hun tijd verspillen met een persoonlijk interview.

Maar de meeste ingenieurs fronsen tegenwoordig de wenkbrauwen bij het idee om een codeertest te voltooien, en meer dan 50% weigert regelrecht status-quo-beoordelingen uit te voeren (gebaseerd op ons onderzoek met 100+ bedrijven in SEA).

3 meest voorkomende redenen waarom ingenieurs status-quo-coderingstests haten:

1. Ze testen op algoritmische vaardigheden in plaats van op het vermogen om code te schrijven.

Bedrijven hebben de scores van beoordelingen nodig om significant te zijn, en de gemakkelijkste manier om dit te doen om strikvragen op de beoordelingen te gebruiken. Om deze tests goed te doen, moeten kandidaten wekenlang oefenen met het schrijven van code voor een lijst met strikvragen. Slechts een fractie van de ontwikkelaars kan deze tests goed doen.

Als interviewer is het heel gemakkelijk om te vergeten hoe stressvol de interviewomgeving voor de geïnterviewde is. Uitvoerbare code moeten schrijven voor een zeer niche-algoritme dat je op school hebt gestudeerd (ook dat alleen als je een CS-majoor was), en nooit echt hebt gebruikt in je tijd als ingenieur in de echte wereld, met de timer die tikt, kan heel erg zijn intimiderend!

Hoewel het geweldig is als iemand goed is in algoritmen (hoewel deze vaardigheid kan worden verbeterd door te oefenen), is dit geen sterke indicator van hoe goed een ingenieur iemand is/hoe goed ze zullen zijn in de rol. Slechts een klein deel van de technische rollen vereist een sterk algoritmisch vermogen. Ook heeft deze manier om de vaardigheden van ontwikkelaars te meten een inherente voorkeur voor meer ervaren ontwikkelaars.

Zoals je je kunt voorstellen, is geen enkele geweldige ontwikkelaar enthousiast over het vooruitzicht om in de eerste plaats een test te geven. Voeg daarbij het feit dat vragen irrelevant zijn en 50% van de kandidaten weigert regelrecht deze tests af te leggen.

2. Ze zijn te groot gevraagd

De kandidaat vragen om meer dan 60 minuten aan een codeertest te besteden voordat u enige tijd hebt besteed, is oneerlijk.

Wanneer je een codeertest van 3 uur gebruikt, schiet dit het doel van automatisering voorbij, want hoewel de personeelsmanager niets te verliezen heeft, moet de kandidaat er nu meer tijd aan besteden dan aan een video- of persoonlijk interview.

Hoe langer je assessment, hoe lager het afnamepercentage.

3. Het is moeilijker om te coderen in een onbekende omgeving

De meeste ontwikkelaars hebben een voorkeur voor IDE (geïntegreerde ontwikkelomgeving) die ze zo hebben aangepast dat ze naadloos code kunnen schrijven. Een testomgeving is onbekend en het is moeilijker voor een software engineer om optimaal te functioneren. Dit is met name het geval wanneer voor de test niet alleen een programmeertaal in een eenvoudige code-editor moet worden gebruikt, maar in plaats daarvan wordt getest op front-end/backend-codeframework-mogelijkheden.

Ontwikkelaars betwisten vaak de validiteit van codeertests/beoordelingen vanwege deze en andere redenen en dat is begrijpelijk.

Dus, moeten we codeertests helemaal overslaan?

Dat is geen optie. Iedereen die betrokken is geweest bij het inhuren van technologie, weet dat er genoeg ontwikkelaars in de wereld zijn die niet gekwalificeerd genoeg zijn voor de rol, waardoor het noodzakelijk is om een soort van lakmoesproef te hebben die kandidaten moeten doorstaan voordat ze worden uitgenodigd voor een interview.

Kunnen we in plaats daarvan geen cv-scherm gebruiken?

Software-ingenieurs zijn meestal niet goed in het verkopen van zichzelf, en goede kandidaten verkopen zichzelf vaak enorm op papier. In het beste geval helpt een cv-scherm u om enkele kandidaten te elimineren die duidelijk niet gekwalificeerd zijn voor de functie en om cv's op prioriteit te sorteren. Buiten dat, heeft het gebruik van een cv-filter een inherente voorkeur voor kandidaten met goede referenties (opleiding en werkgeschiedenis). Goede programmeurs kunnen overal vandaan komen, en als u trefwoorden gebruikt, loopt u waarschijnlijk veel geweldige kandidaten mis. Maar als bedrijven beginnen met het interviewen van iedereen die solliciteert, zou het al de tijd van het technische team in beslag nemen om kandidaten te interviewen.

Hoe evalueren we of een assessmentoplossing een goede is?

Hier is een lijst met de belangrijkste dingen waarop u wilt controleren. Je bent in goede handen als:

  1. Uw toetsafnamepercentage > 70%.
  2. De gemiddelde tijd om de beoordeling te voltooien is tussen de 45-75 minuten.
  3. Als je kandidaten om feedback vraagt tijdens persoonlijke sollicitatiegesprekken, hebben ze goede dingen te zeggen over hun ervaring met het geven van de beoordeling.
  4. Wervingsmanagers zijn blij met de kwaliteit van kandidaten die worden doorgestuurd naar persoonlijke rondes.

Als uw huidige oplossing niet aan deze criteria voldoet, loopt u mogelijk sterke kandidaten voor uw team mis. Als software-engineers en wervingsmanagers hebben mijn mede-oprichter en ik eerder een meerderheid van de status-quo-oplossingen gebruikt en de resultaten onbevredigend gevonden. Dit is dus waar we de afgelopen jaren naartoe hebben gewerkt en waar we al vroeg succes in hebben gezien.

Bij Adaface bouwen we aan een manier voor bedrijven om de eerste ronde van technische interviews te automatiseren met een conversatie-AI, Ada.

Dus, is dit slechts een coderingstest, maar in chatbot-formaat?

Nee. Dit is wat we anders doen dan de status-quo:

  • Kortere beoordelingen (45-60 minuten) om ervoor te zorgen dat ingenieurs het zo snel mogelijk kunnen doen, ze investeren zo min mogelijk tijd, terwijl ze toch genoeg tijd hebben om hun expertise te laten zien.
  • Aangepaste beoordelingen afgestemd op de vereisten van de rol (GEEN strikvragen).
  • Vragen aan de eenvoudigere kant van het spectrum (het is een screeningsinterview) met een royale tijdstoeslag (3x wat ons team nodig heeft om er code voor te schrijven).
  • Extreem gedetailleerde score die valse positieven en valse negatieven elimineert.
  • Vriendelijke kandidaat-ervaring (hints voor elke vraag, vriendelijke berichten en chatbot; gemiddelde kandidaat-NPS is 4,4/5). ️

Hoe scoort Adaface op onze criteria voor een assessmentoplossing?

  1. We hebben een gemiddeld testpercentage van 86%, vergeleken met de industriestandaard van 50%.
  2. De gemiddelde tijd om de beoordeling in te vullen is 62 minuten.
  3. We zijn het meest trots op de feedback die kandidaten na het assessment delen. De gemiddelde beoordeling is 4,4/5.
  4. We richten ons op het testen van on-the-job vaardigheden voor elke rol. Ada kan kandidaten screenen op 700+ vaardigheden in Software Engineering, Data science, DevOps, Analytics, Aptitude, etc. Dit helpt onze klanten de meest gekwalificeerde kandidaten te vinden. Verschillende van onze klanten zijn overgestapt van het gebruik van status-quo-oplossingen naar Adaface en zijn in staat om meer dan 75% tijd te besparen in het screeningproces.

Hier is een voorbeeldreview van een van de kandidaten die een eerste ronde interview met een van onze klanten heeft afgerond:

Voorbeeldreview van een van de duizenden kandidaten die een eerste gesprek op Adaface hebben afgerond

Op de vraag wat hen ervan overtuigde om Adaface te gebruiken, antwoordde Brandon Lee, Head of People & Culture, Love, Bonito:

Extern kregen we van kandidaten positieve feedback over het gebruiksgemak en gemak van Adaface. Intern, nadat we het met onze teamleden hadden getest, waren we ook verbaasd over de validiteit en nauwkeurigheid van de opdrachten.

Als je momenteel iemand zoekt, wil ik graag met je praten. Neem contact op met [email protected] of vind me hier op LinkedIn .