Fragen im Vorstellungsgespräch für Data Engineers — 30+ Fragen & Expertenantworten

Data-Engineering-Stellen sind seit 2020 um über 60 % gewachsen und damit eine der am schnellsten wachsenden Spezialisierungen in der Technologiebranche [1]. Doch bei durchschnittlich 118 Bewerbern pro offener Stelle und einer Einstellungsquote von 27 % aus Vorstellungsgesprächen [2] bleiben die Interviews hochgradig wettbewerbsintensiv. Moderne Vorstellungsgespräche für Data Engineers gehen über SQL-Kompetenz hinaus — sie testen Ihre Fähigkeit, skalierbare Pipelines zu entwerfen, Daten für Analysen zu modellieren, Datenqualität zu managen und in Produktionsumgebungen mit Tools wie Spark, Kafka, dbt und Airflow zu arbeiten [3]. Die folgenden Fragen spiegeln die Muster wider, die von Einstellungsteams bei Unternehmen verwendet werden — von Startups, die ihren ersten Datenstack aufbauen, bis hin zu Großunternehmen, die Petabyte-große Data Warehouses verwalten.

Wichtigste Erkenntnisse

• Vorstellungsgespräche für Data Engineers umfassen SQL, Python, Datenmodellierung, ETL/ELT-Pipeline-Design und Systemarchitektur [1].
• Erwarten Sie Coding-Aufgaben in SQL und Python sowie Whiteboard-Sessions zum Pipeline-Design.
• Verhaltensfragen untersuchen, wie Sie mit Datenqualitätsvorfällen, Stakeholder-Kommunikation und teamübergreifender Zusammenarbeit umgehen.
• Kenntnisse moderner Datenstack-Tools (dbt, Airflow, Spark, Kafka, Snowflake, Databricks) werden zunehmend erwartet.
• Das Verständnis von Data Governance, Datenherkunft und Observability unterscheidet Senior-Kandidaten.

Verhaltensfragen

Data Engineers befinden sich an der Schnittstelle von Engineering und Analytics und arbeiten mit Data Scientists, Analysten und Produktteams zusammen. Verhaltensfragen bewerten, wie Sie diese Beziehungen unter realen Bedingungen navigieren [4].

1. Beschreiben Sie eine Situation, in der eine von Ihnen erstellte Datenpipeline in der Produktion fehlgeschlagen ist. Wie haben Sie das Problem diagnostiziert und behoben?

Verwenden Sie STAR: die Situation (täglicher ETL-Job schlug um 3 Uhr morgens fehl, verzögerte das morgendliche Analytics-Dashboard), die Aufgabe (Datenaktualität vor Geschäftsbeginn wiederherstellen), die Aktion (Airflow-Logs geprüft, Schemaänderung in der Quell-API identifiziert, die den Extraktionsschritt unterbrach, Schema-Evolution-Handling implementiert und Alerting hinzugefügt), und das Resultat (Pipeline innerhalb von 90 Minuten wiederhergestellt, Integrationstests hinzugefügt, die Schemaänderungen künftig automatisch erkennen).

2. Erzählen Sie von einer Situation, in der Sie mit einem Data Scientist oder Analysten uneinig waren, wie Daten modelliert werden sollten. Wie haben Sie das gelöst?

Beschreiben Sie den Kompromiss — vielleicht wollte der Analyst eine breite denormalisierte Tabelle für Abfrageleistung, während Sie ein normalisiertes Dimensionsmodell für Wartbarkeit befürworteten. Erklären Sie, wie Sie beide Ansätze mit repräsentativen Abfragen getestet und einen Kompromiss gefunden haben (materialisierte Views oder voraggregierte Tabellen), der beiden Anforderungen gerecht wurde.

3. Führen Sie mich durch eine Situation, in der Sie eine Legacy-Datenpipeline geerbt haben und entscheiden mussten, ob Sie sie refaktorisieren oder neu erstellen.

Bewerten Sie die Entscheidungskriterien: Dokumentationsqualität, Testabdeckung, Geschäftskritikalität und die Kosten von Ausfallzeiten während der Migration. Starke Antworten zeigen eine systematische Bewertung, anstatt standardmäßig „alles neu schreiben" oder „so lassen" zu wählen.

