Ingenieurs interviewen voor AI-ondersteunde codering
De vaardigheid waar niemand naar vraagt in interviews
Tegen half 2026 gebruiken de meeste ingenieurs een AI-assistent voor minstens een deel van hun dagelijkse werk. Uw interview moet niet beantwoorden: "kan deze kandidaat zonder AI coderen" - dat is hypothetisch. Het moet beantwoorden: "kan deze kandidaat sneller en veiliger code afleveren mét een AI-assistent dan de ingenieur naast hem?"
Dat is een ander type vaardigheid, en het vereist een ander soort interview. Een take-home-opdracht met een verborgen no-AI-regel meet dit niet. Een LeetCode-screening meet het niet. Zelfs de meeste open-book-formaten laten kandidaten doorglippen doordat ze de AI als een opgevoerde zoekmachine gebruiken. Hieronder vindt u een praktische gids voor het ontwerpen van een ronde die AI-vaardigheid rechtstreeks meet en deze eerlijk beoordeelt.
Hoe AI-vaardigheid er eigenlijk uitziet
Kijk een sterke ingenieur een uur lang met een assistent werken. U zult zien dat zij vijf dingen doen:
- Het probleem formuleren rond beperkingen, niet oplossingen. Ze vertellen het model wat de code moet doen en niet doen, en itereren vervolgens.
- Zelfverzekerd afwijzen. Wanneer het model iets subtiel fout voorstelt - een verkeerde API-versie, een gefingeerde bibliotheek, een kwetsbaar patroon - zien zij dat binnen seconden en sturen bij.
- De assistent het meest inzetten op de saai gedeelten. Standaardcode, test-scaffolding, formaatconversies - gebruik met hoge impact. Ze schrijven zelf de kritieke logica of stellen het model aan strikte specifications.
- Verifiëren voordat ze vertrouwen. Ze voeren de code uit, lezen de diff en controleren randgevallen. Ze committen niet op gevoel.
- Weten wanneer ze moeten stoppen. Wanneer het model in kringetjes rond gaat, schakelen ze terug naar zelfstandig denken en lezen.
Een zwakke AI-gebruiker doet het tegenovergestelde: stelt brede vragen, accepteert lange gegeneraties zonder kritiek, laat het model de oplossing ontwerpen, en levert af wat werkend is. Het interview moet deze twee onderscheiden.
Het vraagformaat dat dit blootlegt
De vorm van de vraag telt meer dan het specifieke probleem. Kies er een met deze eigenschappen:
- Het naïeve AI-antwoord is op subtiele wijze fout. Geen strikvraag - een echte beperking die de kandidaat moet opmerken. Een veel voorkomende variant: vraag hen iets te implementeren tegen een recente of ongebruikelijke API, waar de trainingsdata van het model verouderd is.
- Het probleem is te groot voor een no-AI-kandidaat om af te ronden, en te subtiel voor een full-AI-kandidaat om in één poging op te lossen. Dit dwingt zowel instrumenten als oordeel af.
- De acceptatiecriteria zijn duidelijk. Niet "maak iets nettes" - expliciete must-haves die de kandidaat kan verifiëren.
- Er is opzettelijke ambiguïteit in de specificatie. Een redelijk ingenieur zou dit doorvragen of een aanname stellen. Een zwakke AI-gebruiker plakt de spec in het model en levert af wat eruit komt.
Een werkend voorbeeld: "Bouw een klein commando dat een CSV met bestellingen inleest, per-klant maandelijkse totalen berekent en JSON uitvoert. Twee ambiguïteiten die je moet oplossen: ordertijdzones en hoe je refundrijen behandelt. 60 minuten. Elk gereedschap dat je wilt."
Voer het live uit, niet asynchroon
Een zuiver asynchroon take-home kan de twee profielen niet onderscheiden. Het artefact ziet er hetzelfde uit. Voer dit uit als een 60-75 minuten durende live coding-sessie met scherm delen of een gezamenlijke editor, met uitdrukkelijke toestemming om AI te gebruiken.
Basisregels aangekondigd van tevoren:
- Elk AI-tool is toegestaan. Vertel ons welke je gebruikt.
- We trekken geen punten af voor het gebruik van AI. We zullen navragen hoe je het gebruikt.
- We zullen navragen wat de AI je gaf. Wees voorbereid om alles wat je behoudt uit te leggen.
Deze framing verschuift de kandidaat van defensief naar demonstratief. Sterke kandidaten gaan erin mee. Zwakke raak gestrest, omdat hun werkstroom niet tegen controle bestand is.
Waar je in real-time op moet letten
Vijf concrete signalen tijdens de sessie:
- Kwaliteit van prompts. Leggen ze beperkingen, voorbeelden en de vorm van de gewenste output uit? Of plakken ze de spec in en hopen het beste?
- Afwijzingsfrequentie. Hoe vaak verwerpen ze een generatie? Sterke ingenieurs verwerpen er minstens een paar - soms stilzwijgend, soms hardop. Ingenieurs die alles behouden lezen niet wat ze afleveren.
- Waar ze AI alleen laten. Schrijven ze zelf de kritieke logica? Of laten ze de assistent het onderdeel bezitten dat bepalend is voor correctheid?
- Verificatiegewoontes. Voeren ze code uit op echte invoer? Lezen ze de diff voordat ze accepteren? Kijken ze naar randgevallen?
- Herstel. Wanneer het model in kringetjes rond gaat, stappen ze terug en denken na, of bleven ze prompting?
Deze zijn waarneembaar in een 60-minuten window als je naar de toetsaanslagen kijkt, niet alleen naar het artefact. De collaborative editor van ClarityHire registreert de volledige sessie met paste-events apart getagd van getypte invoer - handig wanneer je tijdens de walk-through een specifieke keuze met de kandidaat wilt herzien.
Een scorerrubric
Vijf dimensies, elk 1-4, gescoord vóór de debriefing:
| Dimensie | Zwak (1) | Sterk (4) |
|---|---|---|
| Prompting | Plakt de spec in, stelt brede vragen | Formuleert beperkingen, geeft voorbeelden, itereert |
| Kritisch lezen | Accepteert lange generaties zonder controle | Verwerpt, bewerkt en schrijft binnen seconden |
| Oordeel over hefboomwerking | Gebruikt AI op de dragende logica | Gebruikt AI op standaardcode, bezit het kritieke pad |
| Verificatie | Levert ongeteste of nauwelijks geteste code af | Voert uit tegen echte invoer, leest diffs, controleert randgevallen |
| Herstel | Loopt met het model vast | Schakelt terug naar code lezen of om verduidelijking vragen |
Score elk onafhankelijk. De structured interview-scorecards van ClarityHire sluiten deze vast zodat reviewers niet kunnen afdrijven na het zien van het artefact.
De walk-through na de sessie
Besteed de laatste 15 minuten aan drie vragen:
- "Laat me een generatie zien die je hebt verworpen. Waarom?"
- "Loop me door het gedeelte hiervan dat je zelf hebt geschreven, en waarom je de AI het niet hebt laten doen."
- "Wat is het breekbaarste onderdeel van wat we hebben afgeleverd? Wat zou je daarna nog aanpassen?"
Kandidaten die werkelijk hebben nagedacht tijdens de sessie kunnen deze zonder aarzeling beantwoorden. Kandidaten die alles hebben geaccepteerd wat het model produceerde kunnen dit niet - en de kloof verschijnt in de eerste tien seconden van elk antwoord. Dit is dezelfde auteurschapstest die je zou uitvoeren op een take-home, toegepast op live AI-gebruik.
Waar dit in de flow past
Beschouw deze ronde als een vervanging voor de standaard live coding-screening, niet als toevoeging. Uw flow moet nog steeds een system design-ronde en een behavioralronde bevatten; de vraag die deze ronde beantwoordt is die eerder behandeld door de closed-book coding-screening, die het meeste van zijn signaal heeft verloren in het LLM-tijdperk.
Wat doen vervolgens
Drie concrete stappen voordat u uw volgende AI-toegestane ronde houdt:
- Kies een rol en herschrijf de live coding-vraag naar iets dat AI niet in één poging kan oplossen maar dat een no-AI-kandidaat ook niet kan afmaken.
- Train uw interviewers om de workflow te scoren, niet het artefact. Het artefact is nu basisniveau. De workflow is het signaal.
- Bepaal wat "geverifieerd" betekent voordat de kandidaat aankomt. Door de rubric van tevoren vast te leggen voorkomt u achteraf rationalisatie die kalibratie verpest.
De teams die dit in 2026 goed voor elkaar krijgen, zullen beter recruiten dan teams die doen alsof het model niet in de kamer is. De vaardigheid is echt, de kloof tussen sterke en zwakke gebruikers is enorm, en het interviewformat om het te meten is niet moeilijker uit te voeren dan wat het vervangt.