Hoe je AI-resistente codeervraagstukken voor interviews schrijft

De premisse is veranderd

Tegen het midden van 2026 is de interessante vraag niet meer of de kandidaat ChatGPT open heeft staan. Het is of je interview nog iets meet als dat het geval is. De meeste teams reageerden door detectie op te stapelen — keystroke biometrie, paste-vlaggen, code coherence scoring. Detectie helpt. Vraagstuk ontwerp helpt meer. Een probleem dat een LLM in acht seconden oplost, zegt je niets over de mens achter het toetsenbord, hoe schoon je de paste ook kunt markeren.

Dit is een veldgids voor het schrijven van codeervraagstukken die nog steeds signaal produceren wanneer je aanneemt dat AI-assistentie beschikbaar is.

Wat maakt een vraagstuk makkelijk voor een LLM

Drie eigenschappen spelen tegen je:

1. Het komt voor in de trainingsgegevens. LeetCode, HackerRank, Codeforces, populaire GitHub-repositories — het zit allemaal in de gewichten. Als je vraagstuk een Wikipedia-achtige naam heeft (Two Sum, Word Ladder, Longest Increasing Subsequence), kun je ervan uitgaan dat het antwoord is onthouden.
2. De volledige specificatie wordt van tevoren overhandigd. Een compleet, ondubbelzinnig prompt is precies de vorm waar een LLM voor is getraind. Het model heeft niets van de kandidaat nodig.
3. De uitvoer is gesloten vorm. Een functie met één invoer, één uitvoer, één correct antwoord is triviaal gradeerbaar — en triviaal genereerbaar.

LeetCode #1 voldoet aan alle drie. Net als het grootste deel van de vragenbibliotheek die je hebt geërfd.

Ontwerpprincipe 1: Verberg de spec, toon het symptoom

In plaats van "implementeer een functie die de langste substring zonder herhalende tekens retourneert," geef je de kandidaat een mislukkende testcase en een vaag foutenrapport: "Klanten zien dubbele items in hun winkelwagen nadat dit eindpunt wordt uitgevoerd. Hier is één mislukkende invoer. Zorg dat het stopt."

De kandidaat moet nu:

• De bestaande code lezen
• Een hypothese vormen over wat er mis is
• Beslissen wat "correct" eigenlijk betekent

Het model kan nog steeds helpen — maar alleen nadat de kandidaat het probleem heeft geframed. Framing is de vaardigheid die je toch wilde meten.

Ontwerpprincipe 2: Draag de codebase over, niet het prompt

Vervang losstaande puzzels door een kleine repository. 100–300 regels, meerdere bestanden, één of twee opzettelijke bugs, een spaarzame README. Vraag: "Vind de bug die de 500 op POST /orders veroorzaakt, en repareer het."

Een model dat je eigen repo niet heeft gezien, is niet beter in dit soort werk dan de kandidaat. Het zal waarschijnlijk gokken en zelfverzekerd — en het fout hebben — omdat het antwoord in de omringende code zit, niet in het prompt.

Dit format doet ook dubbel dienst als LeetCode-vrij interview voor teams die echte engineering willen meten in plaats van puzzelsnelheid.

Ontwerpprincipe 3: Bouw een draai in het midden van de vraag

Halverwege, verander de vereiste. "Nu wil de klant gedeeltelijke terugbetalingen ondersteunen — breid je oplossing uit." Of: "Dit eindpunt moet nu idempotent zijn. Wat verandert?"

De draai doet drie dingen:

• Forceert de kandidaat aan te tonen dat zij hun eigen code begrijpen (een verse paste uit een chatvenster kan dat niet).
• Geeft architectuurinstincten bloot die een eenmalige oplossing verbergt.
• Maakt prompting van een model tijdens het interview duidelijk — de kandidaat stopt, vraagt om een paar minuten, of produceert een tweede schone paste die niets met de eerste op heeft. Dit wordt allemaal signaal in het integriteitrapport.

Ontwerpprincipe 4: Vraag om oordeel, niet om output

Sommige vragen met het hoogste signaal hebben helemaal geen code om te schrijven:

• Code review-oefeningen. Draag een diff van 60 regels over. Vraag de kandidaat om opmerkingen achter te laten alsof zij de reviewer waren op een PR. LLM's produceren oprechte, generieke code review ("overweeg hier een opmerking toe te voegen"). Senior engineers produceren specifieke, geprioriteerde kritiek ("deze lock wordt vastgehouden over het netwerkbericht — dat zal onder belasting deadlock veroorzaken").
• Afweging-gesprekken. "Je hebt twee opties voor deze cache-ongeldigmaking. Welke zou je kiezen en waarom?" De kandidaat moet een keuze verdedigen. Het model heeft geen belang erbij en zal voorzichtig formuleren.
• Een onbekend PR lezen. "Leg me uit wat deze wijziging doet en wat er fout kan gaan."

