Hoe je AI-samenwerkingsvaardigheden in codeeringsinterviews beoordeelt

Wanneer AI-gebruik een vaardigheid wordt in plaats van gedrag om te detecteren

Gedurende het grootste deel van de afgelopen twee jaar was AI in interviews iets om je tegen te verdedigen. De beoordelingscriteria waren "heeft de kandidaat het gebruikt, en hebben we het gepakt?" Dit kader is nog steeds van toepassing in AI-verboden rondes, en de integriteitlaag die misbruik daar oppakt is echt werk.

Maar in dezelfde interviewreeks voeren steeds meer bedrijven nu een ronde uit waarbij AI vereist is. Meta, Canva, Shopify en Coinbase evalueren kandidaten expliciet op AI-samenwerking. Als je interviewreeks in die richting gaat, heb je beoordelingscriteria nodig — want als je een kandidaat vertelt "gebruik welke tools je maar wilt" en je scoren ze op of de uiteindelijke code werkt, meet je bijna niets. De werkende code is de bijdrage van AI. De vaardigheid is degene die de kandidaat erin brengt.

Dit artikel is bedoeld voor aanstellingsmanagers die die AI-collaboratieve ronde ontwerpen. Vier dimensies om te scoren, één oefenformat en de veel voorkomende fouten van interviewers die het signaal vlak maken.

De vier dimensies die het waard zijn om te scoren

Een nuttig beoordelingscriteria voor AI-samenwerking toetst vaardigheden die in 45 minuten waarneembaar zijn en die de ingenieur die AI goed gebruikt onderscheiden van degene die de uitvoer ervan kopieert. Vier dimensies, met ankerpunten op elk niveau.

1. Promptkwaliteit en probleemdecomposing

Sterke kandidaten vragen het model niet om "de functie te bouwen." Ze decomposeren het probleem eerst, en vragen dan om hulp bij het stuk dat ze nodig hebben. De eerste prompt van de goede ingenieur ziet eruit als een goed afgebakend ticket; de eerste prompt van de zwakke ingenieur ziet eruit als de originele probleemstelling.

Hier let je op:

• Hebben ze het probleem in hun eigen woorden opnieuw geformuleerd voordat ze promptten?
• Hebben ze het model ingeperkt — bestandspaden, functiehandtekeningen, de gegevensvorm, voorbeelden van de verwachte uitvoer?
• Hebben ze één ding tegelijk gevraagd, of hebben ze het hele briefing geplakt en gebeden?

Een nuttige proxy: hoeveel tokens schreef de kandidaat in de prompt voor elke regel code die AI produceerde? Onder een bepaalde verhouding gebruikt de kandidaat het model als een toverdoos en oefent geen oordeel uit op de invoer.

2. Verificatie en skepticisme

Dit is de dimensie die meestal sterken van zwakken scheidt. Het model produceert uitvoer. Wat doet de kandidaat ermee?

Het sterkste signaal is of de kandidaat voordat ze integreren verifies. Specifieke gedragingen:

• De gegenereerde code regel voor regel lezen voordat deze wordt geplakt
• Dit tegen een testgeval uitvoeren dat de kandidaat zelf heeft geconstrueerd (niet één die het model heeft voorgesteld)
• Een gehallucineerde functie of bibliotheek opvangen en ofwel opnieuw prompten ofwel zelf vervangen
• Opmerken dat de uitvoer plausibel is maar fout op een hoekgeval

Het zwakste gedrag is paste-and-pray: de kandidaat kopieert de code van het model naar de editor, voert het blije pad uit, ziet groen, en gaat verder. Dit is het AI-samenwerking-equivalent van een junior ingenieur die een diff samenvat zonder deze te lezen.

Gebruik dezelfde code-coherentieanalyse die door AI gegenereerde code in asynchrone beoordelingen markeert. In een AI-verplichte ronde is de score niet "heeft de kandidaat AI gebruikt" — dat is verwacht. De score is of de bewerkingen van de kandidaat op de AI-uitvoer bewijs tonen van lezen en denken, of de diff pure paste is.

3. Controle over de lus

Junior kandidaten volgen AI overal waar het heen leidt. Sterke kandidaten leiden AI.

Concreet gedrag om te scoren:

