Hoe AI-engineers interviewen (LLM, RAG en prompt engineering rollen)

"AI engineer" zijn drie verschillende rollen in één jas

Voordat je de interviewloop ontwerpt, bepaal je eerst wat je werkelijk aanneemt:

1. Applied AI engineer - bouwt productfuncties op stichtingsmodellen. Verantwoordelijk voor prompts, evaluaties, retrievals, latentie, kosten. Werkt in je applicatiecodebase.
2. ML engineer (model-kant) - traint, fine-tunt of distilleert modellen. Verantwoordelijk voor datasets, trainingsinfra, evaluatiesuites. Werkt in je trainingsstack.
3. AI infrastructure engineer - beheert inference, vector DB en observabiliteit. Verantwoordelijk voor latentiebegrotingen, GPU-gebruik, deployment-pijplijnen. Werkt in je platform.

Deze drie rollen delen geen dagelijks werk. Een loop ontworpen voor één zal de andere twee verkeerd evalueren. De rest van deze gids richt zich op de applied AI engineer, omdat dat is wat 80% van teams die "AI engineers" in 2026 aannemen werkelijk nodig hebben.

De vier signalen die werkelijk werkprestaties voorspellen

Na het auditen van tientallen applied-AI wervingslussen onderscheiden vier signalen consistent engineers die werkende LLM-functies opleveren van engineers die aannemelijk ogende demo's opleveren:

1. Promptiteratie discipline. Kunnen zij een vage productvereiste omzetten in een prompt, een evaluatie en een meetbare verbeteringslus?
2. Failure-mode redenering. Gaan zij standaard uit van de aanname dat het model zal hallucineren, tokens zal lekken of het verkeerde tool zal kiezen - en ontwerpen zij dienovereenkomstig?
3. Evaluatieontwerp. Kunnen zij een evaluatie ontwerpen die de regressie die zij werkelijk interesseert, opvangt, niet alleen BLEU score?
4. Kosten- en latentiebewustzijn. Redeneren zij over tokens, caching, modelkeuze en batch-vorm - of grijpen zij naar GPT-5 voor elk oproep?

Geen van deze zijn testbaar met een LeetCode-vraag. Alle vier vereisen een ander interviewformat.

De vier-rondes loop die werkt

Ronde 1: Asynchrone thuiswerkopdracht (90 minuten, betaald indien uw cultuur dit ondersteunt)

Geef de kandidaat een klein, gebroken RAG-systeem en een echte klantenklacht. Voorbeeld:

Onze klantenondersteuningsbot verwijst voortdurend zelfverzekerd naar een productfunctie die niet bestaat. Hier is de repo, de prompt, de retrieval-pijplijn en drie voorbeelden van mislukkingen. Vind de hoofdoorzaak en stel een oplossing voor die je kunt verdedigen.

Wat je zoekt:

• Lezen zij de retrieval-resultaten voordat zij de prompt beschuldigen?
• Identificeren zij dat het embedding-model waarschijnlijk verkeerd is voor dit domein?
• Stellen zij een evaluatie voor om de regressie volgende keer op te vangen?
• Onderscheiden zij "het symptoom verhelpen" van "het systeem verhelpen"?

Een thuiswerkopdracht is het enige format dat je een helder beeld geeft van debuggingdiscipline. Live coderingsronden zijn te kort en staan onder te veel druk om te zien of iemand werkelijk de gegevens leest. Koppel het met een vervolgvraag zodat door AI gegenereerde inzendingen niet ontsnapppen.

Ronde 2: Live prompt engineering sessie (60 minuten)

Koppel de kandidaat aan een interviewer en een echte taak: zet een vage productbrief om in een werkende prompt met meetbare evaluaties, in real time, in je eigen gereedschappen.

Nuttige subtaken:

• Schrijf de eerste versie van de prompt.
• Schrijf drie evaluatiegevallen - waarvan één dat zou moeten mislukken.
• Itereer de prompt totdat de evaluaties slagen.
• Bespreek wat zij in productie zouden willen meten buiten de evaluatieset.

Signaal waarnaar je kijkt: denken zij in evaluaties eerst, prompts daarna? Engineers die LLM-functies hebben opgeleverd weten dat de prompt afgeleid is van de evaluatie. Engineers die alleen geprototypeerd hebben doen het tegenovergestelde.

Een gezamenlijke codeervruimte met Monaco + Yjs werkt daarvoor - de kandidaat schrijft prompts en evaluatiescaffolding in real time, en de interviewer kan precies ingrepen wanneer het ertoe doet.

Ronde 3: Systeemontwerp - maar dan AI-vormgegeven (60 minuten)

Zet de kandidaat neer met een realistisch applied-AI ontwerpverzoek:

Ontwerp een klantgericht vergadersamengevat systeem dat een transcript van 60 minuten inneemt en een actielijst produceert. Het moet in minder dan 30 seconden draaien, minder dan $0,05 per oproep kosten en weigeren inhoud buiten ons productdomein samen te vatten.

Dit is een systeemontwerp interview met AI-specifieke beperkingen. Score het met dezelfde dimensies - verduidelijking, afwegingen, foutmodi, kosten - maar let op de AI-specifieke zetten:

