Hoe je LLM Application Engineers interviewt (geen ML Engineers)

De rol waar je eigenlijk voor werft

"LLM engineer" of "AI application engineer" is een rol die drie jaar geleden nauwelijks bestond en nu in elke product-organisatie zit. Het is niet dezelfde baan als een machine learning engineer. De vaardigheden overlappen misschien voor 30%.

Een machine learning engineer traint en serveert modellen. Een LLM application engineer neemt voorgetrainde modellen en transformeert ze in productfeatures: prompt design, evaluation harnesses, retrieval pipelines, tool-use scaffolding, latency en cost optimization, graceful failure als het model van het script afwijkt. De meest ervaren engineers besteden hun tijd aan het saaie gedeelte van het werk — evals, observability, guardrails — niet aan prompt-slimheid.

Als je deze kandidaten beoordeelt met de ML engineer interview kit, zul je onderzoekers aannemen die niet kunnen opleveren en shippers afwijzen die nooit een model hebben getraind. Als je ze beoordeelt met de generieke software engineer kit, mis je het hele AI-specifieke vakgebied.

Vijf competenties die het testen waard zijn

De baan valt uiteen in vijf testbare gebieden. De meeste loops kunnen vier van de vijf gebieden in drie uur kandidaat-tijd bestrijken.

1. Prompt design en iteratie. Kunnen ze een prompt schrijven die betrouwbaar gestructureerde output produceert, en kunnen ze itereren als dat niet het geval is?
2. Evaluation thinking. Kunnen ze een eval ontwerpen die een regressie opvangt die een vibes-check zou missen?
3. Failure-mode reasoning. Als het model rotzooi oplevert, hebben ze een model van waarom en een plan om het op te lossen?
4. System integration. Kunnen ze het model in een echte product surface weven — retrieval, tool calls, streaming, retries, caching — zonder dat het in productie crasht?
5. Cost en latency awareness. Weten ze wat hun keuzes kosten? Weten ze wat een 30-secondewachttijd voor user trust doet?

Cognitief vermogen en algemene software engineering zijn nog steeds belangrijk. Behandel ze als table stakes, niet als de focus van de LLM-specifieke rounds.

Een vierstadium loop die werkt

Dit is de loop die we aanbevelen voor een mid-to-senior LLM application engineer rol.

Stage 1: Async prompt-engineering work sample (90 minuten)

Geef de kandidaat een kleine dataset — 30 tot 50 input-output pairs die een realistische product task vertegenwoordigen. Voorbeelden: gestructureerde velden uit customer support emails extraheren, een support ticket in een van zeven categorieën classificeren met een confidence score, een gepersonaliseerde e-mailsamenvatting genereren vanuit een customer-event log.

Hun taak: een prompt (of korte prompt-en-code pipeline) schrijven die de gewenste output op de dataset produceert, plus een alinea notitie over waar het nog faalt en waarom.

Sta alle AI tools toe. Dit is een Policy B round — zie onze AI usage policy guide voor de exacte formulering. De vaardigheid die je meet is hoe ze de tools gebruiken om met de tools te bouwen, niet of ze het ongesteund kunnen doen.

Beoordeel op:

• Betrouwbaarheid van de output in de dataset
• Kwaliteit van de failure-mode analyse (de alinea zegt meer dan de prompt zelf)
• Of ze evals hebben bereikt, of alleen op basis van oogmaat hebben beoordeeld

Stage 2: Live evaluation design (45 minuten)

Toon hen de prompt van Stage 1 en een opzettelijk gebroken versie ervan. Vraag hen een evaluatie te ontwerpen die de regressie zou opvangen — niet alleen verbaal, maar door de eval test code in een echte editor te schrijven.

Dit is de meest discriminerende round in de loop. Sterke kandidaten zullen:

• Exact-match, semantic similarity en rubric-graded eval stijlen onderscheiden en de juiste voor de taak kiezen
• Duidelijke positieve cases, edge cases en adversarial cases inbouwen
• Praten over hoe de eval suite in CI zal draaien, wat de failure threshold moet zijn en hoe ze deze in de loop van de tijd zullen bijwerken

Zwakke kandidaten zullen drie asserts schrijven die het happy path testen en het voor gezien houden.

Voer dit uit in een collaborative code editor zodat je het denkproces van de kandidaat toets voor toets kan volgen. De pauzes vertellen je veel.

Stage 3: System design — bouwen met het model (60 minuten)

Geef hen een product brief: "Ontwerp de backend voor een feature waarmee een sales rep de laatste 90 dagen van support tickets van een klant kan plakken en een eenregelige 'moeten we ons zorgen maken over churn' analyse krijgt die ze kunnen delen met de account manager."

