Cum să intervievezi inginerii de aplicații LLM (Nu ingineri ML)

Rolul pe care de fapt îl angajezi

„Inginer LLM" sau „inginer de aplicații AI" este un rol care cu greu exista acum trei ani și acum se găsește în fiecare organizație de produs. Nu este același job ca inginer de machine learning. Abilitățile se suprapun poate 30%.

Un inginer de machine learning antrenează și lansează modele. Un inginer de aplicații LLM ia modele pre-antrenate și le transformă în funcționalități de produs: design de prompturi, harnesses de evaluare, pipeline-uri de recuperare, scaffolding pentru utilizarea instrumentelor, optimizare de latență și cost, eșec ușor atunci când modelul deviază de la script. Cei mai seniori dintre ei își petrec timpul pe jumătatea plictisitoare a lucrării — evals, observabilitate, guardrails — nu pe inteligență de prompturi.

Dacă evaluezi acești candidați cu setul de interviuri pentru ingineri ML, vei angaja cercetători care nu pot livra și vei respinge shipperi care nu au antrenat niciodată un model. Dacă îi evaluezi cu setul generic de ingineri software, pierzi întreaga suprafață de abilități specifice AI.

Cinci competențe demne de testat

Jobul se descompune în cinci zone testabile. Majoritatea buclelor pot acoperi patru din cinci în trei ore de timp pentru candidat.

1. Design și iterație de prompturi. Pot scrie un prompt care produce în mod fiabil output structurat și pot itera când nu?
2. Gândire de evaluare. Pot proiecta o evaluare care capturează o regresie pe care o verificare de vibrații ar rata?
3. Raționament despre moduri de eșec. Când modelul returnează deșeuri, au un model de de ce și un plan pentru a o repara?
4. Integrare de sistem. Pot conecta modelul în suprafața unui produs real — recuperare, apeluri de instrumente, streaming, reîncercări, cache-uri — fără să se prăbușească în producție?
5. Conștientizare de cost și latență. Știu ce costă alegerile lor? Știu ce face o așteptare de 30 de secunde încrederii utilizatorului?

Abilitatea cognitivă și ingineria generală de software mai contează. Trateaz-le ca condiții obligatorii, nu ca focusul rundelor specifice LLM.

O buclă în patru etape care funcționează

Aceasta este bucla pe care o recomandăm pentru un rol de inginer de aplicații LLM mid-to-senior.

Etapa 1: Mostră de lucru de inginerie promptă asincronă (90 de minute)

Oferă candidatului un set mic de date — 30 până la 50 de perechi input-output reprezentând o sarcină realistă de produs. Exemple: extragere de câmpuri structurate din e-mailuri de suport pentru clienți, clasificarea unui tichet de suport în una din șapte categorii cu scor de încredere, generarea unui rezumat personalizat de email dintr-un jurnal de evenimente ale clienților.

Sarcina lor: scrie un prompt (sau conductă scurtă de prompt-și-cod) care produce output-ul dorit pe setul de date, plus o notă de un paragraf despre unde se încă mai eșuează și de ce.

Permite orice instrument AI. Aceasta este o rundă Policy B — vezi ghidul nostru de politică de utilizare AI pentru framing-ul exact. Abilitatea pe care o măsori este cum folosesc instrumentele pentru a construi cu instrumentele, nu dacă o pot face neajutat.

Evaluează pe:

• Fiabilitate a output-ului pe tot setul de date
• Calitate a analizei modurilor de eșec (paragraful este mai revelator decât promptul în sine)
• Dacă au ajuns la evals, sau doar au privit rezultatele

Etapa 2: Design de evaluare live (45 de minute)

Arată-le promptul din Etapa 1 și o versiune deliberat ruptă a acestuia. Cere-le să proiecteze o evaluare care ar detecta regresia — nu doar verbal, ci scriind codul testului de evaluare într-un editor real.

Aceasta este runda cea mai discriminatorie din buclă. Candidații puternici vor:

• Distinge stiluri de evaluare cu potrivire exactă, similaritate semantică și evaluare cu rubrică, și alege-l pe cel potrivit pentru sarcină
• Construi cazuri distincte pozitive, cazuri extreme și cazuri adverse
• Vorbi despre cum va rula suita de evaluare în CI, care ar trebui să fie pragul de eșec și cum o vor actualiza în timp

Candidații slabi vor scrie trei afirmații care testează calea fericit și vor numi-o gata.

Rulează aceasta într-un editor de cod colaborativ pentru a putea urmări procesul de gândire al candidatului tastă cu tastă. Pauzele îți spun mult.

Etapa 3: Design de sistem — construire cu modelul (60 de minute)

Dă-le un rezumat de produs: „Proiectează backend-ul pentru o funcționalitate care permite unui reprezentant de vânzări să lipească ultimele 90 de zile de tichet de suport ale unui client și să obțină o analiză de un paragraf „ar trebui să ne fie teamă de churn" pe care o pot partaja cu managerul de cont."

