Data Analyst:in
Strukturierte Interviewfragen für Data Analyst:in — mit dem Signal, auf das eine starke Antwort jeweils hinweist.
VerhaltensbezogenGeschäftsorientierung Beschreiben Sie eine Analyse, die eine konkrete Geschäftsentscheidung verändert hat. Was war die Ausgangsfrage, was haben Sie gefunden, und was wurde am Ende entschieden?
Worauf eine starke Antwort hinweistFähigkeit, ein Analyse-Projekt entlang der Wirkungskette zu erzählen: Frage, Methode, Ergebnis, Entscheidung. Bonus: die:der Kandidat:in benennt die Stakeholder:innen, die Annahmen und die Unsicherheit der Daten. Wer nur die Methode beschreibt („Ich habe einen Funnel gebaut“), ohne die Entscheidung zu nennen, hat meist Reporting gemacht, nicht Analyse. Wer von „strategischen Insights“ ohne konkrete Zahl oder Aktion spricht, kompensiert oft fehlende Geschäftsorientierung mit Floskeln.
VerhaltensbezogenDatenkritik und Investigation Erzählen Sie mir von einer Analyse, deren Ergebnis Sie ursprünglich für falsch gehalten haben. Was war das Symptom, und wie sind Sie zur Wahrheit gekommen?
Worauf eine starke Antwort hinweistStrukturierte Investigationsmethode: Datenqualität prüfen, Hypothesen aufstellen, mit Stakeholder:innen sprechen, neue Quellen einbeziehen. Bonus: die:der Kandidat:in nennt die Lehre aus dem Fall (was sie:er heute beim ersten Versuch anders machen würde). Ehrlichkeit zur Zeit, die es gedauert hat (eine echte Daten-Anomalie ist selten in 30 Minuten geklärt). Wer noch nie an einem eigenen Ergebnis gezweifelt hat, prüft selten genug.
VerhaltensbezogenStakeholder-Management Beschreiben Sie eine Stakeholder-Anfrage, die Sie zurückgewiesen oder umformuliert haben. Was war die ursprüngliche Frage, und was haben Sie stattdessen geliefert?
Worauf eine starke Antwort hinweistGeschäftsurteil und Mut, eine Frage zu hinterfragen statt mechanisch zu liefern. Bonus: die:der Kandidat:in nennt den Dialog mit der:dem Stakeholder:in (gemeinsame Umformulierung der Frage). Wer jede Anfrage genauso liefert, wie sie kommt, baut viele Dashboards, die niemand nutzt. Wer pauschal verweigert („Das ist die falsche Frage“) ohne Vorschlag, zeigt eine arrogante Haltung, die im KMU schnell zu Konflikten führt.
SituativStakeholder-Management Ein:e Sales-Lead bittet Sie um eine Ad-hoc-Auswertung, die nach Ihrer Einschätzung 2 Tage dauert. Die Person will sie heute Nachmittag. Wie reagieren Sie?
Worauf eine starke Antwort hinweistKlärung des Bedarfs vor der Timeline-Verhandlung: für welche Entscheidung ist die Auswertung gedacht, welcher Detailgrad reicht. Optionen anbieten: einfache Version heute, vollständige Version in 2 Tagen; Scope-Cut; Verweis auf ein vorhandenes Dashboard. Wer einfach zusagt und am selben Tag halbgar liefert, baut Datenqualitätsprobleme ein. Wer pauschal ablehnt, zeigt schwaches Stakeholder-Management.
SituativDatenkritik und Investigation Sie entdecken in der Wochenanalyse eine plötzliche Veränderung einer Schlüsselmetrik (Conversion fällt um 20 % in einer Woche). Was tun Sie in den nächsten 24 Stunden?
Worauf eine starke Antwort hinweistStrukturierte Investigation: (1) Datenqualität und Instrumentierung prüfen (häufigste Ursache), (2) segmentieren (neue vs. bestehende Nutzer:innen, Device, Quelle, Region), (3) mit den betroffenen Funktionen sprechen (gab es ein Release, eine Kampagnenänderung, einen Ausfall bei einem Drittanbieter), (4) priorisierte Hypothesen mit Stakeholder:innen teilen. Wer sofort die Geschäftsführung alarmiert, ohne zu prüfen, schafft falschen Alarm. Wer wartet und beobachtet, verpasst Reaktionsfenster.
SituativPriorisierung und Trade-off Drei Funktionen (Sales, Marketing, Produkt) bitten Sie im selben Quartal um große Analyse-Projekte. Sie können nur zwei davon machen. Wie priorisieren Sie?
Worauf eine starke Antwort hinweistExplizites Priorisierungs-Framework: Geschäftsimpact pro Stunde Aufwand, strategische Bedeutung des Themas, Vorhandensein anderer Quellen für die zurückgestellte Anfrage. Erwartete Methode: mit den drei Funktionen sprechen, um den realen Bedarf hinter der Anfrage zu verstehen, gemeinsam mit der:dem Vorgesetzten priorisieren, transparent zurückmelden. Wer einfach nach dem Auftraggeber-Rang priorisiert (Geschäftsführung first), zeigt schwaches Geschäftsurteil. Wer ohne Rücksprache zwei Projekte auswählt, baut Konflikte ein.
CaseAnalytische Methode Unser SaaS-Produkt hat eine 30-Tage-Aktivierungsquote von 35 %. Das Team möchte verstehen, was die Aktivierungswahrscheinlichkeit am stärksten beeinflusst. Wie gehen Sie analytisch vor?
Worauf eine starke Antwort hinweistStrukturierte Herangehensweise: (1) Aktivierungsdefinition schärfen (welcher konkrete Schritt zählt als Aktivierung), (2) den Funnel instrumentieren und die teuersten Abbruchstellen identifizieren, (3) Kohorten bilden (nach Akquisitionsquelle, Onboarding-Variante, Segment), (4) deskriptive Analyse vor jeder Modellierung (Logistische Regression oder ähnliches kommt erst, wenn die Frage es verlangt). Bonus: die:der Kandidat:in unterscheidet Korrelation von Kausalität und schlägt ein Experiment vor, um eine identifizierte Hypothese zu validieren. Wer sofort von Machine Learning oder einem Random-Forest-Modell spricht, ohne den Funnel einzugrenzen, zeigt eine Methoden-Schwäche.
CaseDatenkritik und Investigation Debug: Ihr Wochenreport zeigt seit 3 Wochen seltsam stabile Conversion-Zahlen, obwohl Marketing-Spend und Produktrelease sich stark verändert haben. Wie gehen Sie vor?
Worauf eine starke Antwort hinweistStrukturierte Datenkritik: (1) Datenquellen prüfen (läuft das Tracking, hat eine API-Änderung das Event-Volumen verzerrt), (2) Stichproben manuell prüfen (passt eine einzelne Konversion zu dem, was in CRM oder Logs steht), (3) mit den Entwickler:innen sprechen (gab es einen stillen Bug im Tracking-Layer), (4) historische Vergleichswerte aus alternativen Quellen ziehen. Wer einfach die Zahlen meldet ohne zu hinterfragen, baut blindes Vertrauen in fehlerhafte Daten ein. Bonus: die:der Kandidat:in erkennt, dass zu stabile Zahlen oft ein stärkeres Warnsignal sind als chaotische.
CaseAnalytische Methode Aufgabe: Sie sollen dem CFO einen Forecast für den ARR-Verlauf der nächsten 6 Monate liefern. Was brauchen Sie an Daten, welche Methode wählen Sie, und welche Unsicherheit kommunizieren Sie?
Worauf eine starke Antwort hinweistKlärung vor der Methode: welche Annahmen zu Akquisition, Churn, Expansion; welcher Detailgrad pro Segment. Methode: einfache Kohorten-Projektion mit Churn- und Expansionsraten, plausibilisiert mit historischen Daten; nicht zwingend ein ML-Modell. Bonus: die:der Kandidat:in liefert Szenarien (Best, Base, Worst Case) statt einer Punktschätzung und benennt die Sensitivität auf 1 bis 2 Schlüsselannahmen. Wer ohne Klärung in eine komplexe Zeitreihenanalyse springt, zeigt fehlendes Gespür für den Bedarf der:des Stakeholder:in.
FachlichSQL- und Tooling-Solidität SQL: Sie haben eine Tabelle events(user_id, event_name, occurred_at). Wie schreiben Sie eine Abfrage, die für jede:n Nutzer:in die Zeit zwischen Sign-up und erstem Kauf liefert?
Worauf eine starke Antwort hinweistBeherrschung von Window Functions oder Self-Joins, CTEs zur Lesbarkeit, korrekte Handhabung von Nutzer:innen ohne Kauf (LEFT JOIN, NULL-Behandlung), Aggregation auf der richtigen Granularität. Bonus: die:der Kandidat:in fragt nach, ob Sign-up und Kauf in derselben Tabelle stehen, ob Mehrfachkäufe vorkommen, welche Zeitzonenkonvention gilt. Wer ohne Klärung sofort eine Abfrage schreibt, die auf einer typischen Datenstruktur nicht läuft, zeigt schwache Praxis. Wer kein CTE oder Window Function einsetzt und mit verschachtelten Subqueries arbeitet, ist meist auf einem niedrigeren SQL-Niveau.
FachlichGeschäftsorientierung Welche Kennzahlen empfehlen Sie einem B2B-SaaS-KMU für das wöchentliche Geschäftsreview? Warum diese und nicht andere?
Worauf eine starke Antwort hinweistGesunde Kadenz-Logik: Frühindikatoren (qualifizierte Pipeline, Aktivierungsquote, Trial-zu-Paid-Conversion) für laufende Steuerung, Spätindikatoren (MRR, ARR, Net Revenue Retention, Churn) für strategische Bewertung. Bonus: die:der Kandidat:in unterscheidet operative von strategischen Metriken und passt das Set an die Phase des Unternehmens an (ein Seed-KMU schaut auf andere Kennzahlen als ein Series-B-Scale-up). Wer 15 Kennzahlen ohne Hierarchie aufzählt, hat noch nie eine echte Steuerung verantwortet.
FachlichAnalytische Methode Erklären Sie den Unterschied zwischen Korrelation und Kausalität an einem konkreten Geschäftsbeispiel. Wie würden Sie eine vermutete Kausalität validieren?
Worauf eine starke Antwort hinweistKlares konzeptionelles Verständnis: Korrelation lässt sich beobachten, Kausalität nur in einem kontrollierten Experiment oder über quasi-experimentelle Methoden (Differenz-in-Differenzen, Regression Discontinuity, Instrumentvariablen) plausibel etablieren. Bonus: die:der Kandidat:in nennt ein konkretes Geschäftsbeispiel (z. B. „Nutzer:innen, die unsere Anleitung lesen, kündigen seltener“ heißt nicht, dass die Anleitung die Kündigung verhindert; vielleicht sind engagierte Nutzer:innen ohnehin treuer). Wer den Unterschied nicht klar formulieren kann, wird in Analysen häufig Schein-Effekte als kausal verkaufen.
WerteStakeholder-Management Wie reagieren Sie, wenn ein:e Stakeholder:in von Ihnen eine Auswertung verlangt, die nach Ihrer Einschätzung eine bereits getroffene Entscheidung im Nachhinein rechtfertigen soll?
Worauf eine starke Antwort hinweistIntegrität und Geschäftsurteil. Bonus: die:der Kandidat:in beschreibt einen konkreten Fall, in dem sie:er die Frage umformuliert hat, um eine ehrliche Auswertung zu liefern (statt entweder mechanisch zu liefern oder konfrontativ zu verweigern). Wer pauschal „Ich liefere, was bestellt wird“ sagt, zeigt eine Auftragsausführer-Haltung ohne Geschäftspartnerschaft. Wer pauschal verweigert, zeigt Schwäche in der Stakeholder-Beziehung. Die gesunde Antwort liegt im Dialog.
WerteMentoring und Weitergabe Welche Rolle spielen Sie bei der Datenkultur eines Teams? Beschreiben Sie eine Situation, in der Sie eine:n Kolleg:in im Umgang mit Daten weitergebildet haben.
Worauf eine starke Antwort hinweistAktive Mentorenhaltung: Schulung in SQL oder im Lesen von Dashboards, Dokumentation häufiger Pitfalls, pädagogische Reviews von Anfragen. Wer „Ich helfe, wenn ich gefragt werde“ sagt, ohne mehr Konkretes, zeigt eine passive Haltung. Im KMU mit kleinem Datenteam ist die Fähigkeit, die Datenkultur breiter zu tragen, entscheidend für die Nachhaltigkeit der Analytics-Funktion.
WerteCoachbarkeit Welche Kritik an einer eigenen Analyse haben Sie zuletzt erhalten, die Sie zunächst für falsch gehalten haben, und was hat Sie umgestimmt?
Worauf eine starke Antwort hinweistOffenheit für Kritik und Lernfähigkeit. Bonus: die:der Kandidat:in nennt den konkreten Auslöser des Umdenkens (eine alternative Datenquelle, eine Stichprobenprüfung, ein methodisches Argument). Wer beschreibt, der:dem Kritiker:in die eigene Logik erklärt zu haben statt zuzuhören, zeigt eine Schwäche in der Coachbarkeit. In einem KMU, in dem die:der Analyst:in oft alleine arbeitet, ist die Fähigkeit, Kritik aktiv zu suchen, ein hartes Qualitätssignal.
Evaluations-Playbook
Die Rolle der Data Analyst:in zeigt sich über fünf Evaluations-Stufen. Die SQL-Praxisaufgabe (Stufe 3) ist die aussagekräftigste Stufe: hier trennt sich die:der Analyst:in mit echter Praxis von der:dem, die:der nur über Dashboards gesprochen hat. Halten Sie die Aufgabe realistisch und unter 2 Stunden, sonst filtern Sie die besten Profile aus.
Stufe 1: CV-Lektüre
Suchen Sie nach konkreten Geschäftswirkungen, nicht nur nach Tools. Ein:e Analyst:in, die:der „SQL, Python, Tableau“ schreibt, ohne ein konkretes Ergebnis zu nennen (Conversion-Funnel um X Punkte verbessert, monatliches Forecasting im Sales-Team eingeführt, Churn-Treiber identifiziert), hat meist Dashboards gepflegt, nicht Entscheidungen unterstützt. Stack-Konsistenz (mindestens 12 bis 18 Monate auf einem ähnlichen Stack) zählt mehr als eine lange Tool-Liste. Studienhintergrund (Statistik, Wirtschaft, Informatik) ist hilfreich, aber nicht zwingend; gute autodidaktische Profile mit Bootcamp-Hintergrund (Le Wagon Data, Spiced, neue fische) liefern oft stärkere Geschäftsorientierung als reine Quant-Absolvent:innen.
Stufe 2: Phone Screen (30 Min.)
Nur drei Fragen: (1) Beschreiben Sie eine Analyse, die eine konkrete Geschäftsentscheidung verändert hat. Was war die Frage, was haben Sie gefunden, was wurde entschieden? (2) Welche Stakeholder-Anfrage haben Sie zuletzt zurückgewiesen oder umformuliert? (Geschäftsurteil und Mut), (3) Warum jetzt ein Wechsel? Ergebnis: Go/No-Go in 5 Min. Debrief. Vermeiden Sie auf dieser Stufe technische Gotcha-Fragen zu SQL-Syntax oder Statistik-Begriffen; suchen Sie das Geschäftsdenken.
Stufe 3: SQL-Praxisaufgabe (90 Min.)
Eine begrenzte, realistische Aufgabe an einem Beispieldatensatz: 3 bis 5 Geschäftsfragen, die mit SQL beantwortet werden müssen (z. B. Conversion-Funnel-Analyse, Kohorten-Retention, Aufdeckung eines Anomalie-Patterns). Wichtig: die:der Kandidat:in darf Dokumentation und Internet nutzen; bewerten Sie die Qualität der Abfragen (CTEs, Window Functions, Joins), die Klarheit der Begründung und die Übersetzung in Geschäftsempfehlungen. Vermeiden Sie reine Algorithmus-Aufgaben ohne Geschäftsbezug. Bonus: die:der Kandidat:in hinterfragt die Datenqualität oder die Fragestellung, bevor sie:er rechnet.
Stufe 4: Stakeholder-Simulation (60 Min.)
Rollenspiel mit einer:einem PM, Sales-Lead oder Geschäftsführer:in: die:der Kandidat:in präsentiert die Ergebnisse der SQL-Aufgabe an eine:n Stakeholder:in, der:die unter Zeitdruck steht und nur die wichtigsten Erkenntnisse hören will. Bewerten Sie: Strukturierung der Botschaft (zuerst die Antwort, dann die Methode), Anpassung an das Vokabular der:des Stakeholder:in, Umgang mit kritischen Rückfragen, Anerkennung der Unsicherheitszonen. Dies ist die prädiktivste Stufe für Geschäftsorientierung und übergreifende Kommunikation, die im KMU mehr wiegen als reine Tool-Beherrschung.
Stufe 5: Referenzen (strukturierte Überprüfung)
Rufen Sie zwei Referenzen an: eine:n ehemalige:n Vorgesetzte:n (Head of Data, CFO, COO) und eine:n ehemalige:n Stakeholder:in aus einer Geschäftsfunktion (Sales, Marketing, Produkt). Stellen Sie beiden dieselben 4 Fragen: Worin ist sie:er am stärksten? Worin würden Sie eine ergänzende Person einstellen? Würden Sie sie:ihn morgen wieder einstellen, warum? Ein konkretes Beispiel einer Analyse, die eine Entscheidung verändert hat? Die Stakeholder-Referenz liefert das eigentliche Geschäftsimpact-Signal, das ein:e Vorgesetzte:r oft glättet.
Woran Sie eine hervorragende Besetzung erkennen
| Kompetenz | Unter Anforderung | Auf Niveau | Über Anforderung |
|---|---|---|---|
| Geschäftsorientierung | Liefert mechanisch, was bestellt wird, ohne den dahinterliegenden Bedarf zu hinterfragen. Beschreibt Projekte über Tools und Methoden, nicht über getroffene Entscheidungen. Verwechselt Reporting mit Analyse. | Klärt vor der Analyse, für welche Entscheidung sie gedacht ist. Strukturiert die Antwort entlang der Geschäftsfrage. Kann eigene Analysen einer:einem nicht-technischen Stakeholder:in in 5 Minuten erklären. | Treibt die Geschäftsfrage aktiv mit: schlägt Analysen vor, die Stakeholder:innen nicht angefragt haben, identifiziert blinde Flecken in der Steuerung, übersetzt Datenbefunde in Entscheidungsempfehlungen. Wird von Geschäftsfunktionen als Sparringspartner:in, nicht als Lieferant:in gesehen. |
| SQL- und Tooling-Solidität | Stolpert über fortgeschrittenes SQL (Window Functions, CTEs, korrekte Joins). Baut langsame oder unleserliche Abfragen. Beherrscht ein BI-Tool nur oberflächlich (drag-and-drop, keine Custom-Metriken). | Schreibt sauberes, lesbares SQL mit CTEs und Window Functions. Beherrscht mindestens ein BI-Tool (Looker, Tableau, Power BI, Metabase) auf Custom-Metriken-Niveau. Kann Python oder R für Ad-hoc-Analysen einsetzen, wo SQL an Grenzen stößt. | Referenz im Team für SQL- und Tool-Qualität: dokumentiert wiederverwendbare Patterns, automatisiert wiederkehrende Auswertungen über dbt oder ein Äquivalent, bildet Kolleg:innen im Tool-Einsatz weiter. Erkennt, wann eine Frage SQL übersteigt und Python oder ein Statistik-Modell verlangt. |
| Analytische Methode | Springt von der Frage direkt in eine komplexe Methode (Machine Learning, Zeitreihenmodell), ohne deskriptive Grundlagen zu schaffen. Verwechselt Korrelation mit Kausalität. Hinterfragt eigene Annahmen selten. | Grenzt die Frage vor der Methode ein. Beginnt mit deskriptiver Analyse, bevor sie:er modelliert. Trennt Korrelation von Kausalität explizit. Erkennt eigene Annahmen und benennt sie in der Kommunikation. | Wählt die einfachste Methode, die die Frage beantwortet, und begründet die Wahl. Schlägt Experimente oder quasi-experimentelle Designs vor, um vermutete Kausalitäten zu validieren. Liefert Szenarien und Sensitivitäten statt Punktschätzungen, wenn die Unsicherheit es verlangt. |
| Datenkritik und Investigation | Vertraut den Daten blind. Erkennt Anomalien nicht oder meldet sie ohne eigene Investigation weiter. Reagiert auf seltsam stabile Zahlen mit Erleichterung statt mit Misstrauen. | Prüft die Datenqualität vor jeder Analyse. Erkennt Anomalien und untersucht sie strukturiert (Segmentierung, Quellenprüfung, Stichproben). Spricht aktiv mit Entwickler:innen und betroffenen Funktionen, um Datenfehler aufzuklären. | Etabliert eine Datenqualitätskultur im Team: dokumentiert bekannte Pitfalls, baut automatische Konsistenzchecks, schult Kolleg:innen im kritischen Lesen von Dashboards. Erkennt systemische Datenqualitätsprobleme und priorisiert deren Behebung in der Infrastruktur. |
| Stakeholder-Management | Liefert mechanisch, was bestellt wird, oder verweigert konfrontativ. Kommuniziert technisch ohne Anpassung an die:den Stakeholder:in. Konflikte mit Geschäftsfunktionen wiederholen sich. | Klärt Anfragen vor der Ausführung. Passt Sprache und Detailgrad an die:den Stakeholder:in an. Kann eine Anfrage umformulieren, ohne die Beziehung zu beschädigen. | Wird von Geschäftsfunktionen schon bei der Fragestellung einbezogen, nicht erst zur Ausführung. Moderiert datenbasierte Entscheidungsmeetings, hält den Fokus auf der Geschäftsfrage und übersetzt zwischen analytischem und operativem Vokabular. |
| Coachbarkeit | Verteidigt die eigene Analyse, statt Kritik zu prüfen. Sucht selten aktiv Feedback. Wiederholt dieselben Fehler über mehrere Projekte. | Nimmt Kritik strukturiert auf, prüft sie an Daten und passt die Analyse an, wenn die Kritik trifft. Sucht aktiv Reviews bei komplexen Projekten. | Sucht systematisch Reviews und kritische Gegenstimmen, bevor eine Analyse veröffentlicht wird. Dokumentiert Lehren aus früheren Fehlern für das Team. Bildet jüngere Profile aktiv in der Aufnahme von Kritik aus. |
30/60/90-Tage-Plan
Bis Tag 30
- Zugang zu allen Datenquellen (Data Warehouse, BI-Tool, Produkt-Analytics, CRM) eingerichtet und mit einer Beispiel-Abfrage validiert
- Wöchentliche 1:1 mit den 3 bis 5 wichtigsten Stakeholder:innen (Geschäftsführung, Sales-Lead, Marketing-Lead, Produkt-Lead) etabliert
- Audit der bestehenden Dashboards und Reports: welche werden tatsächlich genutzt, welche sind verwaist, welche enthalten widersprüchliche Definitionen
- Erste eigenständige Ad-hoc-Auswertung mit dokumentierter Methode und Geschäftsempfehlung geliefert
Bis Tag 60
- Wöchentliches oder zweiwöchentliches Geschäftsreview mit konsolidiertem Kennzahlen-Set etabliert oder bestehendes geschärft
- Erste strukturelle Analyse (Funnel-Analyse, Kohorten-Retention, Forecast oder Äquivalent) abgeschlossen und mit Handlungsempfehlung an die Geschäftsführung präsentiert
- Mindestens eine Datenqualitätslücke identifiziert, dokumentiert und mit dem Engineering-Team adressiert
- Dokumentation der wichtigsten Metrik-Definitionen aktualisiert oder neu erstellt (Aktivierung, Conversion, Churn, ARR)
Bis Tag 90
- Regelmäßige Lieferung (2 bis 4 strukturelle Analysen pro Monat plus Geschäftsreview) konsequent gehalten
- Erste größere Geschäftsentscheidung dokumentiert auf eine eigene Analyse zurückführbar (Pricing-Anpassung, Onboarding-Änderung, Segment-Priorisierung)
- Informelles Mentoring eines Junior-Profils oder einer Geschäftsfunktion (SQL-Schulung, Dashboard-Lese-Workshop, Daten-Lese-Hilfestellung)
- Formales Bilanzgespräch mit der:dem Vorgesetzten: Einarbeitungsphase validiert, Entwicklungsplan auf 1 bis 2 Schwerpunkte (z. B. Vertiefung in Forecasting oder Aufbau eines dbt-Layers)