Measure the slow interaction before rewriting a Power BI report. A slow visual can involve the semantic query, a DirectQuery source, rendering or other work. The right change depends on which part is actually slow.

This Power BI interview exercise uses a fictional report with one noticeably slow region chart. It contains no measured timings. The goal is to design a comparison that could produce reliable evidence.

How do you establish a baseline?

  1. Record the report page, filter selection and interaction.
  2. Use Performance Analyzer to capture the relevant visual activity.
  3. Repeat under comparable conditions.
  4. Record which visual and categories account for the time.
  5. Keep a copy of the results before changing anything.

A single warm-cache run and a single cold-cache run are not a fair before-and-after comparison. Service capacity, network conditions and other users can also affect observations. State those conditions when reporting results.

What does a slow DAX query suggest?

Inspect the measure and model grain. An iterator over a large or unnecessary intermediate table can do more work than the question requires. Relationships and filter propagation can also make an apparently simple expression expensive.

Do not change a measure solely because it contains CALCULATE or an iterator. Those functions are legitimate tools. First understand the requested result and identify the expensive expression with appropriate evidence.

What if the source query is slow?

For DirectQuery, investigate the source-side query, filtering and data access path. A report-only rewrite may not fix a source bottleneck. Coordinate with the source owner using the actual query and authorized diagnostic tools.

Do not add indexes or change production data structures based only on an interview hypothesis. Compare plans, workload and write costs in the relevant engineering process. A small teaching fixture cannot establish production performance.

What if rendering dominates?

Reduce unnecessary visual density and inspect custom visual behavior. A page with many visuals can do more work for one interaction than a focused page. Test whether a clearer layout also reduces the measured work.

Keep accessibility and useful information intact. Removing essential labels to shave time would be a poor trade. Evaluate the report as a tool for its reader, not just as a timing number.

How do you protect correctness?

Use a small known dataset and compare values under representative filters. Check totals, blank cases, multi-selection and row-level security where applicable. A rewritten denominator can be faster while answering a different question.

Comparison record for the fictional chart:
Interaction: select one region
Expected values: checked against known fixture
Baseline evidence: captured before change
Change: one documented model, measure or visual change
After evidence: same interaction and comparable conditions
Regression checks: totals, filters, permitted rows

What should the final explanation say?

  • What the user observed.
  • Which part was measured as slow.
  • What changed and why that part should improve.
  • Whether output values remained equivalent.
  • What the measurements actually showed.
  • Which environment checks remain outside the test.

For practice, take one real report you are allowed to inspect and fill in that record. Do not invent percentage improvements. A careful diagnosis with an honest limitation is more convincing than a dramatic number without evidence.

References and next practice

learn.microsoft.com — bi performance · learn.microsoft.com — bi dax

Browse interview topics · Practise a question in Interview Challenge · How to Answer Technical Interview Questions Out Loud