Interviewfragen für BI-Entwickler, mit ausgearbeiteten Antworten

So nutzt du diese Fragen

Antworte mit einem Bericht, den du gebaut hast: wer ihn wollte, welcher Entscheidung er diente, wie du die Daten modelliert hast, was schiefging und wie viele Menschen ihn heute nutzen. Interviewer vertrauen einem BI-Entwickler, der eine Zahl im Dashboard bis zu der Tabelle zurückverfolgen kann, aus der sie stammt.

Was ein BI-Entwickler können muss

• Tools: Power BIDatenmodelle, Measures, Row-Level Security, Aktualisierung und Freigabe; wissen, warum ein Bericht langsam ist. je nach Anbieter, TableauDatenquellen, berechnete Felder, Dashboards und ihre Performance und das Veröffentlichen für andere. je nach Anbieter, LookerEine semantische Schicht mit gemeinsamen Definitionen und die Dashboards darauf, oft neben BigQuery. je nach Anbieter oder QlikDatenladeprozesse, das assoziative Modell und Apps, in denen Anwender selbst suchen, mit Zugriffsregeln. je nach Anbieter und SQLDie Abfragen hinter den Berichten schreiben und tunen und die Tabellen des Warehouse ohne Hilfe lesen., um die Daten zu lesen und zu formen.
• Modelle: SternschemataSternschemata mit klaren Fakten und Dimensionen, mit benannter Granularität, die viele Berichte teilen. mit Fakten- und Dimensionstabellen, Measures und ein semantisches Modell, das viele Berichte teilen.
• Daten: das Data WarehouseDie Schichten und Tabellen kennen, aus denen Berichte lesen, und bei den Engineers die richtigen Änderungen anfragen., ETLWie und wann Daten ins Warehouse kommen; wohin eine Transformation gehört und wer sie pflegt., Aktualisierung und Datenqualität und ExcelHier arbeiten viele Anwender noch: Verbinde es mit dem gemeinsamen Modell, statt Daten hineinzukopieren., wo Anwender die Zahlen noch immer weiterverarbeiten.
• Menschen und Regeln: Anforderungen, KPIs, Row-Level Security, Versionen und Governance und visuelles DesignDiagramme, die je eine Frage beantworten, in Sekunden lesbar sind und Skalen und Lücken ehrlich zeigen., das man in Sekunden lesen kann.

Anforderungen, KPIs und Modelle

Ein Fachbereich möchte ein neues Dashboard. Wie erhebst du die Anforderungen mit den Stakeholdern?

Worauf sie achten: dass du bei Entscheidungen anfängst, nicht bei einer Liste von Diagrammen.

Kurze Antwort: „Ich frage, wer es nutzen wird, welche Entscheidung damit getroffen wird, wie oft und was die Leute heute tun. Dann vereinbare ich die wenigen Zahlen, auf die es ankommt, ihre genauen Definitionen, die Filter, wer was sehen darf und wie aktuell die Daten sein müssen. Ich skizziere die Seite mit ihnen, bevor ich baue, und wir legen fest, wann sie fertig ist.“

Die ausführliche Antwort: Oft wünschen sich Menschen jede Zahl, die ihnen einfällt; die Skizze hilft ihnen bei der Auswahl. Prüf, ob ein bestehender Bericht die Frage schon beantwortet. Schreib die Anforderung auf einer kurzen Seite auf, die beide Seiten freigeben, damit spätere Änderungen als Änderungen sichtbar sind.

Schwache Antwort: „Ich baue, was sie wollen, und ändere es später.“ Nachfrage: „Zwei Führungskräfte wollen auf derselben Seite Verschiedenes.“ Erkläre, wie du entscheiden oder die Seite aufteilen würdest.

Wie definierst du eine KPI so, dass alle sie gleich lesen?

Worauf sie achten: genaue Definitionen mit einem Verantwortlichen, aufgeschrieben, wo Menschen sie sehen.

Kurze Antwort: „Eine KPI braucht einen Namen, eine Formel in einfachen Worten, die Daten, aus denen sie kommt, was dazugehört und was nicht, die Zeitbasis, das Ziel und einen Verantwortlichen, der über Änderungen entscheidet. Das schreibe ich neben die Zahl im Bericht und in ein gemeinsames Glossar, damit Dashboard und Meeting eine einzige Quelle der Wahrheit nutzen.“

