Fragen zum PySpark-Vorstellungsgespräch

Man kann funktionierendes PySpark schreiben und trotzdem hier stolpern, denn diese Fragen zielen darauf ab, was die Engine tut, nicht darauf, was der Code sagt. Interviewer beginnen oft genau damit, weil sich so unterscheiden lässt, wer einen Job schon getunt hat und wer ihn nur einmal ausgeführt hat. Dieser Abschnitt behandelt die Fragen zum Ausführungsmodell und was eine vollständige Antwort enthalten sollte.

• Was ist der Unterschied zwischen Transformation und Action? Transformationen bauen einen Plan auf und geben lazy ein neues DataFrame zurück; Actions wie count, collect oder ein Schreibvorgang lösen die Ausführung aus. Nichts wird berechnet, bevor eine Action ein Ergebnis verlangt.
• Warum ist Lazy Evaluation nützlich? Der Optimizer sieht die gesamte Kette, bevor sie ausgeführt wird, und kann deshalb Filter umsortieren, unnötige Spalten entfernen und Schritte zusammenfassen.
• Schmale oder breite Transformation? Schmale Operationen wie filter und select sorgen dafür, dass jede Ausgabepartition von genau einer Eingabepartition abhängt. Breite Operationen wie groupBy, join und distinct verteilen Daten über Partitionen neu, das ist ein Shuffle.
• Was ist ein Shuffle und warum ist er wichtig? Daten wandern übers Netzwerk und landen auf der Festplatte, wodurch eine Stage-Grenze entsteht. Das ist meist das Teuerste, was ein Job tut.
• Erkläre Job, Stage und Task. Eine Action startet einen Job, Shuffle-Grenzen teilen ihn in Stages, und jede Stage führt pro Partition einen Task aus.
• RDD, DataFrame oder Dataset? Bevorzuge DataFrame, weil der Catalyst-Optimizer und die spaltenorientierte Ausführung greifen. RDDs bleiben für Low-Level-Kontrolle relevant. Typisierte Dataset sind ein JVM-Konzept, daher lautet die ehrliche Antwort in Python, dass sie nicht zutreffen.

Nenne die Wörter Shuffle und Stage, wenn sie in die Antwort gehören. Interviewer nutzen sie als Abkürzung dafür, ob du schon einmal ein Spark UI gelesen hast.

Die meisten Senior-PySpark-Interviews sind im Kern Performance-Interviews. Die Fragen kommen als Szenarien, nicht als Definitionen.

• Ein Join ist langsam. Was prüfst du? Zuerst die Größe beider Seiten. Passt eine Seite in den Executor-Speicher, wird sie per Broadcast verteilt, und der Shuffle entfällt komplett. Andernfalls prüft man Partitionierung und Skew, bevor man an der Clustergröße dreht.
• Was ist Data Skew und wie behebt man es? Wenige Keys enthalten den Großteil der Zeilen, sodass ein Task noch lange läuft, nachdem die anderen fertig sind. Abhilfe schaffen Salting des Hot Key, Broadcasting der kleineren Seite oder das Herausfiltern von Null-Werten, die alle auf denselben Hash fallen. Das Diagnosesignal ist die Streuung der Task-Laufzeiten im Spark UI.
• Wann verwendet man cache oder persist? Wenn ein DataFrame über mehrere Actions hinweg wiederverwendet wird und eine Neuberechnung teuer wäre. Etwas zu cachen, das nur einmal genutzt wird, verschwendet Speicher, und in langen Jobs zählt auch das rechtzeitige unpersist.
• repartition oder coalesce? repartition löst einen Shuffle aus und kann Partitionen gleichmäßig erhöhen oder verringern; coalesce führt sie ohne vollständigen Shuffle zusammen, was die günstigere Methode ist, um die Zahl der Ausgabedateien zu reduzieren.
• Warum sollte man ein Python-UDF vermeiden? Zeilen werden zwischen der JVM und einem Python-Prozess serialisiert, und der Optimizer kann nicht ins Innere der Funktion blicken. Bevorzuge eingebaute Funktionen und greife nur dann zu einem vektorisierten UDF, wenn keine eingebaute Funktion existiert.
• Warum ist collect gefährlich? Es zieht das gesamte Ergebnis zum Driver und kann dessen Speicher erschöpfen.
• Ein Job schlägt mit Speichermangel fehl. In welcher Reihenfolge untersuchst du das? Zuerst, ob es Driver oder Executor betrifft, dann Skew, dann die Partitionsgröße und erst dann die Speicherkonfiguration. Sofort mehr Speicher zu geben ist die Antwort, die Unerfahrenheit verrät.