• Wanneer het model een fout antwoord geeft, diagnosticeert de kandidaat het en prompt opnieuw met een gecorrigeerde beperking — of blijven ze regenereren in de hoop op een ander antwoord?
• Wanneer het model een architectuur voorstelt die de kandidaat niet eens is, dringen ze erop aan ("Ik zou hier liever een state machine gebruiken, kun je dit daarmee opnieuw doen?") of accepteren ze het voorstel?
• Wanneer het model afzijdig gaat (iets herzien dat de kandidaat niet vroeg), merkt de kandidaat dit op en trekt het terug?

Deze dimensie is onzichtbaar zonder schermopname. Zorg ervoor dat de ronde de promptgeschiedenis en de editor-diff samen vastlegt, niet alleen de uiteindelijke code.

4. Communicatie bij pairing met AI

De laatste dimensie is of de kandidaat de interviewer in de lus houdt. Dit klinkt soft maar het is de signaaluitzending met de hoogste voorspellingswaarde voor hoe de kandidaat dag in dag uit in een team zal werken dat met AI samenwerkt.

Dit is wat goed eruit ziet:

• Narrating voordat u prompt: "Ik ga Claude vragen om de parser te ontwerpen. Ik verwacht dat deze de tokenizer correct krijgt maar waarschijnlijk verkeerd met escape-tekens omgaat — ik zal dat moeten repareren."
• De prompt tonen voordat u deze verzendt
• Onenigheid met het model hardop blootleggen, niet stilzwijgend
• Onderscheiden wat ze schreven van wat het model schreef bij het uitleggen van de code

De zwakke versie: stille prompts, lange pauzes terwijl de kandidaat de uitvoer van het model leest zonder te delen wat ze ervan denken, code die in de editor verschijnt zonder uitleg waar deze vandaan komt. Een kandidaat die stiekem met AI codeert, zal stiekem met mensen samenwerken, en dat is een teamsignaal dat je in de lus wilt opvangen.

De oefening die deze vaardigheden blootlegt

De verleiding is om de kandidaat een algoritmeprobleem te geven en hen AI te laten gebruiken. Doe dit niet. AI zal het in enkele seconden oplossen en de kandidaat zal 40 minuten opmerkingen bewerken. Je leert niets.

Een betere oefening heeft drie eigenschappen:

1. Multi-stap, met een ingebouwde verrassing. Begin met een kleine taak die de kandidaat duidelijk kan oplossen. Halverwege geeft u een wijzigingsverzoek dat een aanname breekt — een nieuw gegevensformat, een prestatiebeperking, een verouderde bibliotheek. De aanpassing is waar de AI-samenwerkingsvaardigheid zich voordoet.
2. Een subtiel gebroken startpunt. Geef de kandidaat code die compileert en draait maar een subtiele bug heeft — een off-by-one, een gestikte uitzondering, een raceconditie onder belasting. Kijk of ze het zelf opvangen of het model vertrouwen om het te vinden. De meeste modellen vinden een subtiele bug zonder een aanwijzing.
3. Een documentatie- of onderzoekscomponent. De taak vereist dat de kandidaat met een onbekende bibliotheek of API integreert. Het model weet ervan. De kandidaat moet verifiëren wat het model zegt tegen de werkelijke docs. Het verschil tussen "modelspreeuken" en "docs zeggen" is rich signal.

Vijfenveertig minuten voor de hele ronde. ClarityHire's collaborative code editor voert Monaco uit met geïntegreerde uitvoering en koppelt het met prompt-history capture, zodat de interviewer de editor-diff en het modelgesprek naast elkaar kan zien tijdens de debriefing — niet alleen de uiteindelijke code.

Scoringsankerpunten, 1 tot 4

Score elke dimensie onafhankelijk op een 1–4 schaal. Verankering van de niveaus aan gedragingen, niet adjectieven.

Promptkwaliteit (1–4):

• 1: Plakt de hele probleemstelling in het model; geen decomposing.
• 2: Vraagt om de feature als geheel, maar voegt minstens één beperking toe.
• 3: Ontleedt de taak in twee of drie stukken; prompt elk afzonderlijk met relevante context.
• 4: Schrijft goed afgebakende prompts met functiehandtekening, gegevensvorm en een uitgewerkt voorbeeld.

Verificatie (1–4):

