Rollen-Leitfaden16 min read

Vorbereitung auf Data Scientist-Interviews: Der vollständige 2026-Leitfaden

Ein praktischer Leitfaden für Data Scientist-Interviews 2026 — SQL-Screens, Statistik, ML-Fallstudien, A/B-Tests und Product-Data-Hybrid-Runden bei FAANG — mit wie ein KI-Copilot in jede Runde passt.

Devon Park

Head of Research, Acedly

Warum das DS-Interview 2026 so aussieht, wie es aussieht

Der Titel Data Scientist im Jahr 2026 ist nicht mehr derselbe Job wie vor fünf Jahren. Zwei strukturelle Verschiebungen haben die Rolle von beiden Seiten zusammengepresst. Von der Modellierungsseite her haben ML Engineers die Produktionsarbeiten übernommen — alles, was zu einem Serving Stack geht, ist jetzt ein MLE-Job, kein DS-Job. Von der Analytics-Seite her haben „Analytics Engineers” mit starken dbt- und Warehouse-Fähigkeiten die Dashboard- und Metrik-Definitions-Arbeiten übernommen. Was in der Mitte übrig bleibt, wo die meisten „DS”-Stellenausschreibungen jetzt angesiedelt sind, ist Product Data Science — die Rolle, die sich um Experimentation, Metrik-Design und die statistische Strenge hinter Produktentscheidungen kümmert.

Das ist wichtig für die Interviewvorbereitung, weil die Schleife der Rolle gefolgt ist. Vor fünf Jahren bestand eine DS-Schleife zu 60% aus Modellierung und zu 40% aus SQL. 2026 ist es näher an 60% SQL und Experimentation, 25% Produktverständnis und Metrik-Sinn und 15% Modellierung — und die Modellierungs-Phase ist, wenn sie auftaucht, zunehmend eine „Case Study” statt eines Coding-Problems. Wenn du die Gewichtung in deiner Vorbereitung falsch einschätzt, wirst du dich zu sehr auf Kaggle-ähnliche Wettkämpfe konzentrieren, während das tatsächliche Interview dich auffordert, zu diagnostizieren, warum eine Metrik gefallen ist.

Es gibt noch eine zweite Spur — die ML-applied DS Rollen bei Unternehmen, die noch zwischen Research Scientists, ML Engineers und Applied Data Scientists unterscheiden (Netflix, Stripe, Anthropic, DeepMind in den seltenen Fällen, in denen sie unter dem DS-Titel einstellen). Diese Schleifen kehren die Gewichtung auf etwa 50% Modellierungstiefe um, wobei die Case-Study-Phase drei Ebenen tief gehen soll — Feature-Design, Eval-Methodik, Online-Evaluation — statt nur die Oberfläche zu streifen. Wenn du diese Rollen anstrebst, bereite dich entsprechend vor; wenn du Meta oder Airbnb anstrebst, dann nicht.

Die 2026 DS-Interview-Schleife, Phase für Phase

Eine typische 2026 Data Scientist-Schleife läuft über vier bis sechs Phasen in drei bis fünf Wochen. Die genaue Zusammensetzung variiert je nach Unternehmen und Pfad, aber die Grundstruktur ist konsistent.

Recruiter Screen (30 Minuten). Größtenteils Logistik und Gehaltserwartungen, plus ein paar „Erzähl mir von dir selbst”-Sonden. Das Signal hier ist, ob du die Art von Problemen, an denen du gearbeitet hast, in klarem Englisch artikulieren kannst — nicht jargonlastig, nicht zu bescheiden. Zwei bis drei prägnante Projektbeschreibungen, jede an ein messbares Geschäftsergebnis gebunden, sind das, was dich zur nächsten Phase bringt.

