Hoe test je prompt engineering vaardigheden bij het aannemen van personeel in 2026

Wat "prompt engineering" in 2026 bij recruitment echt betekent

Twee jaar geleden betekende "prompt engineer" meestal "kent de magische woorden." Tegenwoordig is deze rol in drie echte specialisaties opgesplitst, en de test die je opzet, hangt af van welke je aanneemt:

• Applied prompt engineer. Bouwt productieprompts in een applicatie, beheerst evaluaties, debugt wanneer een model zich anders gaat gedragen na een update van de leverancier. Werkt in code, in evaluatieframeworks en in de API-logs.
• Prompt-systems engineer. Ontwerpt de orchestratie rondom de prompt — retrieval, tool use, guardrails, fallbacks. Meer als een backend engineer die in tokens denkt.
• Conversational designer / prompt specialist. Schrijft prompts en persona's voor productoppervlakken (support, sales, coaching). Meer als UX-writing met een technische twist.

Als je beoordeling hetzelfde is voor alle drie, zul je voor minstens twee ervan de verkeerde persoon aannemen. Dit artikel richt zich op de eerste twee, waar het technische proces het meest telt.

Wat je moet testen (en wat niet)

Test dit:

• Eval discipline. Kan de kandidaat een kleine evaluatieset schrijven voordat ze de prompt schrijven, en deze gebruiken om te bepalen wanneer de ene prompt beter is dan de ander?
• Failure-mode reasoning. Gegeven een prompt en een steekproef van slechte outputs, kunnen ze hypothetiseren wat er misgaat en welke hendel ze moeten omzetten — temperature, systemprompt, few-shot examples, retrieval changes, tool-call shape?
• Kostenbesef en latency-bewustzijn. Weten ze wat hun prompt per call kost, wat een 50% reductie zou opleveren, en welke optimalisatie zou het minste kwaliteit verliezen?
• De geest van het model lezen, niet hun eigen. Wanneer de kandidaat een prompt aanpast, reageren ze op wat het model werkelijk deed, of op wat ze hopen dat het zou doen?

Test dit niet:

• Onthouden van promptpatronen ("chain-of-thought," "ReAct," "tree-of-thought"). Het opzeggen van de catalogus bewijst niets over of ze het kunnen toepassen.
• De huidige eigenaardigheden van een specifiek leveranciersmodel. De eigenaardigheden veranderen volgende kwartaal.
• Of ze in 10 minuten een "perfecte" prompt kunnen produceren. Echt promptwerk is iteratief, en vragen naar one-shot brilliance selecteert voor onthouden, niet voor vaardigheid.

Stadium 1: Een korte MCQ-test over LLM-basisprincipes

Een 20-minuten eerste-ronde test met 10-15 meerkeuzevragen filtert kandidaten eruit die "veel ChatGPT hebben gebruikt" en zichzelf prompt engineers noemen. Behandel concepten waarvan ze vloeiend moeten zijn: tokens versus karakters, waarom temperature 0 niet deterministisch is tussen leveranciers, wat contextvensters kosten, wanneer retrieval beter is dan fine-tuning, en wat evaluatieframeworks meten.

Bouw de vragenbank op uit concepten, niet uit leverancierstrivialiteiten. ClarityHire's MCQ-testbuilder ondersteunt gebundelde vragen met gerandomiseerde volgorde zodat kandidaten elkaar niet in Discord kunnen coachen. Voor deze rol specifiek: gebruik MCQ niet voor de uiteindelijke beslissing — gebruik het als een basiscontrole.

Stadium 2: Een take-home met een kleine, vuile eval set

Dit is het stadium met het hoogste signaal. Geef de kandidaat een kleine dataset van 40-80 voorbeeld-inputs met gewenste outputs (call-samenvattingen met handmatig beoordeelde kwaliteit, classificatie-voorbeelden met opzettelijk dubbelzinnige gevallen, een kleine RAG-corpus met drie valstrikken). Vraag ze om:

1. Een evaluatieset uit de gegevens te bouwen — inclusief de metriek die ze zouden gebruiken en waarom.
2. Een baseline-prompt te schrijven en de scores ervan te rapporteren.
3. Minstens drie versies te itereren, met de scoredelta en één zin met uitleg van de wijziging.
4. Een korte samenvatting in te dienen van afwegingen die ze hebben overwogen, wat ze met nog een dag zouden doen, en welke fouten ze niet hebben opgelost.

Een nuttige take-home lengte voor dit werk is 90-120 minuten, met een maximum. Onder de 60 leer je alleen of ze een prompt kunnen schrijven. Boven 2 uur selecteer je voor wie een vrij zaterdag heeft, niet voor de sterkste kandidaten.

Dit is wat je beoordeelt:

• Hebben ze een eval gebouwd voordat ze itereerden, of itereerden ze op intuïtie?
• Maakte elke promptversie een specifieke, verdedigbare wijziging?
• Hebben ze de opzettelijk dubbelzinnige gevallen opgemerkt of erover heen gekeken?
• Was de samenvatting specifiek over afwegingen, of was het marketing voor hun eigen werk?

