Was wird im Vorstellungsgespräch als Data Engineer am häufigsten gefragt?

Entwurf von Pipelines, SQL und Datenmodellierung, Batch gegen Streaming, Datenqualität, Performance und Kosten und bei Senior-Rollen Entscheidungen über die Plattform und die Führung von Engineers.

Gibt es eine Coding-Runde?

Meistens: Fragen zu SQL und oft eine kleine Aufgabe in Python. Übe beides und erkläre dabei laut, wie du denkst.

Muss ich Spark können?

Bei großen Datenmengen oft ja. In Teams mit einem Cloud-Warehouse und dbt zählen starkes SQL und Modellierung mehr.

Ein Cloud-Zertifikat für Daten hilft bei Beratungshäusern und manchen großen Firmen. Pipelines, die du gebaut und betrieben hast, zählen mehr.

Wie bereite ich mich in einer Woche vor?

Sag die beiden ausgearbeiteten Antworten laut, übe Joins und Fensterfunktionen in SQL und bereite je eine Geschichte zu einem Fehler, einer Beschleunigung und einer Kosteneinsparung vor.

Interviewfragen für Data Engineers, mit ausgearbeiteten Antworten

Sechzehn Fragen, die in Vorstellungsgesprächen für Data Engineers immer wieder kommen, vom ersten Datenjob bis zum Lead und Datenarchitekten. Zu jeder: worauf der Interviewer achtet, eine kurze Antwort, die ausführliche Antwort in einfachen Worten, eine schwache Antwort, die du vermeiden solltest, und eine typische Nachfrage.

Das cvscored-TeamVeröffentlicht 05.11.2026 · Aktualisiert 05.11.2026

Inhalt

So nutzt du diese Fragen
Was ein Data Engineer können muss
Entwurf von Pipelines
Datenmodellierung und SQL
Datenqualität und der Betrieb von Pipelines
Big Data, Performance und Kosten
Plattformen, Standards und die Führung von Engineers
Dein Lebenslauf für diese Fragen
Das Wichtigste
Häufige Fragen
Mehr zu diesem Beruf

So nutzt du diese Fragen

Lies die kurze Antwort und sag sie laut. Das sind deine ersten dreißig Sekunden. Dann lies die ausführliche Antwort und wähle zwei oder drei Punkte, die du ergänzt, mit einem Beispiel aus deiner eigenen Arbeit: die Datenmenge, das Tool, was kaputtging und was du geändert hast. Interviewer wollen Gründe hören, keine Liste von Tools.

Was ein Data Engineer können muss

Sprachen: SQL in der Tiefe und Python für Pipeline-Schritte und kleine Tools.
Verarbeitung: Batch (große Mengen nach Zeitplan) und Streaming (Ereignisse, sobald sie passieren), mit Tools wie Spark und Kafka.
Orchestrierung: Schritte in der richtigen Reihenfolge laufen lassen, mit Wiederholungen und Alarmen, zum Beispiel in Airflow.
Modellierung: Tabellen so formen, dass sie zu den Menschen passen, die sie nutzen, oft als dbt-Modelle in einem Warehouse wie Snowflake.
Cloud: die Datendienste von AWS, Azure oder Google Cloud und was sie kosten.
Gewohnheiten aus dem Engineering: Git, Tests, CI/CD und Docker, genau wie in der Softwareentwicklung.
Recht und Vertrauen: personenbezogene Daten nach der DSGVO (EU) und ähnlichen Gesetzen: was gespeichert wird, wie lange und wer es sehen darf.

Entwurf von Pipelines

Entwirf eine Pipeline, die jede Nacht die Bestellungen von gestern aus der Datenbank des Shops ins Warehouse lädt.

Worauf sie achten: dass du an den ganzen Weg denkst: Quelle, Ladung, Prüfungen, Fehler und die Menschen, die das Ergebnis nutzen.

Kurze Antwort: „Ich kopiere nur die geänderten Zeilen aus der Quelle, lege sie roh im Speicher ab und bereinige und modelliere sie dann im Warehouse. Die Schritte laufen in einem Orchestrator mit Wiederholungen. Jeder Lauf lässt sich gefahrlos wiederholen, Prüfungen halten schlechte Daten von den Berichten fern, und jemand bekommt einen Alarm, wenn es spät wird.“

Die ausführliche Antwort, in sechs Schritten:

