Power BI Interview Questions and Answers by Difficulty Level

Power BI interviews test whether you understand the engine behind the dashboards — not just whether you can drag a field onto a canvas. Interviewers move quickly from "what is a measure" to "explain context transition," and the gap between a junior and a senior answer is usually depth on the data model and DAX.

This guide groups the most common Power BI interview questions and answers into three levels so you can find the ones that match the role you're targeting. Each answer is concise enough to say out loud and accurate enough to survive a follow-up.

What you'll find here:

• Beginner questions on Power BI components, Desktop vs. Service, and basic concepts
• Intermediate questions on star schema, relationships, cardinality, and core DAX
• Advanced questions on filter context, time intelligence, RLS, and VertiPaq performance
• How to stand out beyond technically correct answers
• A short FAQ on preparing for a Power BI interview

Beginner Power BI Interview Questions

These come up in screening calls and entry-level analyst roles. The interviewer wants to confirm you know the moving parts and can talk about the product clearly.

What is Power BI and what is it used for?

Sample answer: Power BI is Microsoft's business analytics platform for connecting to data, modeling it, and building interactive reports and dashboards. You pull data from sources like SQL databases, Excel files, or cloud services, shape it into a model, write calculations, and publish reports that business users can explore. The selling point is self-service analytics — analysts build and share reports without waiting on a central BI team for every request. Microsoft describes it as a collection of services, apps, and connectors that turn unrelated data sources into coherent insights.

What are the main components of Power BI?

Sample answer: The platform has a few core pieces that work together:

• Power BI Desktop — the free Windows authoring tool where you connect to data, build the model, write DAX, and design reports.
• Power BI Service — the cloud SaaS platform (app.powerbi.com) where you publish, share, and schedule refreshes.
• Power BI Mobile — native apps for viewing reports on phones and tablets.
• Power Query — the ETL layer for extracting and transforming data.
• Power BI Gateway — the bridge that lets the cloud service refresh data sitting on-premises.

Knowing how these split between authoring (Desktop), distribution (Service), and consumption (Mobile) is usually enough at this level.

What is the difference between Power BI Desktop, Service, and Mobile?

Sample answer: They map to three different jobs in the workflow. Here's the breakdown:

Most development happens in Desktop. You publish the .pbix file to the Service, where collaboration, security, and refresh scheduling live, and consumers view it through the browser or the mobile apps.

What is a measure and how does it differ from a calculated column?

Sample answer: Both are DAX calculations, but they behave very differently — this is one of the most common questions you'll get, so be precise:

A calculated column adds a value to every row and takes up space in the model. A measure aggregates over whatever rows the current visual is filtering. Rule of thumb: if you want to aggregate or summarize, use a measure; if you need a per-row value to group or filter on, use a calculated column.

What is a slicer?

Sample answer: A slicer is an on-canvas filter the report user can interact with directly — a dropdown, list, or date range that filters the other visuals on the page. Unlike the Filters pane, it lives on the report itself and is meant for the end user. Good slicer design (single-select where appropriate, syncing across pages) is part of building a clean, usable report.

Intermediate Power BI Interview Questions

This is where most data analyst and BI developer interviews actually get decided. The focus shifts to how you model data and write calculations that perform.

What is a star schema and why is it recommended for Power BI?

Sample answer: A star schema splits your model into fact tables (the events you measure — sales, orders, transactions) and dimension tables (the things you describe — products, customers, dates). The fact table sits in the center, connected to surrounding dimension tables by one-to-many relationships, which is where the "star" shape comes from.

Microsoft recommends it because it matches how the engine works: dimension tables handle filtering and grouping, fact tables handle summarization. Each report visual sends a query that filters, groups, and aggregates — and a star schema gives the engine exactly the shape it wants. It also keeps DAX simpler and the model smaller than a flat, fully denormalized table or a deeply normalized snowflake.

Explain relationships and cardinality in Power BI.

Sample answer: A relationship connects two tables on a shared column and defines a filter propagation path — when you filter the "one" side, that filter flows to the "many" side. Cardinality describes how rows on each side relate:

• **One-to-many (1:*)** — the standard relationship. One dimension row (one product) maps to many fact rows (many sales). The "one" side is always the dimension.
• **Many-to-one (*:1)** — the same thing viewed from the fact side.
• One-to-one (1:1) — rare; usually a sign two tables should be merged.
• **Many-to-many (*:*)** — supported, but use it deliberately. It can produce ambiguous filter paths and is often better solved with a bridging table.

