Die 25 wichtigsten Data-Engineering-Interviewfragen 2026 -- mit Antworten und Code

Data-Engineering-Interviews haben sich 2026 grundlegend verändert. Neben SQL-Kenntnissen erwarten Unternehmen fundiertes Wissen über Systemarchitektur, Echtzeit-Pipelines, Kostenoptimierung und KI-Bereitschaft. Dieser Leitfaden deckt die 25 Fragen ab, die bei Vorstellungsgesprächen für Data Engineers -- von Startups bis hin zu FAANG-Unternehmen -- am häufigsten gestellt werden, ergänzt durch praxistaugliche Antworten.

SQL und Abfrageoptimierung

SQL bildet nach wie vor das Fundament jedes Data-Engineering-Interviews. Selbst erfahrene Kandidaten werden mit SQL-Fragen konfrontiert, die typischerweise auf Performance statt auf Syntax abzielen.

1. Was unterscheidet eine Window Function von GROUP BY?

GROUP BY fasst Zeilen zu aggregierten Ergebnissen zusammen und reduziert die Zeilenanzahl. Window Functions hingegen berechnen Werte über eine Menge verwandter Zeilen, ohne diese zu kollabieren. Die Ausgabe behält jede Originalzeile bei.

-- GROUP BY: one row per department
SELECT department, AVG(salary) AS avg_salary
FROM employees
GROUP BY department;

-- Window function: every row preserved, avg added
SELECT
  employee_id,
  department,
  salary,
  AVG(salary) OVER (PARTITION BY department) AS dept_avg
FROM employees;

Die Window-Function-Variante ist unverzichtbar, wenn eine Abfrage gleichzeitig Detaildaten auf Zeilenebene und aggregierten Kontext benötigt -- eine gängige Anforderung in Datenqualitätsprüfungen und Reporting-Pipelines.

2. Wie lässt sich eine langsame Abfrage auf einer 500-Millionen-Zeilen-Faktentabelle optimieren?

Ein strukturierter Ansatz liefert die besten Ergebnisse:

1. Ausführungsplan analysieren (EXPLAIN ANALYZE), um Full-Table-Scans, Hash-Joins auf nicht-indizierten Spalten oder Disk-Spills zu identifizieren.
2. Tabelle partitionieren nach Datum oder einer hochkardinalen Spalte, die zu den Abfragefiltern passt.
3. Gezielte Indizes anlegen auf häufig gefilterten Spalten -- aber Überindizierung vermeiden, da jeder Index den Schreib-Overhead erhöht.
4. Zwischenergebnisse materialisieren, falls dieselbe Unterabfrage wiederholt in mehreren Dashboards läuft.
5. Prädikate nach unten schieben, um frühzeitig zu filtern und das zwischen Stufen verschobene Datenvolumen zu minimieren.

Das entscheidende Signal für Interviewer: das Verständnis, dass Optimierung iterativ und kontextabhängig ist -- keine Checkliste.

3. CTEs vs. Unterabfragen vs. temporäre Tabellen: Wann kommt was zum Einsatz?

CTEs (Common Table Expressions) verbessern die Lesbarkeit und ermöglichen rekursive Abfragen. Die meisten Query-Engines inlinen sie, sodass die Performance mit Unterabfragen vergleichbar bleibt. Temporäre Tabellen materialisieren Daten physisch, was hilfreich ist, wenn dasselbe Zwischenergebnis mehrere nachgelagerte Abfragen in einer Sitzung speist. Unterabfragen eignen sich gut für einfache, einmalige Transformationen.

Faustregel: CTE für Klarheit, temporäre Tabelle für Wiederverwendung, Unterabfrage für triviale Inline-Filter.

Einen tieferen Einblick in fortgeschrittene SQL-Muster bietet der Artikel SQL für Data Analysts: Window Functions, CTEs und Advanced Queries.

ETL vs. ELT und Data-Pipeline-Architektur

Fragen zum Pipeline-Design testen architektonisches Denken. Interviewer erwarten eine differenzierte Trade-off-Analyse, kein Plädoyer für ein bestimmtes Tool.

4. ETL vs. ELT: Wann eignet sich welches Modell?

