Unternehmen stellen einen „AI Forward Deployed Engineer“ (FDE) ein, wenn sie jemanden benötigen, der ein komplexes, unstrukturiertes Kundenproblem schnell in eine funktionierende Produktlösung überführen kann – ohne dabei Vertrauen, Sicherheit oder Zeitpläne zu gefährden. Ein Forward Deployed Engineer (FDE) ist ein Ingenieur, der direkt mit Kunden zusammenarbeitet, um Lösungen in deren Systemumgebung bereitzustellen, und die dabei gewonnenen Erkenntnisse anschließend an das Produktteam zurückspielt.
Stellen Sie sich folgendes Szenario vor: Sie bewerben sich auf eine AI-FDE-Stelle, und der Gesprächspartner kommt immer wieder auf ein bestimmtes Projekt zurück – etwa ein Support-Team, das mithilfe eines KI-Assistenten Fragen zu Richtlinien auf Basis interner Dokumente beantworten möchte. Der eigentliche Test besteht nicht darin, ob Sie einen bestimmten Trick bei der Modellnutzung kennen. Es geht vielmehr darum, ob Sie die Aufgabe auch an Tag 30 bewältigen können: wenn die Datenlage chaotisch ist, das Sicherheitsteam Bedenken hat und der Stakeholder bereits in der nächsten Woche eine produktive Lösung erwartet.
In den meisten Auswahlverfahren definiert sich „Erfolg“ bis zum 90. Tag über eine überschaubare Anzahl konkreter Ergebnisse: eine erste funktionierende Integration in die Systemlandschaft des Kunden, messbare Qualitätsstandards sowie einen klaren Plan, welche Funktionen als Nächstes bereitgestellt werden und welche noch eine Weiterentwicklung des Produkts erfordern. Das Vorstellungsgespräch soll Aufschluss darüber geben, ob Sie dieses Ziel erreichen können, ohne unrealistische Versprechungen zu machen.
Entdecken Sie das Kompetenzprofil, das Unternehmen dabei häufig im Sinn haben.
Der Hauptgrund für die Einstellung ist die Risikominimierung. Ein KI-Projekt kann auf unauffällige Weise scheitern – etwa durch falsche Antworten, die überzeugend wirken, oder durch eine Integration, die zwar in der Demo funktioniert, aber im Produktivbetrieb versagt. Von einem AI FDE wird erwartet, dass er solche Risiken frühzeitig aufdeckt und in Entscheidungen überführt, die vom Kunden mitgetragen werden.
Nehmen wir das Beispiel eines Support-Assistenten: Die erste Anforderung des Kunden lautet: „Nutzen Sie unsere Dokumentation und beantworten Sie Fragen wie ein Mensch.“ Ihre Aufgabe ist es, dies in etwas Umsetzbares zu übersetzen, etwa: „Antworten Sie auf der Basis von Textausschnitten aus freigegebenen Quellen, geben Sie die Quellen an und verweigern Sie die Antwort, wenn die Richtlinien unklar sind.“ Bei der Retrieval-Augmented Generation (RAG) werden durch eine Suche in einem Dokumentenbestand relevante Textpassagen abgerufen und dem Modell zur Verfügung gestellt, sodass die Antworten auf den gefundenen Informationen basieren.
Zum Erfolg nach 90 Tagen gehören auch gute Kommunikationsgewohnheiten. Sie pflegen einen engen Austausch mit dem Kunden, halten Annahmen schriftlich fest und legen Kompromisse (Trade-offs) verständlich dar. Wenn das Modell eine falsche Antwort liefert, behandeln Sie dies wie einen Vorfall mit einer konkreten Ursache und nicht als vages Problem des „Gesamteindrucks“.
Liefern Sie Ergebnisse, keine Demos Gesucht werden Personen, die Unsicherheit in einen konkreten Plan und schließlich in eine funktionierende Lösung für die Kundenumgebung verwandeln können.
Die meisten Interviewprozesse für AI FDEs kombinieren Fragen zu technischer Umsetzung, analytischem Denkvermögen und der Zusammenarbeit mit Menschen unter Zeitdruck. Dasselbe Szenario – etwa der Support-Assistent – kann in jeder Phase auftauchen, jedoch jeweils aus einem anderen Blickwinkel betrachtet.
In einer Phase zur Problemdefinition (Framing) wird Ihre Fähigkeit zur Anforderungsermittlung (Discovery) geprüft. Discovery bezeichnet die erste Phase von Gesprächen und Informationsbeschaffung, in der eine vage Anfrage in klare Anforderungen und Rahmenbedingungen überführt wird. Eine überzeugende Antwort lautet etwa: „Wer wird das Tool nutzen? Was gilt als korrekte Antwort? Welche Daten sind zulässig? Und wie reagiert das Modell, wenn es sich unsicher ist?“
In einer Phase zum Systemdesign werden Entscheidungen zur Architektur und zum Umgang mit Fehlern geprüft. Für den Assistenten bedeutet das: Festlegen, wo RAG ausgeführt wird, wie Embeddings gespeichert werden, wie die Zugriffssteuerung erfolgt und was protokolliert wird. Single Sign-On (SSO) ermöglicht die Anmeldung über ein zentrales Identitätssystem, sodass ein einziger Login für mehrere Anwendungen genügt; Interviewer achten hier oft darauf, ob Sie berücksichtigen, dass der Dokumentenzugriff mit der Identität des Nutzers übereinstimmen muss.
In einer Programmierphase (Coding Round) stehen meist die Integration verschiedener Komponenten sowie die Korrektheit des Codes unter Zeitdruck im Vordergrund. Mögliche Aufgaben sind die Implementierung eines Retrieval-Aufrufs, einer Prompt-Vorlage, eines Antwortschemas oder eines Test-Frameworks zur Evaluierung. Die Falle besteht darin, Code zu schreiben, der zwar im Idealfall („Happy Path“) funktioniert, aber Timeouts, Wiederholungsversuche und fehlerhafte Eingaben ignoriert.
In einer Fallstudie werden all diese Aspekte kombiniert, um Ihr Urteilsvermögen zu prüfen. Ein Proof of Concept (POC) ist ein kleines Experiment, das die Machbarkeit belegen soll – es handelt sich dabei nicht um einen Produktivstart. Die Interviewer werden gezielt nachfragen, welche Schritte Sie im Rahmen eines POC unternehmen und welche Sie zurückstellen würden, sowie wie Sie den Mehrwert anhand einer einfachen Kennzahl nachweisen.
Bei verhaltensbezogenen Szenarien und Situationen mit Stakeholdern wird geprüft, ob Sie Grenzen wahren können. Sie werden mit Aussagen konfrontiert wie „Der Vertrieb hat das für in zwei Wochen zugesagt“ oder „Die Sicherheitsabteilung untersagt, dass Daten die VPC verlassen“; darauf müssen Sie mit der Aufzeigung von Optionen und Konsequenzen reagieren, anstatt Schuldzuweisungen zu machen.
Hier sehen Sie, wie sich ein typischer Interview-Zyklus nach Runden und Bewertungskriterien aufschlüsselt.