Interviewfragen für MLOps Engineers, mit ausgearbeiteten Antworten

So nutzt du diese Fragen

Die meisten MLOps-Interviews haben eine Designrunde: Hier ist ein Modell, das ein Data Scientist trainiert hat, bring es in Produktion. Geh Daten, Training, Registry, Release, Serving und Monitoring durch und sag, wo es zuerst brechen würde. Erzähl dann von einem Modell, das du am Laufen gehalten hast, und der schlimmsten Überraschung, die es dir bereitet hat.

Was ein MLOps Engineer können muss

• Die Praxis: MLOpsDen ganzen Lebenslauf eines Modells in Produktion betreiben: bauen, testen, ausrollen, beobachten und neu trainieren, mit so wenig Handarbeit wie möglich., CI/CDModelle und Pipelines durch dieselben automatischen Prüfungen testen und ausrollen wie andere Software. für Modelle und Daten, ContainerEin Modell und seine Abhängigkeiten in ein Image packen, das auf dem Laptop genauso läuft wie in Produktion. und KubernetesTrainingsjobs und Modell-Services auf Kubernetes betreiben, mit sinnvollen Limits, Skalierung und Health Checks..
• Das Leben eines Modells: Experiment-Tracking und eine Model RegistryExperimente tracken und Modelle in MLflow registrieren, mit den Parametern, Daten und Metriken, die jedes erklären., Model ServingModelle im Batch oder in Echtzeit bereitstellen, innerhalb der Latenz und der Kosten, die das Produkt tragen kann. und Model MonitoringEingaben, Ausgaben und Qualität eines Live-Modells beobachten und Alarm schlagen, wenn sie sich verschieben..
• Die Daten: Pipelines in Werkzeugen wie AirflowDaten- und Trainings-Pipelines planen und überwachen, mit Wiederholungen und Alarmen, die Sinn ergeben., Versionierung von Daten und in größeren Teams Feature StoresWissen, wann ein Feature Store einem Team hilft, Features wiederzuverwenden und Training und Betrieb im Gleichschritt zu halten..
• Die Menschen: Data Scientists, Data Engineers, Produktteams und die Seite von Sicherheit und Recht.

Die Plattformen kommen gleichrangig nebeneinander vor, und keine ist Pflicht: MLflow für Tracking und Registry; Kubeflow auf jedem Kubernetes; SageMaker, Vertex AI und Azure ML als verwaltete ML-PlattformenEine verwaltete ML-Plattform wie SageMaker, Vertex AI oder Azure ML oder Kubeflow nutzen und wissen, was sie dir abnimmt. in ihrer jeweiligen Cloud. Die Interviewer wollen hören, warum eine Wahl zu einem Team passt, nicht Treue zu einem Namen.

Vom Notebook in Produktion

Wie sieht eine ML-Pipeline aus, von den Rohdaten bis zum Modell in Produktion?

Worauf sie achten: das ganze Leben eines Modells, nicht ein einzelnes Werkzeug.

Kurze Antwort: „Die Daten werden geholt und geprüft, Features werden gebaut, das Modell wird trainiert und an einem festen Testdatensatz und am aktuellen Modell gemessen, und nur ein Modell, das besteht, wird registriert. Das Release nimmt die registrierte Version, rollt sie vorsichtig aus und beobachtet sie. Jeder Schritt ist Code, läuft automatisch und hinterlässt einen Eintrag.“

Die ausführliche Antwort: Eine Pipeline, die nur funktioniert, wenn ihr Autor sie startet, ist noch keine Pipeline.

Schwache Antwort: „Der Data Scientist trainiert es, und wir kopieren die Datei auf den Server.“ Nachfrage: „Das Modell in Produktion gibt andere Antworten als im Notebook.“ Sag, wo du nachschaust.

Wie würdest du Experiment-Tracking und eine Model Registry für ein Team von Data Scientists aufsetzen?

