Data-Engineer-Interviewfragen und -Antworten (2026): SQL, Pipelines und Spark

Interviews für Data-Engineering testen drei Dinge: SQL, wie du Datenpipelines entwirfst und betreibst, und wie du über Skalierung und Ausfälle denkst. Unten findest du 20 Fragen mit Antworten, die du anpassen kannst, in der Reihenfolge, in der Kandidaten ihnen normalerweise begegnen. Die SQL-Beispiele wurden vor der Veröffentlichung gegen eine kleine Beispieldatenbank ausgeführt, und die gezeigten Ergebnisse sind die echte Ausgabe.

SQL-Fragen

1. Finde das zweithöchste Gehalt in jedem Unternehmen oder insgesamt

Verwende DENSE_RANK, damit Gleichstände denselben Rang teilen und „zweithöchstes" den zweiten unterschiedlichen Wert bedeutet.

SELECT name, salary
FROM (
  SELECT name, salary, DENSE_RANK() OVER (ORDER BY salary DESC) AS r
  FROM employees
) t
WHERE r = 2;

Bei einer Tabelle mit den Gehältern 150, 130, 130, 110, 90, 70 liefert das die beiden Personen mit 130. Erkläre, warum du DENSE_RANK statt RANK (das nach Gleichständen Nummern überspringt) und ROW_NUMBER (das Gleichstände willkürlich auflöst) gewählt hast.

2. Die zwei Topverdiener in jeder Abteilung

SELECT dept, name, salary
FROM (
  SELECT dept, name, salary,
         RANK() OVER (PARTITION BY dept ORDER BY salary DESC) AS r
  FROM employees
) t
WHERE r <= 2;

PARTITION BY startet das Ranking für jede Abteilung neu. Erwähne, dass gleich hohe Gehälter mit RANK mehr als zwei Zeilen zurückgeben können.

3. Laufende Summe pro Kunde

SELECT customer, order_date, amount,
       SUM(amount) OVER (PARTITION BY customer ORDER BY order_date) AS running_total
FROM orders;

Bei einem Kunden mit Bestellungen von 10, 20 und 30 zu aufsteigenden Daten sind die laufenden Summen 10, 30 und 60.

4. Doppelte Zeilen entfernen und die erste behalten

SELECT id, user_id
FROM (
  SELECT id, user_id,
         ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY id) AS rn
  FROM events
) t
WHERE rn = 1;

Hier ist ROW_NUMBER richtig, weil du genau eine Zeile pro Gruppe willst. Sei bereit zu sagen, wie du in einer echten Tabelle entscheiden würdest, welches Duplikat du behältst (neuester Zeitstempel, vollständigster Datensatz).

5. Veränderung gegenüber der vorherigen Zeile

SELECT order_date, amount,
       amount - LAG(amount) OVER (ORDER BY order_date) AS change
FROM orders
WHERE customer = 'A';

Die Veränderung der ersten Zeile ist NULL, weil es keine vorherige Zeile gibt. Sag das laut, denn das ist die übliche Nachfrage.

6. Was ist der Unterschied zwischen WHERE und HAVING?

WHERE filtert Zeilen vor der Gruppierung, und HAVING filtert Gruppen nach der Aggregation. Du kannst keine Aggregatfunktion wie COUNT(*) in WHERE verwenden.

7. Wie beschleunigst du eine langsame Abfrage?

1. Schau dir den Abfrageplan an, bevor du etwas änderst.
2. Prüfe, ob die Filter einen Index nutzen können und ob Funktionen auf der Spalte das verhindern.
3. Reduziere die gelesenen Daten: Wähle nur benötigte Spalten aus, filtere früh und partitioniere große Tabellen nach Datum.
4. Ersetze wiederholte Unterabfragen durch Joins oder Common Table Expressions und prüfe auf versehentliche Zeilenvervielfachung in Joins.
5. Prüfe bei Warehouses die Clustering- oder Sortierschlüssel und wie viele Daten jede Abfrage liest.

Fragen zum Pipeline-Design

8. ETL oder ELT?

ETL transformiert Daten, bevor sie geladen werden. ELT lädt zuerst die Rohdaten und transformiert sie im Warehouse. ELT ist bei Cloud-Warehouses üblich, weil Speicher günstig ist, Rohdaten für die erneute Verarbeitung verfügbar bleiben und Transformationen als SQL versioniert werden können. ETL ist weiterhin sinnvoll, wenn Daten bereinigt oder maskiert werden müssen, bevor sie ankommen, zum Beispiel um personenbezogene Daten zu entfernen.

9. Batch oder Streaming?

Entscheide danach, wie aktuell die Daten sein müssen. Batch ist einfacher und günstiger und passt zu täglichen Berichten. Streaming passt zu Fällen, in denen Minuten oder Sekunden zählen, etwa Betrugsprüfungen oder Live-Dashboards. Viele Systeme nutzen beides. Sag, was die geschäftliche Entscheidung ist, nicht nur die Technologie.

10. Was ist eine idempotente Pipeline, und warum ist sie wichtig?

Sie zweimal auszuführen liefert dasselbe Ergebnis wie einmal. Das ist wichtig, weil Jobs fehlschlagen und erneut versucht werden. Um ein Laden idempotent zu machen, schreibe nach Partition und überschreibe diese Partition, oder verwende ein Upsert mit einem stabilen Schlüssel, damit ein erneuter Versuch keine Duplikate erzeugt.

