Data Analyst Mock Interview — mit AI üben

Data-Analyst-Interviews sehen auf dem Papier einfach aus — SQL, etwas Statistik, ein oder zwei Charts — und überrumpeln die Leute im Raum. Die Fragen sind kurz. Die Erwartungen sind es nicht. Ein SQL-Screen mit drei Aufgaben kann 45 Minuten dauern; eine einzige A/B-Test-Diskussion kann sich über eine Stunde ziehen. Das Üben des Formats mit AI-Mocks verwandelt Überrumpelungs-Fragen in Routine.

Die Form eines Data-Analyst-Loops

Die meisten Analyst-Loops haben vier bewegliche Teile. Ein Recruiter-Screen. Ein technischer SQL-Screen (live oder Take-Home), meist 45–60 Minuten mit zwei oder drei Aufgaben zunehmender Schwierigkeit. Eine Produkt-/Business-Case-Runde, in der Ihnen der Interviewer eine mehrdeutige Kennzahlen-Frage stellt und beobachtet, wie Sie argumentieren. Und eine Behavioral-/funktionsübergreifende Runde, die prüft, ob Sie mit Nicht-Daten-Menschen reden können, ohne sie sich dumm fühlen zu lassen.

Senior-Analyst- und Analytics-Engineer-Loops fügen eine fünfte Runde hinzu: eine System- oder Experimentier-Design-Frage. „Entwerfen Sie ein A/B-Testing-Framework für unser Recommendations-Team“ oder „entwerfen Sie eine Metrics-Layer für unsere Finance-Org“. Das sind die Fragen mit der höchsten Varianz im gesamten Loop — sie belohnen strukturiertes Denken und bestrafen Menschen, die zu Dashboards springen, bevor sie die Kennzahlen definiert haben.

AI-Mocks bewältigen drei der vier gut. SQL-Screens sollten Sie in einem echten SQL-Editor mit einem echten Datensatz üben (LeetCode SQL, StrataScratch, Mode-Tutorials sind alle in Ordnung). Alles andere — verbale SQL-Durchläufe, Case Studies, A/B-Test-Argumentation, Behavioral — ist genau das, wofür AI-Mocks gebaut wurden.

SQL-Screens: Wo die meisten Kandidaten Punkte verlieren

Der SQL-Screen filtert mehr Kandidaten heraus als jede andere Runde, und er filtert nicht aus dem Grund, den die meisten annehmen. Die Messlatte ist nicht „können Sie einen Join schreiben“. Sie ist „können Sie eine saubere, korrekte, effiziente Query für ein leicht mehrdeutiges Problem schreiben, und können Sie laut erklären, was Sie geschrieben haben, während ein anderer Mensch zusieht?“. Die zweite Hälfte ist, wo Mocks helfen.

Themen, die garantiert vorkommen

• Window Functions — row_number, rank, lag, lead, partitionierte Aggregate.
• CTEs und rekursive CTEs (seltener, aber sie tauchen bei Senior auf).
• Alle vier Join-Typen mit Edge Cases (NULLs auf beiden Seiten, Self-Joins, Anti-Joins über NOT EXISTS).
• Aggregationen mit GROUP BY + HAVING, einschließlich bedingter Aggregate (COUNT(CASE WHEN ...)).
• Datumsarithmetik — letzte 7 Tage, Retention-Kohorten, Woche-über-Woche-Vergleiche.
• Deduplizierungs-Patterns (welche Zeile behalten Sie, warum).

Klassische Fragemuster: „finden Sie die Top N nach einer Kennzahl innerhalb jeder Gruppe“, „berechnen Sie die Woche-über-Woche-Retention“, „finden Sie Nutzer, die X taten, aber nicht Y“, „finden Sie das zweitneueste Event pro Nutzer“. Wenn die kein automatisches Muskelgedächtnis haben, trainieren Sie sie eine Woche lang vor jedem echten Interview.

A/B-Test-Argumentation

A/B-Test-Fragen entscheiden, ob Sie in die nächste Runde kommen. Sie sind das, was dem „Produkturteil“ am nächsten kommt, das der Interviewer in 45 Minuten testen kann. Das Format ist immer ähnlich: ein vages Feature, ein vages Ziel, Ihre Aufgabe ist es, das Experiment sauber laut zu entwerfen.

Die Kette, die Sie durchlaufen müssen

