Was wird in Data-Analyst-Interviews wirklich getestet?

Mit wem Sie in jeder Phase tatsächlich sprechen

Ein Data-Analyst-Prozess ist selten ein einziges Gespräch. Es sind meist drei oder vier, jedes von jemandem mit anderem Job und anderem Prüfpunkt geführt.

Das Recruiter-Screening testet nicht Ihre analytische Fähigkeit. Es bestätigt, dass Sie über Ihre Arbeit in klarem Deutsch sprechen können, dass Ihre Gehaltsvorstellung und Kündigungsfrist zur Stelle passen und dass Sie die Stellenbezeichnung nicht falsch gelesen haben (Analyst, Analytics Engineer und Data Scientist werden locker verwendet, und Anzeigen wollen manchmal das eine, während sie als das andere betitelt sind).

Die technische Runde wird meist von jemandem geführt, der den Job täglich macht — ein Senior Analyst oder Analytics Manager, manchmal ein Data Engineer, wenn die Rolle viel Pipeline-Arbeit berührt. Das ist die SQL- und Statistik-Runde, und Kandidaten bereiten sich darauf zu wenig vor, weil sie annehmen, Seniorität bedeute weniger Coding — was falsch ist: Je höher die Rolle, desto wahrscheinlicher wird erwartet, dass Sie korrektes SQL unter Zeitdruck schreiben, ohne dass ein Linter Ihre Fehler abfängt.

Die Fallstudie oder "Business-Problem"-Runde wird oft von jemandem aus dem Team geführt, das Sie tatsächlich unterstützen würden — ein Product Manager, ein Marketing Lead, ein Finance Business Partner. Sie bewerten nicht Ihre SQL-Syntax. Sie prüfen, ob Sie eine vage Frage wie "warum sind die Anmeldungen letzten Monat gesunken" in etwas Messbares verwandeln können, ohne dass man Ihnen sagt wie.

Eine letzte Runde mit einem Hiring Manager oder Director geht meist um Urteilsvermögen und Passung: wie Sie mit Meinungsverschiedenheiten mit Stakeholdern umgehen, wie Sie priorisieren, wenn drei Personen widersprüchliche Analysen bis Freitag wollen.

Das technische Assessment: wie es tatsächlich aussieht

Für die meisten Data-Analyst-Rollen im Tech-Bereich erwarten Sie eines oder mehrere von:

• Ein Live- oder aufgezeichneter SQL-Test. Nicht Trivia über Syntax, sondern eine Abfrage gegen ein Schema mit duplizierten Zeilen, nullbaren Foreign Keys oder einem Many-to-Many-Join, der Ihre Counts stillschweigend aufbläht, wenn Sie es falsch machen. Häufige Anforderungen: Window Functions (ROW_NUMBER() OVER (PARTITION BY ...) zum Deduplizieren oder Ranken), ein Self-Join zum Vergleichen des Nutzerverhaltens über Perioden, und ein GROUP BY mit HAVING-Klausel statt WHERE. Wenn Sie eine korrekte Abfrage schreiben können, aber nicht erklären können, warum Sie vor dem Aggregieren dedupliziert haben, zeigt sich diese Lücke.
• Eine Take-Home mit einem echten oder realistischen Datensatz. Sie werden meist gebeten, eine Business-Frage zu beantworten, nicht nur Charts zu produzieren. Interviewer lesen diese darauf, ob Sie Ihre Annahmen genannt haben (wie haben Sie "aktiven Nutzer" definiert?), ob Sie Datenqualitätsprobleme markiert haben statt stillschweigend darum herumzuarbeiten, und ob Ihre Empfehlung aus den gezeigten Zahlen folgt oder sich liest, als wäre sie vorher entschieden worden.
• Ein Tool-Walkthrough. Wenn der Job Looker, Tableau, Power BI oder Mode auflistet, werden Sie möglicherweise gebeten, Ihren Bildschirm zu teilen und etwas live zu bauen oder ein bestehendes Dashboard zu kritisieren. Das prüft, ob Sie einen Diagrammtyp wählen können, der nicht irreführt, nicht ob Sie jedes Menü kennen.
• Leichte Statistik. Für Rollen, die Experimente berühren, erwarten Sie Fragen dazu, was ein p-Wert tatsächlich bedeutet, wie Sie eine Stichprobe für einen A/B-Test bemessen würden und was mit Ihrer Konfidenz passiert, wenn Sie fünf Metriken aus einem Test fahren und den kleinsten p-Wert den Gewinn nennen.

Manche Firmen überspringen die Take-Home ganz und machen all das live auf einem geteilten Bildschirm, weil Take-Homes ausgelagert werden können oder Kandidaten sechs unbezahlte Stunden kosten. Ob das besser für Sie ist, hängt davon ab, ob Sie schneller denken als schreiben; es gibt keinen Konsens unter Hiring-Teams, welches Format fairer ist, und Sie sollten beides erwarten.

Die Fragen, die wirklich etwas testen

Eine Handvoll normal klingender Fragen trägt fast das gesamte Signal. Hier ist, was sie tatsächlich prüfen.

"Führen Sie mich durch eine Analyse, die eine Entscheidung geändert hat." Das fragt nicht nach einer Projektzusammenfassung. Es prüft, ob Sie eine Linie von einer bestimmten Zahl zu einer bestimmten Person zu einer bestimmten Handlung ziehen können, die sie sonst nicht unternommen hätte. Wenn Ihre Antwort bei "und ich fand, dass die Conversion auf Mobile niedriger war" endet, haben Sie eine Beobachtung beschrieben, kein Ergebnis. Der Interviewer hört darauf, was passierte, nachdem Sie die Analyse gesendet haben.

