Hoe je AI-resistente vragen voor codeerinterviews ontwerpt

Je kunt de AI niet verbieden. Je kunt er omheen ontwerpen.

Anno 2026 is kandidaten vragen om AI-assistenten tijdens een interview uit te schakelen puur theater. De lat die kandidaten halen met ChatGPT in een ander tabblad is dezelfde lat waar concurrenten tegen aannemen. De vraag is niet hoe je AI-gebruik detecteert — dat is de helft van het werk, en we behandelen dat in ChatGPT in codeerinterviews detecteren. De andere helft is het ontwerpen van problemen die niet instorten wanneer de kandidaat een LLM ter beschikking heeft.

Dit is een gids voor de tweede helft: hoe je vragen voor codeerinterviews schrijft die echt bruikbare signalen opleveren zelfs wanneer de AI beschikbaar is, en waar de hulp van de AI netjes aansluit bij de vaardigheden die je eigenlijk wilt inhuren.

Waarom standaardvragen niet meer werken

Een typische LeetCode-opgave heeft drie eigenschappen die het triviaal maken voor een LLM:

1. Het staat in de trainingsset. Elk klassiek two-pointer-, sliding window- en dynamisch programmeerprobleem is op het internet beantwoord, uitgelegd en duizend keer uitgelegd.
2. De input is goed gespecificeerd. Twee integer-arrays, een doelwaarde, geef de indices terug. Het model weet precies wat het moet produceren.
3. De output is binair. Tests slagen of falen. Er is geen oordeel in het antwoord dat de kandidaat moet verdedigen.

Een vraag met alle drie de eigenschappen is in 2026 een ChatGPT-vaardigheidtest, geen programmeervaardigheidtest. Elke eigenschap die je verwijdert, maakt het probleem moeilijker uit te besteden.

Principe 1: verankering in code die de LLM nog nooit heeft gezien

De schoonste manier om voordeel uit de trainingsset uit te schakelen is door de kandidaat in een specifieke codebase te laten werken. Een LLM kan uit het hoofd een graaftraversal schrijven. Het kan niet betrouwbaar een 400-regels repository uitbreiden waar twee van de modules een interne afspraak gebruiken die het nog nooit tegengekomen is.

Dit ziet er in de praktijk als volgt uit:

• Bug repareren. Een 200-400 regels repository met een niet voor de hand liggende bug. Het symptoom wordt gegeven, de oorzaak niet. De kandidaat moet lezen, hypothesen stellen, testen en repareren. We schetsen het format in onze gids voor LeetCode-vrij interviewen.
• Feature uitbreiden. Een werkende app met een klein, goed afgebakend feature-verzoek. De kwaliteit van de diff is de beoordeling. Een LLM kan een plausibele diff genereren; het kan niet garanderen dat de diff bij de bestaande conventies past en de bestaande tests in één keer doorstaat.
• Refactoring onder een beperking. "Dit bestand is 600 regels en moeilijk te lezen. Splits het in drie bestanden zonder het gedrag te veranderen. Tests moeten nog steeds doorstaan." Het juiste antwoord is een oordeel. Er is geen canonieke oplossing om te onthouden.

Deze formaten neutraliseren het voordeel van de trainingsset omdat de LLM de repository niet kan hebben gezien. De vaardigheid van de kandidaat om in onbekende code te navigeren wordt het signaal.

Principe 2: maak de input doelbewust ambigu

LLMs zijn het sterkst wanneer de specificatie nauwkeurig is. Ze zijn het zwakst wanneer de specificatie informatie mist die een mens zou opmerken en naar zou vragen.

Een standaardvraag: "Gegeven een CSV met bestellingen, bereken maandelijkse omzet."

Een moeilijker uit te besteden versie: "Hier is een CSV met bestellingen. Bereken maandelijkse omzet. Sommige rijen zijn terugbetalingen en zijn als negatieve bedragen weergegeven. Sommige rijen zijn gedeeltelijke terugbetalingen en gebruiken een andere status-waarde. Sommige rijen zijn van een stopgezette productlijn die nooit daadwerkelijk is verzonden. Bepaal welke hiervan je wilt opnemen en leg je redenering uit voordat je code schrijft."

De redeneerstap is de beoordeling. Een LLM zal graag code produceren die het canonieke geval behandelt en de rest stilletjes laat vallen. Een echte engineer zal pauzeren, de ambiguïteiten opsommen en een verduidelijkingsvraag stellen — of de aannames die ze deden documenteren.

Beoordeel de verduidelijkingen en aannames van de kandidaat afzonderlijk van de code die volgt. De verduidelijkingslijst is moeilijker nep te maken dan de implementatie.

Principe 3: verschuif het gewicht naar het gesprek rond de code

Een indiening is een steekproef, geen antwoord. Een LLM kan een indiening produceren. Alleen de kandidaat kan het onder live vragen verdedigen.

