Cum să intervievezi ingineri AI (Roluri LLM, RAG și Prompt Engineering)

„Inginer AI" înseamnă de fapt trei roluri diferite

Înainte să poți proiecta structura interviului, decide care dintre următoarele roluri angajezi de fapt:

1. Inginer AI aplicat — construiește caracteristici de produs pe baza modelelor de fundație. Gestionează prompt-uri, evaluări, recuperarea datelor, latență și cost. Lucrează în codul aplicației tale.
2. Inginer ML (pe partea de model) — antrenează, fine-tune-ază sau distilează modele. Gestionează seturi de date, infrastructura de antrenament, suite-uri de evaluare. Lucrează în stack-ul tău de antrenament.
3. Inginer de infrastructură AI — administrează inferența, baza de date vector și stratul de observabilitate. Gestionează bugete de latență, utilizarea GPU-ului, pipelineuri de implementare. Lucrează în platforma ta.

Aceste trei roluri nu au nimic în comun în activitatea zilnică. O structură de interviu proiectată pentru un rol va evalua incorect celelalte două. Restul acestui ghid se concentrează pe inginerul AI aplicat, pentru că aceasta este ceea ce 80% din echipele care angajează „ingineri AI" în 2026 au nevoie de fapt.

Cei patru indicatori care de fapt prezic performanța la locul de muncă

După ce am auditat zeci de bucle de interviu pentru AI aplicat, patru indicatori separă constant inginerii care expediază caracteristici LLM funcționale de inginerii care expediază demo-uri care par plauzibile:

1. Disciplina iterației prompt-urilor. Pot transforma o cerință de produs vagă într-un prompt, o evaluare și o buclă de îmbunătățire măsurabilă?
2. Raționamentul modurilor de eșec. Presupun implicit că modelul va alucina, va scurge jetoane sau va alege instrumentul greșit — și proiectează în consecință?
3. Proiectarea evaluării. Pot proiecta o evaluare care surprinde regresia care îi pasă de fapt, nu doar scor BLEU?
4. Conștientizarea costurilor și latențelor. Raționează despre jetoane, cache-ing, selectarea modelului și forma batch-ului — sau recurg la GPT-5 pentru fiecare apel?

Niciunul dintre acestea nu este testabil cu o întrebare LeetCode. Toate patru necesită un format de interviu diferit.

Bucla cu patru ronde care funcționează

Ronda 1: Take-home asincron (90 de minute, plătit dacă cultura ta o susține)

Oferi candidatului un mic sistem RAG defect și o plângere reală de la client. Exemplu:

Chatbot-ul nostru de suport pentru clienți continuă să citeze cu încredere o caracteristică de produs care nu există. Iată repo-ul, prompt-ul, pipelineul de recuperare și trei exemple de eșec. Găsește cauza rădăcinii și propune o corectie pe care să o poți apăra.

Ce cauți:

• Citesc rezultatele recuperării înainte de a blama prompt-ul?
• Identifică că modelul de embedding este probabil greșit pentru acest domeniu?
• Propun o evaluare pentru a surprinde regresia data viitoare?
• Deosebesc „repararea simptomului" de „repararea sistemului"?

Un take-home este singurul format care îți oferă o lectură clară a disciplinei de debugging. Rundele de codare live sunt prea scurte și prea presante pentru a vedea dacă cineva citește de fapt datele. Împerechează-l cu o urmărire live pentru ca trimiteri generate de AI să nu scape.

Ronda 2: Sesiune live de prompt engineering (60 de minute)

Împerechează candidatul cu un intervievator și o sarcină reală: transformă o scurtă și vagă descriere a proiectului într-un prompt de lucru cu evaluări măsurabile, în timp real, în instrumentele tale actuale.

Subteme utile:

• Scrie prima versiune a prompt-ului.
• Scrie trei cazuri de evaluare — inclusiv una care ar trebui să eșueze.
• Iterează prompt-ul până trec evaluările.
• Discută ce ai măsura în producție dincolo de setul de evaluare.

Semnalul pe care îl cauți: gândesc în evaluări mai întâi, prompt-uri pe locul doi? Inginerii care au expediatat caracteristici LLM știu că prompt-ul este downstream de evaluare. Inginerii care au doar prototipat fac opusul.

O cameră de codare colaborativă cu Monaco + Yjs funcționează pentru aceasta — candidatul scrie prompt-uri și scaffolding de evaluare în timp real, iar intervievatorul poate interveni exact când contează.

Ronda 3: Proiectarea sistemului — dar făcută în stil AI (60 de minute)

Plasează candidatul într-o solicitare realistă de proiectare AI aplicat:

Proiectează un sumarizator de întâlniri orientat către clienți care preia o transcriere de 60 de minute și produce o listă de elemente de acțiune. Trebuie să ruleze în mai puțin de 30 de secunde, să coste mai puțin de $0.05 pe apel și să refuze să rezume conținut din afara domeniului tău de produs.

