Code Review Interview: Vragen, Beoordelingscriteria en Waarom Het Beter Werkt dan Algoritmen

Wat een code review interview eigenlijk is

Een code review interview is precies wat het klinkt: de kandidaat krijgt een werkende pull request — 100 tot 400 regels, een enkele feature of bugfix — en wordt gevraagd deze te reviewen als een teamgenoot die deze had geopend. Ze geven issues aan, stellen veranderingen voor, en leggen de interviewer hun redenering uit. Soms zitten er opzettelijke bugs in. Er zijn altijd afwegingen te maken.

Het is het meest onderschatte format in technical hiring. De meeste sollicitatieronden gebruiken nog steeds standaard een algoritme-opdracht of een take-home build. Beide geven goede signalen voor bepaalde dingen. Maar geen van beide test het wat engineers na hun aanstelling het meest doen.

Waarom het beter werkt dan de algoritme-ronde

Drie redenen, op volgorde van impact.

1. Het test het echte werk. Engineers spenderen meer uren aan het reviewen van code dan aan het schrijven ervan. Een sollicitatieronde die niet meet hoe goed iemand kan reviewen, meet de verkeerde dimensie en noemt het engineeren.
2. Het is moeilijk om nep te maken met AI. LLM's kunnen diffs schrijven. Maar ze worstelen met het argument waarom een functie opgesplitst zou moeten worden wanneer een senior reviewer een verdedigbaar tegenargument heeft. Het signaal zit in het heen-en-weer, wat is waar AI-bijgestane kandidaten falen.
3. Het schraalt goed mee per senioriteit. Juniors zien syntax en bugs. Mid-level engineers zien structuur. Seniors zien de ontwerpbeslissingen die in de diff verborgen zitten (wat is verwijderd, wat is opzettelijk niet veranderd). Dezelfde artefact, totaal verschillende inzichten — wat betekent dat één PR interviews kan drijven van L3 tot L6 met aangepaste rubric-gewichten in plaats van aparte vragenbanken.

Dit is het format waar teams naar grepen als ze inzien dat LeetCode niet voorspellend is en een zuivere work-sample take-home te duur is om op schaal in te zetten.

Hoe je de codebase kiest

De PR die je gebruikt bepaalt of de interview oordeelsvermogen of triviale kennis meet. Drie dingen zijn belangrijk:

• Gebruik echte, geanonimiseerde code. Een toy-snippet met drie voor de hand liggende bugs trapt kandidaten op zoek naar trucs. Een echte diff met gemengde kwaliteit dwingt hen daadwerkelijk te lezen.
• Kies een domein dat de kandidaat niet uit het hoofd kent. Vermijd een TODO-app of een LeetCode-algoritme. Gebruik iets met bedrijfslogica — een prijsregel, een permissiecheck, een retry-policy. Domeinbekendheid is niet het signaal.
• Zorg dat er minstens één verdedigbare afweging in zit. De beste code review interview heeft nul "foute" antwoorden en drie plaatsen waar een nauwkeurige reviewer beide kanten op kan gaan. Dat is waar je senioriteit meet.

Zet de ronde op met de diff in een echte editor — niet in een statische PDF. De collaborative coding rooms van ClarityHire openen het bestand met annotaties en een comment thread die de interviewer in realtime kan volgen, zodat de review aanvoelt als een normale GitHub PR in plaats van een verhoor.

Het vier-dimensionaal beoordelingsschema

Gebruiken de structuur van een system design rubric, maar herbouw de dimensies voor review-werk.

1. Issue-identificatie

Hebben ze de dingen gevonden die een echte review zou vinden? Score op dichtheid en ernst:

• 4 — het load-bearing issue (beveiliging, correctheid, of architectuur) plus het kleine werk gevonden
• 3 — het load-bearing issue óf de meeste kleine dingen gevonden
• 2 — oppervlakkige issues gevonden maar het structurele probleem gemist
• 1 — het load-bearing issue gemist en alleen opmaak bepoteld

2. Prioritering

Twee issues zijn nooit even zwaar. Score of de kandidaat het verschil ziet tussen "dit is een bug" en "dit zou netter kunnen" en "ik zou hier niet op blokkeren." Senior engineers richten reviewers gericht op de bugs; juniors behandelen elke opmerking als gelijkwaardig belangrijk.

