Was Data-Engineer-Interviews tatsächlich prüfen

Wer tatsächlich im Raum sitzt

Für eine Data-Engineer-Rolle wirst du nach dem ersten Gespräch selten von einem generalistischen Recruiter beurteilt. Die technischen Runden werden üblicherweise von einem Senior Data Engineer oder dem Data-Engineering-Lead durchgeführt, manchmal mit einem Analytics Engineer oder Data Scientist dabei, falls die Pipelines, die du bauen würdest, deren Modelle speisen. Das ist relevant, weil die Fragen von Leuten kommen, die um 3 Uhr nachts wegen einer kaputten DAG alarmiert wurden, nicht von einer HR-Checkliste. Sie hören darauf, ob du tatsächlich eine Pipeline in Produktion betrieben hast, nicht ob du ETL definieren kannst.

Kleinere Unternehmen fassen oft alles in zwei Runden zusammen: eine Live-Technical-Session und ein Gespräch mit demjenigen, der die Datenplattform verantwortet. Größere teilen es auf in ein SQL/Python-Screening, eine System- oder Pipeline-Design-Runde und eine Werte- oder Stakeholder-Runde mit jemandem aus dem Team, das du mit Daten versorgst — oft ein Analyst oder Product Manager, und es ist die Runde, auf die sich Kandidaten am wenigsten vorbereiten, weil sie wie Smalltalk aussieht und es nicht ist.

Das SQL- und Python-Screening

Das ist selten Trivia. Du bekommst ein Schema — oft sowas wie Orders, Customers, Events — und sollst eine Query mit Fensterfunktionen schreiben: laufende Summen, Rank-within-Partition, ein Self-Join um Lücken oder Überlappungen in Datumsbereichen zu finden. Der Punkt ist nicht die Syntax, sondern ob du zum richtigen Werkzeug greifst, ohne hingeführt zu werden. Ein Kandidat, der "finde den ersten und zweiten Kauf jedes Kunden" mit einer korrelierten Subquery löst, wenn ein LAG() es sauber erledigen würde, sagt dem Interviewer etwas darüber, wie er unter Zeitdruck Produktions-SQL schreiben wird.

Auf der Python-Seite erwarte Datenmanipulation mit pandas oder reinem Python — Deduplizierung eines chaotischen Datasets, Parsen von fehlerhaftem JSON, Umgang mit Nulls, die in verschiedenen Spalten unterschiedliche Dinge bedeuten. Zunehmend wirst du gebeten, über einen Spark-Job zu argumentieren: warum eine Transformation langsam ist, wo ein Shuffle passiert, ob Repartitionierung vor einem Join helfen würde. Wenn du Spark nur über eine Managed Platform wie Databricks ausgeführt und nie erklären mussten, warum ein Job auf Disk gespillt ist, zeigt sich das hier.

Wie eine oberflächliche Antwort hier klingt: aufsagen, dass Indizes "Queries beschleunigen", ohne sagen zu können, was mit der Write-Performance passiert, oder die Syntax einer Fensterfunktion korrekt erklären, aber nicht sagen können, wann du ROW_NUMBER() statt RANK() verwenden würdest und was kaputtgeht, wenn du es bei einer Tabelle mit doppelten Keys falsch machst.

Die Pipeline- oder System-Design-Runde

Das ist die Runde, die Leute trennt, die ein Tool konfiguriert haben, von Leuten, die ein System verantwortet haben. Du wirst typischerweise gebeten, etwas zu designen wie: Events aus einer Applikation in ein Warehouse ingestieren, eine Dimensionstabelle mit einer sich ändernden Upstream-Quelle synchron halten, oder eine Pipeline bauen, die drei Jahre History backfillen muss, ohne die Compute-Rechnung zu verdoppeln.

Der Interviewer hört auf eine kleine Anzahl von Dingen, und sie kommen in fast jeder Version dieser Frage vor:

• Idempotenz. Kann deine Pipeline auf denselben Daten erneut ausgeführt werden, ohne Duplikate oder doppelt gezählte Summen zu erzeugen? Wenn deine Antwort nicht erwähnt, wie du mit einem Job umgehst, der zur Hälfte fehlschlägt und erneut versucht wird, ist das eine Lücke, die sie untersuchen werden.
• Schema-Evolution. Was passiert, wenn ein Quellsystem eine Spalte hinzufügt oder einen Typ von int zu string ändert? Fehlst du laut, oder korrumpierst du stillschweigend Downstream-Tabellen? Die Erwähnung einer Schema Registry oder wie dbt- oder Great-Expectations-Tests das abfangen würden, signalisiert, dass du davon schon mal gebrannt wurdest.
• Batch versus Streaming, und warum. Nicht "Streaming ist besser" — das ist die oberflächliche Antwort. Die echte Antwort erklärt den Trade-off: Kafka oder Kinesis bringt dir niedrige Latenz und Komplexität, die du jetzt verantwortest, versus ein geplanter Batch-Job in Airflow oder Dagster, der einfacher zu verstehen und zu debuggen ist, aber veraltete Daten bedeutet für die Dauer des Schedules.
• Partitionierung und Kosten. Wenn du eine Tabelle designst, ohne zu sagen, wie du sie partitionieren würdest — üblicherweise nach Datum, in einem Warehouse wie BigQuery oder Snowflake — und ohne anzuerkennen, dass ein Full-Table-Scan auf einer Multi-Terabyte-Faktentabelle echtes Geld kostet, bemerkt der Interviewer die Auslassung, auch wenn er es nicht sagt.
• Slowly Changing Dimensions. Wenn das Szenario eine Dimension beinhaltet, die sich über Zeit ändert (die Adresse eines Kunden, die Kategorie eines Produkts), überschreibst du sie, oder versionierst du sie mit etwas wie SCD Type 2? Das falsch zu machen, lässt dich nicht durchfallen, aber den Begriff nicht zu kennen, wenn der Interviewer sagt "wie würdest du damit umgehen, dass ein Kunde die Region wechselt", ist ein Indiz.

