Portfolio Projects for Machine Learning Engineer

Dein Lebenslauf listet fünf Zertifikate auf, und trotzdem kommt keine Einladung zum Gespräch. Das ist frustrierend, aber erklärbar: Zertifikate zeigen, dass du Kurse absolviert hast. Projekte zeigen, dass du Probleme lösen kannst, und genau das prüft ein Hiring Manager.

Was Reviewer in ML-Portfolios wirklich ansehen#

Reviewer verschwenden selten mehr als drei bis fünf Minuten pro Portfolio. Sie suchen nach drei Dingen: ein echtes Problem mit echten Daten, eine nachvollziehbare Entscheidung, und ein Ergebnis, das man verstehen kann. Nicht die Anzahl der Projekte zählt.

Ein Recruiter bei einem Tech-Unternehmen wird dir nicht sagen, was er sucht, aber du kannst es dir selbst beantworten: Würde ich dieses Projekt jemandem anvertrauen, der später unser Modell in Produktion bringt? Genau darum geht es.

Vergiss die Benchmark-Jagd. 0,92 Accuracy auf einem öffentlichen Datensatz beeindruckt niemanden. Ein Modell, das mit unordentlichen Daten umgeht und dessen Grenzen du offen benennst, schon.

Drei Projekte, die Zertifikate schlagen#

Projekt 1: Ein End-to-End-System mit unordentlichen Daten

Baue ein System, das Rohdaten bis zur Vorhersage-API durchzieht. Nicht ein Notebook mit Iris-Daten. Sondern Daten, die du selbst gesammelt, gescraped oder aus einer öffentlichen Quelle mit echten Problemen gezogen hast.

Nehmen wir an, du willst im Bereich E-Commerce arbeiten. Scrape oder lade Produktdaten mit fehlenden Werten, Tippfehlern in Kategorien und Duplikaten. Klassifiziere Produkte in Kategorien, dokumentiere dein Cleaning, und deploye das Modell als kleine API. Das ist die Arbeit, für die ML Engineers bezahlt werden.

Projekt 2: Ein Projekt, das Kosten oder Zeit spart

Zeige, dass du verstehst, wofür ML existiert. Ein Modell, das die manuelle Prüfung von Anträgen, Tickets oder Bildern reduziert, ist mehr wert als ein weiteres Sentiment-Analysis-Notebook.

Beschreibe den Status quo: Wie lange dauert die manuelle Arbeit heute? Was passiert, wenn das Modell daneben liegt? Ein Projekt mit dieser Denkweise zeigt Product Sense, und das ist seltener als Framework-Kenntnisse.

Projekt 3: Etwas, das kaputtgeht und repariert wird

Das klingt kontraintuitiv, ist aber der stärkste Tipp hier. Dokumentiere ein Projekt, bei dem dein erstes Modell versagt hat. Datensatz-Shift, Leakage, eine Metrik, die das Problem nicht traf. Und was du daraus gemacht hast.

Reviewer lesen unzählige Portfolios, in denen alles glatt läuft. Eines, das Rückschläge zeigt, wirkt wie echte Arbeit. Es beweist Debugging-Fähigkeit, und die ist in Interviews schwer zu fälschen.

So präsentierst du Projekte im Lebenslauf#

Dein CV braucht Ergebnisse, keine Technologieliste. Ein Fehler, den ich oft sehe: "Verwendet Python, Scikit-learn, Pandas". Das steht in jedem Lebenslauf. Stattdessen solltest du Wirkung benennen.

Vorher: "Gebaut: Machine Learning Modell zur Kundenabwanderung mit Python und XGBoost."

Nachher: "Prognose der Kundenabwanderung für 200k Nutzer, manuelle Prüfung von 40 auf 12 Fälle pro Tag reduziert, Modell als Batch-Job im Team übernommen."

Der Unterschied ist nicht die Technik. Es ist der Kontext: Umfang, Auswirkung, Übergabe. Zwei bis drei Zeilen pro Projekt reichen völlig aus.