Erst fragen. Wer nutzt die Daten, bis wann und wie frisch müssen sie sein? Ein Bericht, der um neun Uhr morgens gelesen wird, setzt die Frist für die ganze Kette.
Schonend extrahieren. Lies aus einer Replik der Datenbank, nicht aus der laufenden, und nimm nur die Zeilen, die sich seit dem letzten Lauf geändert haben, über eine Spalte mit dem Änderungsdatum oder über Change Data Capture (das Lesen des eigenen Änderungsprotokolls der Datenbank).
Roh ablegen. Speichere die Kopie so, wie sie kam, in einem Rohbereich des Data Lake oder Warehouse, nach Tagen aufgeteilt. Gehen spätere Schritte schief, kannst du von hier neu aufbauen, ohne die Quelle noch einmal zu fragen.
Transformieren. Bereinige Datentypen, entferne Duplikate, verknüpfe mit Kunden und Produkten und bau die Tabellen, die die Berichte lesen, zum Beispiel mit dbt-Modellen.
Prüfen. Zeilenzahlen gegen die Quelle, keine leeren Schlüssel, Summen im üblichen Bereich. Eine fehlgeschlagene Prüfung stoppt den Lauf, bevor sich der Bericht aktualisiert.
Laufen lassen und beobachten. Ein Orchestrator wie Airflow lässt die Schritte der Reihe nach laufen, wiederholt kurze Fehler und alarmiert das Team, wenn die Daten nicht rechtzeitig bereit sind.

Schwache Antwort: „Ich schreibe ein Skript, das jede Nacht die ganze Tabelle kopiert.“ Das geht, bis die Tabelle groß ist; dann belastet es die Quelle und reißt die Frist.

Nachfrage: „Der Job ist bei Schritt vier fehlgeschlagen und noch einmal gelaufen. Hast du die Bestellungen jetzt doppelt?“ Nicht, wenn jeder Schritt idempotent ist: Zweimal laufen ergibt dasselbe Ergebnis wie einmal, zum Beispiel weil du die Partition eines ganzen Tages ersetzt, statt Zeilen anzuhängen.

Wann würdest du Streaming statt Batch wählen?

Worauf sie achten: dass du danach wählst, was das Geschäft braucht, nicht danach, was spannend ist.

Kurze Antwort: „Batch, nach Zeitplan, ist einfacher und günstiger und für die meisten Berichte richtig. Streaming lohnt sich, wenn jemand innerhalb von Sekunden oder Minuten auf die Daten reagiert: Betrugsprüfungen, Lagerbestände, Live-Tracking. Bevor ich wähle, frage ich, wie frisch die Daten wirklich sein müssen.“

Die ausführliche Antwort: Streaming heißt, jedes Ereignis zu verarbeiten, sobald es ankommt, oft aus Kafka, einem System, das Ströme von Ereignissen in ihrer Reihenfolge speichert. Es bringt neue Probleme: Ereignisse kommen spät oder doppelt, die Reihenfolge kann sich ändern, und das System läuft ständig, also muss jemand in Rufbereitschaft sein. Micro-Batch, kleine Batches alle paar Minuten, ist ein Mittelweg, den viele Teams nutzen. Lautet die Antwort auf „wie frisch?“ „bis morgen früh“, gewinnt Batch.

Schwache Antwort: „Streaming ist immer besser, weil die Daten in Echtzeit sind.“ Nachfrage: „Ein Ereignis kommt zwei Stunden zu spät. Was passiert mit den Summen von gestern?“ Nutze den Zeitpunkt, an dem das Ereignis passiert ist, nicht den, an dem es ankam, lass ein Zeitfenster für späte Ereignisse und korrigiere die Summen, wenn sie eintreffen.

Was tust du, wenn ein Quellsystem sein Schema ändert, ohne dir Bescheid zu sagen?

Worauf sie achten: dass du mit Änderungen rechnest und die Menschen weiter hinten in der Kette schützt.

Kurze Antwort: „Ich erkenne es, bevor es Berichte kaputt macht: Die Ladung prüft die Spalten und Datentypen, die sie erwartet. Eine neue Spalte darf durch; eine entfernte oder umbenannte stoppt den Lauf und alarmiert uns. Dann vereinbare ich mit dem Team der Quelle, wie Änderungen künftig angekündigt werden.“

Die ausführliche Antwort: Ein Schema ist die Liste der Spalten und ihrer Datentypen. Die Daten zuerst roh abzulegen, hilft, denn so geht nichts verloren, wenn sich die Form ändert. Formate wie Avro oder Parquet tragen ihr Schema mit sich, und eine Schema Registry hält die vereinbarten Versionen für Streams fest. Die dauerhafte Lösung ist ein Data Contract: eine schriftliche Vereinbarung mit dem Team der Quelle über die Felder, ihre Bedeutung und wie lange vorher eine Änderung angekündigt werden muss.