1. Definieren Sie die Änderung. Was genau ist das Treatment? „Wir zeigen ein neues Banner“ ist zu vage. „Wir zeigen auf der Startseite ein Banner, das zur Upgrade-Seite verlinkt, für Nutzer, die seit über 30 Tagen kostenlos sind“ ist präzise.
2. Formulieren Sie die Hypothese. Richtung und Größenordnung. „Wir erwarten, dass die Upgrade-Rate bei den behandelten Nutzern um 2 Prozentpunkte steigt.“ Konkret. Falsifizierbar.
3. Wählen Sie die primäre Kennzahl. Eine. Nicht drei. „Upgrade-Rate innerhalb von 7 Tagen nach dem Treatment.“ Verteidigen Sie, warum diese und nicht die naheliegenden Alternativen.
4. Wählen Sie Guardrail-Kennzahlen. Was sich nicht verschlechtern darf. „Engagement der Free-Nutzer, Session-Länge, Volumen der Support-Tickets.“ Wenn das Treatment die primäre Kennzahl bewegt, aber eine Guardrail sprengt, liefern Sie nicht aus.
5. Schätzen Sie Stichprobengröße und Laufzeit. Basierend auf der Baseline-Rate, dem minimal detektierbaren Effekt, Alpha und Power. Sie müssen die Mathematik nicht live machen — zeigen Sie nur, dass Sie die Inputs verstehen.
6. Formulieren Sie die Entscheidungsregel. Welcher Evidenzschwellenwert das Feature ausliefert. Was Sie tun, wenn die Ergebnisse nicht eindeutig sind.

Interviewer haken mit Fallen nach: Novelty-Effekte, Netzwerkeffekte (besonders in sozialen Produkten), Interferenz zwischen gleichzeitigen Experimenten, Peeking. Seien Sie bereit, jeden beim Namen zu nennen und zu erklären, warum er wichtig ist.

Dashboards und Case Studies

Case Studies sind Gesprächsrunden ohne Daten auf dem Bildschirm. Ein typischer Prompt: „DAU sind letzte Woche um 5 % gefallen. Was tun Sie?“. Der Interviewer sucht nicht die Antwort (ohne Daten gibt es keine). Er sucht: Zerlegen Sie das Problem sauber, stellen Sie die richtigen klärenden Fragen, priorisieren Sie Hypothesen nach Wahrscheinlichkeit und Wirkung, und wissen Sie, welche Daten Sie ziehen und welche Query Sie ausführen würden.

Ein sauberes Framework: Beginnen Sie mit klärenden Fragen (welches Produkt, welche Definition von DAU, welche Segmente, ist das ein bekanntes Daten-Pipeline-Problem), dann segmentieren Sie Hypothesen in extern (Saisonalität, Marketing, Konkurrenz-Launch), internes Produkt (jüngster Deploy, Feature-Änderung, A/B-Test) und Instrumentierung (Logging-Bug, Schema-Änderung). Ordnen Sie nach Wahrscheinlichkeit. Für die obersten zwei oder drei sagen Sie, was Sie ziehen und worauf Sie schauen würden.

Dashboard-Design-Fragen sind konkreter. „Sie bauen ein Dashboard für den Head of Growth — was steht drauf?“. Listen Sie nicht 40 Kennzahlen auf. Wählen Sie 5–8, die auf Entscheidungen abbilden, die der Head of Growth tatsächlich trifft (Acquisition, Activation, Retention, Monetization, Referral — der AARRR-Loop oder die Variante Ihres Unternehmens). Für jede sagen Sie, welcher Schwellenwert eine Aktion auslöst.

Wie Sie einen AI-Mock für Analyst-Rollen einrichten

Setzen Sie die Rolle auf „Data Analyst“ oder fügen Sie die JD ein, falls Sie eine haben. Wählen Sie für die erste Session den „Tech Screening“-Modus und 10 Fragen — das gibt Ihnen eine etwa gleichmäßige Aufteilung aus SQL-Durchläufen, A/B-Argumentation und ein oder zwei Case Studies. Für tiefere Übungs-Sessions nutzen Sie den Standalone-Modus und sagen der AI, sie solle sich auf einen Bereich konzentrieren: „verbringen Sie die ganze Session mit SQL Window Functions und bedingten Aggregaten“ oder „verbringen Sie die ganze Session mit A/B-Test-Design mit Fallen“.

Ein nützliches Muster speziell für Analysten: Nehmen Sie nach dem AI-Mock die SQL-Fragen und schreiben Sie die Queries tatsächlich in einem SQL-Playground. Der Mock bringt ans Licht, ob Sie den Ansatz erklären können; der Playground bestätigt, dass Sie den Code ausliefern können. Beides zählt.

Häufig gestellte Fragen