Portfolio Projects for Data Scientist

Du hast drei Zertifikate, einen Kurs nach dem anderen absolviert, und trotzdem kommt keine Einladung zum Gespräch. Das Problem ist fast immer dasselbe: Zertifikate zeigen, dass du Unterrichtsstunden abgesessen hast. Projekte zeigen, dass du eine Aufgabe lösen kannst. Genau das prüft, wer deine Bewerbung liest.

Was Reviewer wirklich anschauen#

Wer in einem Bewerbungsteam sitzt, hat für dein Portfolio vielleicht drei bis fünf Minuten. In der Zeit wird nicht jede Zeile gelesen. Geprüft wird eine kurze Kette: Ist eine echte Fragestellung erkennbar? Liegen Daten vor, die nicht perfekt sind? Wurde eine Entscheidung getroffen und begründet? Und ist das Ergebnis nachvollziehbar?

Ein Notebook, das am Ende einen Accuracy-Wert von 0,94 ausspuckt, sagt ohne Kontext fast nichts. Interessant wird es, wenn daneben steht, warum du Accuracy überhaupt gewählt hast, welche Alternativen du verworfen hast, und wie das Modell an einer Stelle versagt, an der es im Business wehtut.

Kurz gesagt: Reviewer suchen nach Urteilsvermögen. Nicht nach der größten Modellbibliothek.

Drei Projekte, die mehr hermachen als ein Kurszertifikat#

Projekt 1: Ein End-to-End-Problem mit schmutzigen Daten

Nimm eine Fragestellung, bei der die Daten erst mal wehtun. Beispiel: Aus einer CSV mit 40.000 Transaktionen sagst du voraus, welche Kunden im nächsten Quartal abwandern. Die Rohdaten enthalten doppelte Zeilen, fehlende Werte in drei Spalten, Zeitstempel in zwei verschiedenen Formaten und eine Zielspalte, die erst ab einem Stichtag überhaupt erhoben wurde.

Der Lernwert liegt nicht im Modell. XGBoost oder eine logistische Regression reicht. Der Lernwert liegt in der Datenaufbereitung, im sauberen Umgang mit Leakage und in einer Metrik, die zum Problem passt. Bei seltenen Klassen ist F1 oder PR-AUC oft ehrlicher als Accuracy.

Projekt 2: Ein Projekt mit Deployment oder Automatisierung

Fast niemand stellt ein, damit du Notebooks pflegst. Zeig, dass dein Code irgendwo läuft, ohne dass jemand ihn anstupst. Das kann ein kleiner FastAPI-Endpunkt sein, der eine Vorhersage liefert, ein Skript, das jede Nacht neue Daten lädt und ein Report-PDF erzeugt, oder ein Streamlit-Dashboard, das ein Nicht-Techniker bedienen kann.

Docker-Compose mit zwei Services, ein paar Tests, ein CI-Lauf auf GitHub Actions: Das ist kein übertriebener Aufwand, sondern der Unterschied zwischen "hat gebastelt" und "kann produktiv werden". Und es ist genau die Lücke, die viele Bewerber offen lassen.

Projekt 3: Ein Analyseprojekt mit einer klaren Entscheidung

Nicht jedes Projekt braucht Machine Learning. Ein sauber durchgezogenes Analyseprojekt wirkt oft überzeugender, weil es zeigt, dass du eine Frage beantworten kannst, statt nur ein Modell zu trainieren.

Beispiel: Du analysierst Öffnungszeiten, Wetterdaten und Umsatz einer Restaurantkette und empfiehlst eine konkrete Änderung der Schichtplanung. Am Ende steht keine Metrik, sondern eine Entscheidung mit Zahlen dahinter. Genau so denkt ein Team im Alltag.

Wie du die Projekte im Resume präsentierst#

Ein Resume ist kein Werkverzeichnis. Jede Projektzeile braucht eine Handlung, einen Kontext und ein Ergebnis, das man überprüfen kann. Drei bis vier Zeilen pro Projekt reichen völlig. Alles Längere wird nicht gelesen.

Schwach formuliert: "Machine-Learning-Projekt zur Kundenabwanderung durchgeführt, verschiedene Modelle verglichen."

Umgeschrieben: "Abwanderungsmodell auf 40.000 Transaktionen gebaut (XGBoost, F1 0,71), Datenpipeline mit Tests in Python dokumentiert, Ergebnis als FastAPI-Endpunkt deployed und im README mit den drei größten Fehlerquellen beschrieben."

Der Unterschied: Die zweite Version nennt Umfang, Methode, Metrik und Auslieferungsform. Wer das liest, weiß sofort, was du kannst.

Wenn du unsicher bist, ob dein Resume überhaupt sauber durch automatisierte Vorauswahl kommt, wirf es vorher durch den kostenlosen ATS-Checker. Der zeigt dir, ob Struktur, Schlagwörter und Format überhaupt erkannt werden.

GitHub, so dass es jemand freiwillig öffnet#

Dein GitHub-Profil ist deine Schaufensterfront, und es wird oft vor dem Resume geöffnet. Was zählt, ist Ordnung und Lesbarkeit, nicht die Zahl der Sterne.