SQL-/Coding-Screen (45–60 Minuten). Das ist der technische Filter. Live-Coding in StrataScratch, DataLemur, Coderpad oder HackerRank — je nach Unternehmen. Zwei bis drei mittelschwere SQL-Probleme plus gelegentlich ein Python-Datenmanipulations-Problem. Der Maßstab ist Korrektheit beim ersten Versuch, ordentliche Variablenbenennung und eine Erklärung von Edge Cases, die der Interviewer nicht gefragt hat. Zeitdruck ist real; die meisten Kandidaten scheitern, indem sie die Join überkomplizieren.

On-site oder virtueller On-site (4–5 Runden, typischerweise je 45 Minuten). Das ist, wo die Schleifen je nach Unternehmen auseinandergehen:

  • Meta führt einen SQL-Deep-Dive, eine Produkt-/Metrik-Sinn-Runde, eine A/B-Testing-Runde und eine verhaltensbezogene Runde durch („nenn mir ein Projekt, auf das du stolz bist”). Die Produktrunde ist am stärksten gewichtet.
  • Google ist breiter: SQL, Statistik, eine ML-Case-Study, eine Produktrunde und eine „Googleyness”-verhaltensbezogene Runde. Der ML-Case ist prominenter als bei Meta.
  • Amazon ist Leadership-Principles-getrieben; erwarte, dass jede Runde mit LP-Prüfungen durchdrungen ist, plus der technische Inhalt. SQL ist kurz; Statistik ist kurz; die DS-spezifische Runde ist normalerweise ein Metrik-Design-Problem, das in LP-Sprache formuliert ist.
  • Netflix ist der strategische-Denk-Ausreißer — weniger Runden, höheres Signal pro Runde erwartet, und starke Betonung auf Schreiben. Dir kann aufgetragen werden, ein einseitiges Memo zu schreiben, das deine Analyse erklärt.
  • Airbnb gewichtet Host-seitige Metriken stark („wie würdest du Host-Churn messen?”) und führt eine lange Produktrunde durch.
  • ML-research-orientierte Unternehmen (DeepMind, Anthropic, OpenAI in den Fällen, in denen sie unter dem DS-Titel einstellen) führen eine Paper-Diskussions-Runde und eine tiefe Modellierungs-Runde zusätzlich zur Standard-Rotation durch.

Hiring-Manager-Runde (45 Minuten). Normalerweise zuletzt geplant, manchmal zwischen technischen Runden. Weniger technisch, mehr über Passung und wie du deine ersten 90 Tage strukturieren würdest. Senior-Kandidaten sollten mit strategischen Fragen rechnen — „was ist die wichtigste Metrik, die dieses Team verfolgen sollte, die es derzeit nicht verfolgt?"

Die gesamte Zeitinvestition vom ersten Recruiter-Gespräch bis zum Angebot dauert selten weniger als drei Wochen und häufig fünf bis sechs. Strukturiere deinen Vorbereitungsplan um diese Dauer herum, nicht um einen einzelnen entscheidenden Tag.

SQL-Runden: Was 2026 wirklich geprüft wird

Die SQL-Runde ist der Punkt, an dem die meisten Kandidaten das Angebot verlieren, und der Unterschied zwischen „Ich kenne SQL” und „Ich kann eine 60-minütige SQL-Runde bestehen” ist größer, als Kandidaten denken. Drei Kategorien von Problemen dominieren.

Window functions — fast universell getestet. Die spezifischen Funktionen, die immer wieder auftauchen: ROW_NUMBER(), RANK(), DENSE_RANK() für Top-N-pro-Gruppe; LAG() und LEAD() für Veränderung über Perioden; SUM() OVER (PARTITION BY ... ORDER BY ...) für laufende Summen. Wenn Sie eine Top-N-pro-Gruppe-Abfrage nicht ohne Nachdenken schreiben können, werden Sie scheitern. Die klassische Falle ist, zu Self-Joins oder korrelierten Subqueries zu greifen, wenn eine Window function es in fünf Zeilen tun würde.