Worauf sie achten: Nachvollziehbarkeit, die die Leute wirklich nutzen.

Kurze Antwort: „Experiment-Tracking heißt, jeden Trainingslauf mit seiner Codeversion, den Daten, Parametern und Metriken zu protokollieren, damit sich Läufe später vergleichen lassen. Eine Model Registry ist der Katalog der trainierten Modelle mit ihren Versionen und Stufen, vom Kandidaten bis zur Produktion. Ich würde ein Werkzeug wählen, etwa MLflow, das Protokollieren für die Data Scientists zu einer Zeile machen und nur registrierte Modelle ausrollen lassen.“

Die ausführliche Antwort: Kostet das Protokollieren Mühe, lassen es die Leute weg, und die Registry füllt sich mit Lücken.

Schwache Antwort: „Jeder hält seine Ergebnisse in einer Tabelle fest.“ Nachfrage: „Ein Prüfer fragt, mit welchen Daten das Modell trainiert wurde, das im letzten März einen Kunden bewertet hat.“ Sag, wie du antwortest.

Wie machst du einen Trainingslauf auch Monate später reproduzierbar?

Worauf sie achten: Disziplin bei Versionen.

Kurze Antwort: „Ich lege die Codeversion fest, die Bibliotheken in einem Container-Image, die Zufalls-Seeds und, am schwersten, die Daten: Versionierung von Daten heißt, einen Snapshot oder einen Verweis auf genau die Daten zu speichern, die ein Lauf genutzt hat. Der Eintrag des Laufs verknüpft all das. Dann ergibt ein Neuaufbau dasselbe Modell oder erklärt zumindest, warum nicht.“

Die ausführliche Antwort: Die meisten gescheiterten Reproduktionen kommen von Daten, die sich unter demselben Namen geändert haben.

Schwache Antwort: „Wir lassen das Notebook einfach noch einmal laufen.“ Nachfrage: „Die Quelltabelle wurde letzte Woche überschrieben.“ Sag, was du gebraucht hättest.

Wann braucht ein Team einen Feature Store, und was löst er?

Worauf sie achten: dass du weißt, wann sich ein Werkzeug lohnt.

Kurze Antwort: „Ein Feature Store ist ein gemeinsamer Ort für die Features, die Modelle nutzen, mit einer Definition für Training und Serving. Er hilft, wenn viele Modelle dieselben Features wiederverwenden oder wenn das Online-Serving Features genau so berechnen muss wie das Training. Für ein Team mit ein paar Batch-Modellen ist er oft mehr Last als Hilfe.“

Die ausführliche Antwort: Das Problem, das er löst, ist, dass Training und Serving auseinanderlaufen, nicht die Speicherung.

Schwache Antwort: „Jedes ML-Team braucht einen.“ Nachfrage: „Dein Modell schneidet offline gut ab und online schlecht.“ Sag, was du vermutest.

Release, Serving und Monitoring

Wie würdest du eine neue Modellversion ausrollen, ohne den Service zu gefährden?

Worauf sie achten: sichere Muster für Releases.

Kurze Antwort: „Ein Canary Release schickt einen kleinen Teil des Verkehrs an das neue Modell und vergrößert ihn, solange die Zahlen halten. Ein Shadow Deployment, der Schattenbetrieb, lässt das neue Modell auf echten Anfragen laufen, ohne seine Antworten zu nutzen, damit wir vergleichen können. Ich nutze eines davon, mit einer klaren Regel für das Weitermachen und einem automatischen Weg zurück.“

Die ausführliche Antwort: Offline-Metriken sagen, dass ein Modell funktionieren kann; nur echter Verkehr sagt, dass es funktioniert.

Schwache Antwort: „Wir tauschen das alte Modell am Freitagabend aus.“ Nachfrage: „Das neue Modell ist im Schnitt besser und für eine Kundengruppe viel schlechter.“ Sag, was du tust.

