Portfolio Projects for Data Engineer

Du hast zwei Zertifikate, ein paar Udemy-Kurse, und trotzdem meldet sich kaum jemand zurück. Das Problem ist fast nie dein Wissen. Es ist, dass du nichts vorzuweisen hast, was ein Recruiter in 30 Sekunden prüfen kann.

Zertifikate belegen, dass du eine Prüfung bestanden hast. Ein eigenes Projekt zeigt, dass du Daten von A nach B bringst, ohne dass jemand dir die Hand hält. Genau das ist die Einstiegshürde.

Was Reviewer wirklich anschauen#

Wer auch immer deine Bewerbung liest, verbringt keine zehn Minuten mit deinem GitHub. Die Person scannt. Sie will wissen: Versteht dieser Mensch, wie eine Pipeline in der Produktion aussieht, oder hat er nur Tutorials nachgebaut?

Drei Dinge fallen sofort auf. Erstens: Ist der Code lesbar, gibt es Tests, gibt es ein README, das ohne dich verständlich ist. Zweitens: Werden Datenqualität und Fehlerfälle behandelt, oder läuft alles nur im Idealfall. Drittens: Gibt es eine Entscheidung, die du begründest. Warum Postgres statt Mongo, warum Airflow statt ein Cron-Skript, warum Batch statt Streaming.

Ein Portfolio mit drei durchdachten Projekten schlägt jedes Zertifikat, das du oben in den Lebenslauf schreibst. Wenn du wissen willst, wie dein Profil sonst noch wirkt, wirf einen Blick auf den kostenlosen ATS-Check und auf unsere weiteren Tipps im Karrierebereich, siehe der kostenlose ATS-Prüfer und weitere Artikel rund um Bewerbungen.

Projekt 1: eine Datenpipeline mit echten Fehlerquellen#

Baue eine Pipeline, die Daten aus zwei Quellen lädt, sie vereinheitlicht und in eine Datenbank schreibt. Eine Quelle sollte dreckig sein. Nimm eine echte CSV von einer offenen Datenseite, mit Umlauten, leeren Feldern, Datumsformaten quer durch Europa.

Die Pipeline läuft täglich per Cron oder Airflow, loggt, was sie tut, und schreibt fehlgeschlagene Zeilen in eine Fehler-Tabelle statt sie stillschweigend zu verschlucken. Dazu ein Test mit pytest, der prüft, ob die Normalisierung korrekt ist.

Das klingt unspektakulär. Genau deshalb funktioniert es. In jedem Unternehmen geht es am Ende darum, Daten verlässlich von A nach B zu bringen, und die langweiligen Fälle sind die teuren.

Projekt 2: ein kleines Warehouse mit Modellierung#

Nimm einen Datensatz mit mindestens zwei Entitäten, zum Beispiel Bestellungen und Kunden, und baue daraus ein Sternschema. Fakten-Tabelle, Dimensionstabellen, ein paar Views für typische Auswertungen. Dokumentiere die Grain-Angabe, also was eine Zeile genau bedeutet. Das ist der Punkt, an dem viele scheitern.

Schreib dazu drei SQL-Abfragen, die ein Analyst wirklich stellen würde: Umsatz pro Monat und Region, Kunden ohne Bestellung in den letzten 90 Tagen, Top-Produkte nach Marge. Zeig den Ausführungsplan einer davon und erklär kurz, wo du einen Index gesetzt hast.

Wenn du mit dbt arbeiten willst, ist das hier der richtige Moment. Aber auch ohne dbt zählt die Modellierung. Ein Reviewer sieht in zwei Minuten, ob du verstanden hast, wie man Daten strukturiert, oder ob du einfach alles in eine Tabelle gekippt hast.

Projekt 3: Streaming oder Orchestrierung, aber mit Monitoring#

Dieses Projekt darf kleiner sein, muss aber eine Produktionsfrage beantworten. Entweder du verarbeitest Events mit Kafka oder einem einfachen Redis-Stream und zeigst, wie du mit Backpressure umgehst. Oder du baust eine Airflow-Orchestrierung mit Retries, Alerts bei Fehlern und einer klaren DAG-Struktur.

Wichtig ist, dass du zeigst, was passiert, wenn etwas schiefgeht. Ein Job, der um 3 Uhr nachts fehlschlägt und niemanden weckt, ist in der Produktion wertlos. Beschreib im README, wie dein System sich verhält, wenn die Quelle nicht antwortet.

Zur Not reicht auch ein einfacher Ansatz. Ein Skript, das bei Fehlern eine Mail schickt und den letzten erfolgreichen Lauf protokolliert, zeigt mehr Verständnis als eine Kafka-Installation, die nur im Happy Path läuft.

So präsentierst du die Projekte auf GitHub#

Jedes Repo braucht ein README, das mit einem Satz beginnt: Was macht das Ding und welches Problem löst es. Danach: Architektur in einem Satz oder einem Diagramm, wie man es lokal startet, welche Daten du verwendest, welche Annahmen du getroffen hast.

Strukturier das README so:

• Problem in einem Satz, für wen das relevant ist
• Architektur oder Datenfluss, gern als einfaches Diagramm
• Setup in drei bis fünf Befehlen, ohne Rätselraten
• Annahmen und bewusste Vereinfachungen, offen benannt
• Was du als Nächstes bauen würdest, mit konkretem Grund

Der letzte Punkt wird oft vergessen, ist aber wirksam. Er zeigt, dass du weißt, wo die Grenzen deines Projekts liegen. Wer behauptet, alles sei fertig und perfekt, wirkt unerfahren.

