Business Intelligence Analyst Vorstellungsgespräch: Fragen & Antworten (mit Musterantworten)

Musterantwort

Ich kläre zuerst die eigentliche Geschäftsfrage hinter der Anfrage, denn oft will der Stakeholder eine Entscheidung treffen, nicht nur eine Zahl sehen. Ich frage nach Zweck, Zielgruppe und Entscheidung, die getroffen werden soll, und schlage dann passende Kennzahlen vor. Mit einem schnellen Mockup oder einer ersten Auswertung validiere ich, ob ich auf dem richtigen Weg bin. So vermeide ich aufwendige Berichte, die am eigentlichen Bedarf vorbeigehen.

Musterantwort

Ich definiere Kennzahlen eindeutig und stimme die Definitionen mit den Fachbereichen ab, damit alle dasselbe meinen. Ich prüfe Datenquellen auf Vollständigkeit und Plausibilität, etwa durch Abgleich mit bekannten Summen oder Vorperioden. Vor der Freigabe lasse ich kritische Berichte gegenprüfen und dokumentiere die Logik nachvollziehbar. So habe ich einmal eine fehlerhafte Umsatzkennzahl entdeckt, bevor sie in ein Management-Meeting ging.

Musterantwort

Ich beginne mit der Kernaussage und der empfohlenen Entscheidung, bevor ich Details zeige, damit die Botschaft sofort ankommt. Ich wähle einfache, passende Visualisierungen und vermeide überladene Dashboards mit zu vielen Kennzahlen. Ich verknüpfe Zahlen mit konkreten Geschäftsfolgen, damit sie greifbar werden. So machte ich aus einer abstrakten Abwanderungsanalyse eine klare Handlungsempfehlung für das Vertriebsteam.

Musterantwort

Ich priorisiere nach Geschäftswert und Dringlichkeit, also danach, welche Auswertung die wichtigste Entscheidung unterstützt. Ich kläre Erwartungen transparent und kommuniziere realistische Termine, statt allen alles sofort zu versprechen. Wiederkehrende Anfragen automatisiere ich über Self-Service-Dashboards, um langfristig Kapazität zu schaffen. So reduziere ich Ad-hoc-Last und konzentriere mich auf wirkungsvolle Analysen.

Musterantwort

Mich reizt, dass Sie datengetriebene Entscheidungen ernst nehmen und in den Aufbau einer modernen Datenplattform investieren. Ihre Ausschreibung erwähnt die Einführung eines zentralen Data Warehouse, ein Bereich, in dem ich Erfahrung mit Modellierung und Dashboarding einbringe. Ich liefere gern Analysen, die das Geschäft konkret voranbringen, statt Berichte für die Schublade. Außerdem passt Ihr BI-Stack gut zu meinem Hintergrund.

Ein INNER JOIN liefert nur Zeilen, für die in beiden Tabellen ein passender Schlüssel existiert. Ein LEFT JOIN liefert alle Zeilen der linken Tabelle und ergänzt passende Werte aus der rechten, fehlende Treffer werden mit NULL aufgefüllt. LEFT JOIN nutzt man, wenn man auch Datensätze ohne Entsprechung behalten will, etwa Kunden ohne Bestellung.

Im Star-Schema hängt eine zentrale Faktentabelle direkt an denormalisierten Dimensionstabellen, was Abfragen einfach und schnell macht. Im Snowflake-Schema sind Dimensionen weiter normalisiert und in mehrere verbundene Tabellen aufgeteilt, was Redundanz spart, aber mehr Joins erfordert. Star-Schemata werden in BI wegen Performance und Verständlichkeit häufig bevorzugt.

Eine Dimension ist ein beschreibendes, qualitatives Attribut, nach dem man filtert oder gruppiert, etwa Region, Produkt oder Datum. Ein Measure ist ein quantitativer, aggregierbarer Wert, etwa Umsatz oder Stückzahl. In einem Bericht bilden Dimensionen die Achsen und Measures die ausgewerteten Zahlen.

ETL steht für Extract, Transform, Load, wobei Daten vor dem Laden ins Zielsystem transformiert werden. Bei ELT werden Rohdaten zuerst geladen und erst im leistungsfähigen Zielsystem, etwa einem Cloud Data Warehouse, transformiert. ELT nutzt die Rechenleistung moderner Warehouses und ist bei großen Datenmengen oft flexibler.

Ich gruppiere die Bestelldaten nach Jahr und Monat und summiere den Umsatz, etwa mit GROUP BY auf einer Datumsfunktion wie DATE_TRUNC oder einer Jahr-Monat-Spalte. Mit SUM auf dem Betragsfeld erhalte ich die Monatssummen, sortiert nach Zeitachse. Bei Bedarf ergänze ich Fensterfunktionen, um Vormonatsvergleiche oder gleitende Durchschnitte zu berechnen.

Das Management erwog, ein margenschwaches Produkt einzustellen (Situation). Ich sollte eine fundierte Datengrundlage liefern (Task). Ich habe Deckungsbeiträge, Cross-Selling-Effekte und Kundenbindung analysiert und gezeigt, dass das Produkt indirekt hohe Folgeumsätze auslöste (Action). Das Produkt blieb im Sortiment, und die Entscheidung beruhte auf belastbaren Daten statt auf einem oberflächlichen Margenblick (Result).

Ein Dashboard zeigte plötzlich unrealistisch hohe Verkaufszahlen (Situation). Ich sollte die Ursache finden, bevor falsche Schlüsse gezogen wurden (Task). Ich habe die Pipeline rückverfolgt und doppelt geladene Datensätze durch einen fehlerhaften ETL-Lauf identifiziert und bereinigt (Action). Die Zahlen waren wieder korrekt, und ich ergänzte einen Dublettencheck, der den Fehler künftig automatisch verhindert (Result).

Vertrieb und Finanzen meldeten unterschiedliche Umsatzzahlen und stritten über die Wahrheit (Situation). Ich sollte eine einheitliche Definition schaffen (Task). Ich habe beide Berechnungslogiken offengelegt, die Abweichung in Stornierungen und Zeitpunkt der Erfassung erklärt und eine gemeinsame, dokumentierte Definition abgestimmt (Action). Beide Abteilungen nutzten danach dieselbe Kennzahl, und die Diskussionen hörten auf (Result).

Ein wöchentlicher Bericht wurde mühsam von Hand in Excel zusammengestellt (Situation). Ich sollte den Aufwand reduzieren und Fehler vermeiden (Task). Ich habe die Datenquellen über SQL angebunden und ein automatisch aktualisierendes Dashboard in Power BI erstellt (Action). Der manuelle Aufwand entfiel fast vollständig und die Stakeholder hatten jederzeit aktuelle Zahlen (Result).