4. Beschreiben Sie eine Situation, in der Sie Datenqualitätsmonitoring implementiert haben, das ein Problem erkannte, bevor es nachgelagerte Konsumenten erreichte.

Besprechen Sie spezifische Datenqualitätsprüfungen: Null-Rate-Monitoring, Frische-SLAs, Anomalieerkennung bei Zeilenanzahlen und Schemavalidierung. Erwähnen Sie Tools wie Great Expectations, dbt-Tests oder Monte Carlo. Quantifizieren Sie die Auswirkung — „erkannte einen 40%igen Rückgang der Zeilenanzahl durch eine Änderung im Quellsystem, die zu fehlerhafter Umsatzberichterstattung geführt hätte."

5. Erzählen Sie von einer Situation, in der Sie einem nicht-technischen Stakeholder ein Data-Engineering-Konzept erklären mussten.

ETL-Prozesse, Datenlatenz und Pipeline-Abhängigkeiten in geschäftlichen Begriffen zu formulieren ist essenziell. Beschreiben Sie die Verwendung von Analogien, Dashboards oder Datenfrische-Indikatoren, um den Pipeline-Zustand sichtbar und verständlich zu machen.

6. Wie sind Sie mit einer Situation umgegangen, in der Daten aus einem Quellsystem unzuverlässig oder inkonsistent waren?

Besprechen Sie die Implementierung von Validierung auf der Ingestion-Ebene, die Erstellung von Abstimmungsprüfungen zwischen Quelle und Ziel, die Dokumentation von Datenqualitätsproblemen in einem Datenkatalog und die Kommunikation bekannter Einschränkungen an nachgelagerte Nutzer, anstatt fehlerhafte Daten stillschweigend weiterzugeben.

Technische Fragen

Technische Fragen testen Ihre Tiefe in SQL, verteilten Systemen, Datenmodellierung und Pipeline-Architektur [5].

1. Erklären Sie den Unterschied zwischen ETL und ELT. Wann würden Sie welchen Ansatz wählen?

ETL (Extract, Transform, Load) transformiert Daten vor dem Laden in das Warehouse — geeignet, wenn das Warehouse begrenzte Rechenkapazität hat oder wenn Transformationen komplexe Geschäftslogik erfordern. ELT (Extract, Load, Transform) lädt Rohdaten zuerst und transformiert sie im Warehouse — bevorzugt mit modernen spaltenorientierten Warehouses (Snowflake, BigQuery, Redshift), die elastische Rechenkapazität für Transformationen haben [3]. Besprechen Sie, wie dbt zum Standardtool für das „T" in ELT geworden ist.

2. Schreiben Sie eine SQL-Abfrage, um das zweithöchste Gehalt in jeder Abteilung zu finden.

Verwenden Sie eine Fensterfunktion: SELECT department, employee, salary FROM (SELECT department, employee, salary, DENSE_RANK() OVER (PARTITION BY department ORDER BY salary DESC) as rank FROM employees) ranked WHERE rank = 2. Besprechen Sie, warum DENSE_RANK Gleichstände korrekt behandelt und warum RANK oder ROW_NUMBER unterschiedliche Ergebnisse liefern könnten.

3. Wie würden Sie eine inkrementelle Datenpipeline entwerfen, die nur geänderte Datensätze aus einem Quellsystem verarbeitet?

Besprechen Sie Change-Data-Capture-(CDC)-Strategien: zeitstempelbasierte inkrementelle Loads (unter Verwendung von updated_at-Spalten), logbasiertes CDC (Debezium liest Datenbank-Write-Ahead-Logs) und hashbasierter Vergleich. Adressieren Sie die Herausforderungen: verspätet eintreffende Daten, Löschungen, die für zeitstempelbasierte Ansätze unsichtbar sind, und Garantien für Exactly-Once-Verarbeitung [1].

4. Erklären Sie die Unterschiede zwischen einem Sternschema und einem Schneeflockenschema. Wann würden Sie welches verwenden?