Halte die Repos sauber. Keine Riesen-Commits mit 40 Dateien am Stück, keine auskommentierten Code-Friedhöfe, keine API-Keys im Repo. Ein Reviewer, der einen API-Key findet, klickt weg.

So schreibst du es in den Lebenslauf#

Viele schreiben sowas wie: „Datenpipeline-Projekt mit Python und SQL." Das sagt nichts. Ein Reviewer will Ergebnis, Umfang, deine Entscheidung. Hier ein vorher-nachher-Beispiel:

Vorher: „Eigenes ETL-Projekt mit Python, PostgreSQL und Docker."

Nachher: „Eigene Pipeline, die täglich 2 Quellen (CSV, REST) mit ca. 200.000 Zeilen lädt, Fehlerzeilen in eine Quarantäne-Tabelle schreibt und per Airflow mit Retries gesteuert wird. 12 pytest-Tests, Setup in unter 10 Minuten reproduzierbar."

Der Unterschied ist nicht die Länge. Es ist die Zahl und die Entscheidung dahinter. Wenn du wissen willst, wie deine Formulierungen sonst ankommen, hilft ein Blick auf den Job-Angebots-Entschlüsseler, der zeigt, welche Begriffe aus der Stellenanzeige du spiegeln solltest.

Fehler, die Projekte nach Tutorial aussehen lassen#

Der häufigste Fehler: das Titanic-Dataset oder der Iris-Datensatz. Jeder kennt die Lösung, niemand wird beeindruckt. Nimm Daten, die niemand auswendig kennt.

Der zweite Fehler: keine Begründung für Technologiewahl. „Ich habe MongoDB benutzt" ohne Warum liest sich wie ein Kursprojekt. Schreib einen Satz dazu, warum, und was du verworfen hast.

Der dritte Fehler: fehlende Fehlerbehandlung. Wenn dein Code nur im Idealfall läuft, hast du kein Projekt, sondern ein Skript. Zeig mindestens einen Case, in dem etwas schiefgeht.

• Datenquelle, die niemand auswendig kennt, statt Standard-Datasets
• Begründung für jede Technologieentscheidung, kurz im README
• Mindestens ein Fehlerfall, der getestet und dokumentiert ist
• Tests, die etwas prüfen, nicht nur Coverage-Padding
• Klare Angabe, was eine Zeile bedeutet, in jeder Tabelle
• Keine Secrets im Repo, .env.example stattdessen
• Reproduzierbares Setup, das in unter 10 Minuten läuft

So redest du in Interviews darüber#

Erwarte mindestens eine Frage zu einem Projekt, meist als Einstieg. Die Formel ist simpel: Problem, deine Entscheidung, Ergebnis, was du anders machen würdest. Halte es unter zwei Minuten und lass dich dann ausfragen.

Ein konkretes Beispiel für eine Antwort auf „Erzähl mir von deinem Datenprojekt":

„Ich habe eine Pipeline gebaut, die täglich zwei Quellen lädt, eine CSV und eine REST-Schnittstelle. Die CSV hatte keine sauberen Datumsformate, also habe ich eine Normalisierungsschicht eingezogen und fehlerhafte Zeilen in eine Quarantäne-Tabelle geschrieben, statt sie zu verwerfen. Das Ganze läuft über Airflow mit zwei Retries und einer Mail bei Fehlschlag. Was ich anders machen würde: Ich würde die Schemaprüfung früher einziehen, aktuell fällt ein Spaltenfehler erst beim Laden auf."

Die letzte Satzhälfte ist die wichtigste. Interviewer hören genau hin, wenn du Schwächen selbst benennst. Wer behauptet, alles sei perfekt gebaut, signalisiert mangelnde Selbsteinschätzung.

Bereite zwei Gegenfragen vor, die du stellen kannst, wenn du am Zug bist. Zum Beispiel, wie das Team Datenqualität handhabt, oder welche Tools im aktuellen Stack fehlen. Das wirkt vorbereitet, ohne aufgesetzt zu sein.

Wenn du nach passenden Stellen suchst, lohnt ein Blick auf die aktuellen Stellenangebote für Data Engineer, dort siehst du, welche Begriffe gerade gefragt sind, und kannst deine Projekte daran ausrichten.

Häufige Fragen#

Wie viele Projekte brauche ich wirklich?

Drei durchdachte Projekte reichen für die meisten Bewerbungen. Lieber drei, die du erklären kannst, als acht halbfertige Repos, die niemand versteht.

Reichen Zertifikate nicht für den Einstieg?

Zertifikate helfen bei HR-Filtern, ersetzen aber keine Projekte. Wenn du dich zwischen einem weiteren Zertifikat und einem eigenen Projekt entscheiden musst, nimm das Projekt.

Sollte ich die Projekte auf Englisch dokumentieren?

Englisch ist im Data Engineering Standard und wird in fast allen Teams erwartet. Schreib READMEs auf Englisch, auch wenn du dich im DACH-Raum bewirbst.

Was, wenn meine Projekte klein sind?

Klein ist in Ordnung, solange die Entscheidungen begründet sind und Fehlerfälle abgedeckt sind. Beschreib offen, was du weggelassen hast und warum, das wirkt erfahrener als künstliche Größe.

Wie aktuell müssen die Tools sein?

Es geht weniger um Trends als um Verständnis von Grundlagen. Wer eine saubere Pipeline ohne Framework baut, zeigt mehr als jemand, der das neueste Tool anreißt, ohne es zu verstehen.