| Kriterium | ETL | ELT | |-----------|-----|-----| | Transformationsort | Vor dem Laden (externer Compute) | Nach dem Laden (Warehouse-Compute) | | Geeignet für | Legacy-Systeme, strikte Schemas | Cloud-Warehouses (BigQuery, Snowflake) | | Schema-Flexibilität | Niedrig (Transformation fixiert Schema früh) | Hoch (Rohdaten für Re-Transformation verfügbar) | | Kostenmodell | Compute außerhalb des Warehouse | Warehouse-Compute-Kosten skalieren mit Transformationen | | Datenaktualität | Höhere Latenz (Transformationsschritt) | Niedrigere Latenz (erst laden, dann on-demand transformieren) |

ELT dominiert in modernen Cloud-nativen Stacks, weil Speicher günstig ist, Compute elastisch skaliert und die Aufbewahrung von Rohdaten Schema-Evolution ermöglicht. ETL bleibt relevant, wenn regulatorische Anforderungen eine Transformation vor dem Einladen ins Warehouse vorschreiben -- etwa zur PII-Bereinigung.

5. Wie wird eine idempotente Datenpipeline entworfen und warum ist Idempotenz wichtig?

Idempotenz garantiert, dass das mehrfache Ausführen einer Pipeline mit demselben Input identische Ergebnisse liefert, ohne Daten zu duplizieren. Das ist entscheidend, weil Pipelines fehlschlagen und erneut ausgeführt werden.

Implementierungsstrategien:

• Upsert-Muster (MERGE oder INSERT ... ON CONFLICT), geschlüsselt auf natürlichen oder zusammengesetzten Schlüsseln
• Partitions-Überschreibung: komplette Datumspartitionen ersetzen statt anhängen
• Deduplizierung beim Schreiben: deterministische IDs zuweisen (Hash aus Business Key + Event-Zeitstempel)

# partition_overwrite.py
# Idempotent write: overwrite the entire partition for a given date
from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("idempotent_load").getOrCreate()

df = spark.read.parquet("s3://raw-events/2026-04-11/")

# Transform: deduplicate by event_id, keep latest
df_deduped = (
    df.orderBy("event_timestamp", ascending=False)
    .dropDuplicates(["event_id"])
)

# Overwrite only the target partition
df_deduped.write \
    .mode("overwrite") \
    .partitionBy("event_date") \
    .parquet("s3://warehouse/events/")

Dieser Ansatz stellt sicher, dass ein erneuter Lauf für den 11. April die entsprechende Partition ersetzt, anstatt doppelte Zeilen anzuhängen.

6. Was ist Data Lineage und warum ist es in Produktions-Pipelines unverzichtbar?

Data Lineage verfolgt Ursprung, Bewegung und Transformation von Daten über die gesamte Pipeline. Es beantwortet drei zentrale Fragen: Woher stammt dieser Wert? Welche Transformationen wurden angewendet? Welche nachgelagerten Systeme hängen davon ab?

Praktischer Nutzen: Zeigt ein Dashboard unerwartete Werte, ermöglicht Lineage eine Ursachenanalyse in Minuten statt Stunden. Tools wie OpenLineage, dbt-Dokumentation und Cloud-native Lineage-Funktionen (etwa BigQuery Column-Level Lineage) automatisieren die Erfassung.

Streaming und Echtzeit-Datenverarbeitung

Streaming-Fragen haben sich von grundlegenden Definitionen hin zu architektonischen Entscheidungen verlagert: Wann und wie sollte Streaming eingesetzt werden?

7. Batch vs. Streaming: Wie fällt die Entscheidung?

Die Entscheidung hängt von Latenzanforderungen ab, nicht von Technologiepräferenzen:

• Batch: akzeptabel, wenn Datenkonsumenten Verzögerungen von Minuten bis Stunden tolerieren. Einfacher zu erstellen, zu testen und zu debuggen. Niedrigere Betriebskosten für die meisten Workloads.
• Streaming: erforderlich, wenn Geschäftslogik auf Aktualität unter einer Minute angewiesen ist -- Betrugserkennung, Echtzeit-Preisgestaltung, Live-Dashboards.
• Micro-Batch: ein pragmatischer Mittelweg (z. B. Spark Structured Streaming), der Near-Real-Time mit Batch-ähnlicher Einfachheit verbindet.

Die stärkste Antwort erkennt an, dass die meisten Pipelines als Batch starten sollten und erst dann auf Streaming umgestellt werden, wenn ein konkretes Latenz-SLA dies erfordert.

