ML Engineer Mock-Interview — üben mit AI

ML-Engineer-Interviews liegen irgendwo zwischen Data Science und Backend, und gut abschneiden die Kandidaten, die aufhören, das eine oder das andere vorzutäuschen. Hiring Manager wollen jemanden, der ein Jupyter-Notebook nimmt, es als Service ausliefert und bemerkt, wenn die Offline-AUC das Online-Verhalten nicht mehr vorhersagt. Dieser Leitfaden zeigt, wie Sie AI Mock Interviews nutzen, um genau die ML-Loops zu proben, die zu Angeboten führen — nicht den FAANG-artigen Coding-Spießrutenlauf, sondern das praktische Gespräch „kannst du ein Modell tatsächlich ausliefern“.

Starten Sie jetzt ein ML Engineer Mock-Interview

Wählen Sie Ihren Stack, Ihr Level und absolvieren Sie eine realistische Runde in 30 Minuten. Kostenlos testen.

ML Engineer Mock starten

Typische Interview-Runden für ML Engineers

Der ML-Engineer-Loop variiert je nach Unternehmen stark. Bei ML-First-Unternehmen (Forschungslabore, AI-Startups) rechnen Sie mit 5–6 Runden: ein Phone-Screen zu Grundlagen, ein Coding-Interview (Python plus NumPy/PyTorch), eine ML-System-Design-Runde, eine Paper-Discussion- oder Research-Fit-Runde, ein Behavioral und ein Gespräch mit dem Hiring Manager. Bei Produktunternehmen (dem größten Teil des Marktes) komprimiert sich der Loop auf 4 Runden: ein Phone-Screen, ein Coding-Interview, ein ML-System-Design und eine Case Study sowie ein Behavioral. Gesamtdauer: 5–7 Stunden Gespräch über 1–2 Tage.

Die Runde mit dem höchsten Hebel für AI-Mock-Übungen ist das ML System Design. Sie passt fast perfekt zum Mock-Format — offener Prompt („entwerfen Sie ein Empfehlungssystem für Kurzvideos“), Hin und Her zu Tradeoffs, Bewertung nach Struktur und Tiefe. Die Case-Study-Runde ist das zweitbeste Ziel: „die Accuracy unseres Churn-Modells ist letzte Woche von 0,84 auf 0,71 gefallen, was tun Sie?“ — genau die Art sich entfaltender Untersuchung, die AI-Mocks gut bewältigen.

Wichtigste technische Themen

Feature Engineering und Daten-Pipelines

Die Messlatte hat sich von „kannst du eine SQL-Window-Funktion schreiben“ zu „kannst du einen Feature Store entwerfen“ verschoben. Erwarten Sie Fragen zu Training-Serving-Skew, Point-in-Time-Korrektheit, Online- vs. Batch-Features und wann man materialisiert vs. on demand berechnet. Tooling: Feast, Tecton, Eigenbau — kennen Sie die Tradeoffs. Eine beliebte Frage: „Ihr Modell sagt offline gut vorher, verschlechtert sich aber online — führen Sie mich durch Ihre Untersuchung.“ Starke Antworten verketten Feature-Aktualität, Label Leakage, Distribution Shift und Bugs zur Serving-Zeit.

Training und Modellierung

Die meisten Produkt-ML-Rollen verlangen nicht, dass Sie neuartige Architekturen erfinden. Sie verlangen, dass Sie die richtige Modellklasse wählen, Training debuggen und Tradeoffs erklären. Seien Sie bereit zu diskutieren: Gradient Boosting vs. neuronale Netze für tabellarische Daten, wann Transformer überdimensioniert sind, Regularisierung über L2 hinaus (Dropout, Early Stopping, Data Augmentation), den Bias-Variance-Tradeoff in konkreten Begriffen und wie „dieses Modell ist überangepasst“ in Loss-Kurven tatsächlich aussieht. Bringen Sie Klassen-Imbalance, Kalibrierung und den Unterschied zwischen Accuracy und AUC unaufgefordert ein — Interviewer lieben es, wenn Sie die nächste Frage vorwegnehmen.