Batch-Scoring oder Echtzeit-Serving: Wie wählst du, und wie hältst du die Latenz niedrig?

Worauf sie achten: Serving, das sich nach dem Produkt richtet.

Kurze Antwort: „Wenn die Antworten warten können, ist Batch-Scoring einfacher und günstiger. Braucht das Produkt sofort eine Antwort, stelle ich das Modell hinter einem Endpunkt bereit, halte Modell und Features nah beieinander, bündle Anfragen, wo es geht, und lege die Größe der Maschinen nach Lasttests fest. Die Grenze für die Latenz kommt vom Produkt, nicht vom Modell.“

Die ausführliche Antwort: Viele Echtzeit-Services könnten ein nächtlicher Job sein und wären so günstiger.

Schwache Antwort: „Echtzeit ist immer besser.“ Nachfrage: „Zur Mittagszeit verdoppelt sich die Latenz.“ Sag, wo du nachschaust.

Was überwachst du, wenn ein Modell live ist?

Worauf sie achten: Monitoring, das über den Server hinausgeht.

Kurze Antwort: „Den Service selbst: Latenz, Fehler, Last. Die Daten: ob die Eingaben noch wie die Trainingsdaten aussehen, fehlende Werte, neue Kategorien. Das Modell: seine Ausgaben und, sobald die richtigen Antworten eintreffen, seine Qualität. Und die Geschäftszahl, für die es gebaut wurde. Jeder Alarm hat einen Verantwortlichen und einen aufgeschriebenen ersten Schritt.“

Die ausführliche Antwort: Ein grünes Dashboard für den Server sagt nichts über die Antworten.

Schwache Antwort: „Wir beobachten CPU und Speicher.“ Nachfrage: „Die echten Labels kommen erst nach drei Monaten.“ Sag, was du in der Zwischenzeit beobachtest.

Wie erkennst du Drift, und was tust du, wenn du sie findest?

Worauf sie achten: eine ruhige, gemessene Reaktion.

Kurze Antwort: „Drift heißt, dass sich die Daten oder der Zusammenhang, den das Modell gelernt hat, seit dem Training verschoben haben. Ich vergleiche die Eingaben und Ausgaben im Betrieb mit einem Referenzzeitraum, pro Feature, und alarmiere ab einer festen Schwelle. Schlägt sie an, prüfe ich zuerst, ob eine Datenlieferung kaputt ist, dann, ob die Qualität gesunken ist, und erst dann entscheide ich mit den Data Scientists über ein Neutraining.“

Die ausführliche Antwort: Die Hälfte aller Drift-Alarme ist eine kaputte Leitung weiter oben, keine veränderte Welt.

Schwache Antwort: „Wir trainieren jedes Mal neu, wenn der Alarm losgeht.“ Nachfrage: „Drift zeigt sich in einem Feature, das das Modell kaum nutzt.“ Sag, ob du handelst.

Wann sollte ein Modell automatisch neu trainiert werden, und wann sollte ein Mensch entscheiden?

Worauf sie achten: Automatisierung mit Urteilsvermögen.

Kurze Antwort: „Neutraining heißt, das Modell auf neueren Daten noch einmal zu trainieren. Nach Zeitplan oder auf ein Drift-Signal hin kann eine Pipeline selbst neu trainieren und bewerten, aber ein neues Modell kommt erst in Produktion, wenn es das aktuelle in vereinbarten Tests schlägt. Wo das Modell Menschen betrifft, etwa bei Krediten oder in der Personalauswahl, gibt ein Mensch es frei.“

Die ausführliche Antwort: Automatisches Neutraining ohne automatische Prüfungen ist automatisches Risiko.

Schwache Antwort: „Jede Nacht neu trainieren und ausrollen, was herauskommt.“ Nachfrage: „Die Daten von letzter Nacht hatten einen Fehler.“ Sag, was das schlechte Modell aufhält.