You should also know about cross-filter direction (single vs. both) and active vs. inactive relationships — only one relationship between two tables can be active at a time, and you activate an inactive one in DAX with USERELATIONSHIP.

What is the difference between row context and filter context?

Sample answer: These two contexts are the foundation of DAX, and confusing them is the most common DAX mistake.

• Row context is "the current row." It exists inside a calculated column or an iterator like SUMX — DAX knows which row it's working on, so a column reference returns that row's value.
• Filter context is "the set of filters currently applied." It comes from slicers, the rows and columns of a visual, and filter functions. A measure runs inside whatever filter context the visual creates.

A calculated column has row context but no filter context. A measure has filter context but no inherent row context. The bridge between them is context transition, which CALCULATE performs automatically — it turns the current row context into an equivalent filter context.

What does the CALCULATE function do?

Sample answer: CALCULATE evaluates an expression in a *modified* filter context — it's the most important function in DAX. You give it an expression plus one or more filter arguments, and it applies those filters before evaluating.

Blue Revenue =
CALCULATE(
    SUM(Sales[Sales Amount]),
    'Product'[Color] = "Blue"
)

Two rules to mention: if a filter argument references a column that isn't already filtered, CALCULATE *adds* the filter; if that column is already in the filter context, the new filter *overwrites* the existing one (unless you wrap it in KEEPFILTERS). And called inside a row context, CALCULATE triggers context transition. Knowing those two behaviors signals you actually understand the function rather than having memorized the syntax.

How do you handle ETL in Power BI?

Sample answer: Through Power Query, the transformation engine built into Desktop. You connect to a source, then apply steps — remove columns, change data types, filter rows, merge or append queries, unpivot — and each step is recorded in the M language behind the scenes. The Applied Steps list is a repeatable recipe that reruns every refresh.

Best practice is to do as much shaping as possible upstream in Power Query, or further back in the source, keeping the model clean. Heavy transformation logic belongs in the ETL layer, not in DAX measures.

What is the difference between DirectQuery and Import mode?

Sample answer: They define how Power BI gets to your data:

• Import loads a compressed copy of the data into the in-memory model. Fast queries, full DAX support, but the data is only as fresh as the last refresh and is bounded by memory.
• DirectQuery leaves the data in the source and sends queries to it live. Always current and no size ceiling on the model, but slower, dependent on source performance, and limited in some DAX and modeling features.

Import is the default and right answer for most cases. You reach for DirectQuery when data is too large to import, must be real-time, or can't leave the source for governance reasons. Composite models let you mix both in one model.

Advanced Power BI Interview Questions

These separate senior BI developers from analysts. Expect questions on performance, security, and the deeper DAX behavior that breaks in production.

How does time intelligence work in DAX?

Sample answer: Time intelligence functions let you compare values across periods — year-to-date, prior year, rolling averages — without manually slicing dates. Functions like TOTALYTD, SAMEPERIODLASTYEAR, and DATEADD shift or expand the date filter context for you.

Sales YTD =
TOTALYTD(SUM(Sales[Sales Amount]), 'Date'[Date])

The non-obvious requirement: you need a proper date dimension table marked as a date table, with a continuous, gap-free range of dates. Time intelligence quietly returns wrong results if your date table has missing days or you're relying on a date column inside the fact table. Mentioning that prerequisite shows production experience.

What is row-level security (RLS) and how do you implement it?

Sample answer: Row-level security restricts which rows a user can see based on who they are — a regional manager sees only their region, even though everyone opens the same report. You implement it in two parts:

1. In Desktop, you define *roles* with DAX filter expressions on tables, for example [Region] = "West".
2. In the Service, you assign users or security groups to those roles.

For per-user filtering, you use dynamic RLS: a filter like [Email] = USERPRINCIPALNAME() combined with a mapping table that links each user to the rows they're allowed to see. One filter expression then scales to thousands of users. Be ready to note that RLS filters data but doesn't hide table or column *definitions* — that's object-level security, a separate feature.

What is VertiPaq and how does it affect performance?

Sample answer: VertiPaq is the in-memory, columnar storage engine behind Import mode. Instead of storing data row by row, it stores each column separately and compresses it heavily — using techniques like dictionary encoding and run-length encoding. Columnar storage is why a Power BI model can be a fraction of the source size and still query fast.

