Power BI developer interview questions with scenario-based answers, follow-up probes, and the reasoning interviewers are actually looking for across junior.
Memorizing the definition of a measure is not the hard part. The hard part is when an interviewer says, "You've got a sales report where the monthly total in the matrix doesn't match the card visual — walk me through what you'd check first." That's where power bi developer interview questions actually live: not in definitions, but in decisions made under mild pressure with incomplete information. Junior and mid-level candidates feel this most acutely, because the prep resources they find are mostly vocabulary lists. Senior candidates feel it differently — they get asked to justify architecture choices and anticipate what breaks downstream. This guide covers both, organized by scenario rather than topic, so you can practice the thinking pattern, not just the answer.
How Power BI Interviewers Turn Definitions Into Scenarios
What changes when the question stops being a definition check?
The first question in most Power BI interviews sounds like a definition check: "What is a measure?" or "What does CALCULATE do?" These are warm-up questions. They're not what the interviewer is evaluating. What they're actually doing is watching how you transition from the definition to the application — because the follow-up is always a scenario.
"What does CALCULATE do?" becomes "So if I have a measure that sums sales, and I wrap it in CALCULATE with a filter for the West region, but my visual already has a region slicer — what happens?" That's where candidates who memorized the docs freeze. They know what CALCULATE does in isolation. They haven't thought through what it does when filter context is already present.
The trap is that definitions feel like preparation. They're actually just the entry ticket. The interview starts after the definition lands.
Why your answer needs a decision, not a dictionary
A strong Power BI interview answer has three parts: the problem, the tool choice, and the tradeoff. Not the definition of the tool. The reason you chose it over the alternatives.
Say the requirement is monthly sales by region from a source that has messy date formatting and inconsistent region labels. A weak answer describes what Power Query does. A strong answer says: "I'd fix the date formatting and standardize the region labels in Power Query before the data hits the model — that's transformation work, not calculation work. Then I'd build a measure for the monthly sales aggregation because it needs to respond to slicers. The tradeoff is that the Power Query steps run at refresh time, so if the source changes its format, I need to update the query, not the DAX."
That answer names the problem, explains the split between Power Query and DAX, and acknowledges where the approach can break. That's what interviewers are listening for.
How senior interviewers listen differently from junior ones
At the junior level, the interviewer is checking for correctness. Can you explain what a star schema is? Do you know the difference between a measure and a calculated column? Basic accuracy matters most.
At the mid level, the interviewer is checking for judgment. Not just "do you know what Power Query does" but "do you know when not to use it?" They want to hear you weigh options, not just demonstrate knowledge.
At the senior level, the interviewer is checking for anticipation. A senior candidate should be thinking about what happens to the model when the data volume doubles, what the refresh schedule means for stakeholders in different time zones, and whether the RLS design will hold up when the org chart changes. If a senior candidate answers a question about star schema design without mentioning cardinality, relationship direction, or downstream DAX complexity, the interviewer notices.
Power BI Developer Interview Questions: The Answers Interviewers Actually Want
What is Power BI, and how would you explain it to a non-technical stakeholder?
Power BI is a reporting platform that connects to data sources, transforms that data, and presents it as interactive dashboards that non-technical users can filter and explore without writing code. The business value is that decision-makers stop waiting for analysts to run queries and start exploring data themselves.
The follow-up interviewers use here is: "Tell me about a time you had to get buy-in from a team that wasn't sold on a new reporting tool." They're not testing your product knowledge anymore — they're testing whether you've actually dealt with adoption friction. The right answer acknowledges that adoption is a change management problem, not a features problem, and that showing one useful dashboard to the right person early moves faster than a full rollout presentation.
How do you explain the difference between Power BI Desktop and Power BI Service?
Desktop is where you build: connect to sources, transform data in Power Query, design the model, write DAX, and create visuals. Service is where you publish, share, schedule refresh, and manage access. The workflow goes one direction — from Desktop to Service — and understanding that boundary matters because things that work locally can break in the cloud.
The follow-up is: "What changes about your report once it's published to the Service?" The answer should cover scheduled refresh replacing manual refresh, gateway requirements for on-premises sources, workspace permissions replacing local file sharing, and the fact that some Desktop-only features — like certain data source connections — don't carry over cleanly. Knowing where Desktop stops being enough is a real mid-level signal.
What are Power Query and DAX doing in different parts of the job?
Power Query handles transformation before the model — shaping, cleaning, and structuring data so it's ready to be modeled. DAX handles calculation at query time — responding to filter context, slicers, and visual interactions after the model is built.
A concrete example makes this clearer than any definition. Say you're pulling from a messy CSV of transactions alongside a SQL database of customers. Power Query merges those sources, trims whitespace from the customer names, parses the transaction date into a proper date column, and removes duplicates. That work happens once at refresh. Then DAX calculates revenue by month, customer segment, or product category dynamically as the user interacts with the report. The split is: one-time shaping versus repeated calculation. Interviewers want to hear you name that distinction, not just list what each tool does.
How would you describe a star schema without sounding academic?
A star schema puts your measurable business events — transactions, orders, calls — in one central fact table, and connects lookup information like customers, products, dates, and regions as separate dimension tables around it. The shape looks like a star because the fact table is in the middle with dimension tables radiating outward.
The practical reason this matters: a star schema makes DAX simpler and queries faster. When your date dimension is a separate table with a clean relationship to the fact table, time intelligence functions like TOTALYTD and SAMEPERIODLASTYEAR work correctly without workarounds. When dates are embedded in the fact table instead, those functions break or require extra logic. The follow-up interviewers use is: "What happens to your DAX if the relationships in your model aren't set up correctly?" The answer is that cross-filtering behaves unexpectedly, totals don't aggregate the way users expect, and you end up writing compensating DAX instead of fixing the model.
How do you decide between a measure and a calculated column?
A measure is calculated at query time in response to the current filter context — it changes as the user interacts with the report. A calculated column is computed once at refresh and stored as a static value in the table. The decision comes down to context and storage.
Use a calculated column when you need a fixed label or category that doesn't change based on what the user selects — like a customer segment bucketed by lifetime value at the time of import. Use a measure when you need something that responds to slicers and filters — like revenue by month, where the month changes depending on what's selected. A common mistake is using calculated columns for aggregations, which bloats the model with stored data that could have been computed dynamically. Interviewers often test this with a scenario: "I want to show revenue by customer segment — should I calculate the segment in a column or in a measure?" The right answer is that the segment label belongs in a column, and the revenue aggregation belongs in a measure.
What does CALCULATE actually change in a DAX formula?
CALCULATE modifies the filter context that a measure evaluates in. Without CALCULATE, a measure inherits whatever filters the visual, slicer, or row context applies. With CALCULATE, you can add, remove, or override those filters explicitly.
The interviewer's next probe is usually: "Why would the same measure return a different result in a matrix row versus a card visual?" The answer is filter context. In a matrix, each row applies a row filter — so a sales measure calculates within that product or region. In a card, there's no row filter, so the measure aggregates everything visible. CALCULATE lets you write measures that behave consistently regardless of where they're placed — for example, always showing total company sales regardless of what region filter is applied. That's useful for variance calculations. Understanding this distinction separates candidates who can write DAX from candidates who understand why DAX behaves the way it does.
Power Query, DAX, and the Problem of Picking the Right Layer
When should you clean data in Power Query instead of in DAX?
Anything that fixes the shape or quality of the raw data belongs in Power Query. Trimming whitespace from text fields, splitting a combined name-and-code column into two separate columns, parsing a text date like "Jan 2023" into a proper date value, replacing nulls with meaningful defaults — these are transformation steps that should happen before the data enters the model.
The reason is architectural: once bad data is in the model, every measure that touches it inherits the problem. Fixing it in DAX is possible, but it means writing defensive logic into every calculation that uses that field. Fixing it in Power Query once means the model sees clean data from the start. Interviewers test this by describing a messy source and asking where you'd handle each issue. If you reach for DAX to fix a null value that could be handled in Power Query, that's a signal that your mental model of the data pipeline isn't fully formed.
When do you need both Power Query and DAX for the same report?
Most real reports need both, and the split is usually clear once you think about the lifecycle of the data. A sales dashboard is a good example. Power Query handles the upstream work: merging the orders table with the product catalog, removing cancelled orders, standardizing the date format, and creating a clean region column from a messy territory code field. That work happens at refresh and doesn't repeat.
DAX then handles the business logic that needs to respond to user interaction: total sales by month, year-over-year growth, percentage of target, running totals. These calculations need to change as users filter by product, region, or time period. The tradeoff is that Power Query steps add to refresh time, while complex DAX measures add to query time. A strong mid-level answer acknowledges both and shows awareness of where each type of complexity lives.
What does a good filter context answer sound like when the report total looks wrong?
The wrong answer is "DAX is behaving unexpectedly." The right answer traces the problem to its source. When a report total doesn't match what users expect, the first question is: what filter context is the measure evaluating in?
A common scenario is a matrix where the row total shows a different value than the sum of the visible rows. This usually means the measure uses a function like DISTINCTCOUNT or AVERAGE that doesn't aggregate the same way across all rows as it does within each row — and that's mathematically correct behavior, not a bug. A strong candidate explains that the total row has a different filter context than each individual row, and that if you want the total to behave differently, you use HASONEVALUE or ISINSCOPE to detect that context and return a different calculation. Interviewers are listening for whether you blame the tool or understand the mechanism.
How do you talk through a report requirement that could be solved three different ways?
Say you need to show sales performance against a fixed target, and the target data lives in a separate spreadsheet. You could import it through Power Query and merge it with the fact table, create a calculated table in DAX, or write a measure that references a parameter table. All three work. The question is which one you'd choose and why.
The interviewer isn't looking for the objectively correct answer — they're looking for your reasoning. A good answer says: "I'd pull the target data through Power Query because it's a data source, not a calculation — keeping source data in Power Query and calculations in DAX keeps the model easier to maintain. If the targets change frequently, I'd also check whether a parameter table makes more sense so stakeholders can update them without touching the Power Query steps." That's the kind of reasoning that shows you've built real reports, not just read about them.
Debugging the Questions That Really Separate Beginners From Strong Candidates
Why is my DAX measure returning blanks or the wrong total?
Start with relationships before touching the formula. A measure that returns blanks usually means there's a broken or missing relationship between the tables involved — the filter from the dimension isn't reaching the fact table. Check that the relationship exists, that it's active, and that the cardinality is correct.
If the relationship is fine, check the aggregation. A SUM over a column that contains text returns blank. A DIVIDE that produces a zero denominator returns blank by default. If the total is wrong rather than blank, check whether the measure is using ALL or ALLEXCEPT in a way that removes more filter context than intended. The diagnostic pattern interviewers want to hear is: relationship first, then aggregation logic, then filter context — not "I'd rewrite the formula."
How would you troubleshoot a report that is painfully slow?
Diagnosis before tools. The first question is whether the slowness is in the data load, the visual rendering, or the DAX calculation. Those are three different problems with different fixes.
If the model is large, check cardinality — high-cardinality text columns in fact tables are a common culprit. If the visuals are slow, check how many measures each visual is evaluating and whether any of them use SUMX or CALCULATE with complex filter arguments that iterate row by row. If the dashboard has twenty visuals on one page, that's a rendering problem, not a DAX problem. Performance Analyzer in Desktop shows query times per visual, which makes it easier to isolate where the time is going. A strong answer names the diagnostic step before naming the fix.
What do you say when a report works in Desktop but breaks after publish?
This is a common scenario and a reliable mid-level signal. The most frequent causes are credential failures — the Service can't authenticate to the data source — and gateway issues, where an on-premises source isn't reachable from the cloud without a configured gateway. After that, check workspace permissions, because a report that a developer can see locally may not be accessible to the intended audience in the Service.
Sometimes the issue is a feature that works in Desktop but isn't supported in the Service — certain custom visuals or specific data source connectors behave differently. The answer interviewers want is a structured checklist: credentials, gateway, permissions, Service-specific feature support. Not "I'd check the settings."
How do you answer a question about incremental refresh without sounding like you memorized the docs?
Frame it as a problem before a solution. You have a fact table with three years of transaction history. Every night, a full refresh loads all three years just to capture the last day's new rows. That's slow, expensive, and unnecessary. Incremental refresh solves this by partitioning the table — older historical data is loaded once and frozen, and only the recent window refreshes on schedule.
The interviewer wants to hear the partitioning logic: you define a range parameter for the historical window and a rolling window for the refresh window. But they also want to hear where it can fail: incremental refresh requires a date column that Power Query can fold into the source query, which means it doesn't work with all connectors. If the source doesn't support query folding, Power BI loads everything and filters locally, which defeats the purpose. Naming that failure mode is what separates a rehearsed answer from a real one.
RLS, Refresh, Gateways, and the Power BI Service Questions People Get Wrong
How would you explain row-level security in a real company setup?
RLS restricts what data a user sees based on their identity, applied through roles defined in the model. The classic scenario is a regional sales report where each sales manager should only see their own region's data.
The implementation involves defining a role in Desktop with a DAX filter on the region column — something like `[Region] = USERPRINCIPALNAME()` if the region column stores email addresses, or a lookup through a separate security table if the mapping is more complex. After publishing, you assign users or groups to those roles in the Service. The testing step matters: use the "View as role" feature in Desktop to confirm each role sees the right data before publishing. Interviewers often follow up with: "How do you handle a user who manages multiple regions?" That requires either a security table with a many-to-many relationship or a dynamic approach that checks membership across multiple rows.
What would you say if the gateway is the reason refresh keeps failing?
The gateway is the bridge between the Power BI Service in the cloud and data sources that live on-premises or in a private network. When refresh fails because of the gateway, the diagnostic path is: is the gateway service running on the host machine, can it reach the data source from that machine, and are the credentials stored in the gateway still valid?
Credential expiration is the most common cause of gateway-related refresh failures. The person who set up the gateway used their own credentials, those credentials expired or changed, and nobody updated them in the Service. The fix is straightforward, but the lesson is operational: gateway credentials should be tied to a service account, not an individual, so that password changes don't silently break scheduled refreshes.
How do workspaces, sharing, and permissions actually fit together?
Workspaces are the containers where reports and datasets live in the Service. Roles within a workspace — Admin, Member, Contributor, Viewer — control what each person can do: Admins manage the workspace, Contributors can publish reports, Viewers can only consume them.
Sharing a specific report directly to an individual bypasses workspace roles, which creates a maintenance problem: when the report changes or the person leaves, those direct shares don't automatically update. The cleaner approach is to manage access through workspace roles or through apps, which let you publish a curated set of reports to a defined audience. Interviewers ask this to see whether you understand the governance implications, not just the mechanics of clicking "Share."
What do deployment pipelines and release management have to do with a Power BI interview?
Deployment pipelines let teams maintain separate Development, Test, and Production workspaces and promote content through them in a controlled way. For a junior candidate, knowing this exists is enough. For a mid-to-senior candidate, the interviewer wants to hear why it matters.
The reason is that without a pipeline, developers publish directly to production — which means a broken report or a schema change that wasn't tested goes live immediately. With a pipeline, you promote from Dev to Test, validate with stakeholders or a QA process, then promote to Production. Dataset parameters and deployment rules let you point each stage at a different data source, so Dev uses sample data and Production uses the real source. Knowing this signals that you've thought about what happens after the report works on your laptop.
How to Read the Room for Junior, Mid, and Senior Power BI Roles
What should a junior Power BI answer do that a senior answer does not?
A junior answer needs to be correct and clear. It doesn't need to anticipate every edge case or preemptively address failure modes. If a junior candidate explains the difference between a measure and a calculated column accurately and uses a concrete example, that's a strong answer at that level.
A senior answer that stops there is a weak answer. Senior candidates are expected to continue: what happens to model performance if calculated columns are overused, how does this choice affect refresh time, and what does the downstream DAX look like in each case. The level shift isn't about knowing more facts — it's about knowing which implications to surface without being prompted.
Which topics are the fastest signal of mid-level readiness?
Model design is the clearest one. A candidate who can explain why they chose a star schema over a flat table, what the relationship cardinality means for cross-filtering, and how that affects DAX behavior is demonstrating mid-level judgment. DAX basics — CALCULATE, filter context, time intelligence — matter, but only if the candidate can explain the why, not just the syntax.
Power Query judgment is the second signal: knowing what belongs in the transformation layer versus the calculation layer, and understanding query folding well enough to know when it's at risk. Service knowledge — enough to not break production after publish — rounds out the picture. A mid-level candidate doesn't need to know every Service feature, but they need to know the ones that matter operationally: gateway, RLS, workspace roles, and scheduled refresh.
How do you know if your portfolio story sounds like real project work or homework?
Real project work has friction in it. A stakeholder changed the requirement after the model was built. The source data had a quality problem that didn't show up until the report was in review. The refresh schedule conflicted with a batch process upstream. If your portfolio walkthrough describes a clean, linear build with no surprises, it sounds like a tutorial, not a project.
A strong walkthrough names the original requirement, the complication that emerged, the decision you made to address it, and what you'd do differently now. "I built the report with a flat table initially because the source was simple, but when the business added a second product line, the model didn't scale — so I restructured it as a star schema." That's a real project story. It shows you made a decision, lived with the consequences, and learned from them.
What should you do if you know the syntax but not the reasoning?
Slow down and name the problem. Interviewers trust candidates who can articulate what they're uncertain about more than candidates who give a confident answer that falls apart under the first follow-up. If you know the CALCULATE syntax but aren't sure how it behaves when there's already a filter from a slicer, say that: "I know CALCULATE modifies filter context, but I want to make sure I'm thinking through the interaction with the existing slicer correctly — can I walk through my reasoning?"
That's not weakness. That's how good analysts actually think. The interviewer is watching whether you can reason through a problem you haven't seen before, not whether you've memorized every edge case. Stating your assumption, naming the tradeoff, and explaining what you'd check first is often a better answer than a fluent recitation of something you half-remember.
How Verve AI Can Help You Prepare for Your Power BI Developer Interview
The gap between knowing Power BI and explaining it under pressure is exactly what costs candidates offers. You can understand filter context perfectly and still give a rambling answer the moment an interviewer asks you to trace a broken total live. That's not a knowledge problem — it's a performance problem, and it only gets solved through practice that feels like the real thing.
Verve AI Interview Copilot suggests answers live during your actual interview on Zoom, Google Meet, or Teams — following the conversation as it happens and helping you structure a response when a follow-up goes somewhere you didn't rehearse. On the desktop app, Verve AI Interview Copilot stays invisible during screen share, so the support is there without being visible to the interviewer. Before the day of the interview, the separate Mock Interviews feature lets you run practice scenarios against realistic Power BI questions — the kind that start with a definition and pivot into a broken report — so you've already rehearsed the reasoning path before it counts. For a role where the interview tests your ability to think out loud through a data problem, Verve AI Interview Copilot is built for exactly that moment.
Conclusion
The interviews that go well aren't the ones where you remembered every DAX function. They're the ones where you could explain a broken report clearly, defend a model design decision without wobbling, and show that you know the difference between what belongs in Power Query and what belongs in a measure. That's what these questions are actually testing — not vocabulary, but reasoning under mild pressure with a specific scenario in front of you.
The fastest way to build that confidence is to rehearse the scenario questions first, not the definitions. Pick five of the debugging or service questions from this guide and practice walking through them out loud, naming the problem before the solution. That's the pattern interviewers recognize as real experience, and it's the one that holds up when the follow-up goes somewhere unexpected.
Jason Miller
Career Coach