Aceasta este un interviu de proiectare de sistem cu constrângeri specifice AI. Evaluează-o cu aceleași dimensiuni — clarificare, compromisuri, moduri de eșec, cost — dar observă mutările specifice AI:

• Iau în considerare chunking-ul și map-reduce versus single-shot?
• Raționează despre selectarea modelului (model mai mic + prompt mai bun versus model mai mare)?
• Propun o protecție pentru conținut din afara domeniului (clasificator? prompt? evaluare de respingere)?
• Proiectează observabilitate pentru rata de alucinare, nu doar latență?

Candidații slabi revin implicit la „folosește GPT-5, prompt-ează-l, returnează răspunsul." Candidații buni petrec 10 minute pe bugetele de cost/latență înainte să deseneze măcar o cutie.

Ronda 4: Comportamental pe o caracteristică AI expediată (45 de minute)

O rundă comportamentală structurată ancorat pe o caracteristică specifică pe care au expediatat-o. Întrebările care funcționează:

• „Explică-mi suite-ul de evaluare pe care l-ai construit. Cum s-a schimbat în timp?"
• „Spune-mi despre o regresie care a ajuns în producție. Cum ai descoperit-o?"
• „Descrie un moment când ai folosit un model mai mic dacă un model mai mare ar fi fost mai ușor. De ce?"
• „Spune-mi despre o caracteristică unde LLM a fost instrumentul greșit. Ce ai expediatat în schimb?"

Ultima întrebare este cea cu cel mai înalt semnal din toată bucla. Inginerii care au folosit doar LLM-uri ca un ciocan nu pot răspunde. Inginerii care au expediatat produse reale de obicei îți pot spune despre trei.

Întrebări care par inteligente dar nu sunt

Apar constant în ghidurile de interviu pentru ingineri AI și sunt în principal zgomot:

• „Explică cum funcționează transformers-ii." Trivia. Fiecare candidat a citit același articol de blog. Nu îți spune nimic despre dacă pot expedia.
• „Care este diferența dintre RAG și fine-tuning?" Deja în fiecare set de antrenament. Folosește un model de urmărire în schimb: „spune-mi despre o dată când ai ales una peste cealaltă și de ce."
• „Scrie un transformer de la zero." Relevant doar pentru rolul ML inginer pe partea de model. Pentru AI aplicat, aceasta este semnal de fundal academic, nu abilitate de expediere.
• Whiteboard prompt-engineering („scrie un prompt care face X" fără evaluare și fără iterație). Dezbine de modul în care lucrează de fapt. Un prompt singur, fără o evaluare, este teatru.

Calibrarea pentru seniority

Aceeași buclă funcționează pentru toate nivelurile — ceea ce se schimbă este ce ponderezi.

Un inginer AI aplicat de nivel staff ar trebui evaluat în principal pe proiectare de sistem și comportament — la acel nivel, cumperi judecată, nu viteză de implementare. Un inginer de nivel mid ar trebui evaluat în principal pe take-home și sesiune de prompt — acolo se află valoarea lor. Vezi bucla interviului inginerului senior pentru descompunerea echivalentă pe roluri generale de inginerie.

Integritate, dar mai inteligent

Pentru roluri de AI aplicat în special, interzicerea asistenței AI în timpul interviului este incoherentă. Meseria este să folosești bine AI. Interviul ar trebui să reflecte asta.

Ceea ce recomandăm în schimb:

• Permite asistență AI deschis în take-home. Evaluează utilizarea de AI, nu prezența acesteia. Candidatul care folosește Claude pentru a explora baza de cod și apoi scrie o analiză de rădăcină a cauzei gândită este exact candidatul pe care îl vrei.
• Interzice AI în sesiunea de prompt live. Scopul este să-i vezi iterând. Folosește semnale tastatură și ecran pentru a surprinde utilizarea silențioasă a AI.
• Necesită o urmărire live pe fiecare take-home. Aceasta este interviul cu cel mai înalt semnal pe care majoritatea echipelor îl sare. Împerechează un pasaj de coerență LLM cu o plimbare live de 30 de minute.

Candidatul care poate apăra take-home-ul său timp de 30 de minute l-a scris. Cel care nu poate, nu a făcut-o — indiferent de ce spun semnalele tastaturii.

Ce să faci următor

Dacă setezi o buclă de inginerie AI aplicat de la zero:

1. Alege una dintre cele trei definiții de rol și scrie o descriere de post care se potrivește.
2. Construiește (sau refolosește) un take-home RAG defect. Iterează-l pe inginerii interni mai întâi.
3. Setează sesiunea de prompt live într-un editor colaborativ cu scaffolding de evaluare partajat.
4. Antrenează intervievatorii pe cei patru indicatori de mai sus înainte să ruleze o singură rundă.

Echipele care angajează bine ingineri AI în 2026 nu sunt echipele cu cele mai inteligente întrebări. Sunt echipele ale căror bucle reflectă munca reală — iterează, evaluează, debuguiază, expediază — și care evaluează judecata care necesită ani pentru a construi.