AI-kandidaten beoordelen zonder zelf AI-kennis: een checklist

Het selecteren en aannemen van AI-specialisten stelt HR-professionals, recruiters en niet-technische managers voor een van de lastigste wervingsopgaven van dit moment. Het vakgebied ontwikkelt zich in een razend tempo, het jargon verandert maandelijks en het spectrum aan sollicitanten loopt sterk uiteen. Aan de ene kant staan ervaren software-engineers die machine learning beheersen tot in de kern; aan de andere kant melden zich enthousiaste hobbyisten die voornamelijk kant-en-klare API-aanroepen en standaardscripts uit tutorials hebben overgenomen. Wie zelf geen wiskundige achtergrond of programmeerervaring heeft, loopt al snel het risico te vertrouwen op schijnzekerheden: ronkende termen op een cv, een lange opsomming van modelnamen of een verzameling online certificaten.

Toch is diepgaande technische vakkennis geen absolute vereiste om het kaf van het koren te scheiden. Effectieve selectie door niet-technische beoordelaars draait niet om het controleren van wiskundige bewijsvoeringen of het ontleden van Python-scripts. Het draait om het toetsen van procesmatige discipline, het begrijpen van architecturale afwegingen, het onderzoeken van robuustheid en het controleren van verifieerbaar bewijsmateriaal. Dit artikel biedt een compleet referentiekader en een praktische checklist waarmee niet-technische interviewers een betrouwbare inschatting maken van het werkelijke niveau van een kandidaat.

De intake en rolbepaling: weet exact wat de organisatie zoekt

Voordat het eerste cv op tafel komt, moet binnen de organisatie scherp zijn afgebakend welk probleem de nieuwe medewerker moet oplossen. Een veelvoorkomende valkuil bij niet-technische hiring managers is het samenstellen van een onrealistisch wensenlijstje: een specialist die zelfstandig neurale netwerken traint, schaalbare cloud-infrastructuur uitrolt, juridische compliance waarborgt en tegelijkertijd soepele webinterfaces oplevert. In de praktijk bestaat deze alleskunner zelden, en wie ernaar zoekt trekt vooral kandidaten aan die van alle onderwerpen slechts een oppervlakkige notie hebben.

Het is essentieel om onderscheid te maken tussen de verschillende profielen binnen het AI-landschap. Een Data Scientist richt zich primair op statistische analyse, patroonherkenning en data-exploratie. Een Machine Learning Engineer houdt zich bezig met modeltraining, parameter-optimalisatie en wiskundige pipelines. Een AI Engineer daarentegen integreert bestaande fundatiemodellen en LLM-API's in werkende software en bedrijfsprocessen. Om inzicht te krijgen in hoe deze verschillende disciplines op elkaar aansluiten binnen een organisatie, helpt het overzicht over een effectief AI-team samenstellen om rollen, verantwoordelijkheden en groeifasen zuiver te definiëren.

Door vooraf een expliciete keuze te maken voor een van deze profielen, voorkom je dat kandidaten reageren op basis van verkeerde verwachtingen. Een kandidaat die gespecialiseerd is in datamodellering raakt gefrustreerd wanneer de dagelijkse praktijk bestaat uit het schrijven van API-koppelingen, terwijl een pure softwareontwikkelaar vastloopt op statistische validering. Helderheid in de intake voorkomt ruis tijdens de rest van de selectieprocedure.

CV-screening: het kaf van het koren scheiden

Bij het doornemen van een cv laten veel niet-technische recruiters zich imponeren door een lange opsomming van frameworks en modelbibliotheken, zoals PyTorch, LangChain, LlamaIndex, Transformers, Ollama en Vector Databases. Het noemen van twintig van dit soort termen betekent in de praktijk vaak weinig meer dan dat de kandidaat de documentatie heeft doorgebladerd of een YouTube-handleiding heeft bekeken. Werkelijke vakkennis toont zich in context, randvoorwaarden en concrete uitkomsten.

