Power BI interview questions — where "I built a dashboard" gets tested for depth
Almost every analyst can build a dashboard. Power BI interviews are designed to check whether you understand the data model underneath it — because that's what breaks first at scale.
Power BI is easy to pick up and deceptively easy to interview badly for — you can build a working dashboard by dragging fields onto a canvas without ever touching the data model directly. The interview questions that matter are the ones that check whether you understand what's happening underneath the drag-and-drop, because that's exactly where dashboards start breaking as data grows.
Data modeling — star schema vs. one giant flat table
What gets recited: Power BI works better with a star schema — fact tables connected to dimension tables — than with one wide, flattened table.
What actually gets tested: "Why, specifically?" The honest answer covers more than one reason: a star schema reduces data duplication and file size, makes relationships between tables explicit (so filters propagate correctly), and plays to how Power BI's engine, VertiPaq, actually compresses and queries data — a single denormalized table with repeated text values compresses far worse than normalized dimension tables. A candidate who can only say "it's best practice" without explaining what actually breaks in a flat table (bloated model size, ambiguous filter behavior, slower refreshes) hasn't actually hit that wall yet.
DAX — the question that separates "wrote a formula" from "understands evaluation context"
DAX confuses people specifically because it looks like Excel formulas but behaves completely differently — it's built around row context and filter context, and most DAX bugs come from not knowing which one you're in. A strong interview signal is being able to explain the difference between CALCULATE changing filter context versus a measure just evaluating in whatever context it's placed, and why the same-looking measure can return different numbers depending on which visual or table it's used in. The classic follow-up — "why does this measure return the wrong total when I add it to a table with a different grouping" — is really asking whether you understand context transition, not whether you memorized DAX syntax.
Relationships — cardinality and cross-filter direction, not just "connect the tables"
Everyone can drag a line between two tables. The interview-worthy question is "when would you use a bidirectional relationship, and what's the risk?" The honest answer: bidirectional filtering lets a filter on either table affect the other, which is sometimes necessary (many-to-many scenarios) but can also introduce ambiguous filter paths and circular logic that silently produce wrong numbers — which is why single-direction relationships are the safer default, and bidirectional should be a deliberate choice, not something enabled everywhere out of convenience.
Performance — what actually slows a report down
"Your report takes 30 seconds to load, what do you check?" is a strong practical question because the answer requires knowing where Power BI performance problems actually come from: too many visuals on one page each firing separate queries, DAX measures using row-by-row iterators (SUMX, FILTER) over large tables instead of simpler aggregations, an oversized data model with unnecessary columns imported, or Direct Query mode hitting a slow underlying source instead of Import mode's in-memory speed. A strong answer diagnoses before prescribing — checking Performance Analyzer first, not guessing.
Power Query vs. DAX — knowing which layer should do the work
A subtle but real interview question: "should this transformation happen in Power Query or in a DAX measure?" The useful principle: Power Query (M) transforms and shapes data before it loads into the model — better for anything that should happen once, at refresh time, like cleaning column types or unpivoting a table. DAX calculates dynamically at query time, in response to filters and user interaction — appropriate for anything that needs to change based on what the user is looking at. Doing a static transformation in DAX, or trying to make Power Query respond dynamically to slicers, is a common sign of not understanding which layer owns which job.
If you want to practice explaining data-modeling and DAX tradeoffs out loud, with real follow-ups when an answer stays surface-level, try role-specific mock interviews for Data or Business Analyst — free to start.