• 1: Plakt modeluitvoer zonder te lezen.
• 2: Leest de uitvoer maar test alleen het blije pad.
• 3: Construeert minstens één testgeval onafhankelijk van de suggesties van het model; vangt minstens één probleem op.
• 4: Behandelt elke uitvoer als verdacht; verifieert tegen echte docs, echte testgegevens en hoekgevallen voordat ze integreren.

Controle (1–4):

• 1: Volgt alles wat het model produceert; regenereert in plaats van opnieuw te prompen na een fout.
• 2: Vernieuwde prompt met dezelfde context na fout; vangt soms op dat het model afzijdig gaat.
• 3: Diagnosticeert waarom het model fout is en prompt opnieuw met een gecorrigeerde beperking.
• 4: Stelt zelf de architectuur in en gebruikt het model voor tactische stukken; duwt terug wanneer het model een ander ontwerp voorstelt.

Communicatie (1–4):

• 1: Stille prompting; output verschijnt in de editor onverklaard.
• 2: Narraatst het eindresultaat maar niet het proces.
• 3: Narrates voordat u prompt en toont de prompt aan de interviewer.
• 4: Onderscheid hun eigen bijdrage van het model duidelijk; blootleggen van meningsverschillen met het model hardop.

Gebruik een gestructureerde scorecard waarbij elke interviewer hun score vastlegt voordat de debriefing plaatsvindt. De dimensies zijn onafhankelijk genoeg dat onenigheid informatief is — een interviewer kan de kandidaat 4 op verificatie en 2 op communicatie waarderen, en dat patroon is het ding dat het waard is om te bespreken.

Veel voorkomende fouten van interviewers

Vijf fouten die het signaal in deze ronde vlak maken:

1. De uiteindelijke code beoordelen. De code is van AI. Het oordeel, prompts en bewerkingen zijn van de kandidaat. Scoor die.
2. De kandidaat vragen om "uit te leggen wat de AI deed." Dit toetst leesbegrip, niet samenwerking. Vraag in plaats daarvan "wat zou je veranderen aan hoe AI dit benadering?"
3. Laten de ronde stiekem lopen. Als de kandidaat twee minuten stil wordt terwijl ze modeluitvoer lezen, prompt ze: "praat me door wat je bekijkt." Stilte is niet de test; je evalueert hoe ze samenwerken.
4. Een probleem kiezen dat het model in één keer kan oplossen. Een triviaal probleem betekent dat de kandidaat nooit controle, verificatie of herstel hoeft te demonstreren. Kies een probleem dat minstens één ronde meningsverschil met het model vereist.
5. De integriteitbasislijn vergeten. Dit is de AI-verplichte ronde, maar je bent nog steeds in dezelfde lus als de AI-verboden ronde. Als het toetspatroon van een kandidaat in deze ronde identiek is aan de verboden ronde, dat is interessant — zowel om goede redenen (de kandidaat typt echt op deze manier) als om slechte (dezelfde off-camera helper voert beide rondes uit).

Volgende stappen

Als je op het punt staat een AI-samenwerkingsronde aan je lus toe te voegen:

1. Beslis welke van de vier dimensies het belangrijkst zijn voor de specifieke rol. Een toegepaste ML-ingenieur zal waarschijnlijk verificatie het hoogst wegen; een generalistische software-ingenieur kan communicatie hoger wegen.
2. Ontwerp één oefening die een midden-rondes verrassing en een subtiele startbug bevat. Schrijf de ankerpunten voordat de eerste kandidaat het ziet.
3. Leg de promptgeschiedenis naast de editor-diff vast. Zonder de prompts, je bent code beoordelen; met hen, je bent de ingenieur beoordelen.
4. Calibreer met twee interviewers op een opgenomen sessie voordat u deze live uitvoert. De onenigheid tussen hen is de beoordelingscriteria.
5. Score deze ronde onafhankelijk van de AI-verboden ronde. Ze meten verschillende dingen, en ze samenvoegen zal de verkeerde kandidaat belonen.

Het doel van deze ronde is niet om kandidaten te vinden die AI kunnen gebruiken — bijna alle kandidaten kunnen dat. Het is om degenen te vinden wiens oordeel, verificatie en richting goed genoeg zijn dat de hefboomwerking van AI echt wordt, in plaats van dure paste-and-pray.