Ein Data Engineer, der sich für ein Plattform-Team bewarb, wurde gefragt, warum ein nächtlicher Job, der ein Jahr lang lief, plötzlich vier Stunden brauchte. Die überzeugende Antwort war keine Konfigurationsänderung, sondern dass ein vorgelagerter Partner begonnen hatte, Nullwerte im Join-Key zu senden, sodass jede Null-Zeile in dieselbe Partition gehasht wurde. Interviewer belohnen genau diese Reihenfolge: erst die Daten ansehen, dann den Cluster.

Verwandte Fragensammlungen nach Rolle liegen unter Interviewfragen nach Rolle.

Die restlichen Fragen prüfen, ob du eine Pipeline tatsächlich ausgeliefert hast und nicht nur ein Tutorial abgeschlossen hast.

• Wie liest man Daten effizient ein? Spaltenformate wie Parquet, Partition Pruning auf der Filterspalte und Predicate Pushdown. Erkläre, warum weniger Bytes zu lesen besser ist, als das Danach zu optimieren.
• Warum ein Schema definieren, statt es ableiten zu lassen? Das Ableiten kostet einen zusätzlichen Durchlauf über die Daten und kann Typen zwischen Läufen unterschiedlich erraten.
• Wie geht man mit Nullwerten und Duplikaten um? Die passenden Funktionen, dazu der Hinweis, dass Join-Keys mit vielen Nullwerten Skew erzeugen.
• Wofür werden Window Functions verwendet? Für Ranking, laufende Summen und das Deduplizieren auf den neuesten Datensatz pro Key, eine sehr häufige Aufgabe in Pipelines.
• Wie schreibt man Output, ohne Tausende kleiner Dateien zu erzeugen? Vor dem Schreiben coalesce oder repartition anwenden und den Output nach einer Spalte mit sinnvoller Kardinalität partitionieren.
• Wie testet man PySpark-Code? Mit kleinen lokalen Sessions und Fixture-DataFrames sowie Business-Logik, die in Funktionen ausgelagert ist, die DataFrames entgegennehmen und zurückgeben.
• Wie reicht man einen Job ein und konfiguriert ihn? Executor-Anzahl, Cores und Speicher, dazu die Überlegung, dass sowohl zu viele kleine Executor als auch zu wenige große Executor Kapazität verschwenden.

PySpark-Antworten scheitern laut gesprochen auf eine erkennbare Weise. Die Kandidatin weiß, dass ein Shuffle teuer ist, kann aber nicht sagen, welche Operationen ihn auslösen, und die Antwort wird zu einer Liste von Adjektiven. Eine Fragensammlung zu lesen erzeugt Wiedererkennung, und Wiedererkennung ist nicht dasselbe wie eine Erklärung, die man liefert, während jemand wartet.

Nimm eine Pipeline, die du selbst gebaut hast, und erzähle sie von Anfang bis Ende: das Einlesen, jede Transformation, wo die Stage-Grenzen liegen und was du zuerst prüfen würdest, wenn sie langsamer würde. Sprich es laut, bis du nicht mehr neu ansetzen musst. Diese Fragen an einem KI-Interviewer zu üben, der nachhakt, kommt einer echten Runde näher als das erneute Lesen von Notizen, und genau dafür ist der Modus Mock Interview gedacht.

Aaron Cao, Gründer von SubcueAI, hat die Übungsstruktur um genau diese Lücke beim lauten Sprechen herum aufgebaut, statt einfach mehr Fragen zu liefern. In einem echten Interview können die Desktop-App und das Side Panel der Browser-Erweiterung Struktur sichtbar machen, während der Interviewer spricht, was vor allem bei bereits geübtem Material hilft. Die Einrichtung dauert wenige Minuten und ist auf der Seite Tutorial beschrieben.