Data-Engineering-Interviews sind keine Analytics-Interviews mit ein bisschen Python drangeschraubt. Das Panel klärt, ob man dir die Pipeline anvertrauen kann, die jedes Dashboard, jedes Modell und jeden Finanzbericht der Firma füttert, und ob dir auffallen würde, wenn sie still falsche Zahlen produziert. Deshalb drehen sich die Fragen um Design, Korrektheit und Betrieb statt um clevere Algorithmen. Hier sind die, die wirklich kommen, worauf jede zielt und wie eine starke Antwort aufgebaut ist.
Das sind die Muster für die Rolle allgemein. Wenn du die Shortlist für ein konkretes Gespräch willst, füg die echte Stellenanzeige in den kostenlosen Question Predictor ein und hol dir die zwanzig Fragen, die in genau diesem Loop am wahrscheinlichsten kommen.
Was testen Data-Engineer-Interviews wirklich?
Vier Dinge: ob du eine Pipeline entwerfen kannst, die den Kontakt mit chaotischen Upstream-Daten überlebt, ob dein SQL über einen Join und ein GROUP BY hinausgeht, ob du Daten so modellierst, dass Analysten deine Absichten nicht rückwärts erraten müssen, und ob du Korrektheit als Engineering-Problem behandelst statt als Hoffnung. Tool-Wissen zählt deutlich weniger als Urteilsvermögen.
Die Gewichtung verschiebt sich je nach Firma: Warehouse-lastige Produktteams setzen auf Modellierung und SQL, Plattformteams auf Durchsatz und Kosten, Startups wollen wissen, ob du das Ganze allein hochziehen und günstig halten kannst. Codegenerierung hat das Schreiben einer Transformation trivial gemacht, also verbringen Panels ihre Zeit jetzt mit den Entscheidungen, die ein Generator nicht treffen kann: warum diese Granularität, warum dieser Partitionsschlüssel, was bei einem Replay passiert.
Wie läuft der Bewerbungsprozess als Data Engineer ab?
Ein typischer Loop läuft über vier bis sechs Stufen in zwei bis drei Wochen: ein Recruiter-Screening, ein SQL-Screen, eine Runde zum Pipeline-Design, eine Modellierungsrunde und ein Behavioral-Gespräch. Senior-Loops hängen eine tiefere Systemrunde zu Durchsatz, Kosten und Ausfällen dran. Take-home-Aufgaben sind seltener als früher, tauchen bei kleineren Firmen aber weiter auf.
- Recruiter-Screening (20 bis 30 Minuten). Stack, Größenordnung, Gehaltsrahmen. Beschreib deine größte Pipeline in zwei Sätzen: Volumen, Latenz, wer sie konsumiert.
- SQL-Screen (45 bis 60 Minuten). Live-SQL in einem geteilten Editor, mit Window Functions als üblichem Filter.
- Runde zum Pipeline-Design (60 Minuten). Du bekommst eine Quelle, einen Konsumenten und eine Erwartung an die Aktualität, dann entwirfst du den Weg dazwischen und verteidigst ihn.
- Runde zur Datenmodellierung (45 bis 60 Minuten). Schema-Design für ein beschriebenes Geschäft, meist mit einem Haken zu Historie oder verspäteten Daten.
- Hiring Manager oder Behavioral. Ownership und Stakeholder. Fragen zur Rufbereitschaft landen oft auch hier.
Wenn du die Firma schon kennst, sind die Fragenkataloge der Unternehmen der schnellere Weg zum Hausstil als Foren zu durchforsten.
Welche Fragen zum Pipeline-Design kommen im Data-Engineer-Interview?
Design-Fragen geben dir eine Quelle, ein Ziel und eine Randbedingung und schauen dann zu, wie du denkst. Das Panel will, dass du nach Volumen, Aktualität, Schema-Stabilität und danach fragst, wer schreit, wenn es kaputtgeht, bevor du ein einziges Kästchen malst. Starke Kandidaten schätzen das Problem laut ab und entwerfen dann das Einfachste, das die Anforderung erfüllt und sich sicher neu ausführen lässt.
Führ mich durch eine Pipeline, die du gebaut hast, von Anfang bis Ende. Was das prüft: ob du etwas betrieben hast oder nur einen Task zu jemandes DAG beigetragen. Gib die Form der Reihe nach (Quelle, Ingestion, Speicher, Transformation, Bereitstellung), dann die Zahlen: Zeilen pro Tag, Latenz, Kosten, wer davon abhing. Schließ damit ab, was einmal schiefging und was du geändert hast, denn konkrete Details kaufen dir hier Glaubwürdigkeit für den Rest des Loops.
Entwirf eine Pipeline, die rund 500GB Clickstream-Events pro Tag aufnimmt und sie bis 9 Uhr für Analysten bereitstellt. Was das prüft: Dimensionierung, Partitionierung und den Abstand zwischen Ankunft und Verfügbarkeit. Klär zuerst die Anforderung an die Aktualität, denn täglich bis 9 Uhr ist ein Batch-Problem, kein Streaming-Problem. Leg Rohevents in Object Storage ab, partitioniert nach Datum und Stunde, transformier sie in eine modellierte Tabelle und halt die Rohschicht unveränderlich, damit du replayen kannst. Erwähne Dateigrößen, Tausende winziger Dateien sind die klassische selbst zugefügte Wunde.
Wie gehst du mit verspäteten oder in falscher Reihenfolge eintreffenden Events um? Was das prüft: ob dir klar ist, dass Daten nicht höflich ankommen. Trenn Event-Zeit von Ingestion-Zeit, definier ein Verspätungsfenster, das du akzeptierst, und verarbeite die betroffenen Partitionen neu, statt einzelne Zeilen zu flicken.
Batch oder Streaming: Wie beantwortest du die Architekturfrage?
Antworte aus den Anforderungen, nicht aus Vorliebe. Streaming rechtfertigt seine Kosten, wenn etwas innerhalb von Sekunden auf die Daten reagiert: Betrugsprüfung, Live-Bestände, Alerting. Batch ist für fast alles richtig, was ein Dashboard oder einen Monatsbericht füttert. Die Falle hier ist Begeisterung, denn wer für einen Tagesbericht zum Streaming-Stack greift, optimiert auf Interesse statt aufs Geschäft.
Wann würdest du Streaming statt Batch wählen, und was kostet dich das? Was das prüft: Urteilsvermögen zur Betriebslast. Nenn die Kosten ehrlich: schwereres Testen, schwerere Backfills, State, den du verwalten musst, mehr Fläche für die Rufbereitschaft, ein Team, das jetzt Watermarks verstehen muss. Nenn dann die Bedingung, die all das rechtfertigt: ein Konsument, der schneller auf die Daten reagiert, als deine Batch-Taktung liefern kann.
Was ist der Unterschied zwischen Event-Zeit und Verarbeitungszeit? Was das prüft: Streaming-Grundlagen. Event-Zeit ist, wann das Ding passiert ist, Verarbeitungszeit ist, wann dein System es gesehen hat. Aggregate, die auf Verarbeitungszeit gefenstert sind, driften und widersprechen am Ende still der Source of Truth.
Wie erreichst du Exactly-once-Semantik in einer Streaming-Pipeline? Was das prüft: ob du Marketing nachplapperst oder Mechanik erklärst. End to end baust du At-least-once-Zustellung plus idempotente Writes, mit einem deterministischen Schlüssel, damit ein Replay überschreibt statt dupliziert. Transaktionale Sinks und Offsets, die mit dem Write committet werden, machen das real.
Welche Fragen zur Datenmodellierung solltest du erwarten?
Modellierungsrunden testen, ob du für die Fragen entwirfst, die das Business stellen wird, statt für die Daten, die du zufällig hast. Erwarte ein beschriebenes Geschäft, die Bitte um ein Schema und dann eine Komplikation: Historie, Hierarchie oder ein Attribut, das sich ändert. Dimensionale Modellierung ist immer noch die gemeinsame Sprache, auch in Teams, die ihre Schichten modischer nennen.
Erklär Star Schema gegen eine breite denormalisierte Tabelle. Was würdest du bauen? Was das prüft: Denken über Granularität und Veränderung. Deck auf der einen Seite Abfrage-Einfachheit und Speicherkosten ab, auf der anderen Join-Kosten und duplizierte Attribute, und entscheide dann nach Engine und Konsumenten. Spaltenorientierte Warehouses haben breite Tabellen günstiger gemacht als früher, aber ein Star gewinnt immer noch, wenn sich Dimensionen unabhängig ändern.
Wie modellierst du eine Slowly Changing Dimension? Was das prüft: Historie. Typ 1 überschreibt und verliert die Vergangenheit, Typ 2 fügt pro Version eine Zeile mit Gültigkeitsdaten und einem Current-Flag hinzu, und genau das brauchen die meisten Analytics-Teams für stichtagsbezogene Auswertungen.
Wie würdest du eine große Tabelle partitionieren, und was geht dabei schief? Was das prüft: physisches Design. Partitioniere auf der Spalte, nach der Konsumenten filtern, meist ein Datum, behalt die Partitionsgröße im Auge und halt Partitionierung getrennt von Clustering oder Sortierschlüsseln. Der Klassiker geht schief, wenn du auf etwas Hochkardinales wie die User-ID partitionierst: Millionen winziger Dateien und Abfragen, die langsamer sind als ganz ohne Partitionierung.
Wie tief geht die SQL-Runde für Data Engineers?
Tiefer als bei Analysten-Runden. Joins und Aggregation werden vorausgesetzt, der Filter sind Window Functions, Deduplizierung und das Nachdenken über einen Query-Plan. Die meisten Screens laufen über drei oder vier Fragen mit steigender Gemeinheit, und die letzte braucht meist eine Window Function oder einen Self-Join. Erklär den Ansatz, bevor du tippst, denn die Begründung wird stärker gewichtet als die Syntax.
Finde den zweithöchsten Wert je Gruppe, zum Beispiel die zweitbestbezahlte Person in jeder Abteilung. Was das prüft: Sicherheit bei Window Functions. Greif zu DENSE_RANK oder ROW_NUMBER in einer Subquery und filtere außen auf den Rang, und sag dann, wofür du dich entschieden hast und warum, denn Gleichstände verhalten sich unterschiedlich.
Dedupliziere eine Tabelle, sodass nur die neueste Zeile je Schlüssel übrig bleibt. Was das prüft: die häufigste echte Aufgabe im Job. ROW_NUMBER, partitioniert nach dem Schlüssel, sortiert nach Zeitstempel absteigend, gefiltert auf 1. Frag dann, was den Gleichstand auflöst, wenn zwei Zeilen denselben Zeitstempel haben, denn in echten Daten passiert das.
Eine Abfrage auf einer partitionierten Tabelle ist langsam geworden. Wie diagnostizierst du das? Was das prüft: Debugging anhand von Belegen. Lies den Plan, prüf, ob Partition Pruning wirklich stattgefunden hat (eine Funktion um die Partitionsspalte herum killt es meist), such nach Skew, prüf veraltete Statistiken und ob das File-Layout in viele kleine Dateien zerfallen ist.
Welche Fragen zur Orchestrierung stellen Interviewer?
Orchestrierungsfragen testen, ob deine Pipelines sich ohne Angst neu ausführen lassen. Das Wort, das du parat haben solltest, ist Idempotenz: Denselben Task für dasselbe logische Datum zweimal laufen zu lassen, sollte dasselbe Ergebnis liefern, nicht das doppelte. Erwarte Nachfragen zu Abhängigkeiten, Retries, Alerting und dem Backfill eines ganzen Jahres, ohne Cluster oder Budget zu schmelzen.
Wie machst du einen geplanten Job idempotent und sicher backfill-fähig? Was das prüft: operative Reife. Parametrisiere jeden Task über ein logisches Datum statt über "jetzt", schreib in eine Partition mit diesem Datum als Schlüssel und ersetz diese Partition beim erneuten Lauf, statt anzuhängen.
Wie gehst du mit Abhängigkeiten zwischen Pipelines um, die verschiedenen Teams gehören? Was das prüft: ob du in einer echten Organisation gearbeitet hast. Nimm lieber ein explizites Signal (ein als vollständig markierter Datensatz, ein Event, ein Sensor mit Timeout) als einen hoffnungsvollen Zeitversatz im Schedule.
Wie testen Interviewer Datenqualität?
Sie beschreiben eine falsche Zahl und schauen dir beim Untersuchen zu. Das Signal, das sie wollen: dass du Korrektheit als testbar behandelst. Zeilenzahlen, Null-Raten, Eindeutigkeit auf Schlüsseln, referenzielle Integrität, Verteilungsvergleiche gegen gestern, Aktualität. Wer sagt, er würde aufs Dashboard schauen, verliert die Runde, wer Assertions in der Pipeline beschreibt, die ein schlechtes Publish blockieren können, gewinnt sie.
Woher weißt du, dass eine Pipeline korrekte Daten produziert hat? Was das prüft: ob Qualität eingebaut oder hinterher geprüft wird. Pack Tests in die Pipeline selbst: eindeutige Schlüssel, Not-Null-Constraints, zulässige Wertebereiche, Zeilenzahl-Deltas gegen den vorherigen Lauf.
Ein Stakeholder sagt, die Umsatzzahl von gestern ist falsch. Führ mich durch die Untersuchung. Was das prüft: strukturiertes Debugging plus Kommunikation. Definier, was falsch heißt (gegen welche Quelle, um wie viel), und arbeite dich dann Schicht für Schicht nach oben, indem du an jeder Grenze Zählungen und Summen vergleichst, um zu isolieren, wo die Zahl abweicht.
Eine Upstream-Quelle ändert ohne Vorwarnung einen Spaltentyp. Wie gehst du damit um? Was das prüft: den Umgang mit Dingen außerhalb deiner Kontrolle. Scheitere früh bei der Ingestion mit einem Schema-Check, statt still zu casten, stell den schlechten Batch in Quarantäne und fix nach vorne mit einem Replay.
Welche Behavioral-Fragen bekommen Data Engineers?
Behavioral-Runden für Datenrollen drehen sich um Vertrauen und Stakeholder. Erwarte eine Frage zu einem Vorfall, bei dem deine Daten falsch waren, und eine zu einer Anfrage, bei der du widersprochen hast. Antworte mit knapper Struktur: die Situation, was du entschieden hast, den Kompromiss, den du akzeptiert hast, und die dauerhafte Änderung, die folgte.
Erzähl mir von einem Fall, in dem deine Daten falsch waren und es jemand anderes zuerst gemerkt hat. Was das prüft: Ownership und Ehrlichkeit. Spiel es nicht klein. Sag, was kaputt war, wie lange es falsch war, wer danach gehandelt hat, wie du kommuniziert hast und welche Prüfung du eingebaut hast, damit es nicht still wieder passieren kann.
Erzähl mir von einer Anfrage, die du abgelehnt oder heruntergehandelt hast. Was das prüft: ob du eine Plattform vor hundert Einzelwünschen schützen kannst. Zeig, dass du den dahinterliegenden Bedarf verstanden hast, einen günstigeren Weg dorthin angeboten und die Kosten der ursprünglichen Anfrage sichtbar gemacht hast, statt nur nein zu sagen und zu dem Team zu werden, um das alle herumrouten.
Woran scheitern Data-Engineer-Kandidaten?
Meist an Urteilsvermögen, nicht an Wissenslücken. Panels lehnen selten jemanden ab, weil er ein bestimmtes Tool nicht kennt, sie lehnen Leute ab, die entwerfen, bevor sie fragen, die ihre eigene Pipeline nicht neu ausführen können oder die eine falsche Zahl als das Problem von jemand anderem behandeln. Das sind die Muster, die Runden beenden.
- Entwerfen, bevor man fragt. Volumen, Aktualität, Schema-Stabilität und Konsumenten sollten geklärt sein, bevor du irgendwas malst. Mit einem Tool-Namen anzufangen verliert die Design-Runde.
- Tools nennen statt Mechanik. Zu sagen, du würdest eine bestimmte Engine nehmen, erklärt gar nichts. Sag, was der Job tut, wie er partitioniert, wo der Shuffle passiert, was er kostet.
- Replay und Backfill ignorieren. Ein Design, das sich für ein vergangenes Datum nicht sicher neu ausführen lässt, ist kein Produktionsdesign, und Senior-Interviewer prüfen genau das gezielt.
- Qualität als Aufgabe von jemand anderem behandeln. Wenn deine Antwort auf eine falsche Zahl ist, dass der Analyst sie hätte fangen müssen, ist die Runde vorbei.
- SQL, das bei Joins aufhört. Window Functions sind inzwischen der Standardfilter, und sie nicht zu können liest sich als zu wenig Tiefe, egal wie gut deine Architekturantworten waren.
Wie bereitest du dich auf ein Data-Engineer-Interview vor?
Üb eine Pipeline, die du im Schlaf kennst, mit echten Zahlen dran, denn sie wird den halben Loop tragen. Drille Window Functions und Deduplizierung, bis sie im Muskelgedächtnis sitzen. Üb ein Design laut und gegen die Uhr, denn das Format bestraft Leute, die es zwar denken, aber nicht erzählen können. Leg dir zwei Incident-Stories und eine Stakeholder-Story zurecht.
Vor dem Loop selbst füg die echte Stellenanzeige in den kostenlosen Question Predictor ein und arbeite die zwanzig Fragen durch, die er für diese konkrete Rolle markiert, denn ein Lakehouse-Plattformteam und ein Analytics-Engineering-Team fragen dich sehr unterschiedliche Dinge.
Für die Live-Runden ist GhostPilot ein Echtzeit-Interview-Copilot: ein Side Panel in der Chrome-Erweiterung und eine optionale Windows-Desktop-App, die das Gespräch transkribieren, die Frage abfangen, sobald sie fällt, und rund zwei Sekunden später eine strukturierte Antwort bereithaben. Am meisten hilft es bei Fragen mit eingebauter Falle, etwa einer Design-Aufgabe, die still nach einer Replay-Strategie verlangt. Es ist ein Impuls, kein Skript, und die Details kommen weiterhin aus deiner eigenen Arbeit. Der kostenlose Tarif gibt dir 10 Minuten Live-Interviewzeit pro Woche, ohne Karte.
FAQ zum Data-Engineer-Interview
Wie lange sollte ich mich auf ein Data-Engineer-Interview vorbereiten? Zwei bis drei Wochen passen für die meisten Mid-Level-Kandidaten: eine Woche SQL und Modellierung, eine Woche Design laut üben, ein paar Tage für Stories. Wer von Analytics ins Engineering wechselt, sollte länger planen, vor allem für Pipeline-Design.
Kommen in Data-Engineer-Interviews noch Algorithmus-Fragen? Manche großen Firmen behalten eine Algorithmus-Runde, meist leicht bis mittel. Die meisten Teams haben sie durch SQL und eine praktische Python-Aufgabe zum Parsen oder Transformieren ersetzt. Lass Algorithmus-Grinding nicht die Modellierung verdrängen.
Welche Runde wiegt am schwersten? Pipeline-Design, bei Mid- und Senior-Kandidaten, weil es Urteilsvermögen, Kommunikation und Tiefe auf einmal testet. Bei Junior-Rollen ist der SQL-Screen das echte Tor, und dort passieren die meisten Absagen.
Soll ich zugeben, wenn ich ein genanntes Tool nie benutzt habe? Ja. "Das habe ich nicht in Produktion betrieben, aber so würde ich es angehen und das würde ich zuerst prüfen" schlägt Bluffen, und Interviewer aus dem Datenbereich sind ungewöhnlich gut darin, Geschwafel zu erkennen, weil sie den ganzen Tag falsche Dinge suchen.