Kijk daarom specifiek naar de wijze waarop projecten en werkervaring worden omschreven. Vermeldt de kandidaat uitsluitend vage claims zoals "LLM-oplossing gebouwd voor klantenservice", of benoemt hij meetbare parameters zoals "doorlooptijd van documentverwerking met 40% verlaagd en foutmarge in structured data extractie teruggebracht tot onder de 2%"? Om te doorgronden hoe professionals zelf vacatures analyseren en jargon filteren, is het verhelderend om te zien hoe kandidaten kritisch AI-vacatureteksten lezen om vage modewoorden van echte vereisten te onderscheiden.

Portfolio en projecten beoordelen zonder zelf code te lezen

Een kandidaat die verwijst naar een eigen GitHub-account of publiek toegankelijke demonstratieprojecten levert waardevol bewijsmateriaal. Zelfs als je geen enkele programmeertaal beheerst, kun je de kwaliteit en volwassenheid van zo'n repository verrassend nauwkeurig vaststellen aan de hand van structuur en documentatie.

Open de hoofdpagina van het project en inspecteer het README.md-bestand. Een serieuze ontwikkelaar zorgt voor een glasheldere inleiding die de volgende vragen beantwoordt: welk specifiek probleem lost dit project op, welke aannames zijn gedaan over de invoerdata, hoe installeer en start je de software lokaal, en welke afhankelijkheden zijn vereist? Wanneer een repository slechts bestaat uit een ongeorganiseerde verzameling losse Python-bestanden (zoals script_v2_final.py) zonder enige uitleg, duidt dat op een gebrek aan professionele werkstandaarden.

Let daarnaast op de datum en frequentie van de wijzigingen (de commit history). Zijn alle bestanden in één enkele bulk-upload geplaatst? Dan kan het gaan om een gekopieerd project van elders. Is er daarentegen sprake van een reeks opeenvolgende stappen met duidelijke toelichtingen per wijziging (bijvoorbeeld "foutafhandeling toegevoegd voor ontbrekende JSON-velden" of "evaluatiescript uitgebreid met nieuwe testcases"), dan toont dat een iteratief en doordacht werkproces aan.

Gerichte interviewvragen en antwoordpatronen

Tijdens het persoonlijke gesprek kun je gerichte procesvragen stellen waarbij je niet let op wiskundige details, maar op de logica en robuustheid van de redenering. Goede AI-engineers blinken uit in het beheersen van onzekerheden en onvolkomenheden van modellen.

1. Hoe meet je of een AI-oplossing betrouwbaar functioneert?

Zwakke kandidaten leunen op zogeheten eyeball-evaluatie: ze voeren handmatig een handvol vragen in, zien dat het antwoord er redelijk uitziet en concluderen dat het systeem gereed is voor productie. Ervaren specialisten gruwelen van deze aanpak. Zij leggen uit hoe ze een representatieve testdataset (evaluatiecorpus) hebben opgesteld en welke objectieve metrieken ze hanteren om te controleren of aanpassingen aan prompts of modellen geen regressie veroorzaken. Om te begrijpen hoe systematische evaluatiemethoden in elkaar zitten, biedt het referentiekader voor een raamwerk om zelf een LLM te evalueren concrete methodes om kwaliteit en determinisme meetbaar te maken.

2. Wat gebeurt er als het model hallucineert of corrupte output genereert?

Wanneer een kandidaat antwoordt dat hallucinaties worden opgelost door "het model in de prompt vriendelijk te verzoeken de waarheid te spreken", ontbreekt het aan technisch realisme. Een doorgewinterde engineer bespreekt harde programmeercontroles: validatie van gestructureerde JSON-uitvoer tegen een strikt schema, fallback-mechanismen naar traditionele zoekalgoritmen, en guardrails die controleren of beweringen direct herleidbaar zijn tot meegeleverde brondocumenten.

3. Welke afwegingen maak je tussen modelgrootte, latentie en operationele kosten?

