AI-ondersteund codeersinterviewbeleid: hoe je het ontwerpt en beoordeelt
De beleidsvraag waar elk technisch team nu mee wordt geconfronteerd
Meta deed als eerste de deur open. Shopify, Canva en Rippling volgden binnen een kwartaal. Halverwege 2026 staat ongeveer één op de vier werkgevers AI-ondersteuning tijdens technische interviews expliciet toe, en het tempo neemt toe. De vraag op de meeste technische inhuurcommissies is verschoven van moeten we ChatGPT verbieden? naar als 90% van onze ingenieurs dagelijks met AI coderen, hoe ziet een eerlijk interview er dan uit?
Dit artikel bevat het beleid en beoordelingsschema dat wij aanbevelen voor teams die dit helemaal opnieuw schrijven. Dit is geen vrijbrief voor code-writing zonder focus. Dit is een manier om een interview uit te voeren waarbij de kandidaat dezelfde tools gebruikt die hij op dag één zal gebruiken, en je verlaat het gesprek toch met een verdedigbaar signaal.
Begin door te bepalen wat je eigenlijk meet
De fout die bijna elk team maakt wanneer ze AI voor het eerst toestaan, is dat ze het beoordelingsschema ongewijzigd laten. Ze nemen hun oude prompt "implementeer deze LRU-cache", geven de kandidaat een Claude-tabblad en zijn dan verbaasd wanneer iedereen slaagt.
Als je AI toestaat, beoordeel je niet langer of de kandidaat werkende code kan produceren. Je beoordeelt vier dingen die AI niet voor hen kan doen:
- Probleemformulering. Kunnen zij een vage zakelijke vraag vertalen naar een concrete specificatie, inclusief randgevallen die de vraagsteller niet heeft genoemd?
- Richting bepalen. Kunnen zij bepalen wat ze eerst moeten bouwen, wat ze kunnen overslaan, en wanneer ze een concept moeten verwerpen?
- Kritische beoordeling. Wanneer de AI met vertrouwen onjuiste code teruggeeft, merken zij dat op? Vragen zij om een alternatief of zenden zij de fout op?
- Rechtvaardiging. Kunnen zij elke regel die zij hebben ingediend verdedigen? "Het model heeft het geschreven" is geen antwoord.
Schrijf dit op voordat je een enkel probleem schrijft. Het beoordelingsschema bepaalt alles verder.
Een prompt ontwerpen die AI niet in één keer kan oplossen
Een goed AI-toegestaan prompt heeft drie eigenschappen:
- Het is opzettelijk ondergespecificeerd. De kandidaat moet verduidelijkingsvragen stellen of aannames expliciet maken. Een prompt die alle constraints vooraf bevat, stelt de kandidaat in staat om de spec in het model te dumpen en op te sturen.
- Het "happy path" is de helft van het werk. De andere helft is het omgaan met een beperking die in tegenspraak is met een eerdere aanname. Echte engineering gaat om spanningen verzenen, niet om leetcode-implementatie.
- Het bevat minstens één valstrik. Een subtiele vereiste die, indien gemist, de oplossing er correct uit laat zien maar verkeerd werkt op een niet-voor-de-hand-liggende invoer. Modellen missen deze betrouwbaar; denkende mensen vangen ze.
Concreet voorbeeld. In plaats van "implementeer een rate limiter" vraag je: "Voeg een rate limit toe aan dit bestaande endpoint. Het productteam wil 'redelijke' bescherming tegen misbruik. Het endpoint wordt aangeroepen vanuit zowel een mobiele app als een interne cron-job. Hier is de bestaande code." Nu moet de kandidaat definiëren wat "redelijk" betekent, opmerken dat de cron-job een naïeve limiter per IP zal triggeren, en hun keuzes uitleggen. Het AI-model zal blij een limiter per IP schrijven. De kandidaat moet bepalen dat dit verkeerd is.
Voor meer informatie over het bouwen van prompts die LLM-geplakte oplossingen weerstaan, zie hoe u ontwikkelaars kunt screenen zonder LeetCode.
Hoe het interview er in de praktijk uit ziet
Een live AI-ondersteund codeersinterview duurt in de praktijk 60 minuten:
- 10 minuten — probleemformulering. De interviewer presenteert het probleem. De kandidaat leest het, stelt verduidelijkingsvragen, stelt hun aannames vast. Ze coderen op dit moment nog niet. Dit is het hoogste-signaal gedeelte van het interview en is grotendeels AI-immuun.
- 35 minuten — bouwen, met AI beschikbaar. De kandidaat schrijft code, prompts het model wanneer gewenst, en vertelt wat ze doen. De interviewer let op hoe de AI wordt gebruikt: geven zij de juiste context in prompts, accepteren zij output kritikloos, of behandelen zij het als een junior teamlid?
- 15 minuten — verdediging en uitbreiding. De interviewer vraagt de kandidaat om door een functie te lopen die de AI heeft gegenereerd, een beperking te veranderen, en uit te leggen wat er breekt. Dit is waar zwakke kandidaten instorten.
Dit is dezelfde structuur als een sterk live codeersinterview, met één expliciet verschil: de AI is een tool waar de kandidaat op wordt beoordeeld op goed gebruik, niet een verboden apparaat.
Beoordelingsschema: vijf dimensies, vijf punten elk
Gebruik hetzelfde beoordelingsschema voor elke kandidaat en elke interviewer, met verankerde gedragingen op elk niveau. Een goed startpunt:
| Dimensie | Wat het meet |
|---|---|
| Probleemformulering | Kwaliteit van verduidelijkingsvragen en vermelde aannames voordat er code wordt geschreven. |
| Besluitvorming | Hebben zij het juiste gekozen om eerst te bouwen? Hebben zij gestopt en heroverweging toen zij tegen een doodlopende weg aanliepen? |
| AI-vaardigheid | Zijn prompts specifiek en goed bereikt? Verwerpen zij slechte output en vragen zij om alternatieven? |
| Kritische beoordeling | Wanneer de AI fout is, merken zij dat op? Testen zij het valstrik-geval? |
| Rechtvaardiging | Kunnen zij elke regel uitleggen, deze op verzoek veranderen, en keuzes verdedigen? |
Beoordeel elke dimensie 1–5 met gedragsverankering. Verankering is wat dit onderscheidt van ingevingen; als u nooit een beoordelingsschema hebt gekalibreerd, doe dat voordat u het interview gaat uitvoeren. Vrije-vorm scoren over meerdere interviewers is hoe u eindigt met de luidste stem die instellingen bepaalt.
Bouw het formulier eenmaal in uw scorecard-systeem en hergebruik het. Als uw scorecard niet kunt afdwingen dat elke dimensie wordt beoordeeld voordat het wordt ingediend, krijg er één die dat kan.
De integriteitsvraag: vertrouw maar verifieer
AI toestaan betekent niet dat je ervan uitgaat dat de persoon aan de andere kant van de lijn degene is die wordt ingehuurd. Twee specifieke risico's blijven:
- Impersonatie. Iemand anders zit achter het toetsenbord of fluistert buiten beeld in het oor van de kandidaat.
- Gescripte antwoorden. De kandidaat heeft een tweede apparaat dat hen woordkeuzes en "verduidelijkingsvragen" geeft die zij niet echt hebben gegenereerd.
Geen van beide risico's heeft iets te maken met het AI-beleid. Ze bestaan in elk extern interview. De integriteitslaag van ClarityHire is gebouwd voor precies deze wereld: wij geven kandidaten geen vlag voor het gebruik van AI wanneer AI is toegestaan. Wij verifiëren wel dat dezelfde persoon gedurende het geheel heeft getypt, dat hun gezicht overeenkomt met de identiteit in het bestand, en dat het werk het weerspiegelt wat wij hebben waargenomen dat zij produceren. De toetsaanslag-biometrie en gezichtscontinuïteit signalen vangen impersonatie op, ongeacht of de kandidaat Claude heeft gebruikt.
Als u AI-toegestane interviews uitvoert, moet uw integriteitsrapport niets zeggen over AI-gebruik en alles over wie het werk heeft gedaan.
Wat u nu moet doen
Als u een bestaande interviewschema wilt aanpassen zodat AI is toegestaan, werk in deze volgorde:
- Herschrijf één prompt zodat deze ondergespecificeerd is, met een verborgen beperking. Test het met twee interne ingenieurs voordat een kandidaat het ziet.
- Vervang het oude "correctheid van code" beoordelingsschema door het vijfdimensionaal schema hierboven. Verankering op elk niveau met een gedragsvoorbeeld.
- Kalibreer drie interviewers op een opgenomen sessie voordat u live gaat met kandidaten.
- Bepaal uw integriteitsbeleid los van uw AI-beleid. Dit zijn niet dezelfde vragen.
- Na tien rondes trekt u de scoreverdeling en controleert u op drift. Als iedereen 4'en krijgt voor AI-vaardigheid, zijn uw verankering te genereus.
De teams die dit goed doen, zijn niet degenen met de striktste beleidslijnen. Dit zijn degenen wiens schema's oordeel meten in plaats van typen.