Data-Engineer-Interview-Fragen: SQL, Pipelines und Zuverlässigkeit unter Druck

Die Interviewschleife dieser Rolle dreht sich um eine Kernfrage: Können Sie Daten im großen Maßstab korrekt verschieben und transformieren, ohne dass jemand daneben stehen muss. Das zeigt sich in vier zusammenhängenden Fähigkeitsbereichen: SQL und Datenmodellierung, Pipeline-Design über ETL- und ELT-Muster, Zuverlässigkeit bei Fehlern und das Urteilsvermögen, um Trade-offs an Personen zu kommunizieren, die keinen Code schreiben.

Die meisten Schleifen kombinieren eine praktische SQL-Runde, eine auf eine Pipeline oder Datenplattform konzentrierte Systemdesign-Runde und eine Verhaltensrunde, die untersucht, wie Sie mit beschädigten Daten, fehlenden Anforderungen und Meinungsverschiedenheiten mit Datenwissenschaftlern oder Analysten umgehen. Einige Unternehmen führen auch eine Take-Home-Aufgabe durch, bei der Sie eine kleine Pipeline aus einem rohen Datensatz erstellen, was die gleichen Fähigkeiten ohne Live-Publikum testet.

Interviewer bewerten nicht nur, ob Ihre Abfrage die richtigen Zeilen zurückgibt. Sie hören zu, wie Sie Ihre Überlegungen darstellen: warum Sie sich für eine Fensterfunktion gegenüber einem Self-Join entschieden haben, warum Sie ein inkrementelles Laden gegenüber einer vollständigen Aktualisierung gewählt haben, warum Sie bei Zeilen-Count-Drift alarmieren würden, anstatt nur Nullwerte zu zählen. Ein Kandidat, der eine korrekte Antwort murmelt, verliert oft gegen einen, der eine etwas rauere Antwort klar erklärt.

Vor Ihrem Interview erstellen Sie eine kurze Liste von Pipelines, Tabellen oder Vorfällen aus Ihrer eigenen Arbeit, die Sie in zwei oder drei Sätzen beschreiben können. Sie werden sie ständig über die SQL-, Design- und Verhaltensrunden hinweg nutzen.

SQL ist immer noch das häufigste Gate in Data-Engineering-Interviews, auch bei Unternehmen, die hauptsächlich auf Spark oder dbt ausgeführt werden. Erwarten Sie Aufforderungen wie: Schreiben Sie eine Abfrage, die die letzte Bestellung jedes Kunden zurückgibt, finden Sie Lücken in einer Datumsfolge pro Konto, berechnen Sie einen laufenden siebentägigen Gesamtbetrag des täglichen Umsatzes, oder deduplizieren Sie Zeilen, ohne die neueste Version zu verlieren.

Fensterfunktionen kommen ständig vor. ROW_NUMBER() mit einer PARTITION BY-Klausel ist das Standardwerkzeug für "neueste Aufzeichnung pro Schlüssel"-Probleme; LAG() und LEAD() handhaben Lücken-und-Insel- und Änderungsdetektionsfragen; SUM() OVER ein geordnetes Fenster handhaut laufende Summen ohne einen Self-Join. Interviewer möchten auch, dass Sie einen Abfrageplan laut begründen: Welche Join-Reihenfolge der Optimizer möglicherweise wählt, wo ein Index hilfreich wäre, und wann eine Abfrage langsam ist, weil ein Partitionsfilter fehlt, anstatt eines schlechten Joins.

Datenmodellierungsfragen testen einen anderen Muskel: Schemadesign unter widersprechenden Einschränkungen. Ein häufiger Aufforderung ist das Entwerfen eines Star-Schemas für einen E-Commerce- oder Abonnementdatensatz mit Fakttabellen für Bestellungen oder Ereignisse und Dimensionstabellen für Kunden, Produkte und Zeit. Seien Sie bereit, langsam wechselnde Dimensionen zu erklären: Wenn ein Typ-1-Update (Überschreiben) in Ordnung ist, gegenüber wenn Sie Typ 2 (neue Zeile, effektive Daten) benötigen, um die Historie für eine Metrik wie "Kundensegment zum Zeitpunkt des Kaufs" zu bewahren.

Sie sollten auch Normalisierungs-Trade-offs rechtfertigen können. OLTP-Systeme bevorzugen normalisierte Tabellen, um Write-Konsistenz zu schützen; Analytics-Warehouses denormalisieren oft absichtlich, damit ein BI-Tool eine breite Tabelle abfragen kann, anstatt fünf Joins durchzuführen. Das Benennen dieses Trade-offs, anstatt einen Stil als universell korrekt zu behandeln, ist das, was eine starke Antwort von einer lehrbuchmäßigen unterscheidet.