Ein Sternschema hat eine zentrale Faktentabelle, die mit denormalisierten Dimensionstabellen verbunden ist — einfachere Abfragen, schnellere Lesezugriffe, ideal für BI-Tools. Ein Schneeflockenschema normalisiert Dimensionstabellen in Unterdimensionen — reduziert Speicherredundanz, erhöht aber die Abfragekomplexität. Sternschemata werden für analytische Workloads bevorzugt, bei denen Abfrageleistung wichtig ist; Schneeflockenschemata eignen sich für Umgebungen, in denen Speichereffizienz und Datenintegrität Priorität haben.

5. Wie unterscheidet sich Apache Kafka von einer traditionellen Message Queue wie RabbitMQ, und wann würden Sie Kafka für eine Datenpipeline wählen?

Kafka ist eine verteilte Event-Streaming-Plattform mit dauerhaften, geordneten, wiederabspielbaren Logs. RabbitMQ ist ein Message Broker, der für Punkt-zu-Punkt-Zustellung mit Bestätigungssemantik optimiert ist. Wählen Sie Kafka für Hochdurchsatz-Event-Streaming, Log-Aggregation und Szenarien, in denen mehrere Consumer dieselben Daten unabhängig lesen müssen (Fan-out). Wählen Sie RabbitMQ für Task-Queues mit komplexem Routing und Exactly-Once-Zustellanforderungen [5].

6. Was ist Datenpartitionierung, und wie verbessert sie die Abfrageleistung in einem Data Warehouse?

Partitionierung teilt große Tabellen in Segmente basierend auf einem Schlüssel (Datum, Region, Kunden-ID). Abfragen, die nach dem Partitionsschlüssel filtern, scannen nur relevante Segmente, was I/O und Rechenkosten reduziert. Besprechen Sie Partitionsstrategien: Bereichspartitionierung für Zeitreihendaten, Hash-Partitionierung für gleichmäßige Verteilung und die Bedeutung der Wahl von Partitionsschlüsseln, die mit gängigen Abfragemustern übereinstimmen.

7. Wie gehen Sie mit Schemaevolution in einer Datenpipeline um, wenn vorgelagerte Quellen ihr Datenformat ändern?

Implementieren Sie eine Schema-Registry (Confluent Schema Registry für Kafka oder Avro/Parquet-Schemaevolution). Definieren Sie Vorwärts- und Rückwärtskompatibilitätsregeln. Verwenden Sie Landing-Zones, die Rohdaten ohne Schema-Durchsetzung akzeptieren, dann validieren und transformieren Sie in Staging-Schichten. Alarmieren Sie bei Schemaänderungen und implementieren Sie Circuit Breaker, die die Verarbeitung stoppen, anstatt korrupte Daten weiterzugeben [3].

Situative Fragen

Situative Fragen präsentieren realistische Pipeline-Herausforderungen, um Ihren Problemlösungsansatz zu bewerten [4].

1. Ihre tägliche Pipeline braucht 6 Stunden zur Fertigstellung, aber das Geschäft benötigt alle 2 Stunden aktualisierte Daten. Wie gehen Sie vor?

Analysieren Sie, wo die Zeit verbraucht wird — bei der Extraktion, Transformation oder dem Laden? Implementieren Sie inkrementelle Verarbeitung, um vollständige Tabellenneuladen zu ersetzen. Parallelisieren Sie unabhängige Transformationen. Erwägen Sie, schwere Transformationen ins Warehouse zu verlagern (ELT), um dessen elastische Rechenkapazität zu nutzen. Wenn das SLA Nahezu-Echtzeit erfordert, evaluieren Sie Streaming-Alternativen für die kritischsten Tabellen.

2. Ein Data Scientist berichtet, dass die Genauigkeit eines Machine-Learning-Modells plötzlich gesunken ist. Er vermutet ein Datenqualitätsproblem. Wie untersuchen Sie das?

Prüfen Sie Pipeline-Metadaten: Hat der letzte Lauf erfolgreich abgeschlossen? Vergleichen Sie Zeilenanzahlen, Null-Raten und Wertverteilungen mit historischen Baselines. Prüfen Sie auf Quellsystemänderungen (Schemaänderungen, Änderungen von Geschäftsregeln). Verwenden Sie Datenherkunftstools, um die Eingabefeatures des Modells bis zu ihren Quelltabellen zurückzuverfolgen und zu identifizieren, wo die Verteilungsverschiebung aufgetreten ist.

