Power BI Interview Questions

Note: The strongest Power BI answers are about decisions, not visuals. A dashboard nobody acts on is a failed project regardless of how it looks.

Cover:

• The audience and the question they needed answered. An executive wanting one number weekly and an analyst wanting to slice freely need completely different reports.
• The data sources and their state. Where the data came from, and how bad it was. Real projects spend most of their time here.
• The model. Whether you built a star schema, how many fact and dimension tables, and the key measures. This is what separates someone who builds models from someone who drags fields onto a canvas.
• What changed as a result. A decision made, a process altered, a manual report retired, or hours saved.

If adoption was poor, say so and explain why — usually trust in the numbers, or answering a question nobody was asking.

The main risk in BI work is building something technically correct that nobody uses, so show that you interrogate the request.

• Start with the decision, not the fields. Ask what action they would take differently depending on what the report shows. If there is no answer, the report has no purpose and you should say so early.
• Identify the audience precisely. An executive summary, an operational monitor, and an analytical exploration tool are three different products. Trying to serve all three in one report produces something that serves none.
• Agree definitions in writing. "Active customer" and "revenue" mean different things to different departments, and a disagreement discovered after launch destroys trust in the whole report.
• Establish granularity and refresh frequency. Real-time is expensive and usually unnecessary — ask what decision requires it.
• Check the data exists before promising anything. This is where most requirements gathering fails.

Note: Mentioning that you build a rough mock-up early and iterate is a strong point. People cannot specify a dashboard in the abstract, but they can react to one immediately.

This happens to everyone in BI, and how you handle it is the whole question.

• Check your own work first, quickly and without defensiveness. Trace the number back through the measure, the model relationships, and the source. A surprising number of disputes turn out to be a filter context issue or a many-to-many relationship producing inflated totals.
• Find where the two numbers diverge. If someone's spreadsheet disagrees with your report, reconcile at a granular level rather than arguing about the total. The gap is almost always a definition difference — a different date field, an excluded category, or a currency conversion.
• Be willing to be wrong publicly. If your report was incorrect, say so immediately and fix it. Trying to defend a wrong number costs far more credibility than the error did.
• If the report is right and the news is bad, present the evidence calmly and let people react. Do not soften a genuine finding.

Note: The systemic fix is worth adding — documented measure definitions and a data dictionary, so "what does this mean" is answered once rather than every time.

Adoption is the real deliverable, and it is mostly about trust and fit rather than features.

Building trust:

• Show the data freshness on the report. A visible "last refreshed" timestamp prevents the most common source of confusion.
• Reconcile against a source people already believe. If the finance number matches finance's own report, the rest of the dashboard inherits that credibility.
• Document measure definitions where users can see them, so nobody has to guess what "active user" counts.
• Fix errors fast and visibly. A report that was wrong once and corrected quickly retains trust; one with a known unfixed error is dead.

Building usage:

• Make it fast. A report taking twenty seconds to load will not be opened twice.
• Deliver it where people already are — a Teams tab, a subscribed email, or an app rather than a link they must remember.
• Train briefly and watch someone use it. Observing a user struggle for two minutes teaches you more than a feedback form.
• Check usage metrics and retire what nobody opens.

How you keep up: Power BI ships monthly, so the release blog is the primary source. Beyond that, the community — the Power BI community forums, SQLBI for DAX and modelling depth, and Guy in a Cube for practical walkthroughs. Most usefully, rebuilding something you already made using a new capability, because reading about a feature rarely tells you where it breaks.

How you filter:

• Modelling and DAX fundamentals repay study far more than new visuals. Filter context, relationships, and star schema design are what determine whether a report is correct and fast — and they change slowly.
• Preview features are not for production. They can change or disappear, and reports built on them can break.
• Does it solve a problem you have? A new visual type is irrelevant if your reports are slow because the model is wrong.

Note: Being able to say you deepened your understanding of a fundamental — filter context, or the difference between calculated columns and measures — rather than only collecting features, is the more impressive answer. Most Power BI problems in the wild are modelling problems, not feature gaps.

They are three distinct layers, and confusing them is the most common source of Power BI trouble.

• Power Query (M language) — the extract and transform layer. It connects to sources and shapes data before it enters the model: removing columns, filtering rows, unpivoting, merging queries, changing types. Everything here happens at refresh time.
• The data model — how tables relate to each other. Relationships, cardinality, filter direction, hierarchies, and formatting. This is where report correctness is largely determined.
• DAX (Data Analysis Expressions) — the calculation layer. Measures and calculated columns evaluated when the report is used, responding to whatever filters the user has applied.

The rule that follows: do transformation as far upstream as possible. Best of all in the source database, otherwise in Power Query, and only in DAX when the calculation genuinely depends on user interaction. Filtering rows or renaming columns in DAX rather than Power Query is a common mistake that costs both performance and clarity.

Note: The corollary about calculated columns versus measures follows the same logic — a calculated column is computed at refresh and stored in memory, so if the value does not need to respond to filters, it should have been created in Power Query instead.