Pipeline-Design-Fragen bitten Sie, zu skizzieren, wie Rohdaten zu einer vertrauenswürdigen Tabelle werden. Eine typische Aufforderung: Entwerfen Sie eine Pipeline, die Clickstream-Ereignisse aufnimmt und eine tägliche aktive Benutzertabelle erzeugt, die das Product-Team jeden Morgen abfragen kann. Eine starke Antwort beginnt mit der Quelle, nicht mit dem Werkzeug: Wo stammen die Daten, wie oft kommen sie an, welche Latenz ist akzeptabel, und was passiert, wenn ein Batch zu spät ist oder ein Stream abbricht.

Erwarten Sie, ETL und ELT explizit zu vergleichen. Im ETL transformieren Sie Daten vor dem Laden in das Warehouse, was sich für kleinere Volumen oder strenge Compliance-Anforderungen eignet. Im ELT laden Sie Rohdaten zuerst und transformieren sie innerhalb des Warehouse mit einem Tool wie dbt, was jetzt das häufigere Muster ist, da Warehouse-Compute billig ist und es die Rohhistorie für die Neuverarbeitung beibehält. Seien Sie in der Lage zu erklären, warum Sie sich für eine dieser Optionen für eine bestimmte Datenquelle entscheiden würden.

Orchestration-Fragen prüfen, ob Sie über Fehlschlag nachdenken, nicht nur über den glücklichen Pfad. Interviewer möchten von DAGs in einem Tool wie Airflow oder Dagster hören, Task-Level-Wiederholungen, Rückfüllungen für ein Schema, das sich mitten in der Geschichte geändert hat, und inkrementelle Lasten, die nur neue oder geänderte Zeilen verarbeiten, anstatt jede Ausführung eine ganze Tabelle neu zu verarbeiten. Idempotenz ist eine Lieblings-Nachfrage: Wenn eine Task auf halbem Weg fehlschlägt und erneut ausgeführt wird, erzeugt sie doppelte Zeilen oder das gleiche korrekte Ergebnis?

Streaming-spezifische Fragen zeigen sich häufiger bei Unternehmen mit Echtzeit-Anforderungen. Sie können gefragt werden, eine Kafka-basierte Streaming-Pipeline gegen einen Micro-Batch-Ansatz zu vergleichen, oder genau zu erklären, was exactly-once versus at-least-once Liefersemantik bedeutet, und welche Deduplizierungsstrategie Sie nachgelagert verwenden würden, wenn ein System nur at-least-once garantiert.

Zuverlässigkeitsfragen in Data-Engineer-Interview-Fragen beginnen normalerweise mit einem Szenario: Ein Dashboard zeigt heute Morgen null Umsatz, führen Sie mich durch, wie Sie es debuggen würden. Eine gute Antwort arbeitet rückwärts durch die Pipeline in der richtigen Reihenfolge, anstatt zufällig zu raten. Überprüfen Sie, ob das Quellsystem tatsächlich Daten produziert hat, überprüfen Sie die Protokolle und Zeilenzahlen des Aufnahmejobs, überprüfen Sie die Transformationsschicht auf einen fehlgeschlagenen oder stillschweigend übersprungenen Lauf, und überprüfen Sie, ob das Dashboard selbst auf eine veraltete Tabelle oder einen Cache verweist.

Datenqualitätsprüfungen sind ein häufiges Thema auf sich allein. Interviewer möchten Besonderheiten: Null-Raten-Checks für erforderliche Felder, Zeilen-Count-Anomalieerkennung gegen einen historischen Basis, Frische-Checks, die alarmieren, wenn eine Tabelle nicht innerhalb ihres erwarteten Fensters aktualisiert wurde, und referentielle Checks, die verwaiste Fremdschlüssel nach einer Quellschemaänderung erfassen. Tools wie dbt-Tests oder Great Expectations kommen häufig vor, aber das Benennen eines Tools ist weniger wichtig als die Erklärung, was Sie tatsächlich überprüfen würden und warum dieser Check den Fehlermodus erfasst, dem Sie sich Sorgen machen.

Sie sollten auch mit Fragen zu SLAs und SLOs für Datenfreshness rechnen, und wie Sie Benachrichtigungen entwerfen würden, damit die richtige Person für ein echtes Problem benachrichtigt wird, ohne das Team mit Lärm aus erwarteter Variation zu ersticken. Sprechen Sie darüber, wie Sie Schwellenwerte festlegen, Benachrichtigungen nach Schweregrad weiterleiten und eine Benachrichtigung vermeiden, die jeden Tag ausgelöst wird und ignoriert wird.