Model Serving und MLOps

Hier unterscheidet sich der ML Engineer vom Data Scientist. Seien Sie bereit, über Folgendes zu sprechen: Batch- vs. Real-Time-Serving, Latenzbudgets (was bedeuten 50 ms p99 tatsächlich für ein Modell von der Größe eines XGBoost vs. eines 7B-LLM), Model Versioning, A/B-Testing-Infrastruktur für ML (nicht nur für Buttons), Shadow Deployment, Rollback-Strategie bei Modell-Regression und Feature-Flag-Muster für ML. Tools: BentoML, KServe, Triton, Ray Serve, vLLM. Eins davon gut zu kennen schlägt das Kennen von fünf Namen.

Evaluation und Metriken

Online-Metriken bewegen sich selten auf dieselbe Weise wie Offline-Metriken. Seien Sie bereit zu erklären, warum und was Sie dagegen tun würden. Themen: Offline-Online-Korrelation, Proxy-Metriken, kontrafaktische Evaluation, Off-Policy-Schätzung für Ranking, Holdout-Populationen und die spezifischen Fallen beim CTR-Modeling (Selection Bias, Position Bias). Eine häufige Frage: „Das Team will ein Modell ausliefern, das NDCG offline um 2 % verbessert — was sagen Sie?“ Antworten, die das Eval-Framework hinterfragen, schneiden besser ab als solche, die der Zahl einfach vertrauen.

LLMs und der neue Stack

Die Hälfte der ML-Stellenbeschreibungen im Jahr 2026 erwähnt LLMs, selbst wenn die Rolle nicht LLM-spezifisch ist. Seien Sie bereit: Prompt Engineering vs. Fine-Tuning vs. RAG (wann wählt man was), Embedding-Evaluation, Vektor-DB-Wahl (Qdrant vs. pgvector vs. Pinecone), Latenz- und Kostenökonomie im großen Maßstab, Halluzinations-Minderung. Ist die Rolle LLM-spezifisch, ergänzen Sie: Kuration von Trainingsdaten, Design eines Eval-Harness (eigenes, nicht nur MMLU), Distillation, Quantisierungs-Tradeoffs.

Trainieren Sie die Themen, die tatsächlich über Ihr Angebot entscheiden

Realistische AI-Fragen, bewertetes Feedback, kalibriert auf Ihr Level.

Kostenlose Session starten

Häufige Szenario-Fragen

Behavioral-Schwerpunkte — worauf Hiring Manager achten

ML-Hiring-Manager achten auf drei weniger offensichtliche Signale. Erstens kalibriertes Selbstvertrauen — ML ist die Disziplin, in der Übertreibung von den Daten entlarvt wird. Starke Kandidaten sagen „Ich bin nicht sicher, so würde ich es herausfinden“, ohne zu zögern. Zweitens Geschäftssinn — ML Engineers, die einen Anstieg von 0,03 in der Offline-NDCG mit einem Dollarwert verbinden können, landen schneller Senior-Angebote als solche, die nur über Mathematik reden können. Drittens Zusammenarbeit mit Nicht-ML-Leuten — die meiste ML-Arbeit scheitert an der Kommunikation mit PM, Data Engineering oder Ops, nicht an der Modellarchitektur. Rechnen Sie mit Prompts zu einem gescheiterten Projekt und antworten Sie mit der funktionsübergreifenden Reibung, nicht der algorithmischen.

Wie Sie AI-Mock-Übungen für diese Rolle nutzen

Stellen Sie den Interview-Typ auf „ML System Design“ und wählen Sie Ihre Seniorität ehrlich. Senior-ML-Loops erwarten, dass Sie das Gespräch führen; Mid-Level erwartet, dass Sie gut auf Prompts reagieren; Junior erwartet saubere Grundlagen. Fügen Sie die Stellenbeschreibung ein, falls vorhanden — die AI gewichtet die Fragen zum Stack des Unternehmens (Recsys-Unternehmen bekommen mehr Ranking-Tiefe, LLM-Unternehmen mehr Eval- und Serving-Tiefe).