Schwache Antwort: „Ich repariere die Pipeline, wenn sie kaputtgeht.“ Nachfrage: „Das Team der Quelle sagt, es kann nichts vorher ankündigen.“ Bitte um eine Testkopie ihrer Änderungen oder lies aus einem Ereignis, das sie gezielt veröffentlichen, statt aus ihren internen Tabellen.

Datenmodellierung und SQL

Wie würdest du Vertriebsdaten modellieren, damit Analysten sie leicht nutzen können?

Worauf sie achten: dass du Daten nach den Fragen formst, die Menschen stellen, und die üblichen Muster kennst.

Kurze Antwort: „Ich würde ein Sternschema bauen: eine Faktentabelle mit einer Zeile pro Verkauf und den Zahlen, umgeben von Dimensionstabellen für Kunde, Produkt, Filiale und Datum. Analysten verknüpfen von den Fakten zu allem, wonach sie aufschlüsseln wollen, und die Regeln liegen an einer Stelle.“

Die ausführliche Antwort: Ein Datenmodell ist die Art, wie Tabellen geformt und verbunden sind. In einem Sternschema sind Fakten Ereignisse mit Zahlen (ein Verkauf, ein Klick), und Dimensionen beschreiben sie (wer, was, wo, wann). Es ist leicht zu lesen und schnell in einem Warehouse. Leg zuerst die Granularität fest, also was eine Zeile bedeutet, denn gemischte Granularitäten führen zu doppelt gezählten Werten. Für Historie, etwa einen Kunden, der in eine andere Stadt zieht, behält eine Slowly Changing Dimension die alte Zeile mit Datumsangaben, statt sie zu überschreiben, damit alte Verkäufe weiter für die alte Stadt zählen.

Schwache Antwort: „Ich würde alles in eine große Tabelle packen.“ Nachfrage: „Finanzen und Vertrieb zählen den Umsatz verschieden.“ Vereinbare mit beiden eine Definition, schreib sie auf und bau sie einmal ins Modell, mit einem eigenen Measure, wenn sie wirklich zwei brauchen.

Eine Abfrage, die früher Sekunden brauchte, braucht jetzt zwanzig Minuten. Wie findest du heraus, warum?

Worauf sie achten: ein ruhiger, geordneter Weg, den langsamen Teil zu finden.

Kurze Antwort: „Ich lese den Ausführungsplan, um zu sehen, welcher Schritt die Zeit braucht, und prüfe dann, was sich geändert hat: mehr Daten, ein neuer Join, fehlende Statistiken oder ein Filter, der die Partition nicht mehr nutzt. Ich behebe genau diesen Schritt und messe noch einmal.“

Die ausführliche Antwort: Der Ausführungsplan ist die eigene Beschreibung der Datenbank, wie sie die Abfrage ausführen wird. Häufige Ursachen: ein Join, der Zeilen vervielfacht, weil ein Schlüssel nicht eindeutig ist; ein Filter, der in eine Funktion verpackt ist, sodass die Datenbank keine Partitionen überspringen kann; das Lesen aller Spalten, wenn wenige gebraucht werden; und eine Tabelle, die auf das Zehnfache gewachsen ist. In einem Warehouse lässt Partitionieren oder Clustern großer Tabellen nach Datum oder Kunde eine Abfrage nur den Teil lesen, den sie braucht; das spart Zeit und Geld.

Schwache Antwort: „Ich würde ein größeres Warehouse beantragen.“ Nachfrage: „Der Plan zeigt einen riesigen Join.“ Prüf die Join-Schlüssel auf Duplikate, filtere vor dem Join und verdichte die große Seite vorab, wenn das Detail nicht gebraucht wird.

Datenqualität und der Betrieb von Pipelines

Eine Führungskraft sagt, eine Zahl im Dashboard sei falsch. Wie findest du die Ursache?

Worauf sie achten: dass du Schritt für Schritt rückwärts arbeitest und die Ursache behebst, nicht nur die Zahl.

Kurze Antwort: „Zuerst finde ich heraus, was sie erwartet hat und warum, dann verfolge ich die Zahl durch jeden Schritt zurück: den Bericht, das Modell, die bereinigten Daten, die Rohdaten, die Quelle. Der Schritt, an dem sie sich ändert, ist der, an dem das Problem sitzt. Ich behebe es, korrigiere die vergangenen Daten und füge eine Prüfung hinzu, die es gefunden hätte.“

Die ausführliche Antwort, in fünf Schritten:

