So interviewen Sie LLM-Applikationsingenieure (keine ML-Ingenieure)

Die Rolle, die Sie tatsächlich besetzen

„LLM-Ingenieur" oder „KI-Applikationsingenieur" ist eine Rolle, die vor drei Jahren kaum existierte und heute in jedem Produktteam zu finden ist. Sie ist nicht dasselbe wie Machine-Learning-Ingenieur. Die Fähigkeiten überlappen sich vielleicht zu 30 %.

Ein Machine-Learning-Ingenieur trainiert und deployed Modelle. Ein LLM-Applikationsingenieur nimmt vortrainierte Modelle und verwandelt sie in Produktfunktionen: Prompt-Design, Evaluierungsrahmen, Abrufpipelines, Werkzeug-Scaffolding, Latenz- und Kostenoptimierung, elegantes Fehlschlagen, wenn das Modell vom Plan abweicht. Die erfahrensten verlieren ihre Zeit mit der langweiligen Hälfte der Arbeit – Evaluierungen, Observability, Guardrails – nicht mit cleveren Prompts.

Wenn Sie diese Kandidaten mit dem ML-Ingenieur-Interview-Kit bewerten, stellen Sie Forscher ein, die nicht deployen können, und lehnen Entwickler ab, die noch nie ein Modell trainiert haben. Wenn Sie sie mit dem generischen Software-Ingenieur-Kit bewerten, verpassen Sie die gesamte KI-spezifische Fähigkeitsfläche.

Fünf Kompetenzen, die getestet werden sollten

Der Job zerlegt sich in fünf testbare Bereiche. Die meisten Interview-Runden können vier von fünf in drei Stunden Kandidatenzeit abdecken.

1. Prompt-Design und Iteration. Können sie einen Prompt schreiben, der zuverlässig strukturierte Ausgaben produziert, und können sie iterieren, wenn nicht?
2. Evaluierungsdenken. Können sie eine Evaluierung entwerfen, die eine Regression erfasst, die ein Bauchgefühl-Check verpassen würde?
3. Fehlermodus-Analyse. Wenn das Modell Müll zurückgibt – haben sie ein Modell warum und einen Plan zur Behebung?
4. Systemintegration. Können sie das Modell in eine echte Produktoberfläche integrieren – Abruf, Werkzeugaufrufe, Streaming, Wiederholungen, Caching – ohne dass es in der Produktion zusammenbricht?
5. Kosten- und Latenz-Bewusstsein. Wissen sie, was ihre Entscheidungen kosten? Wissen sie, was eine 30-sekündige Wartezeit für Benutzervertrauen bedeutet?

Kognitives Denken und allgemeine Softwareentwicklung sind immer noch wichtig. Behandeln Sie sie als Voraussetzung, nicht als Fokus der LLM-spezifischen Runden.

Eine vierstufige Interview-Runde, die funktioniert

Dies ist die Interview-Runde, die wir für eine mittlere bis Senior-Rolle im LLM-Bereich empfehlen.

Stufe 1: Asynchrone Prompt-Engineering-Arbeitsprobe (90 Minuten)

Geben Sie dem Kandidaten einen kleinen Datensatz – 30 bis 50 Input-Output-Paare, die eine realistische Produktaufgabe darstellen. Beispiele: strukturierte Felder aus Support-E-Mails extrahieren, ein Support-Ticket in eine von sieben Kategorien mit einem Konfidenz-Score klassifizieren, eine personalisierte E-Mail-Zusammenfassung aus einem Kundenevent-Log generieren.

Ihre Aufgabe: einen Prompt (oder eine kurze Prompt-und-Code-Pipeline) schreiben, der die gewünschte Ausgabe auf dem Datensatz produziert, plus eine einseitige Notiz darüber, wo es noch fehlschlägt und warum.

Erlauben Sie alle KI-Tools. Dies ist eine Policy-B-Runde – siehe unseren Leitfaden zur KI-Nutzungsrichtlinie für die exakte Formulierung. Die Fähigkeit, die Sie messen, ist wie sie die Tools nutzen, um mit den Tools zu bauen, nicht ob sie es ohne Hilfsmittel können.