CTEs und mehrstufige Transformationen — der moderne Stil. Alles Komplexere als ein einfacher Join wird erwartet, als eine Kette von CTEs ausgedrückt zu sein, klar benannt, mit jedem Schritt, der eine Sache tut. Der Interviewer schaut sich die Lesbarkeit genauso an wie die Korrektheit; eine 40-Zeilen-CTE-Kette mit beschreibenden Namen schlägt jedes Mal eine 12-Zeilen-Nested-Subquery-Lösung.

Die vier kanonischen Muster:

  1. Top-N pro Gruppe (finden Sie die Top-3-Kunden nach Ausgaben in jeder Region) — Window function mit RANK() oder ROW_NUMBER(), Filterung auf Rang.
  2. Retention und Kohortenanalyse (welcher Anteil der Januar-Anmeldungen kehrte im Februar zurück) — Self-Join auf user_id mit Datumsarithmetik, oder Window functions für Aktivitäts-Flaggen.
  3. Trichter-Konvertierung (Anmeldung → Aktivierung → erster Kauf) — gestaffelte CTEs mit LEFT JOIN oder EXISTS-Überprüfungen, Berechnung der Konvertierungsraten zwischen Stufen.
  4. Sessionisierung (Zeilen in Sitzungen gruppieren, wobei aufeinanderfolgende Ereignisse innerhalb von 30 Minuten liegen) — LAG() zur Berechnung von Zeitdeltas, dann eine laufende Summe von „neue Sitzung”-Flags.

Der mit Abstand häufigste Fehler ist falsche Granularität. Wenn Ihre Ausgabe eine Zeile pro Benutzer-Tag haben sollte und Sie versehentlich eine Zeile pro Ereignis erzeugen, ist jede nachgelagerte Zählung um Größenordnungen falsch. Geben Sie immer laut an, welche Granularität die Ausgabe haben sollte, bevor Sie die Abfrage schreiben, und überprüfen Sie mit einem kleinen SELECT COUNT(*) danach.

Statistik- und Wahrscheinlichkeitsrunden

Die Statistik- und Wahrscheinlichkeits-Runde ist die variabelste zwischen den Unternehmen. Einige sind theoretisch (Bayes-Ableitungen, Verteilungseigenschaften); einige sind angewandt („welchen Test würden Sie für dieses Szenario durchführen?”). Drei Unterkategorien decken ab, was in den meisten Fällen gefragt wird.

Bayesian / conditional probability. Das Monty Hall-Problem wird immer noch überraschend oft gestellt, und seine Varianten — „zwei Münzen, eine fair, eine verzerrt, Sie werfen und sehen Köpfe, was ist P(verzerrt)?” — erscheinen in den meisten Unternehmen. Das mechanische Verfahren ist, Bayes' theorem aufzuschreiben, die Prior, die Likelihood und die Evidence zu identifizieren und zu berechnen. Dies auf einem Whiteboard zu tun und dabei zu sprechen ist die eigentliche getestete Fähigkeit; die Antwort zu bekommen ist notwendig, aber nicht ausreichend.

Distributions and when to assume them. Normal approximations sind nützlich, aber Kandidaten wenden sie zu oft an. Der Interviewer möchte hören: „Ich würde hier eine Normal-Verteilung annehmen, weil n groß genug ist, dass CLT zutrifft, aber ich würde es überprüfen, indem ich die Residuen überprüfe; wenn die zugrundeliegenden Daten schwanzreich sind, würde ich zu einer t-distribution oder einer non-parametric-Alternative greifen.” Die Annahme und die Verifikation zu benennen ist das Senior-Signal.

Hypothesis testing. Das Standard-„welchen Test würden Sie durchführen?”-Framework: Identifizieren Sie den Metriktyp (Anteil, Mittelwert, Zählung, Verhältnis), überprüfen Sie die Annahmen (Unabhängigkeit, Normalität, Stichprobengröße), wählen Sie den Test (z-test für Anteile, t-test für Mittelwerte, chi-square für kategorisch, Mann-Whitney für nicht-normal), geben Sie die Null- und Alternativhypothese an, definieren Sie das Signifikanzniveau, und besprechen Sie die Multiple-Comparisons-Korrektur falls anwendbar. Sie sollten in der Lage sein, dies in 90 Sekunden für jedes gegebene Szenario durchzugehen.