Die Behauptung verstehen. Welche Zahl, welcher Tag, verglichen womit? Oft stimmt der Bericht, und die Definition ist eine andere, zum Beispiel aufgegebene gegen gelieferte Bestellungen.
Aktualität prüfen. Ist der Lauf von letzter Nacht fertig geworden? Eine späte Ladung sieht aus wie eine falsche Zahl.
Zurückverfolgen. Rechne die Zahl auf jeder Schicht der Pipeline nach, bis zwei benachbarte Schichten nicht übereinstimmen. Dieser Schritt enthält die Ursache: ein verlorener Join, ein Duplikat, ein geänderter Filter, eine Zeitzone.
Beheben und nachladen. Korrigiere den Schritt und lass die betroffenen Tage neu laufen. Ein Backfill ist das erneute Laufen einer Pipeline für vergangene Tage; er ist nur sicher, wenn die Schritte idempotent sind.
Vorbeugen. Füge an dieser Stelle einen Test der Datenqualität hinzu, sag den Menschen Bescheid, die die falsche Zahl genutzt haben, und schreib kurz auf, was passiert ist.

Schwache Antwort: „Ich würde die Zahl im Bericht ändern.“

Nachfrage: „Das Quellsystem selbst hat schlechte Daten.“ Markiere die schlechten Zeilen oder stell sie unter Quarantäne, melde sie mit Beispielen dem Verantwortlichen der Quelle und vereinbare, wer sie behebt; korrigiere sie nicht stillschweigend im Warehouse.

Wie testest du Datenpipelines?

Worauf sie achten: dass du den Code und die Daten testest, automatisch.

Kurze Antwort: „Ich teste die Logik vor dem Release mit kleinen, ausgedachten Eingaben, und ich teste die echten Daten bei jedem Lauf: keine fehlenden Schlüssel, keine Duplikate, Werte im Bereich, Zeilenzahlen, die zur Quelle passen. Tests laufen in der CI, bevor eine Änderung gemergt wird, und Datenprüfungen blockieren eine schlechte Ladung.“

Die ausführliche Antwort: Unit Tests prüfen eine Transformation mit wenigen Zeilen, deren Ergebnis du kennst. Datentests, wie sie Tools wie dbt oder Great Expectations ausführen, prüfen jeden Tag Annahmen über die echten Daten. Eine Staging-Kopie mit einer Stichprobe der Produktionsdaten findet Probleme, die eine ausgedachte Eingabe übersieht. Und jede Änderung geht durch ein Review in Git und durch CI/CD, die automatische Strecke für Test und Auslieferung, wie jede andere Software.

Schwache Antwort: „Ich schaue mir das Ergebnis nach dem Lauf an.“ Nachfrage: „Welchen Test würdest du einer ungetesteten Pipeline zuerst hinzufügen?“ Prüfungen auf Eindeutigkeit und Nicht-leer bei den wichtigsten Schlüsseln, denn Duplikate und fehlende Schlüssel verursachen die meisten falschen Zahlen.

Wie richtest du die Orchestrierung ein, damit ein Team den nächtlichen Läufen vertrauen kann?

Worauf sie achten: Wiederholungen, Abhängigkeiten, Alarme und die Gewohnheiten darum herum.

Kurze Antwort: „Jede Pipeline ist eine Reihe von Schritten mit klaren Abhängigkeiten in einem Orchestrator, mit Wiederholungen für kurze Fehler, Zeitlimits und Alarmen, die bei den Menschen ankommen, die handeln können. Läufe lassen sich gefahrlos wiederholen, und jeder hat einen Verantwortlichen und eine Frist, an der die Alarme gemessen werden.“

Die ausführliche Antwort: In Airflow oder einem ähnlichen Tool ist eine Pipeline als Graph von Schritten gezeichnet, sodass ein Schritt nur läuft, wenn die Schritte davor erfolgreich waren. Wiederhole einen Netzwerkfehler; wiederhole keine fehlgeschlagene Datenprüfung, die braucht einen Menschen. Alarmiere bei Verspätung, nicht nur bei Fehlern, denn ein Job, der hängt, schlägt nie fehl. Bewahre Secrets wie Passwörter in einem Secret Store auf, nicht in den Dateien der Pipeline. Schreib pro Pipeline ein kurzes Runbook: was sie tut, wer sie nutzt und was zu tun ist, wenn sie fehlschlägt.

Schwache Antwort: „Wir nutzen Cron und schauen morgens in die Logs.“ Nachfrage: „Jede Nacht gehen Alarme los, und alle ignorieren sie.“ Entferne oder repariere die lauten; ein Alarm, auf den niemand reagiert, ist schlimmer als keiner.

Nach einer Änderung der Logik musst du zwei Jahre Daten per Backfill neu laden. Wie machst du das sicher?

