Der beste Power-BI-Test für die Einstellung von Data Analysts
Warum die meisten Power-BI-Tests die echte Arbeit verfehlen
Viele Power-BI-Tests sind Dashboard-Bauwettrennen. Bau ein Dashboard. Drei Visualisierungen. Fertig in 45 Minuten. So arbeiten Analysts aber nicht.
Echte Power-BI-Arbeit ist:
- Unsaubere Quelldaten verstehen und entscheiden, was bereinigt wird
- Zwischen berechneten Spalten, Measures und DAX-Logik wählen
- Dashboards für konkrete Zielgruppen designen (Execs wollen KPIs, Operations Drilldowns, Finance Audit-Spuren)
- Performance tunen, wenn ein Report 100k Zeilen erreicht
- Erkennen, wann Power BI overkill ist und Excel oder SQL schneller wären
Ein guter Test bewertet diese Dimensionen, nicht nur „kannst du Visualisierungs-Buttons klicken".
Screening-Stufe: Kann sie modellieren?
Starte mit einem 30-Minuten-Szenario. Schicke einen unsauberen CSV-Export:
- Daten in Power BI laden
- Offensichtliche Datenqualitätsprobleme identifizieren
- Zwei Spalten bereinigen (mit echten Problemen)
- Drei Measures erstellen (Gesamtumsatz, Durchschnittsdeal, Monatswachstum)
- Erklären, warum Measure statt berechneter Spalte für eine davon
Bewertet:
- Konzeptverständnis von Faktentabellen, Dimensionen, Star Schema
- Datenqualitätsbewusstsein
- DAX-Basics (SUM, DIVIDE, sichere Division)
- Urteil zu Measure vs. berechneter Spalte (Schlüsselunterschied junior vs. mid-level)
Bewertung:
- Daten geladen und bereinigt: pass/fail
- Measures korrekt: ja/nein
- Erklärung Spalte vs. Measure: oberflächlich vs. nuanciert
Filtert, wer nie ein Datenmodell gebaut hat.
Take-home: echtes Dashboard-Design
Wer das Screening besteht, bekommt 2–3 Stunden:
„Du hast einen CSV mit 6 Monaten Transaktionsdaten: Datum, Kunden-ID, Produktkategorie, Betrag, Region, Kundensegment (neu/wiederkehrend).
Bau ein Power-BI-Dashboard, das beantwortet:
- Gesamterlös und Kundenzahl pro Region
- Wie sich Neue vs. Wiederkehrende im Durchschnittsausgaben vergleichen
- Welche Kategorien Monat-zu-Monat zulegen
- Für eine gegebene Kunden-ID (Eingabe) die volle Transaktionshistorie und LTV.
Designe für eine VP Sales. Sie schaut täglich rein. Eine Seite. Mach es actionable."
Bewertet:
- Datenmodellierung: strukturiert sie für effiziente Queries?
- Visualisierungsauswahl: passender Charttyp? (Umsatz nach Region = Balken/Karte, nicht Line)
- Zielgruppenbewusstsein: überladen oder fokussiert?
- Interaktivität: sinnvolle Slicer und Drill-through, oder nur Lärm?
- Performance-Bewusstsein: versteht sie, was Power-BI-Modelle lahm macht?
Abgabe:
- Power-BI-Datei (.pbix)
- 1-Seiten-Designdokument: „Warum diese Visuals, wie eine VP es nutzen würde, was mit den aktuellen Daten fehlt."
Trennt Report-Bauerinnen von Analystinnen, die in Wirkung denken.
Bewertungsgespräch: 30 Minuten
Bring das Dashboard in einen Videocall. Frage:
- „Erkläre dein Datenmodell. Warum so strukturiert?" Erwarte Sprache von Fakten/Dimensionen oder „ich hab Transaktionen reingelegt und Regionen gemappt." Beides zeigt das mentale Modell.
- „Wie performt das mit 2 Jahren statt 6 Monaten? Was bricht?" Trennt Produktions-Erfahrung von Prototyperfahrung.
- „Eine VP fragt nach Kundenprofitabilität (Erlös minus Kosten pro Kunde). Wie fügst du das hinzu?" Testet, ob sie es in die Source schiebt (falsch), als Measure (besser) oder Edge Cases bedenkt (am besten).
- „Was kann dieses Dashboard nicht sagen?" Erkennt sie Grenzen der Transaktionsdaten?
- „Hast du Power BI schon in Produktion genutzt?" Ehrliche Selbsteinschätzung zählt.
Was prüfen vs. weglassen
Prüfen (differenzieren):
- Modellierungsbasics
- DAX-Urteilsvermögen (Measures vs. berechnete Spalten, Division durch Null)
- Visuelles Design für Zielgruppe (nicht hübsch, sondern funktional)
- Performance-Intuition
- Datenqualitätsdenken
Weglassen:
- Obskure DAX-Funktionen. Analystinnen nutzen SUM, DIVIDE, DISTINCTCOUNT, RELATED — das sind 95 %.
- Formatierung und Farben. Subjektiv, geringes Signal.
- Admin-Features. Row-Level-Security, Pipelines, Gateways — Infrastruktur, nicht Analyst-Skill.
- SQL oder DWH. Außer wenn Rolle ETL umfasst.
Häufige Fehler
1: keine Datenqualitätsprobleme im Test. Echte Daten sind unsauber. Inkonsistente Datumsformate, fehlende Werte, Duplikate, Whitespace.
2: Zeit zur Fertigstellung messen. „In 1 Stunde gemacht, ist schnell" — vielleicht aus einem Tutorial. Qualität zählt.
3: zu viel Freiheit. „Bau, was du willst." Gib Zielgruppe und konkrete Fragen.
4: Tableau/Looker-Syntax statt analytischen Denkens prüfen. Wenn dir Power BI wichtig ist, teste Power BI. Aber das meiste Skill ist analytisches Denken, nicht tool-spezifische Syntax.
Pro Rolle
Business Analyst
Fokus auf Dashboard-Design für nicht-technische Stakeholder. Trends einfach erklären?
Data Analyst / Analytics Engineer
Modellierung tief testen. Rigor in DAX. Aggregation-Scope vs. Filter-Kontext zu unterscheiden trennt junior von erfahren.
Analytics Manager
Dashboard-Strategie. Bei einer Geschäftsfrage: wie würde sie die Analytics strukturieren? Wann würde sie sagen „das gehört nicht in Power BI"?
Integration in deinen Hiring-Prozess
Power-BI-Bewertung passt in eine breitere Software-Skills-Strategie:
- Screening (30 min): Modellierung + Measures. Pass/fail.
- Take-home (2–3 h): echtes Dashboard. Wer besteht, geht zum Interview.
- Gespräch (30 min): Reasoning über die Arbeit, Performance-Bewusstsein, ehrliche Selbsteinschätzung.
- Verhaltensrunde (30–45 min): echte Projekte. Mehrdeutige Anforderungen? Was lief schief?
Zusammen prüfen sie Fähigkeit und Urteilsvermögen.
Meta-Bewertung: Werkzeugwahl
Eine starke Analystin könnte sagen: „Ich hab Tableau und Looker genutzt, aber ich lerne neue Tools schnell. Mein Skill ist Datendenken, nicht Tool-Syntax."
Stimmt. Teste das Denken. Das Tool ist Implementierung.
Aber wenn der Job Power BI verlangt (weil dein Team es nutzt oder Kunden es fordern), teste es. Passe die Bewertung an den realen Job an.
Ein Dashboard-Test, der echtes analytisches Denken misst — Datenqualitätsbewusstsein, Zielgruppen-Design, Performance-Intuition — schlägt jedes Mal ein Formatierungs-Wettrennen.