Für Coding-Übungen nutzen Sie den Mock für den verbalen Durchlauf einer ML-Pipeline („wie würden Sie eine Leave-One-Out-Cross-Validation für eine Zeitreihen-Prognose implementieren?“) und kombinieren ihn mit einem echten Notebook. Verwenden Sie ihn nicht als Ersatz für das tatsächliche Schreiben von PyTorch.

Ein Drill, der sich schnell auszahlt: Machen Sie fünf aufeinanderfolgende Case Studies, in denen Sie ein verschlechtertes Modell triagieren. Das Mustererkennen für „ist das Label Leakage, Distribution Shift oder ein Pipeline-Bug“ ist die am besten übertragbare Interview-Fähigkeit im ML.

Häufig gestellte Fragen

Wie viel Mathematik brauche ich für ein ML-Mock-Interview?

Weniger, als die Lehrbücher vermuten lassen, mehr, als Bootcamp-Absolventen erwarten. Seien Sie sicher in: linearer Algebra auf Skalarprodukt-Niveau, Intuition für Gradient Descent, der Kettenregel, Wahrscheinlichkeit und Likelihood, grundlegender Informationstheorie (Cross-Entropy, KL). Sie müssen Backprop nicht am Whiteboard herleiten. Sie müssen aber erklären, warum der Gradient in tiefen Netzen verschwindet und was Sie dagegen tun würden.

Sollte ich mich auf LLM-Fragen vorbereiten, auch wenn die Rolle nicht LLM-fokussiert ist?

Ja — inzwischen erwähnt etwa die Hälfte der ML-Stellenbeschreibungen LLMs als „Plus“ oder „Vertrautheit mit“. Selbst Produkt-ML-Rollen bekommen ein bis zwei Fragen zu Prompt Engineering vs. Fine-Tuning, RAG-Architektur oder Eval-Strategie. Eine oberflächliche Vertrautheit genügt; tiefes LLM-Wissen ist nur für explizit LLM-fokussierte Rollen erforderlich.

Muss ich bestimmte MLOps-Tools kennen oder nur die Konzepte?

Konzepte plus ein Tool in der Tiefe. Kennen Sie einen Feature Store, ein Model Registry, ein Serving-Framework, einen Experiment-Tracker — und seien Sie bereit zu erklären, warum Sie es gewählt haben und wo seine Grenzen liegen. Fünf Tools ohne Tiefe zu zitieren schneidet schlechter ab, als bei einem in die Tiefe zu gehen.

Wie lange sollte ein ML-Mock-Interview dauern?

ML-System-Design-Runden dauern 45–60 Minuten. Case Studies dauern 30–45. Coding dauert 45–60, aber der Großteil davon ist der Algorithmus, nicht das ML. Planen Sie einen vollständigen Mock von 50–60 Minuten, wenn Sie eine echte Runde simulieren; 25–30, wenn Sie eine Schwachstelle trainieren.

Mein Hintergrund ist Data Science, nicht Engineering. Wo werde ich Punkte verlieren?

Vor allem bei Serving und Infrastruktur. Data Scientists beherrschen Modellierung und Evaluation aus dem Effeff; ML Engineers ergänzen die Fähigkeit, auszuliefern und zu betreiben. Trainieren Sie: ein Modell hinter einer API deployen, Drift in Production überwachen, der Unterschied zwischen Batch- und Real-Time-Serving sowie die grundlegenden Linux- und Docker-Fähigkeiten, die von einem ML Engineer erwartet werden.

Ihre Angebotsquote steigt mit jeder Wiederholung

Trainieren Sie ML-Engineer-Fragen, bis die Antworten ohne Nachdenken kommen. Kostenlos testen.

Mit dem Üben beginnen

Verwandte Leitfäden