Worauf sie achten: dass du die Historie neu laufen lassen kannst, ohne die heutigen Läufe oder das Budget zu sprengen.

Kurze Antwort: „Ich lasse es in Scheiben laufen, einen Tag oder einen Monat auf einmal, in eine eigene Tabelle, vergleiche die neuen Ergebnisse auf ein paar Scheiben mit den alten und tausche die Tabellen, wenn die Prüfungen bestanden sind. Es läuft in ruhigen Stunden mit begrenzten Ressourcen, damit die nächtliche Pipeline nicht langsamer wird.“

Die ausführliche Antwort: Ein Backfill ist nur sicher, wenn sich jede Scheibe allein neu laufen lässt und jedes Mal dieselbe Antwort gibt; die Schritte müssen also idempotent und nach Datumspartition aufgeteilt sein. Schätze die Kosten zuerst, indem du eine Scheibe laufen lässt. Sag den Nutzern, dass sich die Historie ändern wird, und warum. Behalte die alte Tabelle eine Weile, falls die neue Logik falsch ist. Die meisten Orchestratoren können einen Backfill für einen Zeitraum laufen lassen, mit einer Grenze, wie viele Läufe gleichzeitig laufen.

Schwache Antwort: „Ich lösche die Tabelle und lasse die ganze Historie über Nacht laufen.“ Nachfrage: „Auf halbem Weg fehlen die alten Daten im Quellsystem.“ Bau diese Monate aus den Rohkopien neu, die du abgelegt hast; genau deshalb werden Rohdaten aufbewahrt.

Wie gehst du in einer Pipeline mit personenbezogenen Daten um?

Worauf sie achten: dass Datenschutz in den Entwurf eingebaut ist und nicht am Ende dazukommt.

Kurze Antwort: „Ich nehme nur die personenbezogenen Felder, die gebraucht werden, maskiere oder entferne den Rest früh, begrenze, wer den Rohbereich sehen darf, und sorge dafür, dass Daten gelöscht werden, wenn die Regeln es verlangen, auch in Kopien und Backups. Nach der DSGVO in der EU kann eine Person außerdem die Löschung ihrer Daten verlangen, also muss die Pipeline sie finden können.“

Die ausführliche Antwort: Stufe Spalten als personenbezogen oder nicht ein, wenn sie auf die Plattform kommen. Pseudonymisiere, wo du kannst: Ersetze einen Namen oder eine E-Mail-Adresse durch einen Schlüssel, damit Analysten Personen zählen können, ohne zu sehen, wer sie sind. Vergib Zugriffe nach Rollen und protokolliere, wer sensible Tabellen liest. Leg eine Speicherdauer pro Datenbestand fest und lösche automatisch. In der EU begrenzt die DSGVO auch, personenbezogene Daten aus der EU hinauszubringen, was beeinflusst, wo der Cloud-Speicher liegt. Arbeite früh mit dem Datenschutzbeauftragten zusammen.

Schwache Antwort: „Sicherheit ist Sache der IT-Abteilung.“ Nachfrage: „Analysten brauchen die E-Mail-Adresse, um mit einem Marketing-Tool zu verknüpfen.“ Verknüpfe über einen gehashten oder pseudonymisierten Schlüssel an einer kontrollierten Stelle und gib nur weiter, was das Tool braucht.

Big Data, Performance und Kosten

Ein Spark-Job, der einen Tag an Daten verarbeitet, ist sehr langsam geworden. Wo schaust du nach?

Worauf sie achten: dass du verstehst, wie Spark die Arbeit aufteilt, und seine üblichen Fallen kennst.

Kurze Antwort: „Ich öffne die Spark UI, um die langsame Stage zu finden, und suche dann nach den üblichen Ursachen: ein Shuffle, der zu viele Daten bewegt, Skew, bei dem eine Partition viel größer ist als der Rest, zu viele winzige Dateien oder das Lesen von weit mehr Daten als nötig.“

Die ausführliche Antwort: Spark teilt Daten in Partitionen und bearbeitet sie parallel. Bei einem Shuffle müssen Daten zwischen Maschinen wandern, für einen Join oder ein Group By; er ist der teuerste Schritt. Skew entsteht, wenn ein Schlüssel, etwa ein riesiger Kunde, die meisten Zeilen hält, sodass ein Worker die ganze Arbeit macht; den Schlüssel zu salzen oder diesen Kunden getrennt zu behandeln, hilft. Schick eine kleine Tabelle per Broadcast an jeden Worker, statt die große zu shuffeln. Filtere und wähle Spalten früh aus. Fasse viele kleine Dateien zu wenigen großen zusammen. Ältere Plattformen auf Hadoop haben dieselben Probleme.