Vraag door op:

• Hoe ze de prompt zouden structureren (system, user, tool calls?)
• Hoe ze het cost en latency profiel zouden aanpakken (synchronous? async met een webhook? gestreamed?)
• Hoe ze het zouden testen (golden examples, A/B tegen een baseline, human-in-the-loop?)
• Hoe ze een regressie na de volgende model upgrade zouden opvangen
• Wat ze zouden doen als het model een specifieke accountnaam hallucineerde

Het artefact is het gesprek, niet een diagram. Zie onze system design rubric voor scoring guidance.

Stage 4: Walk-through plus structured behavioral (45 minuten)

Een enkele round gesplitst in twee helften. Eerst 25 minuten door de Stage 1 work sample lopen met het follow-up question template. Dan 20 minuten structured behavioral vragen over samenwerking met niet-engineering stakeholders — product, design, support — omdat de meeste failure modes in LLM features door mensen worden opgemerkt die geen code schrijven.

Vraagpatronen die echt signaal opleveren

Drie patronen die het stelen waard zijn voor elke LLM application engineering round.

"Laat me een prompt zien die je schreef en die in productie crashte. Wat heb je veranderd?" Dit is de beste vraag in de kit. Sterke kandidaten hebben specifieke verhalen met specifieke fixes. Zwakke kandidaten praten abstract over prompting.

"Wat is het goedkoopste model dat je voor deze feature zou kunnen gebruiken? Waarom gebruik je het niet?" Toetst cost awareness en dwingt hen de quality-cost trade-off die ze impliciet hebben gekozen, uit te leggen. Het antwoord "Ik grijp altijd naar het grootste model" is op elk ervaringsniveau zorgwekkend.

"Hoe weet je dat je prompt beter is dan de vorige versie?" Toetst of ze eigenlijk evals runnen of alleen op vibes vertrouwen. Een opvallend deel van de kandidaten heeft LLM features opgeleverd zonder ooit kwaliteit te meten.

Wat werkt niet

Enkele benaderingen die we teams hebben zien proberen en verlaten.

• LeetCode-style algoritme interviews. Bijna geen LLM application work is algoritmisch. Het signaal dat je krijgt correleert niet met de baan. Zie screen developers without LeetCode voor het bredere argument.
• "Bouw een chatbot van nul in 90 minuten." Toetst snelheid-typen, niet engineering. De interessante keuzes zitten in eval design en failure handling, niet in het weven van een API call.
• Prompt-trivia screens. "Wat is temperature?" toetst woordenschat, niet oordeel. Toets het oordeel direct.
• Math whiteboards op transformer internals. Nuttig als je een model researcher aanneemt. Irrelevant voor iemand die hun week aan retrieval pipelines en eval suites zal besteden.

De integriteit vraag voor een AI-gebruikende rol

Dit is de round-tripping vraag die elk team raakt: als de kandidaat Claude of ChatGPT mag gebruiken tijdens de work sample, wat voorkomt dan dat ze gewoon het model het werk laten doen?

Drie dingen, in combinatie:

1. De Stage 4 walk-through. Een kandidaat die hun eigen prompt, eval of system design niet kan verdedigen, heeft het werk niet echt gedaan — wat het artefact ook zegt.
2. De Stage 2 live evaluation design. Deze round draait in een proctored editor zonder chat tools, in 45 minuten. Het is moeilijk om te faken.
3. Code coherence analysis op de Stage 1 submission. AI-gegenereerde code heeft structurele kenmerken zelfs wanneer de kandidaat AI ook gebruikte om het te camoufleren.

Het gaat niet om ze op heterdaad te betrappen. Het gaat erom ervoor te zorgen dat het score van elke kandidaat weerspiegelt wat ze in een echte engineering week kunnen doen, met de tools die ze echt zullen gebruiken.

Wat je vervolgens moet doen

Als je deze kwartaal LLM hiring opstart, is de meest impactvolle zet stoppen met het hergebruiken van de senior backend engineer loop. Kies drie van de vijf competenties hierboven voor je eerste versie van de rubric, schrijf één work sample en één eval-design oefening, en voer het uit op twee interne engineers om te kalibreren.

Voer het vervolgens uit op vijf externe kandidaten. Bij kandidaat drie weet je al of de loop scherper is dan wat je daarvoor had. De rollen veranderen. De discipline — kies methoden die echt signaal opleveren, en verifieer dan dat het signaal van de kandidaat is — niet.