Ein verwandter Verhaltensthread ist die Postmortem: Beschreiben Sie einen Vorfall, bei dem schlechte Daten einen Bericht oder Modell erreichten, bevor jemand es erkannte. Interviewer hören auf Verantwortung und Prozessveränderung, nicht Schuld. Eine starke Antwort nennt die Grundursache, die unmittelbare Behebung und die spezifische Sicherungsmaßnahme, die Sie danach hinzugefügt haben, wie etwa eine neue Validierungsprüfung oder eine Änderung, wie Rückfüllungen überprüft werden.

Verhaltungsfragen für Data Engineers konzentrieren sich weniger auf individuelle Heldentaten und mehr darauf, wie Sie konkurrierende Anforderungen von Personen handhaben, die von Ihren Pipelines abhängen. Häufige Aufforderungen: Erzählen Sie mir von einer Zeit, in der ein Stakeholder Daten schneller brauchte als Ihre Pipeline liefern konnte; erzählen Sie mir von einem Meinungsverschied mit einem Datenwissenschaftler oder Analytiker über ein Schema oder eine Metrikdefinition; erzählen Sie mir von einer Zeit, in der Sie einen Fehler in Produktionsdaten entdeckten, nachdem er bereits in einem Bericht verwendet worden war.

Verwenden Sie STAR, aber halten Sie den Abschnittsabschnitt spezifisch für Datenarbeit. Für die "Daten bereits in einem schlechten Bericht verwendet"-Geschichte erklären Sie, wie Sie den Fehler entdeckten, wem Sie es sagten und wie schnell, wie Sie die Downstream-Zahlen korrekt machten, und welche Validierung Sie hinzugefügt haben, damit die gleiche Fehlerklasse nicht erneut durchschlüpfen konnte. Interviewer möchten sehen, dass Sie Dateninzidente wie ein Softwareingenieur einen Produktionsausfall behandeln, nicht als eine kleine Unannehmlichkeit.

Für Schema- oder Metrik-Meinungsverschiedenheiten zeigen Sie, dass Sie eine technische Position halten können, während Sie trotzdem eine Entscheidung erreichen, mit der das Team leben kann. Erklären Sie den Trade-off, den Sie verfochten haben, wie Abfrageleistung versus Speicherkosten, oder ein strengeres Schema versus schnelleres Onboarding einer neuen Datenquelle, und wie Sie es gelöst haben, ohne einfach die andere Person zu überstimmen.

Prioritisierungsfragen sind ebenfalls häufig: Wie entscheiden Sie zwischen dem Beheben einer instabilen Pipeline, der Erstellung einer neuen Datenquelle, auf die ein Stakeholder wartet, und der Tilgung technischer Schulden in einem alten Modell. Eine glaubwürdige Antwort wiegt die Geschäftsauswirkungen, die Reichweite der Auswirkungen, wenn die instabile Pipeline erneut fehlschlägt, und wie lange das Team die Schulden noch tolerieren kann, bevor sie jede zukünftige Änderung verlangsamt.

Diese Fragen sind leichter auf dem Papier als laut zu beantworten. Das Erklären einer Fensterfunktion, eines Pipeline-Designs oder eines Incidents-Postmortem in klaren gesprochenen Sätzen ist eine andere Fähigkeit als das Schreiben des korrekten SQL oder das Zeichnen des richtigen DAG, und Interviewer benoten die Erklärung so sehr wie die Antwort.

Üben Sie, SQL-Lösungen zu narretieren, bevor Sie eine Tastatur anfassen: Geben Sie den Ansatz an, benennen Sie die Fensterfunktion oder Join-Strategie, die Sie verwenden werden, dann schreiben Sie die Abfrage. Für Pipeline-Design-Aufforderungen üben Sie, durch Quelle, Latenzanforderungen, Transformationslogik und Fehlerbehandlung in dieser Reihenfolge zu sprechen, so wird die Struktur unter Druck automatisch. Für Verhaltensgeschichten üben Sie, bis die technischen Details spezifisch bleiben, ohne sich in einen Monolog zu verwandeln.

Nehmen Sie sich selbst auf, wenn Sie einige dieser Fragen beantworten, und hören Sie zurück auf Füllwörter, Herumrammelei, bevor Sie zum Punkt kommen, oder übersprungene Schritte in einer Pipeline-Durchgehung. SayNow AI kann dir helfen, Data-Engineer-Interview-Fragen laut zu üben, mit Feedback zu Klarheit und Tempo, damit dein technisches Denken so selbstbewusst rüberkommt, wie es auf der Seite gelesen wird.