Schwache Antwort: „Ich würde mehr Maschinen dazunehmen.“ Nachfrage: „Ein Task läuft eine Stunde, während die anderen in einer Minute fertig sind.“ Das ist Skew: Finde den schweren Schlüssel und teile ihn auf.

Die Cloud-Rechnung der Datenplattform hat sich in drei Monaten verdoppelt. Was tust du?

Worauf sie achten: dass du Kosten als Teil des Jobs behandelst und zuerst die großen Posten findest.

Kurze Antwort: „Ich finde heraus, wohin das Geld geht, nach Dienst, Warehouse, Job und Team, und fange bei den größten Posten an. Typische Einsparungen: Abfragen, die ganze Tabellen scannen, Jobs, die niemand mehr nutzt, Warehouses, die nie pausieren, und Daten, die jahrelang in teurem Speicher liegen.“

Die ausführliche Antwort: Versieh jede Ressource mit einem Tag für Team und Pipeline, damit sich die Kosten zuordnen lassen. Dann schau dir die zehn größten Jobs und Abfragen an: Partitioniere oder clustere große Tabellen, damit Abfragen weniger lesen; lass schwere Jobs seltener laufen, wenn die Nutzer sie nicht stündlich brauchen; lass Warehouses im Leerlauf pausieren; verschiebe alte Rohdaten mit einer Aufbewahrungsregel in günstigeren Speicher. Vereinbare ein Budget pro Team und einen Alarm, wenn es überschritten wird, damit eine Überraschung wie diese in einer Woche auffällt, nicht in drei Monaten.

Schwache Antwort: „Die Cloud kostet eben, was sie kostet.“ Nachfrage: „Das Dashboard eines Teams aktualisiert sich alle fünf Minuten und kostet am meisten.“ Frag, wie oft sie wirklich hinschauen; eine Aktualisierung pro Stunde oder eine kleine Übersichtstabelle kann den Großteil der Kosten sparen.

Plattformen, Standards und die Führung von Engineers

Diese Fragen kommen bei Senior und Lead Data Engineers und bei Rollen als Datenarchitekt.

Wie würdest du zwischen einem Data Warehouse, einem Data Lake und einem Lakehouse wählen?

Worauf sie achten: dass du nach Bedarf und Team wählst, nicht nach der Mode.

Kurze Antwort: „Ein Warehouse ist am besten für saubere, strukturierte Daten und Berichte in SQL. Ein Data Lake speichert beliebige Daten günstig, auch Dateien und Logs, braucht aber mehr Pflege, um nutzbar zu bleiben. Ein Lakehouse setzt Funktionen eines Warehouse, etwa Tabellen und Transaktionen, auf den Speicher eines Data Lake. Ich wähle nach den Daten, den Nutzern, den Fähigkeiten des Teams und den Kosten.“

Die ausführliche Antwort: Schreiben die meisten Nutzer SQL und kommen die Daten aus Geschäftssystemen, ist ein verwaltetes Warehouse wie Snowflake oder BigQuery einfach und schnell. Hat die Firma auch große Dateien, Ereignisse und Machine Learning, vermeidet ein Lakehouse auf offenen Tabellenformaten wie Delta oder Iceberg zwei Kopien. Ein Datenarchitekt fragt außerdem: Wer betreibt es, wie wird der Zugriff kontrolliert, und wie leicht kommt man vom Anbieter wieder weg? Schreib die Entscheidung und ihre Gründe auf, damit das nächste Team sie versteht.

Schwache Antwort: „Wir sollten nehmen, was am neuesten ist.“ Nachfrage: „Die Geschäftsleitung will eine Plattform für alles.“ Zeig die Kosten und das Risiko des Umzugs und fang mit einer Domäne an, um es zu beweisen, bevor der Rest umzieht.

Wie bringst du andere Teams dazu, für die Qualität der Daten einzustehen, die sie dir schicken?

Worauf sie achten: dass ein Senior Data Engineer Probleme an der Quelle behebt, über Vereinbarungen, nicht über Heldentaten.

Kurze Antwort: „Mit Data Contracts: Das Team der Quelle vereinbart, welche Felder es schickt, was sie bedeuten, wie gut sie sein müssen und wie Änderungen angekündigt werden. Prüfungen an der Grenze zeigen, wer was kaputt gemacht hat, und die Qualitätszahlen werden offen geteilt.“

