Interviewfragen für Data Engineers, nach Runde

Vielleicht bereitest du dich genauso vor wie für einen Software-Engineering-Prozess und fragst dich, was anders ist. Dieser Abschnitt bildet die Runden ab, die diese Interviews wiederverwenden, damit du deine Zeit auf die zwei verwendest, die Kandidaten wirklich trennen. Der technische Filter ist selten der Punkt, an dem Angebote verloren gehen.

• SQL. Fensterfunktionen, Deduplizierung und Query-Performance, meist live.
• Datenmodellierung. Tabellen für ein beschriebenes Geschäft entwerfen und die gewählte Granularität verteidigen.
• Pipeline- und ETL-Design. Eine offene Systemdesign-Runde, beschränkt auf Datenbewegung.
• Verteilte Verarbeitung. Wie ein Framework deinen Job tatsächlich ausführt, und warum er langsam ist.
• Coding. Python oder Scala, oft leichter als eine Software-Engineering-Runde.
• Verhalten. Bereitschaftsdienst-Vorfälle, kaputte Dashboards und Stakeholder, die die Zahl gestern wollten.

Titel überschneiden sich stark mit Analytics Engineering und Plattformrollen, daher verschiebt sich die Mischung. Verwandte Rollen-Sammlungen findest du im Hub Interviewfragen nach Rolle.

SQL

• Dedupliziere eine Tabelle und behalte nur die neueste Zeile pro Schlüssel.
• Schreibe eine Query, die die Sitzungsanzahl jedes Nutzers mit einer Inaktivitätslücke von 30 Minuten zurückgibt.
• Berechne eine laufende Summe und eine Monat-über-Monat-Veränderung in einer Query.
• Finde Zeilen, die im Snapshot von gestern vorhanden sind, aber im heutigen fehlen.
• Was macht QUALIFY, und was würdest du ohne es schreiben?
• Diese Query scannt eine Milliarde Zeilen und braucht zwanzig Minuten. Wie diagnostizierst du das?
• Erkläre den Unterschied zwischen Partitionierung und Clustering, und wann welches hilft.

Datenmodellierung

• Entwirf die Tabellen für die Bestellhistorie eines Online-Marktplatzes. Was ist die Granularität deiner Faktentabelle?
• Erkläre ein Sternschema, und wann du bewusst weiter denormalisieren würdest.
• Was ist eine langsam wechselnde Dimension, und wie implementierst du Typ zwei?
• Ein Stakeholder will, dass historische Reports die aktuelle Region eines Kunden widerspiegeln. Was bricht dabei?
• Wie würdest du einen Event-Stream modellieren, der ungeordnet ankommt?
• Wann würdest du eine breite Tabelle einem normalisierten Modell vorziehen?

Die Modellierungsrunde belohnt, sich auf eine Granularität festzulegen und sie zu verteidigen. Kandidaten, die drei mögliche Designs beschreiben, ohne sich zu entscheiden, schneiden schlechter ab als Kandidaten, die ein vernünftiges Design wählen und dessen Schwäche benennen.

Pipeline- und ETL-Design

• Entwirf eine Pipeline, die tägliche Transaktionen für Reporting in ein Warehouse lädt.
• Die vorgelagerte Quelle sendet die Daten von gestern erneut. Was passiert mit deinem Job?
• Wie machst du eine Pipeline idempotent, und warum ist das für Reruns wichtig?
• Wie würdest du zwei Jahre Historie nachladen, ohne die tägliche Ladung zu stören?
• Verspätete Daten tauchen drei Tage nach Schließen der Partition auf. Was tust du?
• Wie würdest du erkennen, dass eine Pipeline erfolgreich war, aber falsche Daten erzeugt hat?
• Was überwachst du, und was weckt jemanden um drei Uhr morgens?

Verteilte Verarbeitung und Streaming

• Was verursacht einen Shuffle, und warum ist er teuer?
• Dein Job ist langsam, und eine Aufgabe dauert deutlich länger als der Rest. Was passiert da?
• Erkläre Data Skew und zwei Wege, damit umzugehen.
• Wann würdest du Streaming einem geplanten Batch-Job vorziehen?
• Was garantiert Exactly-once-Verarbeitung tatsächlich, und wo gilt das nicht?
• Wie behandeln Watermarks ungeordnete Events in einer Fenster-Aggregation?

Beachte, wie wenige davon dich bitten, ein Tool zu nennen. Ein Tool zu nennen ist der Anfang der Antwort, nicht die Antwort. Die Nachfrage ist immer warum, und was bricht.

Diese Listen zu lesen schafft Wiedererkennung. Die Design-Runden prüfen etwas anderes: ein System im Kopf zu behalten, während dich jemand mit einem Fehlerfall unterbricht. Das kommt nur davon, Designs laut auszusprechen.

• Zeichne und erzähle eine Pipeline in fünfzehn Minuten. Quelle, Landing, Transform, Serve, plus wie jede Stufe versagt.
• Greife dein eigenes Design an. Frage nach jedem Übungslauf, was bei einem Rerun, bei verspäteten Daten und bei einer Schemaänderung passiert.
• Halte eine Zahl für die Skala bereit. Zeilen pro Tag, Größe, Latenzbudget. Deine angenommene Skala zuerst zu nennen, wird bewertet.
• Schreibe SQL von Hand. Live-Runden nutzen oft einen einfachen Editor ohne Autovervollständigung und ohne Ausführung.
• Übe eine Vorfallgeschichte richtig. Was kaputtging, wie du es gefunden hast, was du geändert hast, damit es nicht wieder vorkommen konnte.

Eine Data-Engineerin mit sechs Jahren auf Batch-Pipelines bereitete sich vor, indem sie Framework-Interna wiederholte, und stockte dann bei "die vorgelagerte Quelle hat die Datei von gestern erneut gesendet", weil sie das nur je von Hand behandelt, nie erklärt hatte. Das Wissen war da; die gesprochene Antwort nicht. Die Design-Runde mit Nachfragen zu üben, ist genau, wofür der Modus Übungsinterview gebaut ist.