Falls du dir unsicher bist, ob dein CV überhaupt von automatisierten Systemen sauber gelesen wird, prüfe ihn vorab mit einem kostenlosen ATS-Check. Viele Bewerbungen scheitern schon an der Formatierung, bevor ein Mensch sie sieht.

Dein GitHub ist kein Ablageort#

Ein GitHub-Profil mit 30 Repositories und null READMEs ist schlimmer als drei saubere Projekte. Jedes Repository braucht eine README, die in 30 Sekunden beantwortet, worum es geht.

Struktur wie folgt: Ein Satz zum Problem. Zwei bis drei Sätze zur Lösung. Ein Abschnitt zu Daten (Quelle, Größe, bekannte Probleme). Ein Abschnitt zu Ergebnissen mit konkreten Metriken. Ein Abschnitt zu Grenzen und nächsten Schritten. Dazu die Befehle, um das Projekt lokal laufen zu lassen.

Pinne die drei besten Repositories. Lösche oder markiere alte Notebook-Reste. Ein gepinntes Repo mit klarer Struktur schlägt zehn unfertige.

Ein Tipp zur Recherche: Schau dir aktuelle Stellenanzeigen für ML Engineer Rollen an, am besten gesammelt auf einem Jobportal. Notiere die dort genannten Tools und Aufgaben. Deine Projekte sollten zeigen, dass du diese Arbeit bereits einmal gemacht hast.

Fehler, die Projekte nach Tutorial aussehen lassen#

Erster Fehler: Der Datensatz ist zu sauber. Wenn du keinen einzigen fehlenden Wert hattest, hast du den falschen Datensatz gewählt. Öffentliche Übungsdaten sind für den Unterricht gemacht, nicht für Portfolios.

Zweiter Fehler: Keine Modellauswahl begründet. Wer einfach das letzte Framework aus einem Kurs kopiert, hat nichts gelernt. Schreib zwei Sätze dazu, warum du dieses Modell gewählt hast und was du verworfen hast.

Dritter Fehler: Die Metrik ist nicht an das Problem gekoppelt. Accuracy bei stark unbalancierten Klassen ist fast bedeutungslos. Nenne Precision, Recall oder einen Business-relevanten Fehlercost.

Vierter Fehler: Keine Reproduzierbarkeit. Fehlende Requirements-Datei, harte Pfade, Daten, die nirgends verlinkt sind. Jemand, der dein Repo in fünf Minuten nicht starten bekommt, klickt weg.

Fünfter Fehler: Ausgeliehene Projekte ohne eigenen Winkel. Wenn du ein bekanntes Tutorial nachbaust, ändere Daten, Problemstellung oder Zielgröße. Sonst wirkt es kopiert, und das fällt sofort auf.

Wenn du dir unsicher bist, wie deine Projekte auf die konkrete Stelle passen, hilft ein Blick auf die Ausschreibung selbst. Ein Decoder für Stellenanzeigen zeigt dir schnell, welche Anforderungen dort wirklich gemeint sind, und welche nur Standardformulierungen sind.

So redest du in Interviews über deine Projekte#

Die häufigste Frage lautet: "Erzählen Sie mir von einem Projekt." Viele Kandidaten beginnen mit der Technik. Das ist falsch. Beginne mit dem Problem.

So könnte eine gute Antwort klingen: "Ein Team verbrachte täglich etwa zwei Stunden mit manueller Prüfung von Anträgen. Ich habe historische Daten aufbereitet, ein Modell zur Vorauswahl trainiert, und die Top-20-Prozent zur Prüfung priorisiert. Die Prüfzeit ging auf etwa 40 Minuten pro Tag zurück. Am Anfang hatte ich ein Leakage-Problem, das ich erst beim Validieren mit Zeit-Splits gefunden habe."