"Wie würden Sie messen, ob dieses Feature funktioniert?" Das testet, ob Sie standardmäßig zu einer Metrik greifen oder die Frage erst hinterfragen. Eine starke Antwort fragt, was "funktionieren" für das Business bedeutet, bevor sie eine Metrik nennt, markiert mindestens eine plausible Weise, wie die offensichtliche Metrik irreführend sein könnte (ein Feature, das Engagement steigert, indem es etwas schwerer auffindbar macht, ist kein Gewinn), und nennt eine Guardrail-Metrik neben der Headline-Metrik. Eine schwache Antwort springt direkt zu "ich würde täglich aktive Nutzer tracken".

"Erzählen Sie mir von einer Zeit, als Ihre Analyse falsch war oder Sie sie anders gemacht hätten." Das prüft intellektuelle Ehrlichkeit, und es ist schwerer vorzutäuschen als Leute denken, weil eine einstudierte Nicht-Antwort ("Ich glaube nicht, dass ich falsch lag, aber wenn ich etwas sagen müsste...") sofort erkennbar ist für jeden, der Analysen für den echten Einsatz geliefert hat. Was sie wollen: was falsch war, wie Sie es herausfanden und was Sie an Ihrer Arbeitsweise infolgedessen geändert haben.

Ein Live-SQL-Problem mit einem Twist — duplizierte Zeilen, ein Join, der auffächert, ein Datumsfeld mit gemischten Formaten. Das testet, ob Sie Ihre Zeilenzahlen vor und nach einem Join prüfen, laut, ohne dass man es Ihnen sagt. Analysten, die von einem Fan-out-Join gebrannt wurden, machen das automatisch. Analysten, die es nicht wurden, machen es nicht, und der Interviewer weiß meist innerhalb von dreißig Sekunden, welche Art er beobachtet.

Wie eine oberflächliche Antwort klingt

Für jemanden, der diesen Job macht, verraten ein paar Muster einen Kandidaten, der nicht tatsächlich mit dem Durcheinander echter Daten gesessen hat.

Das Tool statt der Entscheidung beschreiben — "Ich baute ein Dashboard in Tableau mit Filtern für Region und Datum" — und dort stoppen. Niemand fragte, wie das Dashboard aussah; sie fragten, was sich deswegen änderte.

Die Definition eines p-Werts rezitieren, ohne sagen zu können, was er nicht aussagt. Wenn jemand nicht in eigenen Worten erklären kann, warum ein statistisch signifikantes Ergebnis auf einer winzigen Stichprobe nicht automatisch handlungswert ist, hat er den Begriff auswendig gelernt statt ihn verwendet.

In einer Fallstudie direkt zu einem Chart oder einer Abfrage springen, ohne erst zu fragen, was das Business tatsächlich mit dem Begriff in der Frage meint — "Engagement", "Churn", "aktiv" — bedeuten verschiedene Dinge bei verschiedenen Firmen, und Analysten, die mit echten Stakeholdern gearbeitet haben, wissen zu fragen, bevor sie bauen.

Eigenverantwortung für eine Analyse beanspruchen ohne Erwähnung, dass jemand ihr widersprochen hat. Echte analytische Arbeit beinhaltet, dass jemand im Raum mit Ihrer Zahl oder Ihrer Rahmung nicht einverstanden ist. Eine Antwort ohne Reibung darin ist entweder ein sehr einfacher Job oder eine bearbeitete Geschichte.

Und speziell bei SQL: eine Abfrage schreiben, die kompiliert, aber stillschweigend doppelt zählt wegen eines unbehandelten Joins, und es nicht bemerken, und nicht prüfen.

Was Sie vor dem Interview tatsächlich tun sollten

Wählen Sie ein Projekt aus Ihrer eigenen Geschichte — idealerweise eines mit wirklich unordentlichen Daten — und üben Sie, es in unter einer Minute zu erklären: die Frage, was Sie fanden, was sich änderte. Wenn Sie es nicht unter eine Minute bekommen, haben Sie wahrscheinlich noch nicht fertig den Befund vom Rauschen darum herum getrennt.

Üben Sie SQL gegen ein Schema mit Duplikaten und Nulls, nicht saubere Tutorial-Daten. Trainieren Sie speziell Self-Joins, Window Functions für Deduplizierung und Ranking und das Prüfen von Zeilenzahlen vor und nach einem Join.

Bereiten Sie eine ehrliche Geschichte über Falsches vor, mit der Korrektur, nicht nur dem Fehler.

Vor einer Fallstudien-Runde schreiben Sie zwei oder drei Fragen auf, die Sie einen Stakeholder fragen würden, bevor Sie die Daten berühren, und üben Sie, sie laut zu stellen, statt zu einem Chart zu springen.

Wenn Sie viele Bewerbungen rausschicken und wenig zurückbekommen, ist die Interview-Phase oben meist nicht der Engpass — es ist, dazu eingeladen zu werden. jobmarket.pro liest jede Anzeige gegen Ihr tatsächliches Profil und sagt Ihnen, wo Sie wirklich passen, bevor es etwas in Ihrem Namen vorbereitet.