5 exercises — choose the best-structured answer to BI Developer interview questions covering Power BI, DAX, data modelling, and report performance.
Structure for BI Developer interview answers
Name the specific tool or pattern (VertiPaq, star schema, DAX Studio) — don't stay generic
Explain the mechanism — why does the technology behave this way?
State the trade-off — every architecture decision has a cost; name it
Give a decision rule — under what conditions do you choose option A vs option B?
0 / 5 completed
1 / 5
The interviewer asks: "Explain the difference between a star schema and a snowflake schema in a BI data model and when you would choose each." Which answer best demonstrates data modelling expertise?
Option B is the strongest because it names the specific technical mechanisms (VertiPaq columnstore, Hyper engine, single-hop query path), explains why the storage advantage of snowflaking disappears in columnar BI engines, and gives a precise rule for when to actually snowflake (shared high-cardinality sub-dimensions). Option A is vague and only states preference without reasoning. Option C is superficial. Option D confuses the cloud database vendor with the schema pattern. Structure: define both → explain trade-offs → name engine behaviour → state decision criteria.
2 / 5
The interviewer asks: "How do you optimise a slow Power BI report that takes 30 seconds to load?" Which answer best demonstrates performance-tuning expertise?
Option B is the strongest because it names specific tools (Performance Analyzer, DAX Studio), identifies the three distinct layers where slowness originates (DAX, model, visual), gives concrete examples of each anti-pattern (context transition in CALCULATE loops, SUMX on large tables, cross-filtering chains), and provides a prioritisation heuristic. Option A is vague and only restates the problem. Option C is incorrect — DirectQuery typically makes reports slower for analytical queries. Option D externalises the problem without diagnosing it. Structure: diagnose layer → name tools → list root causes per layer → prioritise.
3 / 5
The interviewer asks: "What is DAX context transition and why does it matter for calculated measures?" Which answer best demonstrates DAX expertise?
Option B is the strongest because it gives the precise technical definition (row context → equivalent filter context via CALCULATE or implicit measure reference), explains the two concrete consequences (performance expansion, relationship propagation), and provides actionable mitigation strategies (DAX Studio isolation, KEEPFILTERS, SUMMARIZECOLUMNS). Option A is partially correct but has no depth or practical implication. Option C completely misdefines the term. Option D is inaccurate. Structure: define mechanism → explain consequences → provide mitigation patterns.
4 / 5
The interviewer asks: "How do you design a data model for a report that needs to show both actual and budget figures side by side?" Which answer best demonstrates advanced modelling thinking?
Option B is the strongest because it identifies the core problem (grain mismatch), explains why naively unioning the tables breaks aggregations, names the specific pattern (two fact tables with shared dimensions), addresses the date granularity difference, and provides the SELECTEDVALUE pattern for scenario switching. Option A only suggests slicers without addressing the model design problem. Option C describes a union approach that ignores grain differences. Option D is an operational workaround, not an architectural answer. Structure: identify grain mismatch → separate fact tables → shared dimensions → DAX measure design → scenario switching pattern.
5 / 5
The interviewer asks: "What are the key differences between DirectQuery and Import mode in Power BI, and how do you decide which to use?" Which answer best demonstrates architectural decision-making?
Option B is the strongest because it explains the underlying engine (VertiPaq in-memory vs native SQL pass-through), quantifies the refresh frequency limits (8×/day Premium, hourly Pro), gives a concrete decision framework with named examples (trading dashboards), identifies the operational risk of DirectQuery on unoptimised sources (production DB load), and introduces composite models as an advanced hybrid solution. Option A is partially correct but entirely superficial. Option C oversimplifies to dataset size alone. Option D is factually false. Structure: explain engine differences → quantify constraints → decision criteria with examples → risk → hybrid option.