8. Kafka-Architektur erklären: Topics, Partitions, Consumer Groups

Kafka organisiert Daten in Topics (logische Kanäle). Jedes Topic wird in Partitions (geordnete, unveränderliche Logs) aufgeteilt, die über Broker verteilt sind. Producer schreiben Datensätze in Partitions (Round-Robin oder schlüsselbasiert). Consumer Groups parallelisieren das Lesen: Jede Partition wird genau einem Consumer innerhalb einer Gruppe zugewiesen, was horizontale Skalierung ermöglicht.

Zentraler Trade-off: Mehr Partitions erhöhen die Parallelität, erzeugen aber zusätzlichen Overhead auf dem Broker (Dateihandles, Replikation). Ein typischer Startpunkt sind 6--12 Partitions pro Topic, skalierbar auf Basis der Durchsatzanforderungen.

9. Wie wird mit verspätet eintreffenden Daten in einer Streaming-Pipeline umgegangen?

Verspätete Daten sind in verteilten Systemen unvermeidlich. Drei etablierte Ansätze:

1. Watermarks: einen Schwellenwert definieren (z. B. 10 Minuten), jenseits dessen verspätete Daten verworfen werden. Apache Flink und Spark Structured Streaming unterstützen dies nativ.
2. Wiederverarbeitungsfenster: periodisch Aggregationen für aktuelle Zeitfenster erneut ausführen, um Nachzügler zu erfassen.
3. Delta/Upsert-Senken: in einen veränderlichen Speicher (Delta Lake, Apache Iceberg) schreiben, der Updates unterstützt und es verspäteten Datensätzen ermöglicht, vorherige Ergebnisse zu korrigieren.

Der passende Ansatz hängt davon ab, ob nachgelagerte Konsumenten Exactly-Once-Semantik benötigen oder eventuelle Konsistenz tolerieren können.

Datenmodellierung und Schema-Design

Fragen zur Datenmodellierung zeigen, ob Kandidaten darüber nachdenken, wie Daten konsumiert werden -- nicht nur, wie sie gespeichert werden.

10. Star Schema vs. Snowflake Schema: Welche Trade-offs bestehen?

Das Star Schema denormalisiert Dimensionstabellen zu flachen, breiten Tabellen, die mit einer zentralen Faktentabelle verbunden werden. Das Snowflake Schema normalisiert Dimensionen in Unterdimensionen.

| Aspekt | Star | Snowflake | |--------|------|-----------| | Abfrage-Performance | Schneller (weniger Joins) | Langsamer (mehr Joins) | | Speicherplatz | Höher (redundante Daten) | Niedriger (normalisiert) | | Komplexität | Einfach zu verstehen | Komplexere Beziehungen | | Wartung | Schwieriger bei Dimensions-Updates | Einfacher bei Unterdimensions-Updates | | Geeignet für | BI/Reporting (leseintensiv) | Situationen mit strikter Normalisierung |

In der Praxis dominieren Star Schemas in analytischen Warehouses (BigQuery, Snowflake, Redshift), weil Abfrage-Performance und Einfachheit die Speicherersparnis überwiegen. Weitere Vertiefung bietet das Datenmodellierung-Interviewmodul.

11. Was ist eine Slowly Changing Dimension (SCD)? Typ 1, 2 und 3 erklären.

SCDs beschreiben, wie sich Dimensionsattribute über die Zeit verändern:

• Typ 1: Den alten Wert überschreiben. Keine Historie. Einfach, aber verlustbehaftet.
• Typ 2: Eine neue Zeile mit Versionsverfolgung hinzufügen (valid_from, valid_to, is_current). Vollständige Historie wird bewahrt. Am häufigsten in Produktions-Warehouses.
• Typ 3: Eine Spalte für den vorherigen Wert ergänzen (current_city, previous_city). Begrenzte Historie -- nur eine Änderung wird erfasst.

Typ 2 ist die Standardwahl für die meisten Geschäftsdimensionen (Kundenadresse, Produktkategorie, Mitarbeiterabteilung), da Audit-Trails und historisches Reporting vollständige Nachverfolgbarkeit erfordern.

12. Wie lassen sich Event-Daten für Echtzeit-Analytik und Langzeitspeicherung modellieren?

Ein Zwei-Schichten-Ansatz hat sich bewährt:

1. Hot Layer: Events in einen Echtzeit-Store streamen (Apache Druid, ClickHouse oder Materialized Views im Warehouse), optimiert für niedriglatente Aggregationen auf aktuellen Daten.
2. Cold Layer: Rohe Events in einem Lakehouse (Delta Lake, Iceberg) landen, partitioniert nach Datum, unbegrenzt aufbewahrt für Ad-hoc-Analysen und ML-Feature-Engineering.

Der Hot Layer nutzt voraggregierte oder denormalisierte Schemas für Geschwindigkeit. Der Cold Layer behält die volle Granularität. Ein Abgleichjob validiert periodisch, dass beide Schichten übereinstimmen.

Apache Spark und verteilte Verarbeitung

Spark-Fragen konzentrieren sich auf das Verständnis von Parallelismus und Performance -- nicht nur auf API-Aufrufe.

13. Was verursacht Data Skew in Spark und wie lässt sich das Problem beheben?

Data Skew tritt auf, wenn eine Partition unverhältnismäßig mehr Daten enthält als andere, wodurch ein einzelner Task den gesamten Stage blockiert.

Häufige Ursachen: Join auf einem Schlüssel mit wenigen dominanten Werten (Null-Schlüssel, eine einzelne populäre Produkt-ID) oder Partitionierung nach einer niedrigkardinalen Spalte.

Lösungsansätze:

• Salting: einen zufälligen Suffix an den verzerrten Schlüssel anhängen, auf dem gesalzenen Schlüssel joinen, dann aggregieren, um das Salt zu entfernen.
• Broadcast Join: wenn eine Seite klein genug ist (typischerweise < 200 MB), wird sie gebroadcastet, um Shuffle vollständig zu vermeiden.
• AQE (Adaptive Query Execution): Spark 3.x+ kann verzerrte Partitionen zur Laufzeit automatisch erkennen und aufteilen.

# salting_technique.py
# Fix skewed join by salting the large table's key
from pyspark.sql import functions as F

SALT_BUCKETS = 10

# Add salt to the large (skewed) table
large_df = large_df.withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), (F.rand() * SALT_BUCKETS).cast("int"))
)

# Explode the small table to match all salt values
small_df = small_df.crossJoin(
    spark.range(SALT_BUCKETS).withColumnRenamed("id", "salt")
).withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), F.col("salt"))
).drop("salt")

# Join on salted key (evenly distributed)
result = large_df.join(small_df, "salted_key")

Durch diese Technik verteilt sich die Arbeitslast gleichmäßig über die Executors und der Engpass wird beseitigt.

14. Was ist der Unterschied zwischen Transformationen und Aktionen in Spark?

Transformationen (map, filter, select, join) sind lazy: Sie bauen einen logischen Plan auf, führen aber nichts aus. Aktionen (count, collect, write) lösen die tatsächliche Berechnung aus, indem sie den Plan an den Cluster übermitteln.

Diese Lazy Evaluation ermöglicht es dem Catalyst-Optimizer von Spark, Operationen umzuordnen, Prädikate nach unten zu schieben und unnötige Shuffles zu eliminieren, bevor Daten bewegt werden. Dieses Verständnis ist essenziell für das Debugging: Eine Transformation, die langsam erscheint, ist in Wirklichkeit nicht das Problem -- der Engpass liegt in der Aktion, die sie auslöst.

15. Worin unterscheiden sich repartition() und coalesce()?

repartition(n) führt einen vollständigen Shuffle durch, um exakt n Partitions zu erzeugen und Daten gleichmäßig zu verteilen. Einsatz zur Erhöhung der Parallelität oder zum Rebalancieren verzerrter Partitions.

coalesce(n) reduziert Partitions ohne Shuffle, indem benachbarte Partitions zusammengeführt werden. Einsatz zur Reduzierung der Partitionsanzahl vor dem Schreiben -- dadurch werden viele kleine Dateien vermieden.

Faustregel: coalesce zum Reduzieren, repartition zum Erhöhen oder Rebalancieren.

Orchestrierung und Pipeline-Management

Orchestrierungsfragen testen operative Reife: Wie laufen Pipelines in Produktion, wie scheitern sie, und wie erholen sie sich?

16. Airflow, Dagster und Prefect im Vergleich: Wann eignet sich welches Tool?