A star schema separates tables into two kinds:

• Fact tables — the events or transactions you measure. Long and narrow, containing numeric values and foreign keys. Sales, orders, page views.
• Dimension tables — the context you slice by. Short and wide, containing descriptive attributes. Date, Product, Customer, Region.

Dimensions relate to facts one-to-many, with filters flowing from dimension to fact — producing a diagram shaped like a star.

Why it matters so much in Power BI:

• The engine is built for it. VertiPaq compresses columns, and a star schema produces exactly the pattern it optimises for. A flat wide table or a snowflake with many joins performs worse, often dramatically so.
• Filters behave predictably. Ambiguous paths and bidirectional relationships in a poorly shaped model cause wrong totals that are extremely hard to debug.
• DAX becomes simpler. Many complex measures written to work around a bad model become one line against a good one.
• Slicers work naturally, because dimension attributes are where they belong.

Note: The single most important practical instance is a dedicated Date dimension marked as a date table. Without one, time intelligence functions such as SAMEPERIODLASTYEAR and YTD either fail or return wrong results — and this catches out a large proportion of candidates.

This is the most common Power BI interview question, and the answer is about when the calculation happens.

A calculated column:

• Is computed at refresh time, row by row, and the result is stored in the model, consuming memory.
• Evaluates in row context — it can see the other columns of its own row.
• The value is fixed and does not change as the user filters.
• Use it when you need a value to slice, filter, or group by — a category derived from a numeric range, or a concatenated key.

A measure:

• Is computed when the report is viewed, and nothing is stored.
• Evaluates in filter context — it responds to whatever slicers, rows, and columns are in play, which is why the same measure shows a different number in every cell of a matrix.
• Must aggregate; it cannot return a value for a single row without one.
• Use it for anything you want to see aggregated — totals, averages, ratios, year-over-year change.

The guidance: prefer measures. They cost no memory, respond correctly to user interaction, and remain correct at every level of aggregation.

Note: The classic error is calculating a ratio as a calculated column and then summing it. Summing percentages gives nonsense — a measure dividing the summed numerator by the summed denominator is the correct approach, and interviewers ask this deliberately.

Row context means "the current row". It exists in calculated columns and inside iterator functions such as SUMX and FILTER. It lets you reference other columns of the same row.

Filter context is the set of filters applied when a value is evaluated — from slicers, from the rows and columns of a visual, from page filters, and from relationships. A measure returns a different number in every cell because each cell has a different filter context.

CALCULATE is the most important function in DAX because it is the only one that modifies filter context.

Sales LY =
CALCULATE(
    [Total Sales],
    SAMEPERIODLASTYEAR('Date'[Date])
)

It evaluates the first argument under filter conditions you specify. It can add filters, remove them with ALL or REMOVEFILTERS, or replace them.

The classic pattern is percentage of total, which needs the denominator to ignore the current row's filter:

% of Total =
DIVIDE([Total Sales], CALCULATE([Total Sales], ALL(Product)))

Note: CALCULATE also performs context transition — inside a row context it converts the current row into an equivalent filter context. This is why wrapping a measure in CALCULATE inside SUMX behaves differently from calling it directly, and it is the single concept that most often trips people up in DAX interviews.

Three storage modes with genuinely different trade-offs.

• Import — data is loaded into Power BI's in-memory VertiPaq engine and compressed. Fastest by a wide margin, supports the full range of DAX and Power Query, and works offline. The limits are that data is only as fresh as the last refresh, model size is capped by capacity, and refresh time grows with volume. This should be the default.
• DirectQuery — no data is stored; every visual generates a query against the source at view time. Use it when data must be near real-time, or the dataset is too large to import, or governance forbids copying data. The costs are significant: report performance depends entirely on the source database, many DAX functions are unavailable or slow, Power Query transformations are restricted, and every interaction generates load on the source.
• Live Connection — connects to an existing model in Analysis Services or a Power BI dataset. You build visuals but do not own the model, which is exactly the point: one governed model serves many reports and definitions stay consistent.

Composite models let you mix them — importing dimensions while leaving a huge fact table in DirectQuery, with aggregation tables to answer most queries from memory.

Note: The interview point is that DirectQuery is often chosen for the wrong reason. "Real-time" usually means "refreshed hourly", which Import handles perfectly at a fraction of the complexity.

Relationships connect tables so filtering one filters the other. Each has a cardinality and a cross-filter direction.

Cardinality:

• One-to-many — the standard and desirable case, from a dimension to a fact.
• Many-to-one — the same thing described from the other side.
• One-to-one — usually a sign two tables should be merged.
• Many-to-many — supported, but it creates ambiguity and is often a modelling smell. The cleaner solution is usually a bridge table.

Cross-filter direction is single by default: the one side filters the many side. That is normally what you want — Product filters Sales, not the reverse.

Why bidirectional relationships are dangerous:

• Ambiguity. With several tables and bidirectional filters, more than one filter path can exist between two tables, and the engine either refuses the model or picks a path you did not intend.
• Wrong totals that look plausible — the worst kind of error, because nobody notices.
• Performance cost, since the engine must propagate filters both ways.

The better approach: keep relationships single-direction and use CROSSFILTER inside a specific measure when you genuinely need bidirectional behaviour. That confines the effect to one calculation instead of the whole model.

Note: Only one relationship between two tables can be active. Use USERELATIONSHIP inside CALCULATE to activate an alternative — the standard pattern for a fact table with both an order date and a ship date.

Diagnose first with Performance Analyzer in Power BI Desktop, which shows the time each visual spends on DAX query, visual display, and other. That immediately tells you whether the problem is the model, the DAX, or the report layout. DAX Studio and VertiPaq Analyzer go further, showing which columns consume the most memory.

Model-level fixes — usually the biggest wins:

• Remove columns you do not use. Every column costs memory and refresh time. High-cardinality columns such as GUIDs and timestamps to the second are the most expensive; splitting a datetime into date and time columns often shrinks a model dramatically.
• Adopt a star schema. Flat wide tables and snowflakes both cost performance.
• Reduce cardinality by rounding numbers to the precision you actually report on.
• Filter rows at the source rather than importing history nobody looks at.

DAX-level fixes:

• Avoid iterators over large tables where a simple aggregation would do.
• Use DIVIDE rather than / with an IF guard.
• Use variables with VAR to compute something once instead of repeatedly.
• Avoid FILTER over an entire table inside CALCULATE when a simple boolean filter argument works.

Report-level fixes: fewer visuals per page — each one issues its own query — limit slicers, and avoid heavy custom visuals.

Row-level security (RLS) restricts which rows a user can see within a single dataset, so one report serves everyone while each person sees only their own data.

Static RLS defines a role with a fixed DAX filter:

[Region] = "South"

You then assign users to that role. Simple, but it does not scale — a role per region quickly becomes unmanageable.

Dynamic RLS is the approach used in practice. One role filters based on who is viewing:

[SalesRepEmail] = USERPRINCIPALNAME()

For a hierarchy, add a permissions table mapping users to the regions or accounts they may see, relate it to the model, and filter through that relationship. Adding a new user then means adding a row to a table, not editing the model.

Important details:

• Test with "View as role" in Desktop before publishing, and test again in the Service — behaviour can differ.
• Filters propagate through relationships, so a filter on a dimension flows to the fact table. Check that it reaches everything it should, and watch for bidirectional relationships bypassing it.
• Workspace admins and members bypass RLS. Users must have Viewer access and be assigned to a role for it to apply — a genuine and frequently overlooked security gap.
• RLS filters rows, not columns or measures. Object-level security handles hiding columns.

• Power BI Desktop — the free Windows authoring tool. This is where you connect to data, transform it in Power Query, build the model, write DAX, and design the report. All real development happens here.
• Power BI Service — the cloud platform at app.powerbi.com. You publish to it, and it handles scheduled refresh, sharing, dashboards, subscriptions, alerts, and governance. Reports can be edited here, but the modelling experience is limited.

Within the Service:

• Workspace — a container for datasets, reports, dashboards, and dataflows, with role-based access: Admin, Member, Contributor, and Viewer. This is the development and collaboration space, and it is where your team works.
• App — a curated, published package from a workspace, distributed to consumers. This is the consumption layer. Users get a clean, read-only experience with only the content you chose to include, and you can update the workspace without affecting them until you republish.

The distinction that matters: give consumers an app, not workspace access. Workspace access exposes work in progress and makes permissions harder to manage.

Note: A dashboard and a report are also different. A report is multi-page and interactive, built from one dataset; a dashboard is a single-page collection of pinned tiles that can come from several reports. Mixing up these terms is a common giveaway.

Scheduled refresh re-runs the queries in a published dataset on a timetable. On shared capacity you get up to eight refreshes a day; on Premium, up to forty-eight.

The on-premises data gateway is required for any source that is not cloud-accessible — an on-premises SQL Server, a file share, or a database behind a firewall. It should be installed in standard mode on a server rather than personal mode on someone's laptop, and clustered for redundancy.

Incremental refresh solves the problem of a growing fact table. Instead of reloading everything, you partition the table by date and refresh only the recent partitions.

You configure it with two parameters, RangeStart and RangeEnd, used to filter in Power Query, then set a policy such as "store 5 years of data, refresh the last 10 days".

Why it matters: a refresh that took two hours reloading five years of history can drop to two minutes. It also reduces load on the source and makes datasets larger than would otherwise be refreshable practical.

Note: Two practical points. Query folding is essential — the date filter must be pushed down to the source as a WHERE clause, and if the transformation breaks folding, incremental refresh gives no benefit. And handle late-arriving data deliberately: if records can be backdated beyond your refresh window, they will be missed, so either widen the window or trigger a full refresh periodically.