Confidence intervals. Die Falle ist die Interpretation. „Es gibt eine 95%-ige Chance, dass der wahre Mittelwert in diesem Intervall liegt” ist falsch — frequentist CIs machen keine Wahrscheinlichkeitsaussagen über Parameter. Die richtige Aussage ist: „wenn ich dieses Experiment viele Male wiederholte, würden 95% der konstruierten Intervalle den wahren Mittelwert enthalten.” Wenn Sie dies falsch verstehen, werden Statistik-versierte Interviewer dies vermerken.

A/B-Tests und Experimentation: das Handwerk

Dies ist die Runde, die bei Product-DS-Unternehmen am höchsten gewichtet wird (Meta, Airbnb, Uber). Das erwartete Kriterium umfasst mindestens:

  1. Hypothese — Was glaubst du wird geschehen und warum? Verbunden mit einem Verhaltensmechanismus, nicht nur „wir denken, das wird gut sein."
  2. Metrik — Primäre Erfolgskennziffer, sekundäre Metriken, Schutzmetriken. Senior Candidates geben immer Schutzmetriken an, bevor sie danach gefragt werden.
  3. Leistungsberechnung — Wie viele Stichproben sind nötig, um eine X%-Steigerung bei 80 % Leistung und 5 % Signifikanzniveau zu erkennen? Du solltest das ohne Taschenrechner schätzen können, indem du die Faustregel n ≈ 16 × σ² / δ² pro Arm verwendest.
  4. Randomisierungseinheit — Benutzer, Sitzung, Gerät? Der Interviewer wird das überprüfen; wähle bewusst.
  5. Schutzmetriken und SRM-Überprüfung — Stichprobenverhältnismismatch (die tatsächliche Aufteilung weicht von der beabsichtigten 50/50 ab) ist das häufigste Signal eines fehlgeschlagenen Experiments, und Senior Candidates überprüfen das vor der Berichtslegung.
  6. Analyse — Punktschätzung, Konfidenzintervall, p-Wert (mit Mehrfachvergleichskorrektur falls relevant) und die Unterscheidung zwischen praktischer und statistischer Signifikanz.
  7. Entscheidung — Freigeben, nicht freigeben oder iterieren, mit explizitem Trade-off.

Die Fallstricke, die der Interviewer überprüfen wird:

  • Novelty-Effekte. Die Behandlung sieht in Woche eins großartig aus und lässt sich in Woche drei zurück, weil Benutzer die neue Funktion nur erkundeten.
  • Netzwerkeffekte. Das klassische Facebook News-Feed-Problem — wenn die Behandlung ändert, wer was sieht, kannst du nicht nach Benutzer randomisieren, weil die Kontrollgruppe durch das Verhalten von behandelten Benutzern kontaminiert wird. Der Interviewer wird dies manchmal als „was wenn wir eine Ranking-Änderung im Marktplatz testen würden?” formulieren, und er möchte die Netzwerk-Interferenz-Rahmung hören.
  • Verdünnung. Wenn nur 10 % der Benutzer die Funktion sehen, ist die Steigerung der Gesamtpopulation die Steigerung der 10 % mal 10 %. Wenn man das vergisst, wird eine „5%-Steigerung” zu einer Marketingaussage, die einer zweiten Überprüfung nicht standhält.
  • Primäre vs. Schutzmetriken-Trade-offs. „Was wenn der Umsatz steigt, aber die DAU sinkt?” Die Senior-Antwort bezieht sich auf die Elastizität der Schutzmetrik und eine Horizont-Frage — kurzfristige Umsatzsteigerung, die langfristiges Engagement kostet, ist selten sinnvoll.

Eine Schritt-für-Schritt-Beispielüberprüfung — Gestaltung des Experiments für ein neues Homepage-Feed — sollte etwa 8–10 Minuten dauern. Übe das, bis es automatisch ist.