Het blindelings kiezen voor het grootste en duurste commerciële taalmodel getuigt zelden van goed technisch leiderschap. Vraag de kandidaat waarom hij in een specifiek project niet heeft gekozen voor een compacter model of voor caching. Een sterke kandidaat kan exact voorrekenen hoe tokenlimieten, reactietijden van gebruikersinterfaces en operationele hostingkosten met elkaar in verhouding staan.

Het herkennen van tutorial-kandidaten en hype-surfers

De enorme toegankelijkheid van generatieve AI heeft gezorgd voor een toestroom van sollicitanten die online handleidingen letterlijk overnemen en als eigen werk presenteren. Dit zijn zogeheten tutorial-kandidaten. Ze kunnen een indrukwekkende demonstratie geven zolang alles binnen het voorgeschreven pad blijft, maar vallen stil zodra de context verandert.

Je herkent tutorial-projecten vaak aan typische standaardcases: een chatfunctionaliteit over een geüploade PDF met behulp van standaard bibliotheekinstellingen van een populair framework. Zodra je doorvraagt over wat er gebeurt bij gelijktijdig gebruik door honderd gebruikers, hoe documenten met complexe tabellen worden geparsed, of hoe omgegaan wordt met privacygevoelige gegevens, hebben deze kandidaten geen antwoord.

Een tweede categorie betreft de hype-surfers: professionals die theoretisch exact weten welke modellen en onderzoekspapers gisteren zijn verschenen, maar die weinig affiniteit hebben met gedegen software engineering. Ze praten liever over hypothetische mogelijkheden dan over geautomatiseerd testen, monitoring, deployment pipelines en foutafhandeling. In een zakelijke omgeving is degelijke software-architectuur echter voor 80% bepalend voor het succes van een AI-implementatie.

Het technisch assessment: structuur en onafhankelijke toetsing

Zodra een kandidaat de eerste gespreksrondes succesvol heeft doorlopen, is een technische proefopdracht onmisbaar. Omdat je als niet-technische beoordelaar de code niet zelf kunt auditen op beveiligingsrisico's en efficiëntie, is een gestandaardiseerde opzet noodzakelijk.

Een effectief assessment bestaat uit een realistische take-home opdracht van maximaal 3 tot 4 uur, gericht op een herkenbaar bedrijfsvraagstuk. Vraag de kandidaat bijvoorbeeld om een API-koppeling te bouwen die binnenkomende ongestructureerde klantberichten categoriseert en valideert. Om een goed beeld te krijgen van de eisen en de dynamiek rondom dergelijke toetsen, bekijk je de leidraad voor een technisch assessment voorbereiden binnen het selectieproces voor AI- en softwarefuncties.

Laat de ingeleverde uitwerking vervolgens reviewen door een externe senior specialist of een vertrouwde freelance software-architect. Geef deze beoordelaar een vaste evaluatiematrix mee met concrete scoringscriteria:

De praktische beoordelingschecklist

Onderstaande checklist bundelt alle evaluatiestappen in een overzichtelijk schema dat tijdens het gehele wervingsproces als leidraad kan dienen:

Samenwerken met inhoudelijke experts en afronding

Het selecteren van AI-talent zonder eigen diepgaande technische achtergrond vereist vooral procesmatige nauwkeurigheid en een gezonde dosis kritische distantie. Door de focus te verleggen van imponerende modewoorden naar systematische evaluatiemethoden, foutafhandeling en documentatiestandaarden, kunnen niet-technische interviewers met grote precisie vaststellen of een kandidaat werkelijke waarde gaat toevoegen aan de organisatie.

Wanneer je deze gestructureerde vraagstelling combineert met een onafhankelijke externe review van het code-assessment, ontstaat een robuust en betrouwbaar selectieproces. Zo bouw je met vertrouwen aan een capabel en toekomstbestendig team dat AI-technologie vertaalt naar meetbaar organisatorisch succes.