Bewerten Sie nach:

• Zuverlässigkeit der Ausgabe im gesamten Datensatz
• Qualität der Fehlermodus-Analyse (die Notiz ist aussagekräftiger als der Prompt selbst)
• Ob sie Evaluierungen genutzt haben oder nur die Ergebnisse überprüft haben

Stufe 2: Live-Evaluierungsdesign (45 Minuten)

Zeigen Sie ihnen den Prompt aus Stufe 1 und eine absichtlich fehlerhafte Version davon. Bitten Sie sie, eine Evaluierung zu entwerfen, die die Regression erfasst – nicht nur mündlich, sondern durch Schreiben des Eval-Test-Codes in einem echten Editor.

Dies ist die aussagekräftigste Runde in der Interview-Runde. Starke Kandidaten werden:

• Die Stile exact-match, semantische Ähnlichkeit und Rubrik-bewertete Evaluierung unterscheiden und die richtige für die Aufgabe wählen
• Unterschiedliche positive Fälle, Grenzfälle und gegnerische Fälle einbauen
• Darüber sprechen, wie die Evaluierungs-Suite in CI ausgeführt wird, welcher Fehlerschwelle setzt und wie sie ihn über die Zeit aktualisieren

Schwache Kandidaten werden drei Assertions schreiben, die den Happy Path testen und fertig nennen.

Führen Sie dies in einem kollaborativen Code-Editor aus, damit Sie den Gedankenprozess des Kandidaten Anschlag für Anschlag beobachten können. Die Pausen sagen viel aus.

Stufe 3: Systemdesign – Bauen mit dem Modell (60 Minuten)

Geben Sie ihnen ein Produkt-Brief: „Entwerfen Sie das Backend für eine Funktion, die einem Sales Rep erlaubt, die letzten 90 Tage von Support-Tickets eines Kunden einzufügen und eine einseitige ‚sollten wir uns um Abwanderung kümmern' Analyse zu bekommen, die sie mit dem Account Manager teilen können."

Fragen Sie nach:

• Wie sie den Prompt strukturieren würden (System, Nutzer, Werkzeugaufrufe?)
• Wie sie das Kosten- und Latenz-Profil handhaben würden (synchron? asynchron mit Webhook? gestreamt?)
• Wie sie es testen würden (goldene Beispiele, A/B gegen eine Baseline, Mensch-in-der-Schleife?)
• Wie sie eine Regression nach dem nächsten Modell-Upgrade erfassen würden
• Was sie tun würden, wenn das Modell einen bestimmten Kontonamen halluziniert

Das Artefakt ist das Gespräch, nicht ein Diagramm. Siehe unseren Systemdesign-Rubrik für Bewertungsleitfaden.

Stufe 4: Durchgang plus strukturierte verhaltensorientierte Fragen (45 Minuten)

Eine einzelne Runde, aufgeteilt in zwei Hälften. Zuerst 25 Minuten Durchgang der Stufe-1-Arbeitsprobe mit der Nachfrage-Frage-Vorlage. Dann 20 Minuten strukturierte verhaltensorientierte Fragen zu Zusammenarbeit mit nicht-technischen Stakeholdern – Produkt, Design, Support – da die meisten Fehlermodi bei LLM-Funktionen von Menschen gefunden werden, die keinen Code schreiben.

Fragemuster, die echtes Signal produzieren

Drei Muster, die es wert sind, für jede LLM-Applikationsingenieur-Runde geklaut zu werden.

„Zeige mir einen Prompt, den du geschrieben hast und der in der Produktion fehlgeschlagen ist. Was hast du geändert?" Dies ist die beste Frage im Kit. Starke Kandidaten haben spezifische Geschichten mit spezifischen Fixes. Schwache Kandidaten sprechen abstrakt über Prompting.