• Overwegen zij chunking en map-reduce versus single-shot?
• Redeneren zij over modelkeuze (kleiner model + betere prompt versus groter model)?
• Stellen zij een waarborg voor inhoud buiten het domein voor (classifier? prompt? afwijzingsevaluatie)?
• Ontwerpen zij observabiliteit voor hallucinatiesnelheid, niet alleen latentie?

Slechte kandidaten stellen voor "gebruik GPT-5, prompt het, retourneer het antwoord." Goede kandidaten besteden 10 minuten aan de kosten-/latentiebegroting voordat zij een enkel vak tekenen.

Ronde 4: Gedragsmatig over een opgeleverde AI-functie (45 minuten)

Een gestructureerde gedragsmatige ronde verankerd in een specifieke functie die zij hebben opgeleverd. De vragen die werken:

• "Loop me door de evaluatieset die je hebt gebouwd. Hoe is deze in de loop der tijd veranderd?"
• "Vertel me over een regressie die naar productie werd verstuurd. Hoe vond je het?"
• "Beschrijf een keer dat je een kleiner model gebruikte waar een groter veel gemakkelijker zou zijn geweest. Waarom?"
• "Vertel me over een functie waarbij het LLM het verkeerde tool was. Wat heb je in plaats daarvan opgeleverd?"

Die laatste vraag is het hoogste signaal in de loop. Engineers die LLM's alleen als hamer hebben gebruikt kunnen het niet beantwoorden. Engineers die echt product hebben opgeleverd kunnen je meestal over drie vertellen.

Vragen die slim lijken maar niet zijn

Deze komen voortdurend voor in AI engineer interviewhandleidingen en zijn meestal ruis:

• "Leg uit hoe transformers werken." Triviakennis. Elke kandidaat heeft dezelfde blogpost gelezen. Zegt niets over of zij kunnen opleveren.
• "Wat is het verschil tussen RAG en fine-tuning?" Al in elke trainingsset. Gebruik een vervolgpatroon in plaats daarvan: "vertel me over een keer dat je er één boven de ander koos en waarom."
• "Schrijf een transformer van nul af aan." Alleen relevant voor de model-kant ML engineer rol. Voor applied AI is dit een signaal van academische achtergrond, geen opleververmogen.
• Whiteboard prompt-engineering ("schrijf een prompt die X doet" zonder evaluatie en zonder iteratie). Losgekoppeld van hoe het werk werkelijk gebeurt. Een prompt op zichzelf, zonder een evaluatie, is theater.

Kalibratie voor ervaringsniveau

Dezelfde loop werkt op alle niveaus - wat verandert is wat je weegt.

Een staff applied-AI engineer zou vooral op systeemontwerp en gedragsmatig moeten worden geëvalueerd - op dat niveau koop je oordeel, niet implementatiesnelheid. Een engineer op middellang niveau zou vooral op thuiswerkopdracht en promptsessie moeten worden geëvalueerd - dat is waar hun waarde ligt. Zie de senior engineer interviewloop voor de gelijkwaardige verdeling op algemene engineeringrollen.

Integriteit, maar slimmer

Voor applied-AI rollen specifiek, AI-hulp tijdens het interview verbieden is incoherent. De taak is AI goed gebruiken. Het interview zou dat moeten weerspiegelen.

Wat wij in plaats daarvan aanbevelen:

• Sta AI-hulp openlijk toe in de thuiswerkopdracht. Score het gebruik van AI, niet de aanwezigheid. De kandidaat die Claude gebruikt om de codebase te verkennen en vervolgens een doordachte analyse van de hoofdoorzaak schrijft, is exact de kandidaat die je wilt.
• Sta AI niet toe in de live promptsessie. Het punt is om hen zien itereren. Gebruik toetsaanslag en scherm signalen om stille AI-gebruik op te vangen.
• Eis een live vervolgingsgesprek voor elke thuiswerkopdracht. Dit is het enkele hoogste signaal interview dat de meeste teams overslaan. Koppel een LLM-coherentiecontrole met een 30-minuuts live uitloop.

De kandidaat die hun thuiswerkopdracht 30 minuten lang kan verdedigen schreef het. Degene die dat niet kan, schreef het niet - ongeacht wat de toetsaanslag signalen zeggen.

Wat je nu moet doen

Als je een applied AI engineeringloop van nul af aan opzet:

1. Kies één van de drie roldefinities en schrijf een vacaturebeschrijving die overeenkomt.
2. Bouw (of hergebruik) één gebroken RAG thuiswerkopdracht. Itereer het op interne engineers eerst.
3. Stel de live promptsessie in in een gezamenlijke editor met gedeelde evaluatiescaffolding.
4. Train interviewers op de vier hierboven genoemde signalen voordat zij een enkele ronde uitvoeren.

De teams die AI engineers goed aannemen in 2026 zijn niet de teams met de slimste vragen. Het zijn de teams waarvan de lussen het werkelijke werk spiegelen - itereren, evalueren, debuggen, opleveren - en die voor het oordeel scoren dat jaren kost om op te bouwen.