4) Technische & professionelle Fragen (hier entscheidet sich das Interview)
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.