3. Sie entwerfen eine Datenplattform für ein Startup, das derzeit 10 GB Daten hat, aber erwartet, innerhalb von 18 Monaten 10 TB zu erreichen. Wie gestalten Sie die Architektur für Wachstum, ohne überzuengineeren?

Beginnen Sie mit einem verwalteten Cloud-Warehouse (Snowflake, BigQuery), das elastisch skaliert. Verwenden Sie dbt für Transformationen, das mit der Warehouse-Rechenkapazität skaliert. Implementieren Sie von Anfang an Orchestrierung mit Airflow oder Dagster — nachträglich hinzufügen ist schwieriger. Entwerfen Sie dimensionale Modelle, die zukünftige Erweiterung unterstützen. Vermeiden Sie vorzeitige Optimierung wie Spark-Cluster, bis das Datenvolumen dies tatsächlich erfordert.

4. Zwei verschiedene Teams benötigen dieselben Quelldaten, aber mit unterschiedlichen Transformationen und Frischeanforderungen. Wie vermeiden Sie die Duplizierung von Pipelines?

Implementieren Sie eine gemeinsame Bronze/Silver/Gold-Medallion-Architektur. Nehmen Sie Rohdaten einmal in eine Bronze-Schicht auf, wenden Sie allgemeine Bereinigung in der Silver-Schicht an und lassen Sie jedes Team seine eigenen Gold-Schicht-Transformationen erstellen. Verwenden Sie einen Datenkatalog, um verfügbare Datensätze zu dokumentieren und zu verhindern, dass Teams redundante Ingestion-Pipelines erstellen.

5. Ihre Pipeline verwendet eine API mit einem Rate Limit von 100 Anfragen pro Minute, aber Sie müssen täglich 1 Million Datensätze extrahieren. Wie gestalten Sie die Extraktion?

Implementieren Sie Rate-Limiting mit exponentiellem Backoff im Extraktionscode. Verwenden Sie Paginierung mit cursorbasierten Offsets für inkrementelle Abrufe. Planen Sie die Extraktion zu Nebenzeiten, um den Durchsatz innerhalb der Rate Limits zu maximieren. Cachen Sie API-Antworten, um das erneute Abrufen unveränderter Daten zu vermeiden. Wenn die API Bulk-Export-Endpunkte unterstützt, verwenden Sie diese anstelle von Einzeldatensatz-Abrufen.

Fragen an den Interviewer

Data Engineers sollten die Reife der Datenplattform und die Engineering-Kultur des Teams bewerten [1].

1. Wie sieht Ihr aktueller Datenstack aus — Warehouse, Orchestrierung, Transformation und Observability-Tools? — Enthüllt das technische Umfeld und den Modernisierungsstatus.
2. Wie gehen Sie heute mit Datenqualität um, und gibt es ein bestehendes Framework für Datenqualitätsmonitoring? — Zeigt die Reife der Data Governance.
3. Wie ist das Verhältnis von Data Engineers zu Data Scientists und Analysten im Team? — Zeigt, ob Data Engineers mit Konsumenten zusammenarbeiten oder isoliert sind.
4. Wie handhabt das Team Bereitschaftsdienst für Pipeline-Ausfälle? — Bewertet die operative Belastung und Erwartungen an die Work-Life-Balance.
5. Gibt es einen Datenkatalog oder ein Datenherkunftstool? — Zeigt Auffindbarkeit und Dokumentationspraktiken.
6. Was ist die größte Data-Engineering-Herausforderung, der das Team derzeit gegenübersteht? — Gibt Einblick, ob die Rolle mit Ihren Fähigkeiten und Interessen übereinstimmt.

Interviewformat und was Sie erwarten können

Vorstellungsgespräche für Data Engineers umfassen typischerweise vier bis fünf Runden, die sowohl Coding-Fähigkeiten als auch Systemdesign-Denken bewerten [3].

Recruiter-Screening (30 Minuten): Besprechung von Erfahrung, Gehaltsvorstellungen und allgemeinem technischen Hintergrund.