Die ausführliche Antwort: Die meisten Streitfälle kommen von kleinen Unterschieden: brutto oder netto, Bestelldatum oder Rechnungsdatum, mit oder ohne Retouren. Zeig die Definition beim Darüberfahren mit der Maus oder in einer kurzen Notiz. Werden beide Definitionen gebraucht, gib ihnen zwei Namen.

Schwache Antwort: „Umsatz ist Umsatz.“ Nachfrage: „Vertrieb und Finanzen zeigen für März verschiedene Umsätze.“ Erkläre, wie du den Unterschied finden würdest.

Entwirf das Datenmodell für einen Vertriebsbericht. Was gehört in die Fakten- und Dimensionstabellen des Sternschemas?

Worauf sie achten: dimensionale Modellierung mit klarer Granularität.

Kurze Antwort: „Ein Sternschema hat eine Faktentabelle mit einer Granularität, hier eine Zeile pro Rechnungsposition, mit den Zahlen, die man aufsummiert, etwa Menge und Betrag. Darum liegen Dimensionstabellen mit allem, wonach man filtert und gruppiert: Datum, Kunde, Produkt, Region, Vertriebsmitarbeiter. Jede Dimensionstabelle hängt über einen Schlüssel an der Faktentabelle.“

Die ausführliche Antwort: Ein Stern hält das Modell in jedem BI-Tool einfach und schnell. Verknüpfe keine Fakten mit Fakten und vermeide Viele-zu-viele-Beziehungen, solange sie nicht verstanden sind. Eine gemeinsame Datumstabelle lässt jeden Bericht Zeiträume auf dieselbe Weise vergleichen. Zählt die Historie, etwa die Region eines Kunden im letzten Jahr, muss die Dimension sie behalten.

Schwache Antwort: „Ich importiere alle Quelltabellen und verbinde sie, wie sie kommen.“ Nachfrage: „Die Ziele sind monatlich, die Umsätze täglich.“ Erkläre, wie zwei Granularitäten in einem Modell leben.

Was ist ein Measure, und wie hältst du Measures richtig und wiederverwendbar?

Worauf sie achten: Berechnungen im Modell, getestet, benannt und geteilt.

Kurze Antwort: „Ein Measure ist eine Berechnung, die das BI-Tool im Moment des Ansehens ausrechnet, für die gerade gesetzten Filter, etwa der Gesamtumsatz oder die Marge in Prozent. Ich definiere jedes Measure einmal im Modell, in Power BI in DAX oder in der Berechnungssprache des jeweiligen Tools, mit klarem Namen und Beschreibung, und teste es gegen Zahlen aus der Quelle.“

Die ausführliche Antwort: Measures, die in jeden Bericht kopiert werden, laufen auseinander. Halte die Basis-Measures einfach und baue die anderen daraus. Achte auf Summen und Quoten, denn dort verstecken sich die Fehler: Ein Durchschnitt von Durchschnitten ist kein Durchschnitt. Schreib die Testfälle auf, damit sich eine Änderung prüfen lässt.

Schwache Antwort: „Jeder Bericht hat seine eigenen Berechnungen.“ Nachfrage: „Die Summenzeile passt nicht zur Summe der Zeilen.“ Erkläre, warum das richtig oder falsch sein kann.

ETL, Aktualisierung, Performance und Sicherheit

Wo sollte eine Transformation passieren: im ETL, im Warehouse oder im BI-Tool?

Worauf sie achten: dass du Logik dorthin legst, wo sie geteilt, getestet und gepflegt werden kann.

Kurze Antwort: „So weit vorn in der Datenkette, wie es sinnvoll ist: Bereinigung und Geschäftsregeln, die viele Berichte brauchen, gehören ins ETL oder ins Warehouse, oft als versionierte Modelle in einem Tool wie dbt. Das BI-Tool übernimmt, was nur einen Bericht betrifft, und die Measures, die von Filtern abhängen.“

Die ausführliche Antwort: Logik, die in einem Bericht versteckt ist, lässt sich weder wiederverwenden noch prüfen, und jeder andere Bericht kopiert sie ein wenig anders. Alles vorne in der Kette zu machen, kann kleine Änderungen langsam machen; vereinbare deshalb mit den Data Engineers, wem was gehört und wie schnell sie reagieren können.