Die ausführliche Antwort: Viele Datenprobleme beginnen dort, wo Daten entstehen. Ein Contract macht das Versprechen sichtbar; eine automatische Prüfung bei der Ankunft setzt es durch. Data Mesh ist ein Ansatz, bei dem jeder Geschäftsbereich seine Daten als Produkt verantwortet, mit einem Team, das dafür einsteht, und das zentrale Plattformteam die Tools stellt. Es braucht reife Teams; die meisten Firmen übernehmen Teile davon, etwa benannte Verantwortliche pro Datenbestand, ohne das ganze Modell.

Schwache Antwort: „Wir bereinigen alles im Warehouse.“ Nachfrage: „Ein Team weigert sich, einen Contract zu unterschreiben.“ Zeig ihm, was seine schlechten Daten Menschen kosten, die ihm wichtig sind, und fang mit den zwei oder drei Feldern an, auf die es am meisten ankommt.

Wie setzt du als Lead Data Engineer Standards für ein Team von Engineers?

Worauf sie achten: bei Lead-Rollen Führung über klare Regeln, Reviews und Coaching.

Kurze Antwort: „Ich vereinbare mit dem Team wenige Standards: wie Pipelines benannt und getestet werden, wie Änderungen geprüft werden und was jede Pipeline vor dem Release haben muss, etwa einen Verantwortlichen, Tests, Alarme und ein Runbook. Mit Vorlagen mache ich den richtigen Weg zum einfachen, und ich coache über Reviews und Pairing.“

Die ausführliche Antwort: Standards, an die sich niemand hält, sind schlimmer als keine, also halte sie kurz und setze sie in CI/CD durch, nicht in Meetings. Eine Vorlage für eine neue Pipeline gibt allen denselben Start. Regelmäßige Design-Reviews finden Probleme, bevor sie gebaut werden. Ein Lead plant außerdem die Arbeit mit dem Geschäft, schützt Zeit für die Reparatur alter Pipelines und hilft jedem Engineer zu wachsen: neue Verantwortung, ehrliches Feedback und sichtbare Anerkennung.

Schwache Antwort: „Ich prüfe jeden Pull Request selbst.“ Nachfrage: „Ein Senior Engineer übergeht immer wieder die Standards.“ Sprich unter vier Augen mit ihm, versteh den Grund und ändere den Standard, wenn er falsch ist, oder bleib dabei, wenn nicht.

Wie würdest du den Umzug einer alten On-Premise-Datenplattform in die Cloud planen?

Worauf sie achten: bei Senior- und Architektenrollen eine große Änderung mit wenig Risiko planen.

Kurze Antwort: „Ich liste auf, was es gibt und wer es nutzt, streiche, was niemand nutzt, und ziehe in Wellen um, beginnend mit einer Domäne mit wenig Risiko. Alt und Neu laufen nebeneinander, mit Prüfungen, ob ihre Zahlen übereinstimmen, bis die Nutzer umgezogen sind. Dann wird der alte Teil abgeschaltet.“

Die ausführliche Antwort: Die meisten alten Plattformen, zum Beispiel auf Hadoop, haben viele Jobs, an die sich niemand erinnert; eine Liste mit Verantwortlichen und Nutzern streicht oft ein Drittel der Arbeit. Entscheide pro Teil: so umziehen, wie er ist, neu bauen oder stilllegen. Lass beide Plattformen parallel laufen und vergleiche die Ergebnisse Tag für Tag. Plane die Seite der Menschen: Schulungen, neue Regeln für die Rufbereitschaft und ein Datum, an dem das alte System abgeschaltet wird, denn sonst laufen beide ewig und kosten doppelt.

Schwache Antwort: „Wir kopieren alles an einem Wochenende hinüber.“ Nachfrage: „Das Geschäft will es in sechs Monaten fertig haben.“ Zeig, was hineinpasst, welches Risiko die Eile hat und welche Wellen zuerst Nutzen bringen.

Dein Lebenslauf für diese Fragen

Jede Antwort oben fällt leichter, wenn dein Lebenslauf sie schon sagt, denn der Interviewer fragt nach dem, was darin steht. Schreib für jeden dieser Punkte eine Zeile unter den passenden Job, in den Worten der Anzeigen:

Skill	Schwache Zeile	Starke Zeile, mit Beleg
Pipelines	ETL-Pipelines gebaut.	Inkrementelle Ladungen aus 12 Quellsystemen gebaut; der nächtliche Lauf sank von 5 Stunden auf 50 Minuten.
Datenqualität	Datenqualität sichergestellt.	Tests auf Eindeutigkeit und Wertebereiche für 80 Tabellen eingeführt; die falschen Zahlen, die die Finanzabteilung meldete, gingen innerhalb eines Jahres von monatlich auf null zurück.
Spark	Verarbeitung von Big Data.	Den Skew im wichtigsten Spark-Job behoben, indem ich den größten Kunden aufgeteilt habe; Laufzeit um 70 % gesenkt.
Kosten	Cloud-Kosten optimiert.	Die 3 größten Tabellen partitioniert und ungenutzte Warehouses pausiert; die Rechnung der Plattform sank in einem Quartal um 30 %.
Führung	Ein Datenteam geleitet.	4 Data Engineers durch einen Umzug in die Cloud in 3 Wellen geführt; die alte Plattform wurde nach Plan abgeschaltet.