| Merkmal | Airflow | Dagster | Prefect | |---------|---------|---------|---------| | Reifegrad | Am ausgereiftesten, größte Community | Wachsend, stark in ML/Data-Teams | Cloud-first, starke Developer Experience | | Kernabstraktion | DAGs aus Tasks | Assets (datenzentriert) | Flows und Tasks | | Testing | Schwieriger (DAG-Ebene) | Eingebautes Asset-Testing | Gutes Task-Level-Testing | | Lokale Entwicklung | Benötigt Docker/Container | Native lokale Ausführung | Native lokale Ausführung | | Geeignet für | Komplexe, langlebige ETL | Data Mesh / Asset-orientierte Teams | Teams mit minimalem Infrastruktur-Overhead |

Airflow bleibt der Industriestandard für ausgereifte Datenplattformen. Dagster passt zu Teams, die in Daten-Assets statt in Task-Sequenzen denken. Prefect spricht Teams an, die Airflow-ähnliche Orchestrierung mit weniger operativem Aufwand wünschen. Für Airflow-spezifische Interviewvorbereitung eignet sich das Airflow-Grundlagen-Modul.

17. Wie werden Pipeline-Fehler und Alerting in Produktion gehandhabt?

Eine produktionsreife Fehlerstrategie umfasst mehrere Ebenen:

1. Retry mit Backoff: Transiente Fehler (Netzwerk-Timeouts, API-Rate-Limits) lösen sich häufig mit exponentiellem Retry.
2. Dead-Letter-Queues: Fehlerhafte Nachrichten werden in eine separate Queue geleitet zur manuellen Untersuchung, ohne die Pipeline zu blockieren.
3. Circuit Breaker: Nach N aufeinanderfolgenden Fehlern wird die Pipeline pausiert und alarmiert, anstatt nachgelagerte Systeme mit fehlerhaften Daten zu überfluten.
4. Observability: Strukturierte Logs, Metriken (Task-Dauer, Zeilenzahlen, Fehlerraten) und Datenqualitätsprüfungen (Great Expectations, dbt-Tests) auf jeder Pipeline-Stufe.
5. Alerting-Stufen: P1 (Pipeline ausgefallen, Daten fehlen) benachrichtigt den Bereitschaftsdienst sofort. P2 (Datenqualitätsdrift) sendet eine Slack-Benachrichtigung für den nächsten Geschäftstag.

18. Was macht eine Pipeline "produktionsreif" im Vergleich zu einem Prototyp?

Produktionsreife bedeutet: idempotente Läufe, automatisierte Retries, Monitoring und Alerting, Datenvalidierung bei Ingestion und Transformation, dokumentierte Datenverträge, versionskontrollierte Pipeline-Definitionen und ein getesteter Rollback-Pfad. Ein Prototyp verfügt über nichts davon. Die Lücke zwischen beiden ist der Ort, an dem sich der Großteil der technischen Schuld im Pipeline-Bereich ansammelt.

Cloud-Datenplattformen und Lakehouse-Architektur

Fragen zu Cloud-Plattformen prüfen, ob Kandidaten Kosten-, Skalierungs- und Architektur-Trade-offs jenseits herstellerspezifischer Syntax verstehen.

19. Was ist ein Lakehouse und warum hat es sich zur dominierenden Architektur entwickelt?

Ein Lakehouse kombiniert die Flexibilität eines Data Lake (Schema-on-Read, Rohdatenspeicherung, vielfältige Dateiformate) mit der Zuverlässigkeit eines Data Warehouse (ACID-Transaktionen, Schema-Erzwingung, Abfrageoptimierung). Technologien wie Delta Lake, Apache Iceberg und Apache Hudi ermöglichen dies, indem sie eine Metadaten- und Transaktionsschicht über Object Storage (S3, GCS, ADLS) legen.

Das Lakehouse setzt sich durch, weil es die kostspielige ETL-Schicht zwischen Lake und Warehouse eliminiert, sowohl BI-Abfragen als auch ML-Workloads auf denselben Daten unterstützt und günstigen Object Storage nutzt.

20. Wie lassen sich Cloud-Warehouse-Kosten optimieren (BigQuery, Snowflake, Redshift)?

Bewährte Strategien zur Kostenoptimierung:

• Tabellen partitionieren und clustern, um die pro Abfrage gescannten Bytes zu reduzieren
• Angemessene Warehouse-Größen wählen (Snowflake) oder Slot-Reservierungen (BigQuery) basierend auf Workload-Mustern festlegen
• Idle-Ressourcen automatisch suspendieren: Snowflake-Warehouses sollten nach 1--5 Minuten Inaktivität auto-suspendieren
• Kosten pro Abfrage überwachen: BigQuerys INFORMATION_SCHEMA.JOBS-View zeigt teure Abfragen
• Materialized Views nutzen für wiederholt berechnete Aggregationen
• Kalte Daten archivieren in günstigere Speicherstufen mit Lifecycle-Policies

Das Interview-Signal: Kandidaten, die Kosten als erstrangige Engineering-Einschränkung behandeln -- nicht als nachträglichen Gedanken.

Datenqualität und Governance

Fragen zur Datenqualität unterscheiden Ingenieure, die Pipelines ausliefern, von solchen, die vertrauenswürdige Datenplattformen betreiben.

21. Wie werden Datenqualitätsprüfungen in einer Pipeline implementiert?

Datenqualitätsprüfungen gehören an drei Stellen:

1. Ingestion: Schema-Konformität validieren, auf Null-Primärschlüssel prüfen, Zeilenanzahl-Schwellenwerte mit der Quelle abgleichen.
2. Transformation: Geschäftsregeln durchsetzen (z. B. Umsatz > 0, Datumsangaben im gültigen Bereich), referentielle Integrität über Tabellen hinweg prüfen.
3. Serving: Metrik-Drift überwachen -- ein plötzlicher 50-%-Rückgang der täglich aktiven Nutzer deutet wahrscheinlich auf ein Pipeline-Problem hin, nicht auf eine Geschäftsveränderung.

Tools: dbt-Tests (Schema und Custom), Great Expectations, Soda Core, Monte Carlo (Data Observability). Der beste Ansatz integriert Prüfungen direkt in den Pipeline-DAG, sodass Fehler die nachgelagerte Verarbeitung blockieren.

22. Was ist ein Data Contract und wie verhindert er Pipeline-Brüche?

Ein Data Contract ist eine formale Vereinbarung zwischen einem Datenproduzenten und seinen Konsumenten. Er spezifiziert: Schema (Spaltennamen, Typen, Nullability), Aktualitäts-SLA (Daten verfügbar bis 06:00 UTC), Volumenerwartungen (zwischen 1M und 10M Zeilen täglich) und semantische Regeln (Status-Feld enthält ausschließlich ACTIVE, INACTIVE, SUSPENDED).

Ändert ein Produzent sein Schema, ohne den Contract zu aktualisieren, erkennt die automatisierte Validierung die Abweichung, bevor sie sich nachgelagert ausbreitet. Dies verschiebt Pipeline-Fehler von stiller Datenkorruption hin zu expliziten, handlungsfähigen Fehlermeldungen.

System Design und Architektur

System-Design-Runden sind Standard für mittlere bis seniorlevel Data-Engineering-Positionen. Diese Fragen testen End-to-End-Denken.

23. Eine Echtzeit-Analyse-Pipeline für eine E-Commerce-Plattform entwerfen

Ein solides Design adressiert vier Bereiche:

Ingestion: Clickstream-Events und Transaktions-Events fließen in Kafka-Topics, partitioniert nach user_id für Ordnungsgarantien innerhalb einer Nutzersitzung.

Verarbeitung: Ein Flink- oder Spark-Structured-Streaming-Job konsumiert von Kafka, reichert Events mit Produktkatalogdaten an (Broadcast Join aus einer Dimensionstabelle) und berechnet Session-Level- sowie 5-Minuten-Aggregationen.

Serving: Aggregierte Metriken landen in einem Echtzeit-OLAP-Store (ClickHouse oder Apache Druid) für Dashboard-Abfragen mit Sub-Sekunden-Latenz. Rohe Events landen parallel in Delta Lake oder Iceberg für historische Analysen.

Datenqualität und Fehlerbehandlung: Schema Registry (Confluent oder AWS Glue) validiert Event-Schemas bei der Ingestion. Streaming-Datenqualitätsprüfungen markieren Anomalien (plötzlicher Rückgang des Event-Volumens) und leiten sie an ein Dead-Letter-Topic. Kafkas Consumer-Offsets ermöglichen Exactly-Once-Processing mit Checkpointing. Der Streaming-Job startet bei Fehler automatisch vom letzten Checkpoint.

