KI-Ingenieure erfolgreich interviewen (LLM-, RAG- und Prompt-Engineering-Rollen)

"KI-Ingenieur" - drei verschiedene Rollen in einem Kostüm

Bevor Sie das Interviewverfahren gestalten, klären Sie, welche dieser Rollen Sie eigentlich einstellen:

1. Applied-AI-Ingenieur - entwickelt Produktfeatures auf Basis von Foundation Models. Verantwortet Prompts, Evaluierungen, Retrieval, Latenz und Kosten. Arbeitet in Ihrer Anwendungscode-Basis.
2. ML-Ingenieur (modellseitig) - trainiert, fine-tuned oder destilliert Modelle. Verantwortet Datensätze, Training-Infrastruktur und Evaluierungssuites. Arbeitet in Ihrem Training-Stack.
3. KI-Infrastruktur-Ingenieur - verwaltet Inferenz, Vector DB und das Observability-Layer. Verantwortet Latenz-Budgets, GPU-Auslastung und Deployment-Pipelines. Arbeitet in Ihrer Plattform.

Diese drei Rollen haben keinen gemeinsamen Alltag. Ein für eine Rolle konzipiertes Interviewverfahren wird die anderen beiden schlecht evaluieren. Der Rest dieses Leitfadens konzentriert sich auf den Applied-AI-Ingenieur, weil das 2026 das ist, was 80% der Teams wirklich brauchen, die "KI-Ingenieure" einstellen.

Die vier Signale, die tatsächlich die Job-Performance vorhersagen

Nach der Auswertung von Dutzenden Applied-AI-Einstellungsprozessen trennen vier Signale konstant Ingenieure, die funktionierende LLM-Features ausliefern, von denen, die beeindruckend aussehende Demos bauen:

1. Disziplin bei der Prompt-Iteration. Können sie eine vage Produktanforderung in einen Prompt, eine Evaluierung und eine messbare Verbesserungsschleife umwandeln?
2. Fehlermodelle verstehen. Gehen sie automatisch davon aus, dass das Modell halluziniert, Token leckt oder das falsche Tool wählt - und entwickeln entsprechend?
3. Evaluierungsdesign. Können sie eine Evaluierung entwerfen, die die Regression erfasst, um die es ihnen wirklich geht, nicht nur BLEU-Scores?
4. Bewusstsein für Kosten und Latenz. Denken sie über Tokens, Caching, Modellwahl und Batch-Größe nach oder greifen sie reflexartig zu GPT-5?

Keine dieser Fähigkeiten ist mit einer LeetCode-Frage überprüfbar. Alle vier erfordern ein anderes Interviewformat.

Das Vier-Runden-Verfahren, das funktioniert

Runde 1: Asynchrone Take-Home-Aufgabe (90 Minuten, bezahlt wenn Ihre Kultur das ermöglicht)

Geben Sie dem Kandidaten ein kleines, fehlerhaftes RAG-System und eine echte Kundenbeschwerde. Beispiel:

Unser Customer-Support-Bot behauptet wiederholt zuversichtlich, dass ein Produktfeature existiert, das es gar nicht gibt. Hier ist das Repository, der Prompt, die Retrieval-Pipeline und drei Beispiele fehlgeschlagener Abfragen. Finden Sie die Grundursache und schlagen Sie eine Lösung vor, die Sie verteidigen können.

Worauf Sie achten:

• Lesen sie die Retrieval-Ergebnisse, bevor sie den Prompt beschuldigen?
• Erkennen sie, dass das Embedding-Modell wahrscheinlich nicht für diese Domäne geeignet ist?
• Schlagen sie eine Evaluierung vor, um diese Regression nächstes Mal zu vermeiden?
• Unterscheiden sie zwischen "Symptom beheben" und "System beheben"?

Eine Take-Home-Aufgabe ist das einzige Format, das Ihnen ein klares Bild der Debugging-Disziplin gibt. Live-Coding-Runden sind zu kurz und zu stressbelastet, um zu sehen, ob jemand die Daten wirklich analysiert. Kombinieren Sie sie mit einer Live-Nachbereitung, damit KI-generierte Einreichungen nicht durchschlüpfen.