„Was ist das günstigste Modell, das du für diese Funktion verwenden könntest? Warum verwendest du es nicht?" Testet Kostenbewusstsein und zwingt sie, den Qualitäts-Kosten-Tradeoff zu artikulieren, den sie implizit gewählt haben. Die Antwort „Ich greife immer zum größten Modell" ist bei jeder Erfahrungsstufe besorgniserregend.

„Wie weißt du, dass dein Prompt besser ist als die vorherige Version?" Testet, ob sie tatsächlich Evaluierungen ausführen oder nur auf Bauchgefühl vertrauen. Ein überraschend hoher Anteil von Kandidaten hat LLM-Funktionen deployed, ohne jemals die Qualität gemessen zu haben.

Was nicht funktioniert

Ein paar Ansätze, die wir Teams versuchen und aufgeben sahen.

• LeetCode-Style-Algorithmus-Interviews. Fast keine LLM-Applikationsarbeit ist algorithmisch. Das Signal, das Sie bekommen, ist unkorreliert mit dem Job. Siehe Entwickler ohne LeetCode prüfen für das breitere Argument.
• „Baue einen Chatbot von Grund auf in 90 Minuten." Testet schnelles Tippen, nicht Engineering. Die interessanten Entscheidungen befinden sich in Evaluierungsdesign und Fehlerbehandlung, nicht im Verdrahten eines API-Aufrufs.
• Prompt-Trivia-Screens. „Was ist Temperatur?" testet Vokabular, nicht Urteil. Testen Sie das Urteil direkt.
• Mathe-Whiteboards über Transformer-Interna. Nützlich, wenn Sie einen Modell-Forscher einstellen. Irrelevant für jemanden, der seine Woche mit Abrufpipelines und Evaluierungs-Suites verbringt.

Die Integritätsfrage für eine KI-nutzende Rolle

Dies ist die Rücksprech-Frage, die jedes Team trifft: Wenn dem Kandidaten erlaubt ist, Claude oder ChatGPT während der Arbeitsprobe zu verwenden, was hindert ihn daran, das Modell einfach die Arbeit machen zu lassen?

Drei Dinge, in Kombination:

1. Der Stufe-4-Durchgang. Ein Kandidat, der seinen eigenen Prompt, seine Evaluierung oder sein Systemdesign nicht verteidigen kann, hat die Arbeit nicht wirklich getan – unabhängig davon, was das Artefakt sagt.
2. Die Stufe-2-Live-Evaluierungsdesign. Diese Runde läuft in einem beaufsichtigten Editor ohne Chat-Tools, in 45 Minuten. Es ist schwer zu fälschen.
3. Code-Kohärenz-Analyse bei der Stufe-1-Abgabe. KI-generierter Code hat strukturelle Indikatoren, auch wenn der Kandidat KI auch zur Verschleierung nutzten.

Der Punkt ist nicht, sie rot-handed zu erwischen. Es ist, sicherzustellen, dass jede Kandidaten-Punktzahl widerspiegelt, was sie in einer echten Engineering-Woche, mit den Tools, die sie tatsächlich verwenden werden, tun können.

Was Sie als Nächstes tun sollten

Wenn Sie LLM-Einstellung dieses Quartal aufbauen, ist der höchste Leverage-Punkt, die Senior-Backend-Engineer-Runde nicht wiederzuverwenden. Wählen Sie drei der fünf Kompetenzen oben für Ihre erste Version der Rubrik, schreiben Sie eine Arbeitsprobe und eine Evaluierungs-Design-Übung, und führen Sie sie an zwei internen Ingenieuren durch, um zu kalibrieren.

Führen Sie dann an fünf externen Kandidaten durch. Beim dritten Kandidaten werden Sie bereits wissen, ob die Runde schärfer ist als das, was Sie davor hatten. Die Rollen ändern sich. Die Disziplin – wählen Sie Methoden, die echtes Signal produzieren, dann verifizieren Sie, dass das Signal vom Kandidaten stammt – nicht.