SQL-Coding-Runde (60 Minuten): SQL-Abfragen in einer gemeinsamen Umgebung schreiben — Fensterfunktionen, CTEs, Aggregationen und JOINs. Erwarten Sie Optimierungsdiskussionen über Abfrageausführungspläne.

Python-/Programmierrunde (60 Minuten): Datenverarbeitungslogik implementieren — Dateien parsen, Datenstrukturen transformieren oder eine einfache Pipeline-Komponente erstellen. Fokus auf sauberen, testbaren Code.

Systemdesign-Runde (60–90 Minuten): Eine Datenpipeline oder Datenplattform End-to-End entwerfen. Häufige Aufgaben: ein Echtzeit-Analysesystem entwerfen, einen Data Lake für ein Multiprodukt-Unternehmen aufbauen oder eine ereignisgesteuerte Datenplattform architekturieren.

Verhaltensrunde (45–60 Minuten): Fragen zu Zusammenarbeit, Incident Response und Kommunikation mit nicht-technischen Stakeholdern.

Vorbereitung

Die Vorbereitung auf Data-Engineer-Interviews sollte SQL-Übungen, Studium von Pipeline-Design und toolspezifisches Wissen kombinieren [5].

SQL meistern: Üben Sie Fensterfunktionen, CTEs, Self-Joins und Abfrageoptimierung. Nutzen Sie Plattformen wie LeetCode-Datenbankaufgaben, HackerRank SQL oder Stratascratch. Seien Sie in der Lage, komplexe Abfragen ohne IDE zu schreiben.

Datenmodellierung studieren: Verstehen Sie Sternschemata, Schneeflockenschemata, Slowly Changing Dimensions (Typ 1, 2, 3) und die Medallion-Architektur (Bronze/Silver/Gold). Seien Sie bereit, ein dimensionales Modell am Whiteboard zu entwerfen.

Ihre Tools kennen: Seien Sie bereit, die in der Stellenbeschreibung genannten Tools zu diskutieren. Für Spark: verstehen Sie RDDs vs. DataFrames, Partitionierung und Shuffle-Operationen. Für Airflow: verstehen Sie DAGs, Operators, Sensors und XComs. Für dbt: verstehen Sie Models, Tests, Macros und inkrementelle Materialisierungen.

Pipeline-Design üben: Gehen Sie fünf End-to-End-Pipeline-Designs durch: Batch-ETL, Echtzeit-Streaming, CDC-basierte Replikation, API-basierte Extraktion und Data-Warehouse-Migration. Identifizieren Sie für jedes die Tools, Fehlermodi und Monitoring-Strategie.

Datenqualitätsgeschichten vorbereiten: Haben Sie konkrete Beispiele für Datenqualitätsprobleme, die Sie entdeckt, untersucht und gelöst haben. Quantifizieren Sie die geschäftliche Auswirkung des Erkennens (oder Verpassens) dieser Probleme.

Konzepte verteilter Systeme wiederholen: Verstehen Sie Partitionierung, Replikation, Konsistenzmodelle und das CAP-Theorem, wie sie auf Datensysteme anwendbar sind. Bücher wie Designing Data-Intensive Applications von Martin Kleppmann sind eine unschätzbare Vorbereitung.

Häufige Interviewfehler

Vermeiden Sie diese Fallstricke, die Data-Engineering-Kandidaten häufig disqualifizieren [4].

1. Korrektes, aber nicht optimiertes SQL schreiben. Eine Abfrage, die das richtige Ergebnis liefert, aber unnötigerweise die gesamte Tabelle scannt, signalisiert mangelndes Produktionsbewusstsein. Diskutieren Sie immer Indizierung, Partitionierung und Ausführungspläne.

2. Datenqualität im Pipeline-Design ignorieren. Eine Pipeline ohne Validierung, Monitoring und Alerting ist unvollständig. Integrieren Sie immer Datenqualitätsprüfungen in Ihre Systemdesign-Antworten.

3. Überengineering für Skalierung, die Sie nicht haben. Kafka und Spark für eine tägliche Last von 10 GB vorzuschlagen ist genauso ein Fehler wie einfache Skripte für eine tägliche Last von 10 TB zu verwenden. Passen Sie die Architektur an das tatsächliche Datenvolumen und die Wachstumstrajektorie an.