Runde 2: Live Prompt-Engineering-Session (60 Minuten)

Kombinieren Sie den Kandidaten mit einem Interviewer und einer echten Aufgabe: Wandeln Sie eine vage Produktbeschreibung in einen funktionierenden Prompt mit messbaren Evaluierungen um, in Echtzeit, in Ihrem eigenen Werkzeug-Setup.

Nützliche Aufgaben:

• Schreiben Sie den ersten Prompt-Entwurf.
• Schreiben Sie drei Evaluierungsfälle - einschließlich eines, das fehlschlagen sollte.
• Iterieren Sie den Prompt bis die Evaluierungen bestanden sind.
• Diskutieren Sie, was sie in der Produktion über den Evaluierungssatz hinaus messen würden.

Das Signal, auf das Sie achten: Denken sie in Evaluierungen zuerst, Prompts zweiter? Ingenieure, die LLM-Features ausgeliefert haben, wissen, dass der Prompt von der Evaluierung abhängt. Ingenieure, die nur prototypisiert haben, machen es umgekehrt.

Ein kollaborativer Coding-Raum mit Monaco + Yjs funktioniert dafür hervorragend - der Kandidat schreibt Prompts und Evaluierungs-Gerüste in Echtzeit, und der Interviewer kann genau im richtigen Moment eingreifen.

Runde 3: Systemdesign - aber KI-spezifisch (60 Minuten)

Werfen Sie den Kandidaten in eine realistische Applied-AI-Design-Aufgabe:

Entwerfen Sie einen kundenseitigen Meeting-Zusammenfassungs-Service, der ein 60-Minuten-Transkript aufnimmt und eine Action-Item-Liste produziert. Er muss in unter 30 Sekunden laufen, unter 0,05 USD pro Aufruf kosten und sich weigern, Inhalte außerhalb Ihrer Produktdomäne zusammenzufassen.

Dies ist ein System-Design-Interview mit KI-spezifischen Constraints. Bewerten Sie es mit den gleichen Dimensionen - Klärung, Tradeoffs, Fehlerszenarien, Kosten - aber achten Sie auf die KI-spezifischen Züge:

• Überlegen sie, ob Chunking und Map-Reduce besser sind als Single-Shot?
• Denken sie über Modellwahl nach (kleineres Modell + besserer Prompt vs. größeres Modell)?
• Schlagen sie einen Guardrail für Off-Domain-Inhalte vor (Klassifizierer? Prompt? Rejection-Eval)?
• Entwerfen sie Observability für Halluzinations-Rate, nicht nur für Latenz?

Schwache Kandidaten sagen automatisch "nutze GPT-5, frag es, gib die Antwort zurück." Gute Kandidaten verwenden 10 Minuten für das Kosten-/Latenz-Budget, bevor sie eine Schachtel zeichnen.

Runde 4: Verhaltensfragen zu einem ausgelieferten KI-Feature (45 Minuten)

Ein strukturiertes Verhaltensinterview verankert in einem spezifischen Feature, das sie ausgeliefert haben. Fragen, die funktionieren:

• "Führen Sie mich durch die Evaluierungs-Suite, die Sie gebaut haben. Wie hat sie sich im Laufe der Zeit verändert?"
• "Erzählen Sie mir von einer Regression, die in die Produktion ging. Wie haben Sie sie gefunden?"
• "Beschreiben Sie eine Zeit, in der Sie ein kleineres Modell verwendet haben, wo ein größeres einfacher gewesen wäre. Warum?"
• "Erzählen Sie von einem Feature, bei dem das LLM das falsche Werkzeug war. Was haben Sie stattdessen ausgeliefert?"

Diese letzte Frage ist die mit dem höchsten Signal im gesamten Verfahren. Ingenieure, die LLMs nur als Hammer verwendet haben, können sie nicht beantworten. Ingenieure, die echte Produkte ausgeliefert haben, können Ihnen normalerweise von drei berichten.

Fragen, die intelligenty klingen, aber es nicht sind

Diese tauchen ständig in KI-Ingenieur-Interview-Leitfäden auf und sind meist Rauschen:

• "Erklär mir, wie Transformer funktionieren." Trivial. Jeder Kandidat hat denselben Blog-Post gelesen. Sagt nichts darüber, ob sie etwas ausliefern können.
• "Was ist der Unterschied zwischen RAG und Fine-Tuning?" Bereits in jedem Trainingsdatensatz. Verwenden Sie stattdessen ein Folgefrage-Muster: "Erzählen Sie mir von einer Zeit, in der Sie sich für eins entschieden haben und warum."
• "Schreibe einen Transformer von Grund auf." Nur relevant für die modellseitige ML-Ingenieur-Rolle. Für Applied AI ist das ein Zeichen akademischen Hintergrunds, nicht der Fähigkeit, Produkte auszuliefern.
• Whiteboard Prompt-Engineering ("schreib einen Prompt, der X macht" ohne Evaluierung und ohne Iteration). Abgelöst von der Realität der Arbeit. Ein Prompt in Isolation, ohne Evaluierung, ist Theater.

Kalibrierung nach Senioritätsstufe

Das gleiche Verfahren funktioniert auf allen Levels - was sich ändert, ist die Gewichtung.

Ein Staff Applied-AI-Ingenieur sollte hauptsächlich anhand von Systemdesign und Verhalten evaluiert werden - auf dieser Stufe kaufen Sie Urteilsfähigkeit, nicht Implementierungsgeschwindigkeit. Ein Mid-Level-Ingenieur sollte hauptsächlich auf Take-Home und Prompt-Session evaluiert werden - dort liegt sein Wert. Siehe Interviewschleife für Senior Engineers für die entsprechende Aufschlüsselung bei allgemeinen Engineering-Rollen.

Integrität, aber intelligenter

Für Applied-AI-Rollen ist es speziell inkoherent, KI-Unterstützung während des Interviews zu verbieten. Der Job besteht darin, KI gut zu nutzen. Das Interview sollte das abbilden.

Was wir stattdessen empfehlen:

• Erlauben Sie KI-Unterstützung offen in der Take-Home-Aufgabe. Bewerten Sie die Nutzung von KI, nicht ihre Anwesenheit. Der Kandidat, der Claude nutzt, um die Codebase zu erkunden, und dann eine durchdachte Analyse der Grundursache schreibt, ist genau der Kandidat, den Sie wollen.
• Verbieten Sie KI in der Live Prompt-Session. Der Punkt ist, sie iterieren zu sehen. Verwenden Sie Tastatur- und Screen-Signale, um stille KI-Nutzung zu erkennen.
• Verlangen Sie eine Live-Nachbereitung bei jeder Take-Home-Aufgabe. Dies ist das einzelne Signal-stärkste Interview, das die meisten Teams auslassen. Verbinden Sie einen LLM-Kohärenz-Pass mit einer 30-minütigen Live-Durchbesprechung.

Der Kandidat, der seine Take-Home-Aufgabe 30 Minuten lang verteidigen kann, hat sie geschrieben. Der, der es nicht kann, hat es nicht - unabhängig davon, was die Tastatur-Signale sagen.

Was Sie jetzt tun sollten

Wenn Sie ein Applied-AI-Engineering-Interviewverfahren von Grund auf aufbauen:

1. Wählen Sie eine der drei Rollendefinitionen und schreiben Sie eine entsprechende Stellenausschreibung.
2. Bauen Sie (oder verwenden Sie) eine fehlerhafte RAG-Take-Home-Aufgabe. Testen Sie sie zunächst mit internen Ingenieuren.
3. Richten Sie die Live Prompt-Session in einem kollaborativen Editor mit gemeinsamen Evaluierungs-Gerüsten ein.
4. Schulen Sie Interviewer in den vier oben genannten Signalen, bevor sie eine einzige Runde durchführen.

Die Teams, die KI-Ingenieure 2026 gut einstellen, sind nicht die Teams mit den cleverstenen Fragen. Es sind die Teams, deren Verfahren die echte Arbeit widerspiegeln - iterieren, evaluieren, debuggen, ausliefern - und die nach der Urteilsfähigkeit bewerten, die Jahre braucht, um sich zu entwickeln.