• Ein Profil-README, das in fünf Zeilen sagt, wer du bist und woran du arbeitest
• Pro Projekt ein README mit Problemstellung, Datenherkunft, Setup-Befehlen, Ergebnis und bekannten Grenzen
• Klare Ordnerstruktur: src, notebooks, data (ohne große Rohdaten, die gehören nicht ins Repo), tests
• Ein requirements.txt oder eine lock-Datei, damit der Code bei mir wirklich läuft
• Ein Screenshot oder GIF vom Endergebnis direkt oben im README
• Keine abgebrochenen "test123"-Repos in den ersten fünf Zeilen der Übersicht

Pinne die drei relevantesten Repositories. Alles andere tritt zurück.

Fehler, die Projekte nach Tutorial aussehen lassen#

Der häufigste Fehler: Das Projekt endet dort, wo das Tutorial endet. Titanic-Dataset, iris-Digits, ein Kaggle-Notebook mit Standard-Feature-Engineering: Das erkennen Reviewer in zehn Sekunden, und es sagt nichts über dich aus.

Zweiter Fehler: Keine Grenzen benennen. Ein Projekt, das keine Schwächen kennt, wirkt, als hätte sich niemand Gedanken gemacht. Schreib eine Sektion "Limitationen" und meins es ernst.

Dritter Fehler: Modellwahl als Selbstzweck. Wenn du acht Modelle vergleichst und am Ende das komplexeste nimmst, ohne den Trade-off zu erklären, wirkt das wie Beschäftigungstherapie.

Vierter Fehler: Fehlende Reproduzierbarkeit. Wenn ich dein Repo klone und der Befehl aus dem README scheitert, ist das Gespräch für mich erledigt.

Und ein letzter: Metriken ohne Basislinie. Ein F1 von 0,71 klingt gut oder schlecht, je nachdem, wie die Verteilung ist. Nenn immer die Baseline, gegen die du misst.

So redest du im Interview darüber#

Im Gespräch will niemand dein Notebook hören. Gefragt ist, wie du gedacht hast. Bereite dich auf drei Fragen vor und antworte mit einem konkreten Beispiel aus deinem Projekt.

"Warum hast du dich für dieses Modell entschieden?" "Ich habe mit einer logistischen Regression als Baseline angefangen, weil sie interpretierbar ist und wir im Team die Treiber erklären mussten. XGBoost hat den F1-Wert von 0,64 auf 0,71 gehoben, die Verbesserung kam aber fast nur aus zwei Feature-Gruppen. Deshalb bin ich geblieben und habe die Komplexität im Deployment gegen den Gewinn abgewogen."

"Was würdest du heute anders machen?" "Die Zielspalte war erst ab einem Stichtag verfügbar. Ich habe das im zweiten Durchlauf sauberer abgebildet und im ersten Modell vermutlich etwas Leakage drin gehabt. Heute würde ich die zeitliche Aufteilung von Anfang an strikt ziehen."

"Wo versagt dein Modell?" "Bei Kunden mit weniger als drei Transaktionen im Datensatz. Da ist die Unsicherheit hoch, und ich habe im README eine Mindestmenge an Historie als Bedingung notiert, statt das Modell blind anzuwenden."

Kurz, konkret, ohne Show. Das wirkt.

Übrigens: Wenn du dir unsicher bist, was eine Stellenanzeige überhaupt verlangt, hilft ein Blick auf die Decoder-Funktion für Stellenanzeigen. Da sieh du schnell, welche Anforderungen echt gemeint sind und welche nur Standardfloskeln sind.

Wo du passende Stellen findest#

Sobald dein Portfolio steht, such gezielt nach Rollen, die End-to-End-Arbeit wertschätzen. In den aktuellen Stellenangeboten für Data Science findest du schnell heraus, welche Firmen Deployment-Kompetenz erwarten und welche eher Analyse-Schwerpunkte setzen. Orientierung für den Einstieg gibt es außerdem im Karrierebereich mit weiteren Artikeln rund um Bewerbung und Portfolio.

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 Portfolio-Projekte brauche ich für die erste Bewerbung?

Drei saubere Projekte reichen für den Einstieg völlig aus. Lieber drei durchgezogene Fälle mit README, Tests und ehrlichen Grenzen als zehn halbfertige Notebooks, die niemand nachvollziehen kann.

Sollte ich Kaggle-Wettbewerbe ins Portfolio aufnehmen?

Nur, wenn du deinen Weg dorthin dokumentierst. Ein Kaggle-Link allein sagt wenig, weil das Notebook jeder kopieren kann. Beschreib, welche Hypothesen du getestet hast und warum du dich für den finalen Ansatz entschieden hast.

Müssen die Projekte aus der echten Berufserfahrung kommen?

Nein. Private oder ehrenamtliche Projekte funktionieren, solange die Fragestellung real wirkt und die Daten nicht aus dem Standardkatalog stammen. Noch besser: Ein Problem aus einem Nebenjob, einem Verein oder einem öffentlichen Datensatz mit konkretem Nutzen.

Wie aktuell müssen die Projekte sein?

Zwei bis drei Jahre alte Projekte sind in Ordnung, wenn der Code noch läuft und die Methodik nachvollziehbar bleibt. Was schadet, sind veraltete Bibliotheken ohne Anleitung, weil dann niemand reproduzieren kann, was du gemacht hast.

Reicht ein Deployment zwingend, oder genügt ein gutes Notebook?

Für viele Junior-Rollen genügt ein gutes Notebook mit sauberer Dokumentation. Wenn du dich aber auf Rollen bewirbst, die Produktivsysteme erwarten, ist ein kleiner Service mit Tests und CI der schnellste Weg, aus der Masse herauszustechen.