Fragen im Vorstellungsgespräch für AI Engineer (2026)
Die Rolle des AI Engineers ist neuer und weniger standardisiert als Software oder Data Science, weshalb Interviews stark variieren — aber ein Prozess von 2026 prüft meist LLM-Grundlagen, Retrieval-Augmented Generation (RAG), Prompt- und Context-Engineering, Evaluation, und die ingenieurstechnische Arbeit, KI-Features zuverlässig zu liefern. Viele Prozesse behalten auch eine klassische Coding-Runde, also vernachlässige Datenstrukturen nicht.
Interviewer suchen jemanden, der sowohl die Modelle als auch das Engineering darum versteht: wie Transformer und Attention konzeptionell funktionieren, wie man ein Modell mit Retrieval erdet, wie man nicht-deterministische Systeme evaluiert, und wie man Latenz und Kosten in Produktion kontrolliert. Vages Reden von 'wir rufen einfach die API auf' ist ein schneller Weg zum Scheitern.
Da sich das Feld schnell bewegt, zählt mehr, dass du aus ersten Prinzipien argumentierst — und dass du lieferst und misst, nicht nur prototypst — als gestrige Benchmark-Zahlen zu rezitieren.
Fragen im Vorstellungsgespräch für AI Engineer und wie man sie beantwortet
1. Erkläre, wie Attention in einem Transformer auf hohem Niveau funktioniert.
Ansatz: Beschreibe Query/Key/Value, Scaled-Dot-Product-Attention, und warum Self-Attention jedem Token erlaubt, jedem anderen Token Aufmerksamkeit zu schenken — und damit Langzeitabhängigkeiten erfasst, mit denen RNNs kämpfen. Erwähne die Rolle von Multi-Head-Attention und die quadratischen Kosten.
2. Wie würdest du ein RAG-System für eine Unternehmenswissensdatenbank entwerfen?
Ansatz: Gehe die Pipeline durch: Chunking-Strategie, Wahl des Embedding-Modells, ein Vector Store, Retrieval (top-k, hybrid mit Keyword), Reranking, und Prompt-Zusammenstellung. Besprich Chunk-Overlap, Auffrischung veralteter Daten, und die Zitierung von Quellen.
3. Wie reduzierst du Hallucinations in einer LLM-Anwendung?
Ansatz: Erde mit Retrieval, schränke mit strukturierten Outputs ein, senke die Temperatur für faktische Aufgaben, füge Zitationspflichten hinzu, und verifiziere mit einem zweiten Durchgang oder Regeln. Betone Evaluation: du kannst nicht reduzieren, was du nicht misst.
4. Wie würdest du ein nicht-deterministisches LLM-Feature evaluieren?
Ansatz: Baue ein gelabeltes Eval-Set, nutze rubrik-basiertes oder LLM-as-Judge-Scoring, verfolge Regression bei Prompt-/Modelländerungen, und kombiniere Offline-Evals mit Online-Metriken. Erwähne Kosten und Bias-Vorbehalte bei LLM-as-Judge.
5. Wann würdest du Fine-Tuning statt RAG statt Prompt Engineering einsetzen?
Ansatz: Prompt Engineering zuerst (am günstigsten, am schnellsten). RAG für Wissen/Aktualität. Fine-Tuning für Verhalten, Format, oder Domänenstil, den Prompting nicht verlässlich erreicht. Oft eine Kombination; begründe über Kosten, Latenz und Wartbarkeit.
6. Wie kontrollierst du Latenz und Kosten in einem LLM-Produkt?
Ansatz: Modellauswahl nach Aufgabe (kleine Modelle für einfache Turns), Prompt-/Context-Trimming, Caching, Streaming für gefühlte Latenz, Batching, und Routing. Quantifiziere: kleinerer Context und ein günstigeres Modell können Kosten um eine Größenordnung senken.
7. Was sind die Trade-offs, ein Modell lokal statt über eine Cloud-API laufen zu lassen?
Ansatz: Lokal: Privatsphäre, keine Pro-Token-Kosten, offline, aber begrenzt durch Hardware und Modellgröße. Cloud: Top-Modelle und Skalierbarkeit, aber Kosten, Latenz, und Daten, die dein Gerät verlassen. Verbinde mit dem Use Case — genau der Trade-off, auf dem Natively aufbaut.
8. Wie würdest du ein Embedding-Modell für Retrieval auswählen?
Ansatz: Passe Domäne und Sprache an, prüfe MTEB-artige Benchmarks, wäge Dimensionsgröße gegen Speicher/Latenz ab, und validiere mit DEINEN Daten durch einen Retrieval-Eval. Vertraue keinem Leaderboard mehr als einem domänenspezifischen Test.
9. Implementiere eine einfache semantische Suche über eine Menge von Dokumenten.
Ansatz: Embedde Dokumente und die Query, speichere Vektoren, berechne Kosinus-Ähnlichkeit (oder nutze einen Vektorindex wie sqlite-vec/FAISS), gib die Top-k zurück. Besprich Normalisierung und den Geschwindigkeits-/Genauigkeits-Trade-off bei approximativer Nearest-Neighbor-Suche.
10. Erzähl mir von einem KI-Feature, das du geliefert hast, und wie du seinen Erfolg gemessen hast.
Ansatz: STAR. Betone die Eval-Methodik und die Produktionsmetrik, nicht nur die Demo. Gesucht werden AI Engineers, die liefern und messen — statt endlos zu prototypen.
Erhalte in Echtzeit Hilfe in deinem Vorstellungsgespräch als AI Engineer
Natively ist selbst eine local-first-KI-Anwendung — On-Device-LLMs, lokales RAG mit sqlite-vec, und eine Bring-your-own-key-Architektur. In einem Live-AI-Engineering-Interview kann es die Frage transkribieren und eine präzise Definition oder einen Trade-off in Echtzeit auf deinem Gerät anzeigen.