ML-Fallstudien (der Product-DS-Winkel)

Wenn ML in einer Product-DS-Schleife auftaucht, erscheint es als Fallstudie, nicht als Coding-Runde. Die Rahmung ist immer eine Variante von „Design einen Ranker für X” — Feed-Ranking, Suchergebnisse, Empfehlungen, Anzeigenauswahl. Die erwartete Struktur:

  1. Geschäftsziel — Was optimieren wir tatsächlich? Engagement, Umsatz, langfristige Bindung? Das Senior-Signal ist die Nennung des langfristigen Ziels, auch wenn die Proxy-Metrik kurzfristig ist.
  2. Beschriftungen — Was sind die positiven und negativen Klassen? Wie werden Beschriftungen erzeugt, und welche Verzerrungen führt das ein? (Positionsbias, Selektionsbias, das Cold-Start-Problem.)
  3. Merkmale — Drei bis fünf Kategorien: Benutzermerkmale, Elementmerkmale, Kontextmerkmale, Interaktionsmerkmale und (für sequenzabhängige Modelle) Verlaufsmerkmale der letzten Zeit.
  4. Modellklasse — Gradient-Boosted Trees als Standard-Arbeitstier, Deep Learning wo Daten und Signal es rechtfertigen. Der Senior Candidate benennt den Trade-off — Interpretierbarkeit, Trainingskosten, Online-Serving-Latenz — anstatt das zu greifen, was gerade modisch ist.
  5. Offline-Bewertung — AUC-ROC für Klassifizierung, NDCG für Ranking, RMSE für Regression. Die Falle ist, hier zu stoppen; Offline-Metriken korrelieren schwach mit Online-Geschäftsmetriken, und der Senior Candidate benennt das.
  6. Online-Bewertung — A/B-Test-Design, primäre und Schutzmetriken, die Schleife zurück zur Experimentationsrunde.

Die erwartete ehrliche Tiefe nach Ebene: Bei L4 (Junior) kannst du jeden Schritt beschreiben. Bei L5 (Mid) kannst du Trade-offs bei jedem Schritt argumentieren. Bei L6 (Senior) kannst du die zwei oder drei Schritte identifizieren, wo diese Fallstudie ungewöhnlich ist — was macht sie schwieriger als die Lehrbuch-Rahmung — und vorschlagen, wie du sie handhaben würdest.

Product-/Metrik-Runden: der DAU-Rückgang

Die Signatur-Product-Runde, die bei fast jedem Unternehmen, das Product-DS-Interviews durchführt, gefragt wird, ist eine Variante von: „DAU ist wöchentlich um 5 % gesunken. Erkläre mir, wie du das diagnostizieren würdest."

Das erwartete Rahmenwerk, live ausgeführt:

  1. Überprüfe die Daten zuerst. Ist die Metrik tatsächlich gesunken, oder ist das ein Instrumentierungsproblem? Überprüfe die Logging-Pipeline, überprüfe auf vorgelagerte Änderungen, suche nach Teiltagsdaten.
  2. Segmentiere. Nach Geografie, Plattform, Betriebssystem, Land, Benutzerkohorte, Akquisitionskanal. Der Rückgang ist selten einheitlich; das Finden des Segments lokalisiert die Ursache.
  3. Zerlege nach Verhalten. DAU = neue Benutzer + wiederkehrende Benutzer. Ist die Registrierung neuer Benutzer gesunken? Ist die Bindung wiederkehrender Benutzer gesunken? Diese haben völlig unterschiedliche Ursachen.
  4. Zerlege nach Funnel. Innerhalb jeder Verhaltensgruppe: Sind App-Öffnungen gesunken? Ist die Öffnungs-zu-Engagement-Rate gesunken? Jeder Schritt hat unterschiedliche vorgelagerte Ursachen.
  5. Querverweise mit externen Ereignissen. Produktstarts (deine und die von Konkurrenten), Nachrichtenzyklen, Feiertage, Änderungen im Paid-Marketing, Infrastrukturvorfälle.
  6. Bilde eine Hypothese, gestalte eine Überprüfung. Sobald du eine mögliche Erklärung hast, welche Daten würden sie widerlegen?