Diese Antwort enthält Problem, Umfang, Ergebnis und einen Rückschlag. Genau das wird abgefragt.

Bereite dich außerdem auf Rückfragen vor: Warum diese Metrik? Was wäre bei mehr Daten passiert? Wie hast du das Modell überwacht? Wer hat es übernommen? Wenn du hier stockst, wirkt das Projekt wie eine Übung. Übe die Antworten laut, nicht nur im Kopf.

Bei Gehaltsverhandlungen hilft es, Projekte als Verhandlungsbasis zu nutzen: Du hast bereits Arbeit in genau dieser Größenordnung geliefert. Typische Spannen für ML Engineer Rollen in Deutschland liegen laut verschiedenen Gehaltsübersichten grob zwischen 55.000 und 90.000 Euro brutto, je nach Erfahrung, Region und Unternehmensgröße. Diese Zahlen schwanken stark, also prüfe immer die aktuellen Angaben auf der offiziellen Quelle deines Landes oder aktuellen Gehaltsreports.

Checkliste für dein nächstes Projekt#

• Wähle ein Problem, bei dem echte Daten mit echten Problemen vorliegen
• Dokumentiere jede Entscheidung im README, auch die verworfenen Ansätze
• Nenne mindestens eine Metrik, die zum Business-Ziel passt
• Beschreibe eine Grenze deines Modells ehrlich und ohne Ausrede
• Stelle sicher, dass das Repo in unter fünf Minuten reproduzierbar startet
• Formuliere zwei bis drei Ergebniszeilen für deinen Lebenslauf
• Übe die Projektvorstellung laut, mit Problem zuerst, Technik zuletzt

Falls du nach passenden Ausschreibungen suchst, um zu sehen, welche Projekte gerade gefragt sind, lohnt ein Blick in die aktuellen Stellenangebote für Machine Learning Rollen. Dort siehst du, welche Verantwortungsbereiche Unternehmen tatsächlich ausschreiben, und kannst dein Portfolio daran ausrichten.

Kostenlose Tools#

• jobrise.io/de/free-ats-checker/
• jobrise.io/de/free-jd-decoder/
• jobrise.io/de/jobs/
• jobrise.io/de/blog/

Häufige Fragen#

Wie viele Projekte sollte ein ML-Portfolio haben?

Drei durchdachte Projekte reichen völlig aus, fünfzehn halbfertige nicht. Tiefe schlägt Breite: Ein Projekt mit sauberer Dokumentation, ehrlichen Grenzen und reproduzierbarem Code wirkt stärker als eine lange Liste von Notebook-Übungen.

Brauche ich Zertifikate zusätzlich zu Projekten?

Zertifikate schaden nicht, ersetzen aber kein Projekt. Sie zeigen Lernbereitschaft, Projekte zeigen Anwendung. Wenn du Zeit hast, investiere sie lieber in ein Projekt mit echtem Problem als in den nächsten Kurs.

Müssen die Projekte beruflicher Natur sein?

Nein, aber sie sollten ein Problem lösen, das jemanden interessiert. Ein Hobby-Projekt mit klarem Nutzen, etwa zur Analyse öffentlicher Daten zu einem Thema, das dich beschäftigt, kann genauso gut wirken wie ein berufliches.

Wie aktuell müssen die Projekte sein?

Ideal ist mindestens ein Projekt aus den letzten zwölf Monaten. Ältere Projekte kannst du behalten, wenn sie relevant sind, aber ein Portfolio, das 2022 stehen geblieben ist, wirkt, als hättest du dich nicht weiterentwickelt.

Was, wenn meine Projekte nur mit öffentlichen Datensätzen arbeiten?

Das ist kein Problem, wenn du die Daten sorgfältig aufbereitest und ihre Grenzen benennst. Öffentliche Datensätze sind in Ordnung, solange dein Beitrag in der Aufbereitung, Modellwahl und Interpretation liegt, nicht im bloßen Nachvollziehen eines Tutorials.