Lebenslauf für Machine Learning Engineers: Beispiele und Anleitung

Ein Lebenslauf mit Stoff für zwei Seiten, auf das Wesentliche gekürzt, für eine Machine Learning Engineer mit sechs Jahren Erfahrung, davon die Hälfte mit Modellen im Live-Betrieb. Die Namen sind erfunden. Achten Sie darauf, dass jeder Stichpunkt Modell, Datenumfang, die Anforderung an das Serving und das Geschäftsergebnis nennt und dass Arbeit an der Infrastruktur als echte Arbeit gilt.

Das Team stellt Sie ein, weil Modelle nach der Auslieferung immer wieder kaputtgehen. Danach richtet sich, worauf beim Lesen geachtet wird.

• Hat etwas, das Sie gebaut haben, echten Traffic bedient? Offline-Metriken auf einem statischen Datensatz sind billig. Anfragen pro Sekunde, Latenz, betroffene Nutzerinnen und Nutzer und die Dauer im Live-Betrieb zählen.
• Verantworten Sie den Datenpfad? Die meisten Fehler im Machine Learning entstehen in Pipelines und durch Abweichungen bei Features, nicht im Modell. Feature Engineering, Orchestrierung und ein Feature Store sind starke Signale.
• Können Sie Software entwickeln und nicht nur modellieren? Codestil, Testgewohnheiten, Container und CI zeigen der Leitung, ob Ihnen ständig jemand aus der Softwareentwicklung hinterherräumen muss.
• Messen Sie das Richtige? Wer Offline- und Online-Metrik getrennt nennt (F1 und Conversion, AUC und Umsatz pro Sitzung), zeigt, dass schon etwas ausgeliefert wurde.
• Schwerpunkt und Aktualität. LLM- und Retrieval-Arbeit, klassisches Ranking, Computer Vision und Prognosen sind recht unterschiedliche Aufgaben. Richten Sie den Lebenslauf auf das Problemfeld der Anzeige aus.

“Zeigen Sie mir ein Modell, das Sie vom Notebook in die Produktion gebracht und ein Jahr am Leben gehalten haben. Was ist kaputtgegangen, was haben Sie überwacht, was haben Sie zurückgerollt? Diese Geschichte sagt mir mehr als fünf Kaggle-Medaillen und eine Liste aller Frameworks, die Sie je angefasst haben.”

Drei oder vier Zeilen: Jahre, Problemfeld, die wichtigste Zahl aus der Produktion und die Breite des Stacks, den Sie verantworten. Ein Berufsziel brauchen Sie nicht; auch nach dem Studium ist ein Profil mit Ihrem besten Projekt stärker.

Das übliche Problem ist ein Lebenslauf voller Frameworks ohne Ergebnisse. Versehen Sie jedes Modell mit einer Zahl und einer Anforderung.

Das ist eines der wenigen Felder, in denen Leitungen Ihre Links tatsächlich öffnen. Ein Abschnitt Projekte hilft am Anfang der Laufbahn und kann auch später helfen, wenn das Projekt eine Fähigkeit zeigt, die Ihre Stellen nicht zeigen. Er schadet, wenn er ein Ordner voller Tutorial-Notebooks ist.

• Zwei oder drei Projekte, nicht mehr. Jedes bekommt einen Titel, eine Zeile zum Problem, eine zum Vorgehen und eine zum Ergebnis, dazu einen Link.
• Zeigen Sie auch die langweiligen Teile: Datenerhebung, Evaluation, Bereitstellung oder Reproduzierbarkeit. Ein Projekt mit Dockerfile, Tests und README schlägt eines mit einem größeren Modell.
• Nennen Sie eine echte Metrik und eine Baseline. „F1 0,87 gegenüber 0,72 bei einer Schlagwort-Baseline auf 30.000 annotierten Bewertungen“ ist lesenswert, „Sentiment-Modell gebaut“ nicht.
• Streichen Sie alles, was auf einem bekannten Tutorial-Datensatz beruht, es sei denn, Sie haben damit etwas Ungewöhnliches gemacht. Leitungen haben dasselbe Titanic- und MNIST-Projekt Hunderte Male gesehen.
• Verlinken Sie nur ein GitHub-Profil, das geöffnet werden darf. Sind Ihre angepinnten Repositories leer oder halbfertig, ändern Sie das vor dem Versand.
• Veröffentlichungen, eine Kaggle-Platzierung oder ein Open-Source-Beitrag, der in eine echte Bibliothek übernommen wurde, sind jeweils eine Zeile wert. Eine Wettbewerbsplatzierung ersetzt keine Geschichte aus der Produktion.
• Unterliegt Ihre Arbeit einer Geheimhaltungsvereinbarung, beschreiben Sie die Form ohne Details: „internes Betrugsmodell über rund 30 Mio. Transaktionen pro Monat“ ist in Ordnung. Echte oder personenbezogene Daten des Arbeitgebers gehören nicht in ein öffentliches Repository.

Gruppieren Sie die Liste nach Schichten, damit die Leitung sieht, wie weit Ihre Verantwortung reicht. Füllen Sie sie nicht mit allem auf, was Sie einmal angefasst haben, denn im Gespräch kann nach jedem einzelnen Punkt gefragt werden.

