Senior Data Scientist — Data-Scientist-Interviewfragen

Wie designst du eine Experimentierplattform, die mehrere Produktteams bedient, die gleichzeitig Tests fahren?

Das Kernproblem ist Interferenz: Teams, die überlappende Experimente an denselben Nutzern fahren, können sich gegenseitig die Ergebnisse verunreinigen, daher brauchst du ein geschichtetes Assignment-System — orthogonale Layer oder ein hash-basiertes Bucketing, das unabhängigen Experimenten erlaubt, auf demselben Traffic ohne Kollision zu laufen, plus Guardrails, die anschlagen, wenn zwei Experimente eine Metrik auf Weisen berühren, die interagieren könnten. Über das Assignment hinaus braucht die Plattform automatisierte Sample-Ratio-Mismatch-Erkennung, standardisierte, in den Launch-Flow eingebaute Power-Berechnungen und eine Ergebnis-Pipeline, die niemand still umgehen kann, indem er vor Testende in die Rohdaten schaut — die Aufgabe der Plattform ist es, den statistisch korrekten Weg auch zum einfachsten zu machen.

Ein Stakeholder bittet dich zu beweisen, dass eine Marketingkampagne einen Umsatzanstieg verursacht hat, und ein randomisiertes Experiment wurde nie durchgeführt. Wie gehst du vor?

Du greifst zum nächstliegenden quasi-experimentellen Design, das die Daten hergeben: Difference-in-Differences, wenn es eine vergleichbare unbehandelte Gruppe und eine saubere Vorperiode gibt; Synthetic Control, wenn es keine einzelne unbehandelte Vergleichsgruppe gibt, aber eine gewichtete Kombination anderer sie annähern kann; oder Regression Discontinuity, wenn die Kampagne Nutzer oberhalb eines Schwellenwerts anvisiert hat. Jedes davon beruht auf einer Annahme — parallele Trends, keine Antizipationseffekte, kein gleichzeitiger Confounder —, die du nicht beweisen, sondern nur mit Vorperioden-Diagnostik plausibilisieren kannst, und das Ergebnis muss diese Annahme explizit enthalten, statt eine Punktschätzung als feststehende Tatsache zu präsentieren.

Wie übersetzt du eine vage Business-Frage wie „warum ist die Retention letztes Quartal gesunken" in eine messbare Analyse?

Beginne damit, Präzision bei „Retention" und „gesunken" zu erzwingen — welche Kohorte, welches Zeitfenster, im Vergleich zu welcher Baseline —, denn die Hälfte vager Anfragen löst sich auf, sobald die Metrik tatsächlich definiert ist, und oft stellt sich heraus, dass der Stakeholder auf ein Dashboard-Artefakt reagiert hat, statt auf eine echte Veränderung. Von dort aus zerlegst du die Metrik (konzentriert sich der Rückgang auf ein Segment, einen Kanal, ein Release?), bevor du zu kausalen Werkzeugen greifst, denn Segmentierung verengt eine offene Frage meist schneller zu einer konkreten, testbaren Hypothese als jedes Modell es könnte.

Wie baust du Data-Science-Standards und Review-Praktiken in einem wachsenden Team auf, ohne selbst zum Flaschenhals zu werden?

Kodifiziere die wiederkehrenden Fehlermuster, die du gesehen hast — Leakage, unterpowerte Tests, falsch gelesene p-Werte, Metriken, die nicht zu den Business-Kosten passen — in einer schlanken Review-Checkliste, statt zu verlangen, dass jede Analyse persönlich durch dich läuft, denn persönliches Review skaliert nicht über eine Handvoll Leute hinaus und erzeugt eine Warteschlange, die unter Deadline-Druck jeden lehrt, sie zu umgehen. Kombiniere das mit gemeinsamem Tooling (einer Standard-Library für Power-Berechnungen, einer Vorlage für Experiment-Reports), damit die richtige Praxis auch der Weg des geringsten Widerstands ist, und reserviere deine persönliche Review-Zeit für Entscheidungen mit echtem finanziellem oder strategischem Gewicht statt für Routineanalysen.

Ein A/B-Test sagt, eine Änderung gewinnt; eine längere Beobachtungsanalyse sagt, sie schadet der Retention. Wie bringst du das zusammen?

Prüfe erst die Mechanik, bevor du einer der beiden Zahlen traust: Neuheits- und Primäreffekte verblassen im kurzen Testfenster, zeigen sich aber in längeren Beobachtungsdaten, und eine Metrikverschiebung, die sich in einem Segment konzentriert, für das der Test nicht ausreichend gepowert war, wird im Top-Line-Ergebnis einfach herausgemittelt. Achte auf Interferenz — hat die Änderung die Kontrollgruppe indirekt beeinflusst, über eine gemeinsame Ressource, einen Marktplatz oder ein Empfehlungsmodell, das auf Daten beider Arme neu trainiert wurde —, denn das bricht die Unabhängigkeitsannahme, auf der A/B-Tests beruhen. Wenn die Mechanik stimmt und der Konflikt real ist, vertrau dem randomisierten Ergebnis für den kausalen Effekt und dem Beobachtungsergebnis dafür, wen es betrifft und warum, und sag das explizit, statt die Zahl zu wählen, die zur ohnehin gewünschten Entscheidung passt.