The practical implications drive a lot of optimization advice:

• Cardinality is the enemy. High-cardinality columns (unique IDs, full timestamps, free-text) compress poorly and bloat the model. Splitting a datetime into separate date and time columns often shrinks the file dramatically.
• Remove columns you don't need. Every column has a memory cost whether or not a visual uses it.
• Prefer measures over calculated columns where you can, since columns are materialized and stored.

How do you optimize a slow Power BI report?

Sample answer: I work through it in layers, from model to DAX to visuals:

• Model — adopt a star schema, drop unused columns, reduce cardinality, and avoid bidirectional cross-filtering unless it's genuinely needed.
• DAX — replace iterators with set-based functions where possible, avoid using FILTER over an entire table inside CALCULATE, and watch for measures that force expensive context transitions.
• Visuals — cut the number of visuals per page (each one is a separate query), limit slicers, and avoid putting high-cardinality fields in a single visual.
• Tooling — use Performance Analyzer in Desktop to find which visual is slow, then DAX Studio to read the query plan and server timings.

Naming Performance Analyzer and DAX Studio signals you've actually debugged a real performance problem, not just read about it.

What is query folding in Power Query?

Sample answer: Query folding is Power Query's ability to translate your transformation steps back into a single native query — usually SQL — that runs on the source system. When folding works, the source does the heavy lifting (filtering, grouping, joining) and only the reduced result comes back over the wire.

It matters for performance and refresh time. Steps like filtering rows and removing columns usually fold; steps like adding an index column or certain custom M functions break folding, and everything after the break runs locally in the Power Query engine instead. The optimization rule is to push folding steps as early as possible and put fold-breaking steps last. You can check whether a step folds by right-clicking it and looking for "View Native Query."

How to Stand Out Beyond Correct Answers

Technically correct answers get you past the screen. What separates strong candidates is judgment — showing you know *when* to apply each concept, not just what it is.

A few habits that consistently land well:

• Tie answers to tradeoffs. "I'd use Import mode here, but I'd switch to DirectQuery if the table grew past what we can refresh" reads as experience, not memorization.
• Mention how you'd verify. Saying you'd confirm folding with View Native Query, or profile a slow visual with Performance Analyzer, shows you've shipped real work.
• Be honest about the messy parts. Many-to-many relationships, broken query folding, and RLS performance are where real projects get hard. Acknowledging that beats pretending everything is clean.

If you're going broader than Power BI in your interview loop, it's worth reviewing general technical interview questions and, depending on the role, the data analyst interview questions and data engineer interview questions guides — Power BI roles often overlap with SQL, modeling, and pipeline questions.

Prep for the Person, Not Just the Platform

Nailing the DAX questions gets you shortlisted. What gets you the offer is knowing the team and the person across the table — what they're building, what they care about in a BI hire, and where their reporting stack actually hurts. Articuler helps jobseekers find the hiring manager behind a Power BI role and build a Playbook on that specific person — their background, recent work, and what to ask — so you walk in prepared for that conversation, not a generic one.

FAQ

What are the most common Power BI interview questions?

The most common ones cover the difference between a measure and a calculated column, what CALCULATE does, row context vs. filter context, star schema design, and the difference between Import and DirectQuery. At senior levels, expect questions on row-level security, query folding, and VertiPaq performance tuning.

How do I prepare for a Power BI interview as a data analyst?

Build one project end to end — connect data, shape it in Power Query, model it as a star schema, write a handful of measures with CALCULATE and time intelligence, then publish it with RLS. Being able to talk through real decisions you made beats memorizing definitions, because interviewers follow up on the "why."

Is DAX or Power Query more important in interviews?

Both come up, but DAX usually carries more weight for analyst and BI developer roles because it's where modeling logic lives and where candidates struggle most. Power Query questions tend to focus on ETL concepts and query folding. Know DAX context and CALCULATE cold, and understand folding well enough to explain why it matters.

What's the difference between a measure and a calculated column in Power BI?

A calculated column is computed row by row at refresh and stored in the model, using memory and operating in row context. A measure is computed at query time per visual, isn't stored, and operates in filter context. Use a measure to aggregate or summarize; use a calculated column when you need a per-row value to filter or group by.