• Sprachen: zuerst Python, immer SQL, dazu die Sprache Ihres Serving-Codes (Go, Java, C++ für Edge- und Vision-Anwendungen).
• Modellierung: PyTorch, scikit-learn, XGBoost oder LightGBM, Hugging Face Transformers, TensorFlow, wenn Sie es noch nutzen. Nennen Sie auch die Problemtypen: Ranking, Retrieval, Klassifikation, Prognose, Objekterkennung.
• Daten: Spark, pandas oder Polars, Kafka, dbt, Airflow oder Dagster, ein Feature Store wie Feast und das Warehouse, das Sie abfragen (Snowflake, BigQuery, Redshift).
• Serving und Inferenz: FastAPI, Triton, ONNX, TensorRT, vLLM für Sprachmodelle, Batching und Quantisierung, Kostenentscheidungen zwischen GPU und CPU.
• Plattform: Docker, Kubernetes, Terraform, GitHub Actions und eine Cloud in der Tiefe (SageMaker auf AWS, Vertex AI auf GCP, Azure Machine Learning).
• Tracking und Evaluation: MLflow oder Weights & Biases, Versuchsplanung, A/B-Tests, Paare aus Offline- und Online-Metrik, Analyse nach Segmenten, Shadow Deployments, Modelldokumentation (in regulierten Bereichen zunehmend mit Blick auf die EU-KI-Verordnung).
• Retrieval und Vektoren, falls relevant: Embeddings, FAISS, pgvector oder eine verwaltete Vektordatenbank, Chunking und Reranking für Retrieval-Augmented Generation.
• Der Teil Urteilsvermögen, nach dem im Gespräch gefragt wird: erkennen, wann ein einfacheres Modell die richtige Antwort ist, wann Zukaufen besser ist als Selbstbauen und wie man Nein sagt zu einem Problem, das kein Machine Learning braucht.

Die meisten Anzeigen für Machine Learning Engineers verlangen Erfahrung, die beim Einstieg niemand hat. Der Weg hinein führt meist über eine benachbarte Stelle (Data Science, Data Engineering, Backend-Entwicklung, Praktikum oder Werkstudententätigkeit im ML-Team) oder über Projekte, die wie Produktionsarbeit aussehen.

1. 1Beginnen Sie mit einem umfangreichen Projekt statt mit fünf kleinen. Wählen Sie das, in dem Datenerhebung, Evaluation und Bereitstellung stecken.
2. 2Zeigen Sie Softwareentwicklung, nicht nur Modellierung. Ein bereitgestellter Endpunkt, Tests, ein Container und ein README heben Sie auf diesem Level von den meisten Bewerberinnen und Bewerbern ab.
3. 3Nennen Sie Module nur, wenn sie konkret und aktuell sind: verteilte Systeme, Optimierung, Deep Learning, Statistik. Zählen Sie keine zehn Veranstaltungen auf. Die Abschlussnote gehört dazu, wenn sie 2,0 oder besser ist.
4. 4Nutzen Sie Praktika, Werkstudententätigkeiten und Stellen als wissenschaftliche Hilfskraft richtig: Datenumfang, was Sie gemessen haben, ob jemand das Ergebnis genutzt hat.
5. 5Bewerben Sie sich auch auf die benachbarte Stelle. Data Engineering und Backend-Entwicklung in Unternehmen mit ML-Teams sind ein schnellerer Weg ins ML Engineering als das Warten auf eine Junior-Anzeige.
6. 6Cloud-Zertifikate helfen auf diesem Level ein wenig, vor allem als Beleg, dass Sie die Plattform kennen. Sie ersetzen kein Projekt, das jemand ausführen kann.

• Am Anfang eine Seite, zwei Seiten ab etwa drei Jahren Erfahrung mit echter Produktionsarbeit; in Deutschland sind zwei Seiten ohnehin akzeptiert. In diesem Feld wird die zweite Seite gelesen.
• Setzen Sie die Links (GitHub, eigene Website, Veröffentlichungen) in den Kopf, wo sie angeklickt werden, und prüfen Sie, dass sie im PDF funktionieren.
• Verzichten Sie auf Kenntnisbalken. Vier von fünf Punkten in PyTorch glaubt niemand, und der Parser liest sie als nichts.
• Ein Foto ist in Deutschland üblich, aber freiwillig, ebenso das Geburtsdatum; in internationalen Tech-Unternehmen wird beides oft weggelassen. Bleiben Sie beim einspaltigen Layout, damit der Parser in der richtigen Reihenfolge liest.
• Übernehmen Sie die Begriffe der Anzeige: Steht dort „MLOps“, „LLM“, „Empfehlungssysteme“ oder „Computer Vision“, verwenden Sie genau diese Wörter, wo sie zutreffen. Die Vorauswahl sucht Framework-Namen wörtlich, also schreiben Sie „PyTorch“ und die konkrete Bibliothek, wo es darauf ankommt.
• Lohnt sich, wenn es zutrifft: Produktion, Deployment, Inferenz, Latenz, Durchsatz, Feature Store, Drift, A/B-Test, Fine-Tuning, Embeddings, Kubernetes, Spark, Airflow, MLflow, SageMaker oder Vertex AI.

Eine letzte Prüfung vor dem Versand: Fragen Sie bei jedem Stichpunkt, ob eine Data Scientist, ein Backend-Entwickler und eine ML Engineer genau dieselbe Zeile geschrieben hätten. Wenn ja, leistet sie nichts für Sie. Schreiben Sie sie neu, mit der Anforderung, die Sie erfüllen mussten.