Ein neues Modell ist in Produktion schlechter als im Test. Wie gehst du mit dem Rollback um, und wie findest du die Ursache?

Worauf sie achten: Umgang mit Störungen und Lernen daraus.

Kurze Antwort: „Zuerst der Rollback: Die vorherige Version liegt noch in der Registry, und der Service kann in Minuten zurückschalten, was wir üben. Dann die Ursache: Eingaben und Features online mit denen im Test vergleichen, den Testdatensatz auf Datenlecks prüfen und schauen, welche Gruppen schlechter geworden sind. Die Korrektur kommt in die Prüfungen der Pipeline, damit es nicht noch einmal auf dieselbe Weise passieren kann.“

Die ausführliche Antwort: Ein Rollback, den du nie ausprobiert hast, ist eine Hoffnung, kein Plan.

Schwache Antwort: „Wir trainieren neu, bis es besser aussieht.“ Nachfrage: „Das alte Modell wurde gelöscht.“ Sag, was dir das über den Aufbau verrät.

Plattform, Kosten und die Senior-Runde

Wie betreibst du Training und Serving auf Kubernetes, und wo wird es schwierig?

Worauf sie achten: echte Erfahrung mit Plattformen.

Kurze Antwort: „Das Training läuft als Jobs mit Ressourcenanforderungen und Kontingenten pro Team; das Serving läuft als Services mit Health Checks und Autoscaling. Schwierig sind die GPUs, die eigenes Scheduling und eigene Treiber brauchen, große Modelldateien, die den Start bremsen, und gemeinsame Cluster, die zwischen den Teams fair bleiben sollen.“

Die ausführliche Antwort: Kubernetes löst den Betrieb von Containern, nicht die Frage, wer die GPUs bekommt.

Schwache Antwort: „Kubernetes kümmert sich um alles.“ Nachfrage: „Der Trainingsjob eines Teams lässt die Serving-Pods verhungern.“ Sag, was du änderst.

GPUs sind teuer. Wie hältst du die Kosten für Training und Inferenz im Griff?

Worauf sie achten: Kosten als Ziel im Engineering.

Kurze Antwort: „Ich mache die Kosten pro Team und pro Modell sichtbar, schalte ungenutzte Maschinen ab, nutze günstigere unterbrechbare Maschinen für Training, das neu starten kann, passe die Größe für die Inferenz an und probiere kleinere oder komprimierte Modelle aus, wo die Qualität es zulässt. Eine Zeile zu den Kosten in jedem Modell-Review hält das Thema auf dem Tisch.“

Die ausführliche Antwort: Die teuerste GPU ist die, von der niemand mehr weiß, wer sie gestartet hat.

Schwache Antwort: „Kosten sind Sache der Finanzabteilung.“ Nachfrage: „Die monatliche Rechnung hat sich verdoppelt, und niemand weiß, warum.“ Sag, was dein erster Schritt ist.

Was ändert sich, wenn das Modell in Produktion ein LLM ist?

Worauf sie achten: dass du dieselbe Disziplin auf neue Modelle anwendest.

Kurze Antwort: „Dieselbe Disziplin gilt, mit neuen Teilen: Prompts und die Daten für das Retrieval brauchen auch Versionen, die Qualität wird mit Evaluierungsdatensätzen und Reviews beurteilt statt mit einer einzigen Zahl für die Genauigkeit, Kosten und Latenz wachsen mit der Länge des Textes, und die Ausgaben brauchen Prüfungen auf schädliche oder falsche Antworten. Viele Teams rufen ein externes Modell auf, deshalb werden seine Versionen und Grenzen zu einer Abhängigkeit, die du beobachten musst.“

Die ausführliche Antwort: Ein LLM in Produktion ist immer noch ein Modell in Produktion, nur mit mehr beweglichen Teilen.

