Middle Data Scientist — Data-Scientist-Interviewfragen

Beschreibe, wie du Features für ein Churn-Modell auswählen und Leakage vermeiden würdest.

Beginne mit dem, was zum Vorhersagezeitpunkt tatsächlich bekannt ist — ein Feature, das aus Daten berechnet wird, die erst nach dem Ergebnis existieren (etwa „Tage seit Öffnen der Kündigungs-E-Mail", falls diese E-Mail erst verschickt wird, nachdem sich jemand bereits zum Abwandern entschieden hat), schleust das Label direkt in den Input ein und liefert ein Modell, das offline großartig aussieht und in Produktion versagt. Nach dem Ausschluss von Leakage grenzt du die Liste mit Domänenwissen, der Korrelation zum Ziel und etwas wie Permutation Importance ein, und prüfst dann Multikollinearität unter den verbliebenen Kandidaten, statt einem einzelnen Importance-Wert isoliert zu vertrauen.

Wie funktioniert k-fold Cross-Validation, und warum reicht ein einzelner Train/Test-Split nicht?

Du teilst die Daten in k Folds, trainierst auf k-1 davon und validierst auf dem verbleibenden Fold, rotierst dann durch alle k Kombinationen und mittelst die Ergebnisse. Ein einzelner Split liefert eine verrauschte Schätzung, die stark davon abhängt, welche Zeilen zufällig im Test-Set gelandet sind — ein glücklicher oder unglücklicher Split kann ein mittelmäßiges Modell großartig oder ein gutes Modell schlecht aussehen lassen. Cross-Validation tauscht mehr Rechenleistung gegen eine deutlich stabilere Schätzung der Generalisierungsfähigkeit ein, und genau damit vergleichst du Modelle ehrlich, bevor du eines auswählst.

Wie würdest du einen A/B-Test für eine Änderung designen, bei der du einen kleinen Effekt auf einer Low-Traffic-Seite vermutest?

Ein kleiner erwarteter Effekt bei niedrigem Traffic ist die schlechteste Kombination für statistische Power, weshalb der erste Schritt ist, rechnerisch zu prüfen, ob der Test in einem vernünftigen Zeitrahmen überhaupt machbar ist, statt ihn zu designen und zu hoffen. Falls nicht, sind die ehrlichen Optionen, die berechtigte Population zu erweitern, die Laufzeit zu verlängern, auf eine sensitivere Metrik umzusteigen (eine kontinuierliche Proxy-Metrik statt einer binären Conversion) oder einen größeren minimal nachweisbaren Effekt zu akzeptieren und explizit zu sagen, dass kleinere echte Effekte unentdeckt bleiben.

Wann nutzt du eine Window-Function statt einer Subquery, um eine laufende Summe in SQL zu berechnen?

Eine Window-Function wie SUM(amount) OVER (PARTITION BY customer_id ORDER BY order_date) berechnet die laufende Summe in einem einzigen Durchgang, ohne Zeilen zu kollabieren, und die meisten Query-Planer optimieren sie deutlich besser als die äquivalente korrelierte Subquery, die für jede Ausgabezeile die vorherigen Zeilen erneut durchsucht. Der Subquery-Ansatz taucht immer noch in älteren Codebasen und als „naive" Antwort in Interviews auf — zu erkennen, wann man ihn ersetzt, ist selbst ein Zeichen von SQL-Reife.

Du zeigst einem Product Manager ein Modell mit 92 % Accuracy, und er will es ausrollen. Was prüfst du, bevor du zustimmst?

Erstens die Klassenbalance — wenn 92 % der Daten zur Mehrheitsklasse gehören, erreicht ein Modell, das immer die Mehrheitsklasse vorhersagt, ebenfalls 92 % Accuracy und ist dabei nutzlos, weshalb Precision, Recall und eine Confusion Matrix pro Klasse wichtiger sind als Accuracy allein. Zweitens, ob die Metrik zu den tatsächlichen Business-Kosten passt: Bei Betrugserkennung ist ein False Negative teuer und ein False Positive nur ein kleines Ärgernis, also würdest du den Schwellenwert Richtung Recall verschieben, auch wenn das etwas rohe Accuracy kostet, und das explizit sagen, bevor irgendjemand es ausrollt.