Twee manieren om hierop in te spelen:

• Asynchroon-dan-synchroon. Voer eerst de take-home of asynchrone codeeringsronde uit, plan dan een 30-minuten live-sessie in waarbij de kandidaat je door zijn indiening loopt. Vraag hen om het uit te breiden, een beperking te veranderen, of uit te leggen waarom ze de ene datastructuur boven de andere kozen. We hebben dit format uitgepakt in vervolgvragen voor take-home-indieningen.
• Live pairing op de eigen code van de kandidaat. Verander halverwege het interview één vereiste en vraag hem om live voor je te refactoren. De kandidaat die de originele oplossing van een LLM heeft geplakt, zal moeite hebben om het zonder opnieuw prompten te veranderen.

In ClarityHire voorzien we de live-sessie van codesamenhangchecks op de originele indiening, zodat de interviewer weet welke delen van de code van de kandidaat LLM-gegenereerd lijken en welke handgeschreven. Het gesprek kan dan specifiek de verdachte gedeelten aanvallen.

Principe 4: kies problemen waar AI-hulp een voordeel is, geen bezwaar

Als je vacaturetekst zegt "je zult elke dag AI-tools gebruiken in deze rol", ontwerp dan problemen waarmee je kunt observeren hoe kandidaten ze werkelijk gebruiken. Dit is niet hetzelfde als hen het antwoord laten plakken.

• Open boek met attributie. Zeg duidelijk: "Je mag ChatGPT of enige documentatie gebruiken. Documenteer elke prompt die je hebt gebruikt en het deel van de oplossing dat het produceerde." Een sterke kandidaat gebruikt het model chirurgisch; een zwakke promptt vijf keer voor dezelfde kapotte functie. Het spoor is het signaal.
• AI als tegenstander. Geef de kandidaat een foutieve door AI gegenereerde functie als startpunt. Hun taak is om te identificeren wat er mis is, waarom, en het te repareren. Dit test de vaardigheid die de rol werkelijk vereist: kritisch AI-output beoordelen voordat je het verzend.
• AI-ondersteunde debugging. Geef hun een onbekende repository met een echte bug, sta tool-gebruik toe, en kijk hoe ze de oorzaak oplossen. Engineers die het model gebruiken voor smalle vragen ("wat betekent deze stacktrace?") zien er heel anders uit dan degenen die het hele bestand erin plakken en hopen.

We onderzoeken het grotere plaatje van dit format in open-book codeeringsbeoordelingen.

Principe 5: combineer preventie met detectie — vertrouw niet op slechts één

Zelfs het best ontworpen probleem lekt signaal in slechts één richting. Combineer de ontwerpkeuzes hierboven met passieve integriteitsignalen:

• Toetsaanslag-biometrie markeert burst-paste-gebeurtenissen die niet overeenkomen met menselijke auteurschap.
• Codesamenhanganalyse vangt stilistische verschuivingen in het midden van een indiening.
• Een live vervolgvraag vangt auteurs die hun eigen code niet kunnen verdedigen.

Elk ervan is alleen zwak. Samen maken zij de kosten van vals spelen hoger dan de kosten van het werk doen.

Een korte checklist voordat je de vraag uitzendt

Voordat je in 2026 een codeer-vraag voor een kandidaat neerzet, stel jezelf deze vragen:

1. Zou ChatGPT dit alleen uit de probleemstelling kunnen oplossen? Zo ja, ontwerp het opnieuw of verminder het gewicht ervan in de loop.
2. Is de spec op een manier ambigu die verduidelijkingsvragen beloont? Zo nee, voeg ambiguïteit toe.
3. Moet de kandidaat zijn oplossing live verdedigen of uitbreiden? Zo nee, plan een vervolgvraag.
4. Meet je hoe ze AI gebruiken, of pretendeert je dat ze dat niet zullen? Wees eerlijk tegen de kandidaat hoe dan ook.
5. Heb je een integriteitsignaal dat bevestigt dat dezelfde persoon de indiening schreef en de vervolgvraag uitvoerde? Zo nee, voeg er een toe.

Wat nu te doen

Als je huidige codeeringsronde een enkel LeetCode-achtig probleem met een take-home dropbox is, test je op dit moment prompt engineering, niet engineering. Kies een van de formats hierboven, schrijf één probleem erin, en voer het uit bij drie interne engineers voordat je het voor een kandidaat neerleggen. De eerste versie zal te gemakkelijk of te onduidelijk zijn; de derde zal degene zijn die werkelijk bruikbare signalen oplevert.

Voor bredere context over waar asynchroon in de loop past, zie asynchroon versus live technische interviews. Voor de detectiehelft van dit dezelfde probleem, begin met ChatGPT in codeerinterviews detecteren.