Bewerte deinen Lebenslauf dann an einem echten Job: Du siehst, welche dieser Punkte der Job braucht und welche dein Lebenslauf noch nicht belegt.

Das Wichtigste

Beginne jeden Entwurf bei den Nutzern und ihrer Frist; dann mach jeden Schritt sicher für einen zweiten Lauf.
Wähle Batch, außer jemand reagiert innerhalb von Minuten auf die Daten.
Finde eine falsche Zahl, indem du sie Schicht für Schicht zurückverfolgst, und füge dann den Test hinzu, der sie gefunden hätte.
Behandle Kosten als Teil des Jobs: große Tabellen partitionieren, ungenutzte Jobs stoppen, Warehouses im Leerlauf pausieren.
Senior-Rollen fügen Entscheidungen über die Plattform, Data Contracts mit den Teams der Quellen und Standards hinzu, an die sich das Team hält.

Häufige Fragen

Was wird im Vorstellungsgespräch als Data Engineer am häufigsten gefragt?: Entwurf von Pipelines, SQL und Datenmodellierung, Batch gegen Streaming, Datenqualität, Performance und Kosten und bei Senior-Rollen Entscheidungen über die Plattform und die Führung von Engineers.
Gibt es eine Coding-Runde?: Meistens: Fragen zu SQL und oft eine kleine Aufgabe in Python. Übe beides und erkläre dabei laut, wie du denkst.
Muss ich Spark können?: Bei großen Datenmengen oft ja. In Teams mit einem Cloud-Warehouse und dbt zählen starkes SQL und Modellierung mehr.
Helfen Zertifikate?: Ein Cloud-Zertifikat für Daten hilft bei Beratungshäusern und manchen großen Firmen. Pipelines, die du gebaut und betrieben hast, zählen mehr.
Wie bereite ich mich in einer Woche vor?: Sag die beiden ausgearbeiteten Antworten laut, übe Joins und Fensterfunktionen in SQL und bereite je eine Geschichte zu einem Fehler, einer Beschleunigung und einer Kosteneinsparung vor.

So nutzt du diese Fragen

Was ein Data Engineer können muss

Entwurf von Pipelines

Entwirf eine Pipeline, die jede Nacht die Bestellungen von gestern aus der Datenbank des Shops ins Warehouse lädt.

Wann würdest du Streaming statt Batch wählen?

Was tust du, wenn ein Quellsystem sein Schema ändert, ohne dir Bescheid zu sagen?

Datenmodellierung und SQL

Wie würdest du Vertriebsdaten modellieren, damit Analysten sie leicht nutzen können?

Eine Abfrage, die früher Sekunden brauchte, braucht jetzt zwanzig Minuten. Wie findest du heraus, warum?

Datenqualität und der Betrieb von Pipelines

Eine Führungskraft sagt, eine Zahl im Dashboard sei falsch. Wie findest du die Ursache?

Wie testest du Datenpipelines?

Wie richtest du die Orchestrierung ein, damit ein Team den nächtlichen Läufen vertrauen kann?

Nach einer Änderung der Logik musst du zwei Jahre Daten per Backfill neu laden. Wie machst du das sicher?

Wie gehst du in einer Pipeline mit personenbezogenen Daten um?

Big Data, Performance und Kosten

Ein Spark-Job, der einen Tag an Daten verarbeitet, ist sehr langsam geworden. Wo schaust du nach?

Die Cloud-Rechnung der Datenplattform hat sich in drei Monaten verdoppelt. Was tust du?

Plattformen, Standards und die Führung von Engineers

Wie würdest du zwischen einem Data Warehouse, einem Data Lake und einem Lakehouse wählen?

Wie bringst du andere Teams dazu, für die Qualität der Daten einzustehen, die sie dir schicken?

Wie setzt du als Lead Data Engineer Standards für ein Team von Engineers?

Wie würdest du den Umzug einer alten On-Premise-Datenplattform in die Cloud planen?

Dein Lebenslauf für diese Fragen

Das Wichtigste

Häufige Fragen

Mehr zu diesem Beruf