24. Wie lässt sich eine Legacy-ETL-Pipeline auf einen modernen Stack migrieren?

Die Migration folgt einem Strangler-Fig-Pattern:

1. Audit: Alle bestehenden Pipelines katalogisieren -- ihre Quellen, Transformationen und Konsumenten. Abhängigkeiten und SLAs identifizieren.
2. Parallelbetrieb: Die neue Pipeline neben der alten aufbauen. Beide konsumieren dieselben Quellen und schreiben in separate Ziele.
3. Validierung: Ausgaben zwischen alter und neuer Pipeline vergleichen. Automatisierte Abgleichabfragen markieren Diskrepanzen.
4. Umstellung: Sobald die Ausgaben innerhalb der Toleranz für mindestens zwei Wochen übereinstimmen, Konsumenten auf das neue Ziel umstellen. Die alte Pipeline im Nur-Lese-Modus für Rollback bereithalten.
5. Außerbetriebnahme: Nach einer Stabilitätsphase die Legacy-Pipeline abschalten.

Die zentrale Erkenntnis: Niemals eine Big-Bang-Migration durchführen. Beide Systeme parallel betreiben, bis Vertrauen aufgebaut ist.

25. Ein kritisches Dashboard zeigt falsche Zahlen -- den Debugging-Prozess beschreiben

Ein systematischer Ansatz:

1. Problem eingrenzen: Welche Metriken sind fehlerhaft? Seit wann? Alle Dimensionen oder bestimmte Filter?
2. Serving-Layer prüfen: Das Warehouse direkt abfragen, um festzustellen, ob das Problem im Dashboard-Tool (Caching, Filterlogik) oder in den Daten selbst liegt.
3. Lineage rückwärts verfolgen: Den Daten vom Dashboard-Table zurück durch jeden Transformationsschritt folgen. Zeilenzahlen und Schlüsselmetriken auf jeder Stufe prüfen.
4. Bruchstelle identifizieren: Die Stufe, an der erwartete Werte von tatsächlichen Werten abweichen, ist der Ort der Grundursache.
5. Häufige Ursachen prüfen: Schema-Änderungen in Quellsystemen, fehlgeschlagene Pipeline-Läufe ohne Alarmierung, verspätete Daten außerhalb des Verarbeitungsfensters oder ein Deployment, das die Transformationslogik verändert hat.
6. Beheben und vorbeugen: Das unmittelbare Problem beheben, eine Datenqualitätsprüfung ergänzen, die es erkannt hätte, und das Runbook aktualisieren.

Diese Frage testet Incident-Response-Reife. Interviewer wollen strukturiertes Denken sehen, kein zufälliges Raten.

Vorbereitung auf das Data-Engineering-Interview

Der Data-Engineering-Interviewvorbereitung-Kurs auf SharpSkill deckt diese Themen mit interaktiver Praxis ab -- darunter ETL/ELT-Muster, Datenmodellierung, Airflow, BigQuery und weitere Module.

Fazit

Die 25 hier behandelten Fragen spiegeln wider, was Data-Engineering-Teams 2026 tatsächlich in Vorstellungsgesprächen erwarten:

• SQL-Window-Functions, CTEs und Abfrageoptimierung bleiben grundlegend, unabhängig vom Senioritätslevel
• ETL- vs. ELT-Entscheidungen sollten von Latenzanforderungen, Data-Governance-Bedürfnissen und Infrastrukturkosten bestimmt werden -- nicht von Trends
• Idempotenz, Data Contracts und Datenqualitätsprüfungen unterscheiden produktionsreife Pipelines von Prototypen
• Streaming-Architekturfragen konzentrieren sich auf Trade-offs (Batch vs. Streaming vs. Micro-Batch) statt auf werkzeugspezifisches Wissen
• Datenmodellierungsentscheidungen (Star vs. Snowflake, SCD-Typen) sollten sich an Konsummustern orientieren, nicht an theoretischen Best Practices
• System-Design-Antworten sollten Fehlerbehandlung, Kostenoptimierung und Observability neben dem Happy Path adressieren
• Die stärksten Kandidaten demonstrieren strukturiertes Problemlösen und ehrliches Argumentieren über Trade-offs