Deze clusters werken beter met system design rubrics dan met algoritme scorecards. Beoordeel ze op de redenering, niet op het oordeel.

Ontwerpprincipe 5: Ongebruikelijke beperkingen boven nieuwe problemen

Je hoeft geen nieuwe probleemklasse uit te vinden. Je hebt alleen een ongebruikelijke beperking op een bekende nodig.

• "Implementeer een rate limiter — maar de klok kan tot 30 seconden teruglopen vanwege NTP-drift."
• "Bouw een queue — maar enqueue moet O(1) worst case zijn, niet amortized, omdat we dit in een hard-real-time control loop uitvoeren."
• "Parse dit configuratiebestand — maar de spec evolueert. Laat me zien hoe je backwards compatibility zou hanteren drie versies verder."

LLM's kunnen deze oplossen. Ze zullen de beperking vaak missen. De kandidaat die het opmerkt, erover vraagt, en er omheen ontwerpt, is de kandidaat die je wilt.

Wat je beter niet kunt doen

Een paar veel voorkomende reacties die verkeerd uitpakken:

• AI verbieden zonder het vraagstuk te veranderen. Je verliest topkandidaten die al goed met AI omgaan, behoudt de fraudeurs die zich niets van je regels aantrekken, en leert niets nieuws.
• Problemen gratuït lastig maken om het model te "verslaan". Tegenstrijdige moeilijkheid selecteert mensen die bereid zijn onder druk te sloven, niet voor mensen die het werk kunnen doen. De slagingspercentage zakt en de funnel verstopt.
• Alles naar whiteboard / laptop-loze interviews schakelen. Dit is een echte optie, maar het heeft zijn eigen afwegingen — bereikbaarheid, kandidaatstress, en het feit dat geen enkele engineer op die manier in hun echte baan codeert.
• Vertrouwen op "AI-resistente" labels van vraagleveranciers. Sommige leveranciers verifiëren dat een vraagstuk onder een drempel scoort wanneer het aan GPT-4 wordt gegeven vandaag. Het model van morgen zal anders hertesten. Behandel het label als startpunt, niet als garantie.

Koppel vraagstukontwerp aan de meetlaag

Zelfs een goed ontworpen vraagstuk profiteert van een integriteitlaag die je een tweede as van signaal geeft. ClarityHire's code coherence AI leest het traject van een inzending, niet alleen de uiteindelijke code — deed de kandidaat iteratie, testen en refactor, of kwam de oplossing in één grote coherente paste? Gecombineerd met keystroke timing en paste/tab-events, krijg je een betrouwbaarheidsscore die samenwerkt met de ontwerpkeuzes hierboven in plaats van ze te vervangen.

Het sterkste patroon dat we zien: een AI-resistente vraag voor de async stage, gevolgd door een 30-minuten live vervolgwalk-through waar de kandidaat beslissingen moet uitleggen die zij uren eerder namen. De combinatie is aanzienlijk lastiger om nep voor te geven dan beide stappen apart.

Wat je nu kunt doen

Kies de drie vragen die je het meest toewijst en beoordeel ze aan de hand van de principes hierboven:

1. Verbergt elk vraagstuk een deel van de spec dat de kandidaat moet opmaken?
2. Vereist het vraagstuk het lezen van code die de kandidaat nog niet heeft gezien?
3. Is er een draai of beoordelingsmoment dat een standaard model niet zomaar kan overnemen?

Herschrijf het vraagstuk eenmaal voor elke vraag die slecht scoort en test de nieuwe versie op vijf echte kandidaten voordat je het uitrolt. Meet twee dingen: de gemiddelde kwaliteit van de inzending van je top kwartiel, en het doorvoerpercentage naar de volgende ronde. Als de kwaliteit toeneemt en de doorvoer stabiel blijft, heb je een beter vraagstuk. Als de doorvoer instort, is de nieuwe versie adversariaal, niet selectief — herziening en probeer opnieuw.

AI in coderinginterviews is niet het probleem. AI-vormige vragen zijn het. Fix de vragen en de rest van de integriteitstack begint te doen wat het altijd zou moeten doen: het signaal bevestigen, niet genereren.