Du wirst nicht daran gemessen, ob du SQL „kannst“, sondern ob du damit Business-Fragen korrekt beantwortest – inklusive KPI-Definition, Datenqualität und sauberer Kommunikation unter Druck.
Konkrete Interviewfragen für Data Analyst in Österreich: SQL, KPI, Dashboards, DSGVO, Cases – mit Antwort-Frameworks und Beispielantworten.
Du starrst auf die Einladung im Posteingang. „Data Analyst – Interview, 60 Minuten, Case dabei.“ Klingt machbar – bis du merkst: Das wird kein Plausch über „Stärken/Schwächen“, sondern ein Reality-Check. SQL unter Zeitdruck. KPI-Logik. Stakeholder, die „nur schnell“ ein Dashboard wollen. Und in Österreich kommt noch eine Portion Struktur und Formalität dazu.
Wenn du dich jetzt fragst, welche Fragen wirklich kommen (und wie du sie so beantwortest, dass man dir die Rolle sofort abnimmt): Genau darum geht’s hier. Keine generischen Tipps – sondern Data-Analyst-Fragen, wie sie österreichische Unternehmen 2026 tatsächlich stellen.
In Österreich ist der Prozess oft angenehm geordnet – aber nicht unbedingt kurz. Häufig startest du mit einem HR-Call (15–30 Minuten), in dem es weniger um „Kultur“ geht, sondern um harte Eckdaten: Verfügbarkeit, Gehaltsrahmen, Arbeitserlaubnis, manchmal schon Tool-Stack. Danach kommt das Fachinterview mit Teamlead oder Senior (60–90 Minuten). Hier wird’s konkret: Datenquellen, SQL-Ansatz, KPI-Definitionen, Datenqualität – und ob du Ergebnisse so erklären kannst, dass Fachbereiche nicht aussteigen.
Viele Firmen hängen einen kleinen Case dran: entweder als Live-Übung (z. B. „schreib die Query“) oder als Take-Home (1–3 Stunden). Gerade bei Rollen, die Richtung BI Analyst, Business Intelligence Analyst oder Reporting Analyst gehen, wird oft ein Dashboard-Teil abgeprüft: Modellierung, Measures, Visual-Logik. Remote ist 2026 normal, aber in Österreich gibt’s weiterhin gern eine finale Runde vor Ort – manchmal kombiniert mit einem kurzen Kennenlernen im Team. Rechne außerdem damit, dass Probezeit und Einstufung nach Kollektivvertrag (KV) zumindest gestreift werden – selbst wenn du über KV verhandelst.
Bei Data-Analyst-Interviews wirken manche Fragen auf den ersten Blick „klassisch“. Der Unterschied: Du wirst an Daten-Realität gemessen. Nicht an schönen Worten. Du brauchst Beispiele, in denen du mit unklaren Anforderungen, schmutzigen Daten und widersprüchlichen KPIs sauber umgegangen bist. Und du musst zeigen, dass du nicht nur Zahlen produzierst, sondern Entscheidungen verbesserst.
Q: „Erzähl mir von einem Analyseprojekt, bei dem du aus chaotischen Daten eine Entscheidungsvorlage gebaut hast.“
Why they ask it: Sie testen, ob du Datenqualität, Struktur und Business-Nutzen zusammenbringst.
Answer framework: Problem–Vorgehen–Impact (PVI): 1 Satz Problem, 2–3 Sätze Vorgehen (Daten, Methoden, Validierung), 1 Satz messbarer Impact.
Example answer: „In meinem letzten Projekt waren Bestelldaten aus drei Systemen inkonsistent – gleiche Kund:innen, unterschiedliche IDs. Ich habe zuerst ein Matching über E-Mail/Telefon plus Fuzzy-Logik aufgebaut und die Regeln mit Sales validiert. Danach habe ich eine Kohortenanalyse erstellt, um Wiederkaufraten nach Kanal zu vergleichen. Ergebnis: Wir haben einen Kanal identifiziert, der zwar Umsatz brachte, aber extrem hohe Retouren hatte – die Budgetverteilung wurde angepasst und die Retourenquote sank im Quartal um rund 8%.“
Common mistake: Zu technisch werden („ich habe Python genutzt“) ohne zu erklären, welche Entscheidung dadurch besser wurde.
Zwischen den Zeilen geht’s jetzt um das, was dich im Alltag verfolgt: Anforderungen, die sich ändern. Stakeholder, die „eine Zahl“ wollen. Genau deshalb kommt als Nächstes fast immer die Kommunikationsfrage.
Q: „Wie gehst du vor, wenn ein Fachbereich eine KPI will, die nicht eindeutig definiert ist?“
Why they ask it: Sie prüfen, ob du KPI-Governance und Erwartungsmanagement beherrschst.
Answer framework: Definition–Beispiele–Abnahme: Definition vorschlagen, 2 Beispiele/Edge-Cases klären, schriftliche Abnahme sichern.
Example answer: „Ich starte mit einer Gegenfrage: Wofür wird die KPI genutzt – Steuerung, Bonus, Reporting? Dann lege ich eine Definition mit Formel, Filterlogik und Zeitbezug vor und bringe sofort Edge-Cases rein, z. B. Stornos, Teilrückerstattungen oder verspätete Buchungen. Ich dokumentiere das in einem kurzen KPI-Steckbrief und lasse ihn vom Owner abnehmen. Erst dann baue ich Dashboard und Alerts – sonst diskutieren wir später über Zahlen statt über Entscheidungen.“
Common mistake: Einfach „eine“ Definition implementieren und hoffen, dass niemand nachfragt.
Q: „Erzähl von einer Situation, in der deine Analyse einem Manager nicht gefallen hat.“
Why they ask it: Sie testen Konfliktfähigkeit und ob du bei Fakten bleibst.
Answer framework: STAR (Situation, Task, Action, Result) mit Fokus auf „Action“: wie du kommuniziert und abgesichert hast.
Example answer: „Ein Bereichsleiter war überzeugt, dass eine Kampagne profitabel ist. Meine Auswertung zeigte das Gegenteil, weil die Neukunden zwar hoch waren, aber die Deckungsbeiträge durch Rabatte kippten. Ich habe die Annahmen transparent gemacht, Sensitivitäten gerechnet und angeboten, gemeinsam die Attribution-Logik zu prüfen. Am Ende haben wir die Kampagne nicht gestoppt, aber die Zielgruppe geändert und ein Cap für Rabatte eingeführt. Im Folgemonat war der DB wieder positiv.“
Common mistake: Den Stakeholder als „unvernünftig“ darstellen – das wirkt arrogant.
Q: „Wie stellst du sicher, dass deine Ergebnisse reproduzierbar sind?“
Why they ask it: Sie wollen sehen, ob du sauber arbeitest (Versionierung, Dokumentation, Tests).
Answer framework: Pipeline-Checkliste: Datenquelle → Transformation → Validierung → Output → Monitoring.
Example answer: „Ich trenne Rohdaten, Transformationsschritte und Output klar, idealerweise in einer versionierten Pipeline. Für kritische Kennzahlen baue ich Plausibilitätschecks ein, z. B. Row-Counts, Null-Raten, Range-Checks und Abgleich gegen Vorperioden. Außerdem dokumentiere ich Annahmen direkt dort, wo sie wirken – im Code/Query oder im Datenkatalog. So kann jemand anderes die Analyse nachbauen, ohne mich zu brauchen.“
Common mistake: Reproduzierbarkeit nur als „ich speichere die Excel-Datei“ zu verstehen.
Q: „Was ist für dich ein gutes Dashboard – und wann ist ein Dashboard die falsche Lösung?“
Why they ask it: Sie prüfen Produktdenken: Visualisierung als Mittel, nicht als Selbstzweck.
Answer framework: Zielgruppe–Entscheidung–Interaktion: Wer nutzt es, welche Entscheidung, welche Handlung folgt.
Example answer: „Ein gutes Dashboard beantwortet wenige, wiederkehrende Fragen schnell und ohne Interpretationslotterie. Es hat klare Definitionen, sinnvolle Defaults und zeigt Abweichungen, nicht nur Zahlenwände. Falsch ist ein Dashboard, wenn die Frage einmalig ist oder wenn die Datenlage unsicher ist – dann ist ein kurzer Analyse-Readout oder ein Experiment-Design oft besser. Ich versuche, Dashboards wie Produkte zu behandeln: Owner, Feedback, Iterationen.“
Common mistake: Dashboards als „Reporting-Pflicht“ sehen und alles hineinpacken.
Q: „Wie bleibst du fachlich up to date – konkret als Data Analyst?“
Why they ask it: Sie testen Lernfähigkeit, aber ohne Buzzword-Bingo.
Answer framework: 3-Kanäle-Modell: Praxis (eigene Projekte), Community (Blogs/Meetups), Standards (Dokumentation/Release Notes).
Example answer: „Ich halte mich über Release Notes meiner Tools auf dem Laufenden, weil sich dort echte Arbeit verändert – z. B. neue Funktionen in Power BI oder Snowflake. Zusätzlich mache ich kleine Side-Analysen, um Methoden zu testen, etwa Forecasting oder A/B-Test-Auswertung. Und ich tausche mich in der Community aus, z. B. über lokale Data/BI-Meetups oder gezielte Newsletter. Wichtig: Ich übersetze Neues immer in ‘Was bringt’s unserem Reporting oder der Datenqualität?’“
Common mistake: Nur Kurse aufzählen, ohne zu zeigen, wie du das Gelernte anwendest.
Jetzt kommt der Teil, den viele unterschätzen: Du wirst nicht nur gefragt, ob du SQL kannst – sondern ob du SQL so nutzt, dass Business-Fragen korrekt beantwortet werden. Und ob du als BI Analyst / Business Intelligence Analyst / Reporting Analyst die typischen Fallen kennst: falsche Joins, doppelte Zählungen, KPI-Definitionen, inkonsistente Zeitlogik, Performance, Governance.
Q: „Schreib eine SQL-Query: Umsatz pro Kunde im letzten Quartal, aber ohne Stornos – wie gehst du vor?“
Why they ask it: Sie testen Join-Logik, Filter, Zeitfenster und ob du Stornos korrekt behandelst.
Answer framework: Think-aloud + Schrittfolge: Tabellen klären → Grain definieren → Filter/Timebox → Aggregation → Validierung.
Example answer: „Ich kläre zuerst das Grain: Ist eine Zeile eine Order, eine Position oder eine Buchung? Dann definiere ich ‘Umsatz’ (brutto/netto) und wie Stornos markiert sind – eigener Status oder negative Buchung. In SQL würde ich die Zeitbox über Order-Date oder Booking-Date sauber festlegen, Stornos per Status/Flag ausschließen oder per SUM über signierte Beträge lösen. Danach aggregiere ich auf customer_id und prüfe mit einem Quick-Sanity-Check: Top-10-Kunden, Summenabgleich gegen Finance-Report.“
Common mistake: Einfach WHERE status != 'cancelled' schreiben, obwohl Stornos als Gegenbuchung kommen.
Q: „Erklär den Unterschied zwischen INNER JOIN, LEFT JOIN und wann du dadurch doppelt zählst.“
Why they ask it: Sie prüfen, ob du Kardinalitäten verstehst – das ist Data-Analyst-Brot.
Answer framework: Kardinalität zuerst: 1:1, 1:n, n:m → Join-Typ → Aggregationsebene.
Example answer: „Ich starte immer mit der Frage: Welche Beziehung haben die Tabellen? Bei 1:n kann ein JOIN die Zeilen vervielfachen, wenn ich zu früh aggregiere. INNER JOIN filtert auf Matches, LEFT JOIN behält die linke Tabelle und hängt Nulls an – das ist wichtig für ‘fehlende’ Daten. Doppelt zählen passiert oft, wenn ich Orders mit Order-Items joine und dann Umsatz auf Order-Ebene summiere, ohne vorher auf Order zu aggregieren. Deshalb: erst Grain sauber machen, dann joinen oder aggregieren.“
Common mistake: Join-Typen definieren können, aber Kardinalität ignorieren.
Q: „Wie würdest du ein Datenmodell für ein Sales-Dashboard aufbauen (Star Schema)?“
Why they ask it: Sie testen Modellierungsdenken – besonders relevant für Reporting Analyst/BI.
Answer framework: Fakten–Dimensionen–Grain: Faktentabelle mit klarer Körnung, Dimensionen für Filter/Hierarchien.
Example answer: „Ich definiere zuerst die Faktentabelle, z. B. ‘Sales Transactions’ auf Positionsebene oder Order-Ebene – je nachdem, welche KPIs gebraucht werden. Dimensionen wären Datum, Kunde, Produkt, Region, Kanal, ggf. Sales Rep. Wichtig ist eine konsistente Date-Dimension für YTD/YoY und eine saubere Produkt-Hierarchie. Wenn es mehrere Quellen gibt, baue ich Conformed Dimensions, damit KPIs über Systeme hinweg vergleichbar bleiben.“
Common mistake: Alles in eine breite Tabelle kippen und später Performance- und KPI-Probleme bekommen.
Q: „Power BI: Wann nutzt du Measures (DAX) statt berechneter Spalten – und warum?“
Why they ask it: Sie prüfen, ob du das semantische Modell verstehst (Filterkontext, Performance).
Answer framework: Kontext-Regel: Spalte = row-by-row, Measure = aggregiert im Filterkontext.
Example answer: „Berechnete Spalten nutze ich, wenn ich eine Zeilen-Eigenschaft brauche, die sich nicht mit dem Filterkontext ändert, z. B. eine Klassifikation. Measures nutze ich für KPIs, weil sie im Filterkontext rechnen und in Visuals korrekt aggregieren. Außerdem sind Measures oft speicherschonender, weil sie nicht als zusätzliche Spalte materialisiert werden. Bei Performance achte ich auf saubere Modellbeziehungen und vermeide unnötig komplexe Iteratoren.“
Common mistake: KPIs als berechnete Spalten bauen und sich dann über falsche Summen wundern.
Q: „Wie gehst du mit Slowly Changing Dimensions (SCD) um – z. B. wenn sich Kundensegmente ändern?“
Why they ask it: Sie testen, ob du Historisierung und Reporting-Konsistenz beherrschst.
Answer framework: SCD-Typ wählen: Type 1 (überschreiben) vs. Type 2 (historisieren) + Reporting-Frage.
Example answer: „Ich entscheide anhand der Frage: Will das Business ‘damals’ oder ‘heute’ sehen? Für historische Analysen ist SCD Type 2 sinnvoll: Segmentwechsel wird als neue Dimension-Zeile mit Gültigkeitszeitraum geführt, und die Faktentabelle referenziert die passende Version. Für rein operative Reports kann Type 1 reichen. Wichtig ist, das transparent zu dokumentieren, sonst diskutiert man später über widersprüchliche Zahlen.“
Common mistake: Segment einfach überschreiben und damit historische Auswertungen unbrauchbar machen.
Q: „DSGVO in der Praxis: Was ist für dich ‘personenbezogen’, und wie minimierst du Risiken im Analytics-Setup?“
Why they ask it: In Österreich ist DSGVO-Compliance kein Nice-to-have, sondern Pflicht.
Answer framework: Datenminimierung–Zweckbindung–Zugriff: Was brauche ich wirklich, wofür, wer darf.
Example answer: „Personenbezogen ist alles, was eine Person direkt oder indirekt identifizierbar macht – also nicht nur Name, sondern auch Kundennummern, Geräte-IDs oder Kombinationen. Ich arbeite mit Datenminimierung: nur Felder, die für die KPI nötig sind. Wo möglich pseudonymisiere ich, trenne Identitäten von Verhaltensdaten und setze rollenbasierte Zugriffe. Außerdem achte ich auf Löschkonzepte und darauf, dass Exporte (z. B. CSV) kontrolliert sind.“
Common mistake: DSGVO als „Legal-Thema“ abtun und Daten einfach überall replizieren.
Q: „Wie würdest du Datenqualität messen und sichtbar machen?“
Why they ask it: Sie suchen jemanden, der nicht nur analysiert, sondern das Fundament stabil hält.
Answer framework: DQ-Dimensionen + Metriken: Vollständigkeit, Genauigkeit, Aktualität, Konsistenz, Eindeutigkeit.
Example answer: „Ich definiere Datenqualitätsmetriken pro kritischer Tabelle: Null-Rate in Pflichtfeldern, Duplikatquote, Freshness (Zeit seit letztem Load), Range-Checks und Referenzintegrität. Dann baue ich ein kleines DQ-Dashboard oder Alerts, damit Probleme nicht erst im Monatsreport auffallen. Wichtig ist, DQ-Metriken an Owner zu hängen – sonst sind es nur schöne Charts ohne Wirkung.“
Common mistake: Datenqualität nur „gefühlt“ bewerten statt messbar.
Q: „Erklär A/B-Tests: Welche Kennzahl würdest du nehmen und wie vermeidest du Fehlinterpretationen?“
Why they ask it: Sie testen Statistik-Grundlagen und Business-Sinn.
Answer framework: Hypothese–Metrik–Design–Auswertung.
Example answer: „Ich starte mit einer klaren Hypothese und einer Primary Metric, die nah an der Entscheidung ist, z. B. Conversion Rate oder Deckungsbeitrag pro Nutzer. Dann prüfe ich Randomisierung, Sample Size und Laufzeit, damit Saisonalität nicht alles verzerrt. In der Auswertung schaue ich auf Konfidenzintervalle und Segment-Checks, aber vermeide p-Hacking. Und ich dokumentiere, was vorab festgelegt war – sonst wird’s politisch.“
Common mistake: Viele Metriken testen und sich die „beste“ im Nachhinein aussuchen.
Q: „Du übernimmst ein bestehendes Reporting: Wie findest du heraus, ob die Zahlen stimmen?“
Why they ask it: Das ist eine echte Alltagssituation für Reporting Analyst-Rollen.
Answer framework: Recon–Trace–Edge-Cases: Abgleich gegen Quelle, Datenfluss nachverfolgen, Grenzfälle testen.
Example answer: „Ich mache zuerst einen Recon gegen eine vertrauenswürdige Quelle, oft Finance oder ERP, und vergleiche Summen über mehrere Perioden. Dann trace ich eine Kennzahl von der Visualisierung zurück bis zur Rohquelle: Filter, Joins, Aggregationen. Danach teste ich Edge-Cases wie Stornos, Retouren, Zeitzonen, nachträgliche Buchungen. Wenn ich Abweichungen finde, dokumentiere ich sie als Ticket mit Impact und Fix-Vorschlag.“
Common mistake: Nur Stichproben im Dashboard machen, ohne den Datenfluss zu prüfen.
Q: „Was tust du, wenn dein ETL/ELT-Job am Monatsultimo fehlschlägt und das Management um 9:00 Zahlen will?“
Why they ask it: Sie testen Incident-Handling und Priorisierung unter Druck.
Answer framework: Stabilisieren–Kommunizieren–Workaround–Fix.
Example answer: „Ich stabilisiere zuerst: Was ist kaputt – Quelle, Netzwerk, Transformation, Berechtigung? Parallel kommuniziere ich früh: ‘Zahlen verzögern sich um X, ich liefere um Y ein Update’. Wenn möglich liefere ich einen kontrollierten Workaround, z. B. Vorperioden-Stand plus Delta aus einer stabilen Quelle, klar als ‘vorläufig’ markiert. Danach kommt Root-Cause und ein Preventive Fix: Monitoring, Retry-Logik, Data Contracts.“
Common mistake: Still im Kämmerchen debuggen und erst kommunizieren, wenn es zu spät ist.
Cases sind in Österreich oft pragmatisch: nicht „Google-Level“, sondern realitätsnah. Du sollst zeigen, dass du strukturiert arbeitest, Annahmen explizit machst und Risiken (Datenqualität, DSGVO, KPI-Definition) aktiv managst. Wichtig: Sprich laut. Interviewer wollen deinen Denkprozess hören.
Q: „Du bekommst einen CSV-Export mit 2 Mio. Zeilen und sollst bis morgen früh ein Executive-Chart liefern. Was machst du?“
How to structure your answer:
Example: „Ich würde zuerst die KPI und den Zeitfilter fixieren, dann in Python/SQL (oder Power Query) eine Aggregation bauen, die 95% der Frage beantwortet. Parallel dokumentiere ich Annahmen und liefere ein ‘v1’-Chart mit klarer Definition. Wenn Datenqualität wackelt, zeige ich zusätzlich einen kleinen DQ-Block (z. B. Missing Rate), damit niemand die Zahl als absolute Wahrheit verkauft.“
Q: „Ein Stakeholder fordert, dass du personenbezogene Rohdaten ins BI-Tool lädst, ‘damit man besser filtern kann’.“
How to structure your answer:
Example: „Ich würde erklären, dass Rohdaten im BI-Tool das Risiko von unkontrollierten Exporten erhöht. Dann schlage ich vor, mit pseudonymisierten IDs und vordefinierten Segmenten zu arbeiten, plus Row-Level-Security. Wenn wirklich nötig, nur über eine abgesicherte View mit minimalen Feldern und klarer Zweckbindung – und mit Freigabe durch Data Owner/Datenschutz.“
Q: „Du findest im Monatsreport eine Abweichung von 12% zum Finance-Report. Was tust du als Erstes?“
How to structure your answer:
Example: „Ich würde sofort prüfen, ob wir brutto/netto, Buchungsdatum vs. Leistungsdatum oder unterschiedliche Storno-Logik vergleichen. Dann baue ich eine Recon-Tabelle, die die Differenz in Komponenten zerlegt. Und ich kommuniziere früh: ‘Wir haben eine Abweichung identifiziert, ich liefere bis 14:00 eine Ursachenanalyse und eine korrigierte Zahl oder eine begründete Abgrenzung.’“
Q: „Das Management will ‘eine einzige Wahrheit’ im Dashboard, aber drei Abteilungen haben drei Definitionen.“
How to structure your answer:
Example: „Ich würde eine KPI-Owner-Struktur vorschlagen und die Definitionen als Versionen behandeln. Kurzfristig kann man drei KPIs nebeneinander zeigen (‘Sales-Definition’, ‘Finance-Definition’), damit Transparenz entsteht. Dann moderiert man die Einigung anhand von Use-Cases und entscheidet, welche Definition für welche Steuerung gilt – und dokumentiert das als Standard.“
Als Data Analyst wirst du an Wirkung gemessen: Sind KPIs stabil? Vertrauen die Leute den Zahlen? Werden Entscheidungen besser? Deine Fragen sollten genau darauf zielen – nicht auf „Wie ist das Team so drauf?“, sondern auf Datenrealität, Ownership und Reifegrad.
In Österreich kommt das Gehaltsthema oft früher als du denkst – manchmal schon im HR-Screening, weil Firmen intern mit KV-Bändern und Budgetfreigaben arbeiten. Recherchiere deshalb vorab reale Spannen über StepStone Gehaltsreport und kununu Gehalt und trianguliere mit Jobanzeigen (z. B. karriere.at Jobs). Dein Hebel als Data Analyst ist selten „ich bin motiviert“, sondern: SQL-Sicherheit, Datenmodellierung, Power BI/DAX, Erfahrung mit Stakeholdern, plus seltene Skills (z. B. Experiment-Design, dbt, Snowflake).
Eine Formulierung, die in Österreich gut funktioniert, ohne aggressiv zu wirken: „Auf Basis meiner Erfahrung in SQL, KPI-Governance und Dashboarding sehe ich mich bei X bis Y EUR brutto/Jahr. Wenn der Scope klar Richtung Business Intelligence Analyst/Reporting Analyst geht und ich Ownership für das Datenmodell übernehme, wäre ich eher am oberen Ende.“
Wenn im Interview niemand sagen kann, wer KPI-Owner ist, wirst du später Schiedsrichter:in in endlosen Zahlendiskussionen. Vorsicht auch, wenn „Dashboarding“ versprochen wird, aber du in Wahrheit nur Excel-Exports für Monatsreports baust – oder umgekehrt: Man nennt es Data Analyst, meint aber eine halbe Data-Engineering-Rolle ohne Ressourcen. Ein weiteres Warnsignal: DSGVO wird weggewunken („machen wir später“), obwohl personenbezogene Daten im Spiel sind. Und wenn sie auf die Frage nach Datenqualität nur mit Schulterzucken reagieren, heißt das oft: Du wirst Feuerwehr statt Analyst.
Wenn du das Data Analyst Vorstellungsgespräch in Österreich gewinnen willst, brauchst du drei Dinge: saubere SQL-/Modell-Logik, klare KPI-Definitionen und die Fähigkeit, Ergebnisse stressfrei zu erklären – inklusive DSGVO-Bewusstsein. Üb die Beispielantworten laut, als würdest du sie morgen präsentieren.
Bevor du ins Interview gehst: Stell sicher, dass dein Lebenslauf das auch hergibt. Bau dir einen ATS-optimierten Lebenslauf auf cv-maker.pro – und dann hol dir das Angebot.