Bei Meta und Google ist die erwartete Ausgabe ein „Metrik-Baum” — eine visuelle Zerlegung der Metrik, die jede Eingabe und die relative Größe ihrer Änderung zeigt. Der Senior Candidate zeichnet den Baum, bevor er spricht, und geht dann durch ihn; der Junior Candidate spricht zuerst und kommt nie zum Baum.

Wo ein Echtzeit-KI-Assistent in DS-Runden hilft – und wo nicht

Seien Sie ehrlich darin. Die DS-Schleife hat Runden, in denen KI-Unterstützung Sie fast ganz dorthin bringt, und Runden, in denen sie Sie wie einen Betrüger klingen lässt. Das Raster unten zeigt, was wir unseren Nutzern sagen.

KI-Unterstützung nach DS-Interview-Runde
FeatureSQLStatistikA/B-TestsML-FallProdukt / MetrikVerhalten
KI-Hilfe-QualitätAusgezeichnetGutStarkStarkModeratStark
LatenzanforderungUnter 200 ms (Live-Kodierung)GesprächsmodusGesprächsmodusGesprächsmodusGesprächsmodusGesprächsmodus
HeimlichkeitsanforderungHoch (Bildschirmfreigabe)MittelMittelMittelMittelMittel
Ethisches WohlbefindenUmstrittenAngenehmAngenehmAngenehmAngenehmPersönliche Entscheidung
Empfohlener NutzungsmodusSkript beinahe wörtlichDenkunterstützungFramework-PromptGliederung + Sie ergänzenBrainstorm; verteidigen Sie Ihre PositionNur Gliederung – sagen Sie es mit Ihrer Stimme

Die ehrliche Zusammenfassung: SQL-Screens sind der Ort, an dem KI-Unterstützung der Übernahme der Arbeit am nächsten kommt – die Syntax ist starr, der Abstand von der Eingabeaufforderung zur funktionierenden Abfrage ist gering, und gute Assistenten wie Acedly lesen den Editor direkt. In Statistik- und A/B-Test-Runden ist die KI äußerst nützlich, um das richtige Framework und den richtigen Test zu identifizieren, aber Sie müssen die Antwort immer noch verteidigen, wenn der Interviewer nachfasst. In Produkt-/Metrik-Runden ist die KI ein Brainstorming-Partner, kann aber die Antwort nicht für Sie verteidigen – der Interviewer fragt „Warum dieses Segment und nicht jenes?” und Sie müssen eine Meinung haben. In Verhaltens-Runden kann die KI eine Struktur (Situation-Aufgabe-Aktion-Ergebnis) erzeugen, aber der Inhalt muss von Ihnen stammen, in Ihrer Stimme, sonst klingt es einstudiert.

Acedly während einer Live-DS-Runde

Acedly ist für Live-Human-Interviews konzipiert, bei denen Sie bestimmen, was Sie offenbaren. Speziell für Daten-Wissenschaftler-Runden sind drei Dinge wichtig:

Latenz. Die mediane End-to-End-Latenz beträgt ungefähr 98 ms – gemessen vom Ende der Äußerung bis zum ersten gerenderten Token. Im SQL-Codierungsbildschirm ist dieses Budget am wichtigsten, denn der Unterschied zwischen „die KI hilft” und „die KI ist zu langsam” ist der Unterschied zwischen eigenständiger Lösung und Abschreiben.

Editor-Lesung von Codierungsplattformen. Die meisten DS-SQL-Screens laufen auf Coderpad oder HackerRank – beides verifizierten Oberflächen, auf denen Acedly die Problemstellung, das Schema und die vom Kandidaten geschriebene Teilabfrage liest und alle drei als Grundierungskontext nutzt. Ein Copilot, der nur auf Audio hört, nutzt das Schema nicht, was zu schlechteren SQL-Vorschlägen führt.