11. Wie gehst du mit verspäteten oder außer der Reihenfolge eintreffenden Daten um?

Verwende Ereigniszeit statt Ankunftszeit und definiere, wie spät Daten eintreffen dürfen. In Streaming-Systemen sagt ein Watermark dem Job, wie lange er wartet, bevor er ein Fenster schließt. Bei Batch-Tabellen verarbeite aktuelle Partitionen nach einem Zeitplan neu, oder halte einen Korrekturprozess vor, der die betroffenen Tage neu schreibt.

12. Wie entwirfst du für Ausfälle und erneute Versuche?

Mache Schritte klein, idempotent und unabhängig erneut ausführbar. Speichere den Zustand außerhalb des Jobs. Alarmiere bei fehlenden oder verspäteten Daten ebenso wie bei Fehlern. Setze ein Limit für erneute Versuche und schicke wiederholte Fehler an eine Stelle, an der ein Mensch nachsieht.

13. Wie prüfst du die Datenqualität?

Führe Prüfungen innerhalb der Pipeline aus und brich früh ab, damit schlechte Daten nicht in Berichte gelangen.

Fragen zu Modellierung und Speicherung

14. Was ist ein Star-Schema?

Eine zentrale Faktentabelle enthält messbare Ereignisse wie Bestellungen und ist mit Dimensionstabellen verknüpft, die diese beschreiben, etwa Kunde, Produkt und Datum. Es ist einfach abzufragen und schnell zu aggregieren. Ein Snowflake-Schema normalisiert die Dimensionen weiter, was Speicherplatz spart, aber zusätzliche Joins mit sich bringt.

15. Was sind Slowly Changing Dimensions?

Das sind Dimensionsattribute, die sich im Laufe der Zeit ändern, etwa die Adresse eines Kunden. Typ 1 überschreibt den alten Wert und verliert die Historie. Typ 2 fügt eine neue Zeile mit Start- und Enddatum hinzu, sodass die Historie erhalten bleibt. Sag, welchen Typ du für welches Attribut wählen würdest und warum.

16. Wie partitionierst du eine große Tabelle?

Partitioniere nach einer Spalte, nach der die meisten Abfragen filtern, meistens nach einem Datum. Abfragen, die danach filtern, lesen nur die passenden Partitionen. Vermeide eine Spalte mit zu vielen unterschiedlichen Werten, denn das erzeugt eine riesige Zahl winziger Partitionen.

17. Welche Dateiformate verwendest du für Analytics, und warum?

Spaltenorientierte Formate wie Parquet speichern jede Spalte zusammenhängend, sodass Abfragen, die nur wenige Spalten lesen, den Rest überspringen und gut komprimieren. Zeilenformate wie CSV oder JSON sind einfach zu erzeugen und zu lesen, aber langsam und groß in großem Maßstab.

Fragen zur verteilten Verarbeitung

18. Was ist ein Shuffle in Spark, und warum ist er teuer?

Ein Shuffle verschiebt Daten zwischen Maschinen, damit Zeilen mit demselben Schlüssel zusammenkommen, wie bei Joins und Group-bys. Er kostet Netzwerktransfer, Schreibvorgänge auf die Festplatte und Sortierung. Um ihn zu reduzieren, filtere früh, wähle sinnvolle Partitionierungszahlen und nutze einen Broadcast für eine kleine Tabelle in einem Join, damit die große nicht bewegt werden muss.

19. Wie gehst du mit Datenschiefe um?

Schiefe bedeutet, dass einige wenige Schlüssel den Großteil der Daten enthalten, sodass eine Aufgabe viel länger läuft als die übrigen. Optionen sind das Salting des Hot Keys durch Hinzufügen eines zufälligen Suffixes und zweimaliges Aggregieren, das Broadcasten der kleineren Seite eines Joins sowie das separate Filtern oder Behandeln der Hot Keys.

20. Was macht ein Orchestrator wie Airflow?

Er plant und führt Aufgaben in der richtigen Reihenfolge aus, definiert als gerichteter Graph, in dem jede Aufgabe von anderen abhängt. Er kümmert sich um Wiederholungsversuche, Backfills und Benachrichtigungen und zeigt, was gelaufen ist und was fehlgeschlagen ist. Er koordiniert die Arbeit. Er ist nicht dafür gedacht, selbst schwere Verarbeitung zu übernehmen, die in einem Warehouse oder einer Verarbeitungs-Engine laufen sollte.

So bereitest du dich vor

1. Übe die oben genannten Window-Function-Muster, bis du sie ohne nachzuschauen schreiben kannst.
2. Bereite eine Pipeline vor, die du gebaut hast, mit dem Volumen, den Fehlern, auf die du gestoßen bist, und dem, was du geändert hast.
3. Sei bereit, eine einfache Architektur auf einem Whiteboard zu zeichnen und zu erklären, was passiert, wenn ein Schritt fehlschlägt.
4. Geh deinen Lebenslauf durch: Zu jedem Tool darin kann man dich befragen.

Für verwandte Übung siehe unsere Leitfäden zu Kafka interview questions, Databricks interview questions, Snowflake interview questions und system design interview questions.

Übe laut und in deinen eigenen Worten. Ein Transkript im Anschluss zeigt dir, wo du abgeschweift bist oder den Punkt verfehlt hast. Befolge die Regeln des Arbeitgebers zu KI-Tools in jedem Live-Interview oder Assessment.