De traditionele codeertest -- een tijdgebonden algoritmepuzzel in een lege editor -- verliest terrein. De meeste teams die hem afschaffen, gebruiken taakgebaseerde technische beoordelingen, code walkthroughs of live sessies waarin kandidaten met hun eigen tools werken, inclusief AI-assistenten.
Waarom de algoritmetest niet meer werkte
Het klassieke whiteboard- of HackerRank-formaat was altijd een proxy. Het mat een specifiek soort prestatie -- het oplossen van afgebakende puzzels onder kunstmatige druk -- niet het bredere oordeelsvermogen dat in een echte codebase vereist is. Die proxy was al vóór het tijdperk van AI-tools gebrekkig. Nu is het moeilijker te rechtvaardigen.
Een kandidaat die dynamische-programmeringspatronen uit zijn hoofd kent, is niet per se een betere engineer dan iemand die dat niet doet. En een kandidaat die een binaire zoekopdracht uit het geheugen kan schrijven, zegt niets over of die persoon overgeërfde code kan lezen, een subtiele door een model gegenereerde bug kan opsporen, of verstandige beslissingen kan nemen bij een onvolledig ticket.
De komst van capabele AI-codeerassistenten vergrootte het verschil verder. Engineers die dagelijks op die tools vertrouwen en ze goed inzetten, kunnen langzamer zijn bij het oplossen van puzzels zonder hulp, maar in de praktijk sneller en betrouwbaarder. Wie het eerste toetst, benadeelt het tweede.
Wat teams er in plaats van gebruiken
Er is geen eenduidige vervanging. Gangbare aanpakken, vaak gecombineerd:
- Take-home opdracht op een echte codebase. De kandidaat krijgt een klein, realistisch probleem: een falende test, een feature request, een refactor, en levert werkende code in met een korte toelichting. De beoordeling richt zich op structuur en beslissingen, niet alleen op of het werkt.
- Code walkthrough. De kandidaat brengt een recent stuk eigen werk mee en legt uit hoe het in elkaar zit. Dit laat zien hoe ze denken over design, trade-offs en onderhoudbaarheid, dingen die geen algoritmische test meet.
- Live sessie met AI-tools toegestaan. De interviewer kijkt hoe de kandidaat een assistent gebruikt: wat ze prompten, wat ze accepteren, wat ze in twijfel trekken. Dit is informatiever dan iemand zonder hulpmiddelen zien typen.
- Gestructureerd technisch gesprek. In plaats van code schrijven bespreekt de kandidaat een system design of debug-scenario. Nuttig voor senior functies waarbij oordeelsvermogen zwaarder weegt dan het uit het hoofd kennen van syntax.
Elk format heeft zwakke punten. Take-homes kosten de kandidaat tijd en kunnen worden uitbesteed. Walkthroughs vereisen dat de kandidaat deelbaar werk heeft. Live sessies vragen een ervaren interviewer die weet hoe goed AI-gebruik eruitziet.
Wat de verschuiving onthult over aannamecriteria
Een test vervangen is makkelijker dan het eens worden over wat je eigenlijk zoekt. Teams die zijn afgestapt van algoritmische tests ontdekken vaak dat ze geen helder kader hadden voor wat de vervanging moet meten.
Voor functies waarbij AI-tools centraal staan, zijn de relevante vaardigheden: weten wanneer je gegenereerde code kunt vertrouwen en wanneer je die moet controleren, onbekende code snel lezen, plausibel ogende fouten opsporen en beslissingen nemen bij onduidelijke requirements. Geen van die dingen komt terug op een LeetCode-scoreboard. Zie how to assess an engineer's AI ability voor een uitgebreidere uitleg.
De aanverwante vraag waar reviewers op moeten letten in AI-gegenereerde output komt aan bod in how to review AI-generated code.
Het risico van de ene proxy vervangen door de andere
Sommige teams zijn overgestapt op puur conversationele interviews of portfolioreviews zonder technische verificatie toe te voegen. Dat ruilt het ene probleem in voor het andere. Een kandidaat kan vloeiend over trade-offs praten zonder ze te kunnen implementeren, net zoals een algoritmische test iemand kan laten slagen die geen productiesoftware kan bouwen.
De betere vervangers combineren een praktisch element, iets wat de kandidaat daadwerkelijk produceert of doorwerkt, met voldoende structuur zodat verschillende kandidaten op dezelfde dimensies worden vergeleken. Zonder structuur neigen interviews ertoe om zelfvertrouwen en communicatiestijl te bevoordelen boven technische competentie.
Waar we op testen
De beoordeling van Miyagami gebruikt geen algoritme-puzzels of take-home opdrachten. Kandidaten doorlopen twee live sessies: een fundamentenassessment zonder AI-tools en een AI-native assessment met de tools die ze normaal zouden gebruiken. In beide sessies kijken beoordelaars naar zaken als eigenaarschap, oordeelsvermogen op basis van risico en hoe kandidaten omgaan met ambigue tickets in plaats van goed gedefinieerde. De volledige scorecardcriteria en sessieopzet staan beschreven bij hoe we vetten.
Korte antwoorden
Is het codeerinterview volledig verdwenen?
Niet volledig. Veel grote bedrijven gebruiken ze nog steeds op grote schaal voor filtering. Kleinere teams en teams die inhuren voor AI-native functies stappen er het snelst van af en vervangen ze door taakgerichte beoordelingen of live sessies waarbij AI-tools zijn toegestaan.
Wat is het beste alternatief voor een codeertest?
Er is geen enkel format dat het beste is. De meeste teams combineren een realistische take-home opdracht met een gestructureerd gesprek of walkthrough. Het gaat erom dat je oordeelsvermogen en reviewvaardigheid meet, niet geheugen of puzzelsnelheid.
Kunnen kandidaten gewoon AI gebruiken om een take-home codeertest te halen?
Ja, en daarom is de beoordeling van de inzending net zo belangrijk als de uitkomst. Een vervolgwalkthrough waarbij de kandidaat beslissingen moet toelichten en ingebrachte fouten moet opsporen, maakt snel duidelijk of er sprake is van echt begrip of van gegenereerde code die kritiekloos is geaccepteerd.