3. Kwaliteit van rechtvaarding

Voor elk comment dat ze achterlaten, kunnen ze de afweging verklaren? "Ik zou deze helper uitbreiden" is een middelbare opmerking. "Ik zou deze helper uitbreiden omdat dezelfde logica in de order-cancellation flow staat en we willen dat ze samen evolueren" is de senior-versie. Score op specifiteit, niet vocabulaire.

4. Toon en samenwerking

Code review is een relationshipskunst. Een reviewer die technisch gelijk heeft maar comments schrijft die je team zal ergeren, is een minpunt. Score op: voelt de opmerking aan als een voorstel waar de auteur mee kan werken, of als een afgelasting?

Dit is de dimensie die de meeste interview-formats helemaal niet kunnen meten. Code review interviews maken het zichtbaar.

Voorbeeldvragen als anker voor het gesprek

Dit zijn de prompts die interviewers tot na het eigen voorbijgaan van de kandidaat moeten bewaren:

• "Loop me door de comments die je werkelijk zou plaatsen, in de volgorde waarin je ze zou plaatsen."
• "Welk enkel comment zou je blokkeren?"
• "Als de auteur tegen je grootste comment in gaat, wat is je op-één-na-beste argument?"
• "Wat zit niet in deze diff maar zou er in moeten? Wat zou je in de PR-beschrijving vragen?"
• "Wat zou je niet aankaarten, ook al heb je het opgemerkt?"

De laatste vraag is de meest senior-onderscheidende in de set. Weten wat je kan negeren is de helft van effectieve code review.

Hoe je een open-ended review gradeert

Het interview levert rommelige artefacten op — inline comments, een transcript van de verbale uitleg, soms een geschreven samenvatting. Drie regels om ze consistent te gradeert:

• Gebruik een gedeelde scoring template per rol. Bouw het eenmaal van je rubric library en hergebruik voor alle kandidaten.
• Score het artefact en het gesprek apart. Een kandidaat die goede comments schreef maar slecht argumenteerde in de live discussie is een ander aanhuurkandidaat dan een die dat omgekeerd deed.
• Voer een geschreven-only ronde uit op schaal, live in-person voor finalisten. AI-bijgestane grading van de geschreven comments geeft een nuttige eerste pass op dichtheid en specifiteit bij top-of-funnel, waar je geen live tijd kan besteden. De live ronde pikt het gespreksignaal op dat grading niet kan.

AI-bijstand tijdens de ronde tegengaan

Als de kandidaat de diff door Claude of GPT in een ander tabblad haalt, zullen de comments die ze plakken technisch dicht zijn maar stilistisch inconsistent met hun eigen argumentatie in de discussie. Twee manieren om dat zichtbaar te maken:

• Kijk naar het edit pattern — schone, grote pasta's van gestructureerde proza gevolgd door stilte zijn de aanwijzer, net zoals in een coding ronde
• Maak de live discussie verplicht en adversarial: kies de sterkste comment van de kandidaat en argumenteer ertegenin. AI-geschreven comments vallen uit elkaar wanneer de kandidaat de specifieke formulering die ze hebben gekozen niet kan verdedigen

Je hoeft AI niet te verbieden om de ronde werkend te krijgen. Je hoeft het alleen zo in te richten dat een puur-AI-kandidaat het conversatie-deel niet kan doorstaan.

Wat je nu gaat doen

Kies één PR uit je codebase, anonimiseer het, en test de ronde volgende week met twee huidige engineers. Laat ze de diff koud reviewen en laat ze zichzelf scoren tegen het beoordelingsschema. Welke discrepantie zich openbaart tussen hun score en je intuïtie over hoe ze werkelijk reviewen, is de discrepantie die je rubric gaat repareren. Voer het vervolgens uit in je volgende sollicitatieronde en vergelijk kandidaat-scores met je bestaande coding assessment resultaten. In ons klantenbasis verschuift de rangschikking — en de nieuwe volgorde geeft een betere voorspelling van wie werkelijk goed presteert na aanstelling.