4. Den geschäftlichen Kontext nicht verstehen. Datenpipelines dienen Geschäftsentscheidungen. Kandidaten, die technisch einwandfreie, aber geschäftlich irrelevante Lösungen entwerfen, verfehlen den Punkt. Stellen Sie klärende Fragen darüber, wer die Daten konsumiert und welche Entscheidungen sie antreibt.

5. Batch und Streaming als austauschbar behandeln. Beide haben unterschiedliche Kompromisse bei Komplexität, Kosten und Latenz. Seien Sie klar darüber, wann welcher Ansatz angemessen ist und welche operativen Auswirkungen die Wahl hat.

6. Operative Belange vernachlässigen. Pipeline-Monitoring, Alerting, Retry-Logik, Dead-Letter-Queues und Backfill-Verfahren sind nicht optional — sie machen eine Pipeline produktionsreif [3].

Wichtigste Erkenntnisse

Vorstellungsgespräche für Data Engineers bewerten Ihre Fähigkeit, Datensysteme zu entwerfen, aufzubauen und zu betreiben, die zuverlässige, zeitgerechte Daten an die Menschen liefern, die sie benötigen. Bereiten Sie sich vor, indem Sie SQL meistern, moderne Datenstack-Tools verstehen und End-to-End-Pipeline-Design üben. Die Kandidaten, die herausstechen, sind diejenigen, die über Datenqualität, operative Belastbarkeit und Geschäftswirkung nachdenken — nicht nur über den Happy Path.

Möchten Sie sicherstellen, dass Ihr Lebenslauf die richtigen Data-Engineering-Fähigkeiten hervorhebt? Testen Sie den kostenlosen ATS-Score-Checker von ResumeGeni, um Ihren Data-Engineer-Lebenslauf vor der Bewerbung zu optimieren.

Häufig gestellte Fragen

Welche Programmiersprachen sollte ich für ein Data-Engineer-Interview beherrschen? SQL ist essenziell. Python wird für die meisten Rollen erwartet. Scala ist wertvoll für Spark-lastige Umgebungen. Java kommt in einigen Enterprise-Umgebungen vor [5].

Wie wichtig ist Cloud-Erfahrung für Data-Engineering-Interviews? Sehr wichtig. Die meisten modernen Data-Engineering-Rollen erfordern Erfahrung mit mindestens einer Cloud-Plattform (AWS, GCP oder Azure) und Cloud-nativen Datendiensten (Redshift, BigQuery, Snowflake, Databricks) [1].

Beinhalten Data-Engineer-Interviews Live-Coding? Ja. Erwarten Sie mindestens eine Runde Live-SQL-Coding und oft eine Python-Coding-Runde mit Fokus auf Datentransformationslogik [3].

Was ist die häufigste Systemdesign-Frage für Data Engineers? Das Entwerfen einer Batch-Datenpipeline mit inkrementeller Verarbeitung oder das Entwerfen eines Echtzeit-Event-Streaming-Systems sind die zwei häufigsten Aufgabenstellungen.

Wie bereite ich mich auf Systemdesign-Runden vor, wenn ich nur an bestehenden Pipelines gearbeitet habe? Studieren Sie Open-Source-Architekturen, lesen Sie Engineering-Blogbeiträge von Unternehmen wie Netflix, Uber und Airbnb und üben Sie, Designentscheidungen laut zu erklären. Die Schlüsselkompetenz ist das Artikulieren von Kompromissen, nicht das Auswendiglernen von Architekturen.

Sollte ich dbt für Data-Engineering-Interviews lernen? Ja — dbt ist zum Standardtool im modernen Datenstack geworden. Das Verständnis von Models, Tests und inkrementellen Materialisierungen wird für die meisten Analytics-Engineering- und Data-Engineering-Rollen erwartet [5].

Welche Zertifizierungen helfen bei Data-Engineering-Interviews? Cloud-Zertifizierungen (AWS Data Analytics Specialty, GCP Professional Data Engineer, Azure Data Engineer Associate) demonstrieren plattformspezifisches Wissen und werden von vielen Arbeitgebern geschätzt.