Power BI interview questions
Power BI questions a Data analyst / BI can be asked, from first job to senior. Open one to see the strongest answer and why it works.
In Power BI, when do you write a measure and when do you add a calculated column?
The strongest answer: A column is computed row by row at refresh and stored, so use it for something you slice or group by; a measure is computed at query time in the current filter context, so totals and ratios are measures
Why it works: Right — where and when it is evaluated is the whole distinction, and it decides whether the value can react to a slicer.
- Column: per row, at refresh.
- Measure: at query time, in context.
- Slice by columns, aggregate with measures.
- Columns cost model memory.
A Power BI number changes when a slicer is clicked, and the PM thinks the model is broken. What do you explain?
The strongest answer: Filter context — the measure is computed in the filters that are on; I will show which filters are active instead of “fixing” it to be static
Why it works: Exactly. Context is the product. Hard-coding is how you freeze a lie.
- Show active filters.
- Measures live in context.
- Do not hard-code to “fix.”
- Slicers are real filters.
A column needs splitting, the types need fixing and two sources need merging. Power Query or DAX?
The strongest answer: Power Query — shaping belongs as far upstream as it can go, it runs once at refresh, and it can often be folded back into the source as SQL; DAX calculates over the model that arrives
Why it works: Exactly — upstream first: the warehouse where you can, then Power Query, then DAX. Folding keeps the work on the source.
- Shape upstream, calculate downstream.
- Warehouse, then Power Query, then DAX.
- Query folding pushes work to the source.
- Refresh-time beats query-time for shaping.
A year-on-year measure in Power BI comes back blank for some months and wrong for others.
What do you check first?
The strongest answer: The date table — time intelligence needs a dedicated date dimension with one row per day, no gaps, whole years, marked as the date table and related to the fact
Why it works: Right — those functions walk a contiguous calendar, so gaps and part-years are exactly what makes them blank or wrong.
- One date dimension per model.
- Contiguous days, whole years.
- Mark it as the date table.
- Relate it to every fact.
How do you write a percent-of-total measure in DAX, and what changes when the user has a slicer on?
The strongest answer: Divide the measure in the current filter context by itself with the category filter removed — CALCULATE with ALL for the grand total, ALLSELECTED to respect the slicer — and DIVIDE so an empty denominator is safe
Why it works: Exactly — the question is always which filters the denominator keeps. ALL ignores the slicer; ALLSELECTED honours it.
- Choose what the denominator keeps.
- CALCULATE plus ALL: grand total.
- ALLSELECTED: respects the slicer.
- DIVIDE handles the empty denominator.
An analyst has loaded one wide table with every column into Power BI, and the report is already slow and awkward to slice.
What do you change, and why that shape?
The strongest answer: Split it into a star — a fact table of events with dimensions around it and filters flowing from the one side to the many — because that is the shape the engine and DAX expect, and the repeated text leaves the fact
Why it works: Right — single-direction relationships from dimensions to the fact keep the measures simple and the model small.
- One fact, many dimensions.
- Filters flow one to many.
- Single-direction relationships by default.
- Flat tables repeat and bloat.
Each regional manager must see only their own region in one Power BI report. How do you set that up, and how do you prove it works?
The strongest answer: A role with a DAX filter on the region dimension, matched to the signed-in user through USERPRINCIPALNAME and a mapping table, assigned to a group in the service, and tested with View as role
Why it works: Exactly — filter in the model, assign in the service, verify by viewing as the role. Note that people who can edit the model are not filtered by it.
- Filter in the model, assign in the service.
- Map the signed-in user dynamically.
- Test with View as role.
- Model editors are not filtered.
To make one slicer filter across two fact tables, a developer switched several relationships to filter in both directions.
What is your concern?
The strongest answer: Ambiguity — two open directions give the engine more than one filter path, so measures start returning numbers nobody can explain, and row-level security can leak unless the security filter is applied both ways
Why it works: Right — single direction by default, and CROSSFILTER inside the one measure that genuinely needs the other way.
- Single direction by default.
- Two directions make ambiguous paths.
- Use CROSSFILTER in the one measure.
- Check what it does to security.
You inherit a workspace with two hundred reports, most importing their own copy of the same tables, and nobody knows which ones are used.
What are your first moves?
The strongest answer: Measure before cutting — start with usage, consolidate the common tables into a few shared, endorsed models that reports connect to, give each an owner and a refresh schedule, then retire the rest with notice
Why it works: Right — usage data makes the retirement conversation short, and a shared model is what stops the copies coming back.
- Start with usage, not opinions.
- Consolidate onto shared models.
- Give every model an owner.
- Retire with notice, not silently.