Schwache Antwort: „LLMs brauchen kein MLOps.“ Nachfrage: „Der Anbieter aktualisiert das Modell, und deine Antworten ändern sich.“ Sag, wie du es bemerken würdest.

Wie verändert der EU AI Act die Arbeit eines MLOps-Teams an einem Hochrisiko-System?

Worauf sie achten: dass du die Regeln kennst, ohne Jurist zu spielen.

Kurze Antwort: „Für Systeme, die der EU AI Act als hochriskant einstuft, braucht der Anbieter Risikomanagement, Data Governance, Protokollierung, technische Dokumentation und menschliche Aufsicht. Vieles davon liefert gutes MLOps schon: nachvollziehbare Daten, registrierte Modelle, Aufzeichnungen aus dem Monitoring. Ob ein System hochriskant ist, ist eine rechtliche Frage; meine Aufgabe ist, die Nachweise leicht lieferbar zu machen.“

Die ausführliche Antwort: Gute Aufzeichnungen ab dem ersten Tag zu führen ist billiger, als sie für ein Audit neu aufzubauen.

Schwache Antwort: „Das ist nur etwas für die Rechtsabteilung.“ Nachfrage: „Die Rechtsabteilung fragt nach den Trainingsdaten eines Modells aus dem letzten Jahr.“ Sag, was du übergeben kannst.

Wie würdest du als Senior oder Lead MLOps Engineer einem Junior MLOps Engineer und den Data Scientists helfen, Modelle sicher auszuliefern?

Worauf sie achten: dass du den sicheren Weg zum einfachen machst.

Kurze Antwort: „Ich baue Vorlagen, damit ein neues Modell schon mit Tracking, Tests und Deployment startet, schreibe kurze Anleitungen und gehe die ersten Releases gemeinsam durch. Einem Junior Engineer übergebe ich eine Pipeline von Anfang bis Ende mit einem klaren Ziel und arbeite bei der ersten Störung eng mit ihm zusammen. Der Maßstab ist, wie viele Modelle ohne mich in Produktion kommen.“

Die ausführliche Antwort: Eine Plattform, die niemand nutzt, ist ein Hobby; die Nutzung ist das Ergebnis.

Schwache Antwort: „Die können ja die Dokumentation lesen.“ Nachfrage: „Ein Team von Data Scientists deployt weiter von Hand.“ Sag, was du tust.

Wo können KI-Werkzeuge in der MLOps-Arbeit helfen, und wo muss ein Engineer entscheiden?

Worauf sie achten: nüchterner Umgang mit neuen Werkzeugen.

Kurze Antwort: „KI-Assistenten helfen, Pipeline-Code, Konfiguration und Tests zu schreiben, Logs zusammenzufassen und bei einer Störung Ursachen vorzuschlagen. Ich prüfe trotzdem jede Änderung, halte Secrets und Daten aus Werkzeugen heraus, die nicht freigegeben sind, und lasse Entscheidungen über Releases und Freigaben bei den Menschen, die dafür einstehen.“

Die ausführliche Antwort: Eine falsche Konfiguration, schnell geschrieben, ist immer noch eine falsche Konfiguration.

Schwache Antwort: „Die KI wird die Plattform betreiben.“ Nachfrage: „Eine vorgeschlagene Änderung öffnet einen Storage-Bucket ins Internet.“ Sag, wie du das abfangen würdest.

Dein Lebenslauf für diese Fragen

Jede Zeile in deinem Lebenslauf lädt zu den Fragen oben ein: welches Modell, wie es ausgerollt wurde, was du beobachtet hast. Gib jeder Zeile ihr Modell und ihr Ergebnis, so wie ein Lead Engineer danach fragen wird:

Halte deinen Lebenslauf mit der kostenlosen Bewertung an einen Job als MLOps Engineer; bereite dann die Geschichte eines Modells für den Bereich vor, den sie als dünn erkennt, vom Notebook bis zum Rollback.