Schwache Antwort: „Ich mache alles im BI-Tool, das geht schneller.“ Nachfrage: „Drei Berichte bereinigen Kundennamen auf drei verschiedene Arten.“ Erkläre, wohin du diese Logik verschieben würdest.

Wie richtest du die Aktualisierung eines großen Datasets ein, auch inkrementell?

Worauf sie achten: Aktualisierungen, die schnell, verlässlich und überwacht sind.

Kurze Antwort: „Ich plane die Aktualisierung nach dem Ende der Warehouse-Ladung und nutze für große Tabellen die inkrementelle Aktualisierung, die nur den jüngsten Zeitraum neu lädt und ältere Daten behält. Fehler lösen einen Alarm beim Verantwortlichen aus, und der Bericht zeigt, wann die Daten zuletzt aktualisiert wurden.“

Die ausführliche Antwort: Die inkrementelle Aktualisierung braucht eine verlässliche Datumsspalte und eine Regel für späte Änderungen an alten Daten. Aktualisiere nicht öfter, als sich die Quelle ändert. Brauchst du fast Echtzeit, passt eine direkte Verbindung zur Quelle vielleicht besser, auf Kosten der Geschwindigkeit.

Schwache Antwort: „Wir laden jede Stunde alles neu.“ Nachfrage: „Die Aktualisierung ist fehlgeschlagen, und zwei Tage lang hat es niemand gemerkt.“ Erkläre, wie du das beim nächsten Mal abfangen würdest.

Ein Bericht ist langsam. Wie findest und behebst du die Ursache der schlechten Performance?

Worauf sie achten: eine Methode, die mit Messen beginnt, nicht mit Raten.

Kurze Antwort: „Zuerst messe ich: welche Seite, welches Visual, welche Abfrage die Zeit braucht. Häufige Ursachen sind ein Modell, das kein Stern ist, zu viele geladene Spalten oder Zeilen, komplizierte Measures, zu viele Visuals auf einer Seite oder eine langsame direkte Verbindung. Ich behebe die größte Ursache, messe noch einmal und höre auf, wenn die Anwender zufrieden sind.“

Die ausführliche Antwort: Jedes Tool hat einen Weg, Abfragezeiten zu zeigen; nutze ihn. Entferne Spalten, die niemand nutzt, verdichte Daten, die der Bericht nie im Detail zeigt, und vereinfache die Measures hinter langsamen Visuals. Manchmal liegt die Lösung im Warehouse: eine aggregierte Tabelle oder ein Index.

Schwache Antwort: „Eine größere Lizenz kaufen.“ Nachfrage: „Die Seite ist für dich schnell, für Anwender im Ausland aber langsam.“ Sprich über Gateways, Regionen und Verbindungen.

Wie richtest du Row-Level Security ein, damit jede Person nur ihre Daten sieht?

Worauf sie achten: Zugriffsregeln im Modell, getestet und im Einklang mit dem Benutzerverzeichnis.

Kurze Antwort: „Row-Level Security filtert die Daten danach, wer hinschaut: Eine Regionalleiterin sieht nur ihre Region. Ich definiere Rollen im Modell, ordne ihnen Benutzer oder Gruppen aus dem Verzeichnis der Firma zu, teste jede Rolle und vermeide getrennte Kopien des Berichts für jede Gruppe.“

Die ausführliche Antwort: Stütze die Regeln auf Gruppen, die das Personal- oder das Identity-Team aktuell hält, nicht auf Listen, die jemand von Hand pflegt. Denk daran, dass Exporte und Abonnements dieselben Regeln einhalten müssen. Personenbezogene Daten in Berichten, etwa Namen und Gehälter, brauchen die strengsten Regeln, und in der EU gilt für sie die DSGVO.

Schwache Antwort: „Wir machen eine Kopie des Berichts pro Region.“ Nachfrage: „Eine Führungskraft wechselt die Region.“ Erkläre, wie ihr Zugriff mitwandert.

Semantische Modelle, Dashboards, Qualität und Versionen

Wie baust du ein semantisches Modell, das Self-Service ohne Chaos möglich macht?

Worauf sie achten: gemeinsame Definitionen, mit denen Anwender sicher eigene Berichte bauen.

Kurze Antwort: „Ein semantisches Modell ist die gemeinsame Schicht aus Tabellen, Beziehungen, Measures und Namen, auf der Berichte gebaut werden. Ich baue eines pro Geschäftsbereich, mit fachlichen Namen und Beschreibungen, und lasse geschulte Anwender ihre eigenen Berichte darauf bauen. Self-Service heißt dann Freiheit bei den Seiten, nicht bei den Definitionen.“