Eine oberflächliche Antwort auf eine Design-Frage klingt fließend über Tools und schweigt über Failure. "Ich würde Airflow zur Orchestrierung nutzen und es in Snowflake landen" ist ein Satz ohne Engineering drin — er nennt den Vendor und überspringt die Entscheidung. Eine starke Antwort sagt warum: warum dieser Orchestrator Backfills so handhabt, wie du es brauchst, warum die Clustering Keys dieses Warehouses für das Query-Pattern wichtig sind, das die Analysten tatsächlich ausführen.

Die Fragen, die wie Smalltalk klingen

"Erzähl mir von einem Mal, als eine Pipeline, die du gebaut hast, in Produktion kaputtging" ist kein Eisbrecher. Es ist meist die diagnostischste Frage im ganzen Prozess, weil eine oberflächliche Antwort dir das Symptom gibt ("das Dashboard zeigte falsche Zahlen") und eine echte Antwort dir den Mechanismus gibt: welches Monitoring oder dessen Fehlen bedeutete, dass du es von einem Stakeholder statt von einem Alert erfahren hast, was sich als Root Cause herausstellte — eine verspätete Datei, ein Timezone-Bug, eine Upstream-Schema-Änderung, von der dir niemand erzählt hat — und was du danach geändert hast, damit es nicht auf dieselbe Weise nochmal passieren kann.

Ähnlich wird "wie entscheidest du, was in einer Pipeline zu testen ist" gefragt, um zu sehen, ob du Data-Quality-Checks aus Gewohnheit schreibst — Row Counts, Null-Schwellenwerte, referentielle Integrität zwischen einer Fakten- und ihren Dimensionen — oder ob Testen etwas ist, das du nach einem Incident machst, weil jemand es dir gesagt hat. Die Erwähnung einer spezifischen Praxis, wie zu behaupten, dass ein Foreign Key in einer Faktentabelle sich immer zu einer Zeile in der Dimension auflöst, landet besser als zu sagen "ich schreibe Tests für meine Pipelines", was jeden Job mit dem Wort Pipeline drin beschreiben könnte.

"Wie würdest du einem Stakeholder erklären, warum sein Report einen Tag zu spät ist" testet wieder etwas anderes: ob du eine technische Ursache — ein Source-API-Rate-Limit, eine Downstream-Dependency, die nicht fertig wurde — in Sprache übersetzen kannst, auf die ein Nicht-Engineer reagieren kann, ohne es entweder zu nichts herunterzudummen oder sie in DAG-Terminologie zu ertränken, die sie nicht haben.

Was jemanden verrät, der den Job nicht gemacht hat

Interviewer in diesem Feld bemerken ein spezifisches Muster: Geläufigkeit mit Tool-Namen und keine Meinungen über deren Grenzen. Jemand, der tatsächlich dbt in Produktion betrieben hat, kann dir sagen, wo dessen Testing-Framework zu kurz greift und was er darüber legt. Jemand, der tatsächlich Airflow betrieben hat, kann dir sagen, was kaputtgeht, wenn eine DAG zu viele dynamische Tasks hat, oder warum er eine schwere Transformation aus einem PythonOperator heraus und ins Warehouse selbst verschoben hat. Wenn jede Antwort ein Tool nennt und dort aufhört, ist das die oberflächliche Antwort, und Leute, die Data Engineers einstellen, haben Hunderte davon gehört.

Das andere Erkennungszeichen ist, über Datenvolumen zu sprechen, ohne über Kosten oder Query-Pattern zu sprechen. "Wir hatten Milliarden von Zeilen" ist für sich allein kein Engineering-Fakt. Was bedeutete das dafür, wie die Tabelle partitioniert, geclustert oder kompaktiert wurde, und was wäre mit der Warehouse-Rechnung passiert, wenn du es falsch gemacht hättest? Ein Interviewer, der ein Snowflake- oder BigQuery-Kosten-Dashboard verantwortet hat, wird eine Nachfrage stellen und schnell herausfinden, ob die Milliarden Zeilen etwas waren, womit du umgegangen bist, oder etwas, das du erwähnt hast.

Was als Nächstes zu tun ist

Wähle vor deinem nächsten Interview zwei Pipelines aus, die du tatsächlich gebaut hast, und sei bereit, in spezifischen Begriffen zu beschreiben: wie du sie nach einem partiellen Failure sicher erneut ausführen würdest, was passieren würde, wenn sich das Source-Schema unter dir ändert, und einen Incident, bei dem es kaputtging und was du danach geändert hast. Übe, den Trade-off zu sagen, nicht nur das Tool — Batch versus Streaming, denormalisiert versus normalisiert, Orchestrator A versus Orchestrator B — weil das die Satzform ist, auf die der Interviewer hört.

Wenn das schwierigere Problem gerade ist, überhaupt zu diesem Interview zu kommen — Anzeigen, die nach spezifischer Warehouse- oder Orchestrierungserfahrung fragen, die du in anderer Form hast, und Bewerbungen, die still bleiben — liest jobmarket.pro die Anzeige vollständig, matched sie gegen deine tatsächliche Erfahrung und bereitet die Bewerbung davon ausgehend vor statt von einem generischen Template.