AI-vaardigheid beoordelen bij engineers vereist dat je verder kijkt dan bekendheid met tools, naar werkgewoonten: hoe ze modellen aansturen, output controleren en herstellen wanneer het model zelfverzekerd de fout in gaat. Een developer die AI in productie heeft gebruikt, laat dat zien in hoe hij of zij afwegingen beschrijft, niet alleen in welke tools er worden genoemd.
Waarom het gebruikelijke interview tekortschiet
Vragen 'gebruik je Copilot of Cursor?' zegt je bijna niets. Toolgebruik is inmiddels bijna universeel. De vraag is hoe een engineer deze tools gebruikt, wat hij of zij controleert, en op welk punt ze besluiten er niet meer op te vertrouwen.
Een standaard coderingstest, solo en onder tijdsdruk, geeft ook beperkt inzicht. Engineers die in hun dagelijkse werk op AI-hulp leunen, zullen dat tijdens een test vanzelf doen. AI verbieden meet het verkeerde. Toestaan zonder een gestructureerde nabespreking geeft je geen manier om de engineer van de output te onderscheiden.
Waar je in plaats daarvan op let
Hoe ze een recent stuk AI-ondersteund werk beschrijven. Vraag ze om iets te beschrijven dat ze de afgelopen maand met AI-hulp hebben gebouwd. Let op: welke prompt of context ze het model hebben gegeven, wat er onjuist of onvolledig terugkwam, wat ze hebben aangepast, en hoe ze hebben besloten dat het klaar was om te deployen. Vage antwoorden, of antwoorden die AI behandelen als een zwarte doos waarop ze kritiekloos vertrouwden, zijn veelzeggend.
Hoe ze AI-gegenereerde code reviewen. Een nuttige oefening is ze een kort stuk code geven dat ze zelf niet hebben geschreven, met daarin subtiele fouten. Let erop of ze het lezen of vluchtig doorscannen. Let erop of ze problemen oppikken die aannemelijk lijken maar onjuist zijn. Dit overlapt met normale code review-vaardigheden, maar wordt aangescherpt door het feit dat AI-output op specifieke manieren faalt: zelfverzekerde hallucinatie van API's, logica die structureel klopt maar gedragsmatig fout is, en impliciet aangenomen beveiligingsaannames.
Hoe ze over context praten. Engineers die AI goed gebruiken, hebben doorgaans een helder beeld van wat er in een prompt moet, hoeveel geschiedenis ze meenemen, en wanneer een gesprek zo ver is afgedwaald dat opnieuw beginnen betere resultaten geeft. Als ze nooit hebben nagedacht over context engineering, is dat een signaal. Als ze er sterke opvattingen over hebben, is dat ook een signaal, en de moeite waard om verder te verkennen.
Hoe ze omgaan met een onvolledige specificatie. Geef ze een briefing waaraan bewust details ontbreken. Stellen ze verhelderende vragen, maken ze expliciete aannames en geven ze aan wat ze bevestigd willen hebben voordat ze iets significants genereren? Of vullen ze de gaten stilzwijgend in en leveren ze vol vertrouwen op? AI-tools versterken zowel goede als slechte gewoonten rondom ambiguïteit.
Waar ze zeggen dat het model het fout had. Vraag rechtstreeks: 'vertel me over een keer dat het model je iets gaf dat er goed uitzag maar dat niet was.' Als ze geen specifieke situatie kunnen benoemen, gebruiken ze AI ofwel niet serieus in productie, ofwel controleren ze de output niet. Beide zijn relevant.
Signalen die weinig zeggen
Weten welke tools er bestaan is geen bewijs van vaardigheid. Kunnen uitleggen wat een RAG pipeline of een MCP server is, zegt niets over of iemand er een kan bouwen of beoordelen. Certificaten en cursusafronding op dit gebied hebben beperkte voorspellende waarde; het vakgebied heeft zich sneller ontwikkeld dan de meeste curricula.
De nabespreking structureren
Als je AI-gebruik tijdens een technische oefening toestaat, plan dan direct daarna een nabespreking van 20 minuten. Vraag ze elk onderdeel van het resultaat toe te lichten. Vraag wat het model fout had en hoe ze dat hebben opgemerkt. Vraag wat ze met meer tijd anders zouden doen. Deze aanpak is nuttiger dan welke take-home opdracht dan ook die gepolijst binnenkomt zonder gesprek.
Voor meer over wat er structureel in dit proces is veranderd, zie wat de coderingstest heeft vervangen.
Waar we op testen
Bij Miyagami beoordelen we elke engineer twee keer. Het eerste assessment gaat zonder AI-tools en dekt de basis: debuggen, prioriteren en communiceren. In het tweede werken kandidaten met hun gewone AI-tooling en kijken wij wat ze er in de praktijk mee doen. Controleren ze AI-output voordat ze erop vertrouwen? Hoe sturen ze meerdere tools aan? Blijven ze eigenaar van code die ze zelf niet hebben getypt? Risicogericht oordeelsvermogen en effectieve inzet van AI-tools worden over beide assessments gescoord. Waar we op letten en waarom, lees je op hoe we selecteren.
Korte antwoorden
Moet ik AI-tools verbieden tijdens een technisch interview?
AI-tools verbieden meet een manier van werken die afwijkt van de meeste productieomgevingen. Ze toestaan met een gestructureerde nabespreking geeft meer bruikbaar inzicht: je ziet wat de engineer heeft geaccepteerd, wat ze hebben gevangen en hoe ze het resultaat uitleggen.
Wat is de meest nuttige interviewvraag voor AI-vaardigheid?
Vraag de engineer een recent stuk werk te beschrijven dat ze met AI-hulp hebben gebouwd en waar het model het fout had. De kwaliteit en specificiteit van het antwoord zegt meer dan welke vraag over toolbekendheid dan ook.
Zegt kennis van AI-tools zoals RAG of agents iets over sterke AI-vaardigheid?
Conceptuele kennis is op zichzelf een zwak signaal. Het meer bruikbare bewijs is of de engineer kan beschrijven hoe ze een tool in productie hebben gebruikt, wat er misging en hoe ze dat hebben opgemerkt.