Die ausführliche Antwort: Ohne gemeinsames Modell erzeugt Self-Service Hunderte von Berichten mit verschiedenen Antworten. Biete Schulungen und ein paar Vorlagen an, beobachte, welche Berichte beliebt werden, und gib den wichtigen einen festen Verantwortlichen.

Schwache Antwort: „Jeder kann sich mit der Datenbank verbinden und bauen, was er will.“ Nachfrage: „Der Bericht eines Anwenders zeigt eine andere Marge.“ Erkläre, wie du das zurückverfolgen würdest.

Wie entwirfst du ein Dashboard, das man in wenigen Sekunden lesen kann?

Worauf sie achten: visuelle Entscheidungen, getroffen für den Leser.

Kurze Antwort: „Eine Seite beantwortet eine Frage. Die wichtigsten Zahlen stehen oben links, mit dem Vergleich zum Ziel oder zur Vorperiode. Ich wähle das Diagramm nach dem Vergleich: Linien für Zeitverläufe, Balken für Kategorien, Tabellen, wenn Menschen genaue Zahlen brauchen. Farbe markiert, was Aufmerksamkeit braucht, und ist keine Dekoration.“

Die ausführliche Antwort: Lass die Achsen bei Balken bei null beginnen, beschrifte Einheiten und vermeide Kreisdiagramme mit vielen Stücken. Denk an Farbenblindheit und an Handys. Teste die Seite mit einem echten Anwender: Frag ihn, was sie ihm sagt, und ändere, was er falsch liest.

Schwache Antwort: „Ich bringe so viele Diagramme wie möglich auf die Seite.“ Nachfrage: „Der CEO will alles auf einer Seite.“ Erkläre, wie du dich darauf einigen würdest, was zuerst kommt.

Wie prüfst du die Datenqualität, bevor ein Bericht rausgeht?

Worauf sie achten: Prüfungen, die Fehler finden, bevor es die Anwender tun.

Kurze Antwort: „Ich gleiche wichtige Summen mit dem Quellsystem ab, prüfe auf fehlende Tage, Duplikate und Schlüssel ohne Treffer und vergleiche mit der Vorperiode auf Sprünge, die eine Erklärung brauchen. Die Prüfungen laufen bei jeder Aktualisierung, und der Bericht zeigt eine Warnung, wenn eine fehlschlägt.“

Die ausführliche Antwort: Behebe Fehler wo möglich an der Quelle und sag es dem Verantwortlichen. Schreib bekannte Datenprobleme neben den Bericht, damit Anwender sie nicht erst in einem Meeting entdecken. Ein kurzer Abgleich mit der Finanzabteilung jeden Monat schafft schnell Vertrauen.

Schwache Antwort: „Die Anwender sagen uns schon, wenn etwas falsch ist.“ Nachfrage: „Die Umsätze von gestern fehlen für ein Land.“ Erkläre, was du zuerst prüfen würdest.

Wie verwaltest du Versionen und Änderungen von Berichten und Modellen?

Worauf sie achten: kontrollierte Änderungen, mit Historie und einem Weg zurück.

Kurze Antwort: „Ich halte Modelle und Berichte unter Versionskontrolle, wo das Tool es zulässt, arbeite in einem Entwicklungs-Workspace, teste und veröffentliche dann über einen festen Ablauf in die Produktion. Änderungen an gemeinsamen Measures werden angekündigt, und jedes Release hält fest, was sich geändert hat.“

Die ausführliche Antwort: Viele BI-Tools speichern Berichte heute in Formaten, die eine Versionskontrolle lesen kann; das macht Reviews und Rollbacks möglich. Trenne Entwicklung, Test und Produktion. Berichte, die in den Jahresabschluss einfließen, brauchen unter Umständen Freigaben, die Wirtschaftsprüfer kontrollieren.

Schwache Antwort: „Ich ändere den Live-Bericht direkt.“ Nachfrage: „Eine Änderung hat den Bericht für die Geschäftsleitung eine Stunde vor der Sitzung kaputt gemacht.“ Erkläre, wie du zurückrollen würdest.

Governance, Wahl der Tools und die Senior-Stufen