Dit is ook het stadium waar AI-geassisteerde kandidaten eenvoudig een ander LLM de volledige inzending kunnen laten schrijven. ClarityHire's code coherence analysis voert een authenticiteitscheck uit op de ingediende prompts en samenvatting specifiek om de patronen te markeren die kenmerkend zijn voor LLM-gegenereerde antwoorden — al te vloeiende proza, verdedigende voorbehouden die de kandidaat nooit heeft getest, en handige afwezigheden van de rommelige iteratie die een mens zou achterlaten. Gebruik het als context voor de live vervolgstap, niet als uitspraak.

Stadium 3: Een live werksessie met een LLM

Zestig minuten, scherm gedeeld, in een echte editor met API-toegang — niet een chat-interface. De kandidaat krijgt een vers probleem dat op dezelfde manier is gevormd als de take-home, maar met een twist waarop ze niet hebben kunnen voorbereiden. Een nieuwe failure mode in de gegevens, een strakker latency-budget, een wissel van het ene naar het andere model halverwege de sessie.

Waar je op luistert:

• Lezen ze de output van het model zorgvuldig voordat ze de prompt wijzigen, of gokken ze?
• Wanneer het model rommel teruggeeft, denken ze over waarom voordat ze "wees voorzichtiger" in de systeemprompt erbij halen?
• Vormen ze een hypothese, isoleren ze één variabele en testen ze deze — of schieten ze tien wijzigingen tegelijk af?
• Zeggen ze "Ik weet niet wat dit model hier doet, laat me even snel testen" zonder in paniek te raken?

Dit stadium vervangt de live coding-sessie in een softwareproces. De vaardigheid die wordt getest is hetzelfde — snelle diagnostische redenering onder toezicht — maar het medium is anders.

Stadium 4: Een failure-mode en productie-interview

Een 45-minuten gestructureerd gesprek over productie. Zet echte (geanonimiseerde) voorbeelden van prompts die in dev werkten en in productie kapotgingen. Vraag vervolgens aan de kandidaat ze te diagnosticeren. Nuttige vragen:

• "De eval-score van deze prompt daalde gisterennacht met 15% zonder een deploy. Wat onderzoek je eerst?"
• "Deze output is in 95% van de gevallen correct en catastrofaal fout in 5%. Loop me door je plan om catastrofaal onder 0,5% te drukken zonder de 95% te verliezen."
• "Je tool-calling agent raakte in een loop van 12 pogingen en kostte $40 op een enkele gebruikersquery. Hoe vind je de oorzaak?"

Deze ronde test de productieverstandsdimensie waar een take-home niet kan bereiken, en zij scheidt schoon kandidaten die prompts naar echte gebruikers hebben verstuurd van diegenen die alleen demo's hebben gebouwd.

Beoordeel met een rubric, niet met originaliteit

Gebruik een 1-4 schaal over vier dimensies — eval discipline, failure-mode reasoning, productie-denken, communicatie — verankerd in specifieke beschrijvingen van hoe elke waardering eruitziet. ClarityHire's structured interview scorecards vergrendelt de rubric en vereisen onafhankelijke score-inzending voordat de debriefing, wat hier meer telt dan in een ander technisch proces, omdat "het model zei iets cools" het meest verleidelijke vals signaal in de industrie op dit moment is.

Weeg de dimensies af op de rol:

• Applied prompt engineer. Zwaar gewicht op eval discipline en failure-mode reasoning.
• Prompt-systems engineer. Zwaar gewicht op productieverstand; de live sessie kan naar orchestratie-debugging neigen.
• Conversational designer. Lichter gewicht op de eval en live sessies, zwaarder op communicatie en een portfoliobeoordeling.

Integriteitsoverwegingen specifiek voor AI-hiring

Het ironie van het aannemen van prompt engineers is dat zij de kandidaten zijn die het best uitgerust zijn om AI te gebruiken om de test vals voor te stellen. Drie praktische aanpassingen:

1. Maak de take-home dataset speciaal. Een standaard publieke dataset staat al in iemands prompt-handleiding. Een kleine, intern gegenereerde, dat is niet.
2. Vraag door over de take-home live. Een 20-minuten vervolgstap op "waarom maakte je deze specifieke wijziging tussen v2 en v3?" vindt de kandidaten die werkelijk hebben geïtereerd. AI-geplakte inzendingen hebben geen auteur die kan antwoorden.
3. Gebruik integriteitssignalen als gespreksopeners. Keystroke biometrics, paste-events en code coherence geven je context voor de debriefing. Gebruik ze nooit om automatisch af te wijzen — op dit vaardigheidsniveau zul je sterke kandidaten verliezen aan fout-positieven.

Wat te doen nu

Als je een prompt engineering-positie gaat openen:

1. Bepaal welke van de drie specialisaties je werkelijk nodig hebt voordat je de vacature schrijft.
2. Bouw de take-home dataset uit je eigen product of domein, niet uit een openbare benchmark.
3. Kies de vier beoordelingsdimensies en weeg ze af op de specialisatie voordat je vragen ontwerpt.
4. Koppel de take-home aan een live werksessie en een productie-gesprek — geen van beide is alleen voldoende.
5. Vergrendel de rubric in een structured interview platform zodat de debriefing echt meningsverschil naar voren brengt in plaats van consensus rond het meest indrukwekkende antwoord.

De markt voor prompt engineers in 2026 heeft nog steeds meer openstaande posities dan gekwalificeerde kandidaten. Jouw proces concurreert met elk ander AI-team om dezelfde mensen aan te nemen, en de kandidaten die een serieus proces kunnen doorstaan, zullen weten — in de eerste ronde — of jouw proces serieus is of theater.