Investighează:

• Cum ar structura promptul (sistem, utilizator, apeluri de instrumente?)
• Cum ar gestiona profilul de cost și latență (sincron? asincron cu un webhook? stremat?)
• Cum l-ar testa (exemple de aur, A/B împotriva unei linii de bază, human-in-the-loop?)
• Cum ar detecta o regresie după următoarea actualizare de model
• Ce ar face dacă modelul halucinează un anumit nume de cont

Artefactul este conversația, nu o diagramă. Vezi rubrica noastră de design de sistem pentru îndrumări de cotare.

Etapa 4: Parcurgere plus comportamental structurat (45 de minute)

O singură rundă împărțită în două jumătăți. Mai întâi, 25 de minute parcurgând mostra de lucru din Etapa 1 cu șablonul de întrebări de urmărire. Apoi 20 de minute de întrebări comportamentale structurate despre colaborare cu stakeholder-i non-ingineri — produs, design, suport — deoarece cele mai multe moduri de eșec în funcționalități LLM sunt capturate de oameni care nu scriu cod.

Modele de întrebări care produc semnal real

Trei modele demne de furat pentru orice rundă de inginerie de aplicații LLM.

„Arată-mi un prompt pe care l-ai scris și care s-a rupt în producție. Ce ai schimbat?" Aceasta este cea mai bună întrebare din kit. Candidații puternici au povești specifice cu remedieri specifice. Candidații slabi vorbesc despre promptare în abstract.

„Care este cel mai ieftin model pe care ai putea folosi pentru această funcționalitate? De ce nu îl folosești?" Testează conștientizarea costului și îi forțează să articuleze compromisul calitate-cost pe care l-au ales implicit. Răspunsul „mă ating mereu de cel mai mare model" este îngrijorator la orice nivel de seniorate.

„Cum știi că promptul tău este mai bun decât versiunea anterioară?" Testează dacă de fapt rulează evals sau doar se încrede în vibrații. O fracție surprinzător de mare de candidați au livrat funcționalități LLM fără a măsura vreodată calitatea.

Ce nu funcționează

Câteva abordări pe care le-am urmărit pe care echipele le-au încercat și abandonate.

• Interviuri de algoritmi în stil LeetCode. Aproape nicio muncă de aplicații LLM nu este algoritmică. Semnalul pe care îl obții este necorelat cu jobul. Vezi screenează dezvoltatorii fără LeetCode pentru argumentul mai larg.
• „Construiește un chatbot de la zero în 90 de minute." Testează viteza de tastare, nu inginerie. Deciziile interesante se află în design de evaluare și manipulare de eșec, nu în cablarea unui apel API.
• Ecranele de trivia de prompturi. „Care este temperatura?" testează vocabular, nu judecată. Testează judecata direct.
• Tablele albe matematice pe internele transformatoarelor. Util dacă angajezi un cercetător de modele. Irelevant pentru cineva care și va petrece săptămâna pe conducte de recuperare și suite de evaluare.

Întrebarea de integritate pentru un rol care utilizează AI

Aceasta este întrebarea de round-tripping pe care fiecare echipă o atinge: dacă candidatul are voie să folosească Claude sau ChatGPT în timpul mostrei de lucru, ce îi împiedică să lase pur și simplu modelul să facă munca?

Trei lucruri, în combinație:

1. Parcurgerea din Etapa 4. Un candidat care nu poate apăra propriul prompt, evaluare sau design de sistem nu a făcut de fapt munca — indiferent ce spune artefactul.
2. Designul de evaluare live din Etapa 2. Această rundă rulează într-un editor supravegheat fără instrumente de chat, în 45 de minute. Este greu de falsificat.
3. Analiza coerență a codului pe trimiterea din Etapa 1. Codul generat de AI are semne structurale chiar și atunci când candidatul a folosit și AI pentru a-l dezgheța.

Punctul nu este să-i prinzi în flagrant. Este să te asiguri că scorul fiecărui candidat reflectă ceea ce poate face într-o săptămână de inginerie reală, cu instrumentele pe care le va folosi de fapt.

Ce să faci mai departe

Dacă pornești angajări LLM în acest trimestru, mișcarea cu cea mai mare pârghie este să încetezi reutilizarea buclei inginerului backend senior. Alege trei din cele cinci competențe de mai sus pentru prima versiune a rubricii tale, scrie o mostră de lucru și o exerciție de design de evaluare, și rulează-o pe doi ingineri interni pentru a calibra.

Apoi rulează-o pe cinci candidați externi. După candidatul trei deja vei ști dacă bucla este mai ascuțită decât ceea ce aveai înainte. Rolurile se schimbă. Disciplina — alege metode care produc semnal real, apoi verifică că semnalul este al candidatului — nu.