Wie führst du BI-Governance: Workspaces, zertifizierte Datasets und Verantwortung?

Worauf sie achten: Ordnung, die Anwendern hilft, vertrauenswürdige Berichte zu finden.

Kurze Antwort: „Ich richte Workspaces nach Bereichen mit benannten Verantwortlichen ein, markiere die geprüften gemeinsamen Datasets als zertifiziert oder empfohlen und führe eine Liste der Berichte mit ihrem Verantwortlichen und ihren Anwendern. Berichte, die niemand öffnet, werden archiviert. Zugriffe folgen Gruppen, nicht einzelnen Personen.“

Die ausführliche Antwort: Governance in BI dreht sich vor allem um Vertrauen und ums Finden: Welcher Bericht ist der offizielle? Halte die Regeln kurz und den Ablauf schnell, sonst bauen die Leute daran vorbei. Prüf die Nutzung regelmäßig und räum auf.

Schwache Antwort: „Jeder veröffentlicht, wo er will.“ Nachfrage: „Es gibt fünf Vertriebs-Dashboards, und niemand weiß, welches stimmt.“ Erkläre, wie du das klären würdest.

Wie würdest du Power BI, Tableau, Looker und Qlik für eine Firma vergleichen, ohne eines zu bevorzugen?

Worauf sie achten: ein fairer Vergleich nach den Bedürfnissen und Kosten der Firma.

Kurze Antwort: „Ich schreibe die Bedürfnisse auf: Datenquellen, Zahl und Art der Anwender, die Cloud und Office-Software, die schon im Einsatz sind, Sicherheit, Self-Service, Einbettung und Budget. Dann baut jedes Tool zwei echte Berichte, und wir vergleichen Geschwindigkeit, Einfachheit für die Anwender und die vollen Kosten für Lizenzen und Betrieb.“

Die ausführliche Antwort: Power BI passt natürlich dorthin, wo Microsoft-Tools genutzt werden, Looker, wo die Daten in BigQuery liegen und eine starke semantische Schicht gewünscht ist, Tableau und Qlik, wo die Analyse über viele Quellen hinweg zählt; jedes kann die meisten Aufgaben. Die Migration vom heutigen Tool ist ein großer Kostenblock für sich, also rechne sie mit.

Schwache Antwort: „Ich würde das Tool nehmen, das ich kenne.“ Nachfrage: „Die Finanzabteilung zahlt über einen anderen Vertrag schon für ein Tool.“ Erkläre, wie das den Vergleich verändert.

Wie setzt du als Lead-BI-Entwickler oder Analytics Manager Prioritäten zwischen Fachbereichen?

Worauf sie achten: ein fairer, sichtbarer Weg, Stakeholdern Ja und Nein zu sagen.

Kurze Antwort: „Ich führe eine sichtbare Liste der Anfragen, vereinbare mit dem Management wenige Kriterien, etwa Nutzen, Aufwand und Risiko, und gehe die Liste regelmäßig mit den Bereichsleitungen durch. Für dringende Arbeit gibt es eine klare Regel. Alle sehen, warum ihre Anfrage dort steht, wo sie steht.“

Die ausführliche Antwort: Auf der Stufe von Senior- und Lead-BI-Entwickler besteht viel Arbeit darin, die Modelle anderer zu prüfen und Standards zu setzen; als Analytics Manager sind es das Team, die Prioritäten und das Budget für Tools. Rechne mit einem Fall, in dem Finanzen und Vertrieb das Team beide im selben Monat brauchen.

Schwache Antwort: „Wer am lautesten ruft, kommt zuerst dran.“ Nachfrage: „Die Assistenz des CEO will heute einen neuen Bericht.“ Erkläre, wie das zu den Regeln passt.

Dein Lebenslauf für diese Fragen

Jeder Bericht in deinem Lebenslauf lädt zu den Fragen oben ein: welcher Entscheidung er diente, wie er modelliert war, wie schnell er war und wer ihm vertraut hat. Schreib jeden Bericht als eine Zeile unter den Job, in dem du ihn gebaut hast, und lass den Interviewer wählen, über welchen er hören will:

Bewerte deinen Lebenslauf zuerst an dem Job als BI-Entwickler, den du willst: Jeder fehlende Skill, den die Prüfung nennt, ist eine wahrscheinliche Frage und eine Geschichte über einen Bericht, die du bereithalten solltest.