Multi-Modell-Routing. SQL-Fragen nutzen DeepSeek für Code-Generierung; Statistik- und Wahrscheinlichkeitsfragen nutzen Claude für Reasoning-Qualität; Produkt-/Metrik-Runden nutzen GPT für den breiteren Geschäftskontext. Der Router wählt pro Frage aus, nicht pro Sitzung.

Acht verifizierte Plattformen. Zoom, Microsoft Teams, Google Meet, Webex, Lark/Feishu, Amazon Chime, Coderpad, HackerRank. Zusammen decken diese ungefähr 95 % der professionellen DS-Interview-Plattformen im Jahr 2026 ab.

12+ Programmiersprachen, einschließlich SQL. Python, R, SQL (PostgreSQL-, MySQL-, BigQuery-, Snowflake-Dialekte), Scala, Java, JavaScript/TypeScript, Go, Rust, C++, Julia, MATLAB, Bash. Die SQL-Dialekt-Erkennung ist wichtig, denn die Window-Function-Syntax unterscheidet sich subtil zwischen Postgres und MySQL.

Ein vierwöchiger DS-Interview-Vorbereitungsplan

Wenn Sie vier Wochen Zeit haben, ist der folgende Zeitplan eine funktionierende Aufteilung. Passen Sie die Gewichtung an, wenn Sie auf einen nicht standardisierten Track abzielen.

Woche 1 — SQL-Übungen. Zwei Stunden täglich. Fünfzig Aufgaben auf StrataScratch oder DataLemur, konzentriert auf Window-Funktionen, Retention/Cohort-Muster und Funnel-Abfragen. Jede Aufgabe erhält eine einzeilige Nachbesprechung: Welches Muster, welche Window-Funktion, was war die Granularität? Am Ende der Woche sollten Sie top-N-per-group aus dem ersten Satz erkennen können.

Woche 2 — Statistik, Wahrscheinlichkeit und A/B-Tests. Eine Stunde Theorie (Wiederholung von Verteilungen, Hypothesentests, Bayes), eine Stunde Praxis — arbeiten Sie sich durch zehn klassische A/B-Test-Prompts (Stichprobengröße, Neuheitseffekte, Netzwerkeffekte, Verdünnung). Üben Sie das siebenschrittige Schema laut, bis es automatisch ist. Lektüre: Kohavi, Tang, Xu's Trustworthy Online Controlled Experiments deckt fast alles ab, was gefragt wird.

Woche 3 — Produkt- und Metrik-Mock-Cases. Drei Mock-Cases pro Tag, jeweils 30 Minuten, zu verschiedenen Metriken. Der DAU-Rückgang, der Engagement-Rückgang, der Conversion-Rate-Rückgang, der Churn-Anstieg. Verwenden Sie den Metric-Tree-Rahmen jedes Mal. Nehmen Sie sich selbst auf; schauen Sie es sich an; die ersten drei sind schlecht, die zehnte ist automatisch.

Woche 4 — unternehmensabhängig. Wenn Sie auf Meta abzielen, trainieren Sie Produktfälle aus dem Decode and Conquer-Track. Wenn Sie auf Google abzielen, erweitern Sie über SQL-, Statistik- und ML-Fälle. Wenn Sie auf Amazon abzielen, bereiten Sie ein LP-zugeordnetes Portfolio mit zwei Geschichten pro Grundsatz vor. Die letzten 48 Stunden: Ruhe. Leichtere Aufgaben, Schlaf, die mentale Erfrischung zu erkennen, dass Sie die Arbeit geleistet haben.

Die einzelne Gewohnheit mit dem höchsten Hebel in jeder Woche: Schreiben Sie für jedes Problem, das Sie lösen, eine einzeilige Nachbesprechung. Nach 50 Problemen haben Sie eine laufende Tabelle Ihrer Mustererkennung-Geschichte. Nach 100 werden Sie DAU-Rückgänge im Schlaf diagnostizieren.

Häufig gestellte Fragen