Last updated: October 13, 2026
By Jennifer Burdick, Recruiting Manager, KORE1
Power BI developer interview questions in 2026 should make the candidate predict what a DAX measure returns before anyone runs it, and say where each Power Query step actually executes. Building a chart is the easy part of the job. Reading a model is the hard part, and it is the part most interviews skip.
A paper and packaging converter in Appleton, Wisconsin, found that out over one quarter. About 900 people, six plants, invoices flowing out of Dynamics 365 Business Central into an Azure SQL warehouse. They hired a Power BI developer at $118,000 after a loop that asked him to build a bar chart from a sample file and explain a star schema. He did both well. Nobody on the panel could have asked a harder DAX question, because nobody on the panel wrote DAX.
Seven weeks in, the CFO opened the board pack and read the total row on the plant margin page. It said 187 percent.
Each plant row was correct. Only the total was wrong, which is the most dangerous kind of wrong, because it looks like a typo until somebody asks how it happened. The same month, the nightly refresh crept from 25 minutes to three hours and forty minutes. One Power Query step had merged a 41-million-row invoice table with a customer targets spreadsheet sitting in SharePoint, and from that step on, every row came across the wire to be filtered on the gateway machine. Two bugs. Neither one was exotic. Both were things a single printed question would have exposed.
Power BI reqs started landing on my desk at KORE1 back when half my clients still built their month-end packs in Power Pivot and called the whole thing “the Excel add-in.” These days they come through our Power BI developer staffing desk, and the calls I take after a bad Power BI hire tend to sound like the one from Appleton.
The commercial part, stated once. KORE1 earns a fee when a client hires a developer we introduced, so I would like your search to end with an offer. Nothing below needs us. Hand it to your panel and run it on your own referrals.
Some ground is already covered elsewhere, and I will not repeat it. Our BI developer interview questions take on modeling, governance, row-level security, and the requirements conversation, tool by tool. Which of the four Power BI profiles you are hiring, PL-300 versus DP-600, and three classic DAX build tasks are in the guide to hiring Power BI developers. Pay sits in the BI developer salary guide. The posting that comes before the loop is covered in our Power BI developer job description guide. This page is narrower. DAX and Power Query, read line by line.
Predict the Number Before Anyone Clicks Refresh
A Power BI developer interview is a structured test of whether a candidate can build and maintain semantic models, DAX measures, and Power Query transformations that return correct numbers at production scale. The useful version prints short measures and query steps on paper and asks the candidate to predict the result and explain the cause before anything runs.
Why paper? Because writing DAX is no longer the scarce skill. Copilot, ChatGPT, and a dozen forum threads will hand anyone a year-over-year measure in under a minute, and that measure will usually be fine. What the tools cannot do for your new hire is look at a total row that says 187 percent and know, without running anything, that an iterator summed six ratios. That is reading. Reading is the job.
SQL still matters underneath all of this. In the Stack Overflow 2026 Developer Survey, 58.4 percent of respondents said they use SQL, second only to JavaScript. So almost everyone you interview will claim it. Fine. The questions below assume the SQL screen already happened and go after the two languages that are specific to this seat.
Run each question the same way. Print it. Hide the answer. Ask what the visual will show, then ask why, then ask how they would fix it, and write down the order the candidate does those three things in, because the people who jump straight to a fix without predicting the number first tend to be the same people who ship a fix without checking the total row.
The DAX Half, One Printed Measure at a Time
Every measure here runs against the same small model, so set it up in the candidate’s head first. A Sales fact table with an order date and a ship date. A Date table. Customer, Product, Plant, and Region dimensions. One-to-many relationships, single direction, the way most well-built models start.
Why does the total row say 187 percent when every plant row looks right?
Margin % =
SUMX (
VALUES ( Plant[Plant] ),
DIVIDE ( [Margin], [Revenue] )
)This is the Appleton measure, nearly character for character. On a plant row, VALUES returns one plant, so SUMX adds up exactly one ratio and the answer is right. On the total row, VALUES returns all six plants, and SUMX adds six percentages together. Thirty-one plus twenty-eight plus thirty-four and so on. You get 187.
A strong candidate says “ratio of sums, not sum of ratios” inside the first thirty seconds and rewrites it as a plain DIVIDE of the two measures. A very strong one asks why somebody wrapped it in SUMX in the first place, because usually there was a reason, like a weighting rule from finance, and deleting the iterator would quietly break that rule. Listen for the second question. It is rarer.
A calculated column calls SUM in one version and a measure in the other. What does each customer row get?
-- Column added to the Customer table, version A Customer Sales A = SUM ( Sales[Amount] ) -- Version B, where [Total Sales] is defined as SUM ( Sales[Amount] ) Customer Sales B = [Total Sales]
Version A puts the grand total of every sale ever recorded on every single customer row. Version B gives each customer their own sales. Same arithmetic. Different answer. Very different.
The difference is context transition, and it is the concept that separates people who have debugged DAX from people who have copied it. A calculated column has a row context, and a row context does not filter anything by itself. When a measure is referenced in a row context, Microsoft’s CALCULATE documentation notes, context transition is automatic, so the current row becomes a filter. Candidates do not need to quote the term. They do need to know that version A is wrong and why wrapping it in CALCULATE fixes it. Most mid-level developers get there with a nudge. Some senior ones do not, which tells you something too.
The variable sits above CALCULATE. Why does last year’s number match this year’s?
Sales LY =
VAR CurrentSales = [Total Sales]
RETURN
CALCULATE ( CurrentSales, SAMEPERIODLASTYEAR ( 'Date'[Date] ) )Because the variable was already computed. Done. Frozen. Microsoft’s guidance on DAX variables puts it plainly: variables are always evaluated outside the filters the RETURN expression applies. By the time CALCULATE shifts the dates back a year, CurrentSales is a finished number. Nothing left to shift.
I like this one because it catches people who learned variables as a tidiness habit, which they are, and never learned the cost. The fix is to reference the measure inside CALCULATE instead of the variable. Good candidates fix it in one line and then mention that variables are still worth using everywhere else. That is the right instinct.
The sales manager filters to three of eight regions. Should the percentages add up to 100?
% of Region Total =
DIVIDE (
[Total Sales],
CALCULATE ( [Total Sales], ALL ( Region ) )
)As written, no. With three regions selected, the shares might add up to 41 percent, because ALL removes the slicer and the denominator is still the whole company. Swap in ALLSELECTED and the three visible regions add up to 100. REMOVEFILTERS behaves like ALL here.
The interesting answer is not the function name. It is the question back to you: what does the sales manager actually want to see? Share of the company, or share of what is on the screen? Both are legitimate. A candidate who picks one without asking has probably shipped a few percent-of-total visuals that confused somebody. Ask them about KEEPFILTERS as a follow-up if they are clearly senior. Most will not have needed it. A few will light up.
Sales has an order date and a ship date. How does a ship-date slicer work?
No code on this one. Just the question. Out loud.
Only one relationship between Sales and Date can be active, and in most models it is the order date. You want to hear USERELATIONSHIP inside a measure, which, per Microsoft’s reference, enables the inactive relationship only for the duration of that calculation. Then you want to hear the tradeoff. If users need to slice by order date and ship date at the same moment, on the same page, a second copy of the Date table is often simpler. And if the candidate proposes turning the relationship bidirectional to make the slicer work, slow down and ask what else that change touches. Microsoft’s own modeling guidance says to minimize bidirectional relationships because they hurt query performance and can produce confusing results. Somebody who reaches for that switch first has probably left a few of them behind in their last job.
One measure takes nine seconds. What do you open first?
The order matters more than the tools. Much more. A practiced answer starts in Performance Analyzer to find which visual and which query is slow, copies that query, and runs it in DAX Studio with server timings on. Then it splits the time. Storage engine time is the columnar VertiPaq scan, and it can run in parallel. Formula engine time is single-threaded, as SQLBI’s explanation of the two engines lays out, so a measure that pushes row-by-row logic into the formula engine gets slow in a way more hardware will not fix. The classic culprit is an IF inside a SUMX over forty million rows. Anyone who says “I would add more capacity” before they have looked at server timings is guessing.
Two smaller questions belong here if the candidate is doing well. First, the model has thirty base measures and somebody has copied each one into YTD, prior year, and year-over-year versions, so there are 120 measures nobody can maintain. What would you do? Calculation groups, which have been authorable right in Power BI Desktop since the May 2024 release. Second, when would you write a visual calculation instead of a model measure? Visual calculations reached general availability in May 2026, so this is a fair test of who keeps up. A good answer says a visual calculation lives inside one visual and is fine for a running sum nobody else needs, while anything finance will quote in a meeting belongs in the model, where it can be reused and governed.
Power Query Is Where the Refresh Window Goes
Most interviews give Power Query one question, if that. It deserves fifteen minutes, because this is where the Appleton refresh went from 25 minutes to almost four hours, and nobody saw it until the gateway machine started paging the infrastructure team at 2 a.m.
Give the candidate a list of applied steps for a query against a SQL Server source and ask a single thing. Which of these steps still folds back to the database?
| Applied step | Usually folds? | What a good candidate says about it |
|---|---|---|
| Source (SQL Server table) | Yes | The starting point. Everything after it is translated into SQL for as long as the chain holds. |
| Filtered rows on InvoiceDate | Yes | Becomes a WHERE clause. Should sit as early as possible. |
| Removed other columns | Yes | Becomes a narrower SELECT. Cheap, and it also shrinks the model. |
| Merged with CustomerTargets.xlsx from SharePoint | No | Two different sources cannot be combined inside one SQL statement, so the engine pulls the rows and joins them locally. This is the Appleton step. |
| Changed type, after the merge | No | Once folding breaks, the steps after it run locally too. Order matters. |
| Added index column | Often no | Frequently breaks folding on relational sources. Ask why they need it at all. |
Then ask how they would check. In Power BI Desktop the honest answer is right-clicking a step and seeing whether View Native Query is available, with the caveat that availability depends on the connector. The colored folding indicators people sometimes describe are, according to Microsoft’s Power Query documentation, only in Power Query Online. A candidate who knows that distinction has spent time in dataflows as well as Desktop. Useful to know either way.
The fix for Appleton, by the way, was boring. Load the targets spreadsheet as its own small table and relate it in the model instead of merging it into the fact query, which took their developer about forty minutes once someone pointed at the step, and brought the nightly refresh from three hours and forty minutes back down to twenty-two. Boring fixes are the best kind.
The error says Formula.Firewall. What happened, and what is the fix that is not a checkbox?
The full message reads: “Formula.Firewall: Query ‘Query1’ (step ‘Source’) references other queries or steps, so it may not directly access a data source. Please rebuild this data combination.” Every Power BI developer has seen it. Few explain it well.
What happened is that one query reached into another query that touches a different data source, and the privacy firewall stopped it from possibly sending data from one source to the other. A good answer talks about restructuring the queries so the data access and the combination happen in a sensible place, and about setting privacy levels deliberately. A weak answer is “turn on Ignore the Privacy Levels.” That works on the developer’s laptop. Then someone asks what the gateway in production is set to, and the conversation gets quiet.
A column was renamed in the source file and last night’s refresh failed. Why there?
The automatic Changed Type step. For Excel and CSV sources, Power Query writes it the moment a table lands, and it lists every column by name, so a rename upstream breaks the step with a “column wasn’t found” error. Candidates who have been burned delete the automatic type step, type only the columns they use, and select columns explicitly with Table.SelectColumns and MissingField.UseNull where a missing column should not stop the whole refresh. Ten seconds of answer. Years of pain behind it.
Set up incremental refresh on a 60-million-row table. What has to be true first?
Two parameters named RangeStart and RangeEnd, both Date/Time, both spelled exactly that way because the names are reserved. A filter on the date column that uses them, with one boundary inclusive and the other exclusive so a row on the boundary is not counted twice. And the important part. Microsoft’s incremental refresh overview says the final query does not have to fold, but the step that applies the RangeStart and RangeEnd filter does. If it cannot fold, the engine may apply the filter locally after retrieving all rows. Which means every refresh pulls the whole table anyway. You set up incremental refresh and got a full refresh with extra steps.
A candidate who mentions that Power BI Desktop warns when it cannot confirm folding has configured this for real. One who has never heard of the boundary rule has probably only read about it.
Sixty Minutes, Laid Out
Most panels ask for the timing, so here is the version we hand clients. Print the measures and the step list before the candidate arrives. Keep the answers on a separate page the panel can see and the candidate cannot.
| Minutes | On the table | What the panel is listening for |
|---|---|---|
| 0 to 5 | A sketch of the six-table model | Whether they ask about grain and relationship direction before anything else |
| 5 to 30 | Four printed measures, then the ship-date question | A prediction first, then a cause, then a fix, in that order |
| 30 to 45 | The applied-steps list, the firewall message, the renamed column | Where each step runs, and whether they would check instead of guess |
| 45 to 55 | The nine-second measure and incremental refresh | A method, in order, with named tools |
| 55 to 60 | Their questions for you | Whether they ask who else writes measures in your tenant |
That last row is not filler. Some of the best candidates I have placed spent their five minutes asking how many people can publish to the production workspace, who approves a change to a shared measure, and whether anyone has ever deleted a dataset that four other reports depended on. They were already doing the job. Already.
Some answers should end the interview early, or at least change the grade:
- “I would just add a calculated column.” Said to the 187 percent question, it means they did not see the iterator.
- Silence on the variable question, followed by a guess that DAX “caches things.” Not fatal for a mid-level hire. Fatal for a lead.
- Making every relationship bidirectional so the slicers work.
- “Ignore the Privacy Levels,” with no follow-up about the gateway.
- Any answer to the nine-second question that begins with buying something.
The Candidate Who Could Not Spell SAMEPERIODLASTYEAR
Lubbock, Texas. A regional bank with about 600 employees, a loan book heavy on cotton gins and feedlots, and a senior Power BI seat that had been open since February. Their old loop was a forty-five-minute live build in Power BI Desktop with a panelist watching over a shared Teams screen, and it had already rejected two people our desk liked.
We talked them into the paper version in April.
The finalist they hired would have failed the old loop, and she told them so before they asked. Six years building credit-risk reporting, most of it on a model somebody else had started in 2019. She looks up SAMEPERIODLASTYEAR every time. Every single time. She does not trust her spelling of it, and she said that out loud to a panel of three people deciding whether to pay her six figures, which I thought was a gamble.
It was not. On paper she called all four measures, explained why version A of the calculated column repeats the company’s grand total on every customer row, and was the only finalist of three who flagged the SharePoint merge as the step where folding died. The other two had prettier portfolios. One had a DP-600.
She started at $126,000 in May. By the following spring the bank’s 140 copied time-intelligence measures had become one calculation group with seven items, and the 6:15 a.m. refresh that used to finish around 8:40 was done before 7:30. Their head of analytics called me in March to say the old loop would have hired whoever typed fastest. Probably. Typing is cheap now.
Overheard in the Hallway After the DAX Round
Paper or a laptop with Power BI Desktop open?
Paper for the reading questions, because prediction is the skill you are testing and a running model gives the answer away in one click.
If you want to see them build as well, add a short take-home or a second sitting with Desktop open. Do not combine the two in one hour. You end up watching someone fight a borrowed laptop.
Can the candidate use Copilot or ChatGPT during the exercise?
Let them, on the build portion only, since your developer will use those tools on the job and you learn something from watching them check the output.
The reading questions stay tool-free. An assistant will write a correct-looking measure for the 187 percent problem. It will not tell you whether the candidate would have noticed the total row in a board pack, and that is the thing you are paying for.
Our developer only builds reports on a shared semantic model. Do we still need the DAX half?
Less of it. Keep the percent-of-total and variable questions, drop the performance and calculation group questions, and spend the saved time on report design and the people who will read the report.
Report developers write measures too, mostly in thin report files on top of a shared model, and the variable mistake shows up there as often as anywhere.
How many questions fit in a single hour?
Eight to ten, in our experience, as long as the measures are printed in advance and the panel does not explain the model from scratch for each one.
What if every finalist misses the context transition question?
Then you have learned something about the market or about the question, so check which before you reject everyone.
Try it on the strongest Power BI person you already employ. If they miss it too, the wording is the problem. If they get it in ten seconds, your finalists are thinner than their resumes, and it may be time to widen the search or bring in a contract Power BI developer while you keep looking. Contract seats in this stack often fill faster, because people between projects are easier to reach.
Who on our side should run the DAX half?
Someone who writes DAX weekly, even if they are a contractor or a peer from another team, because a panelist who cannot grade the answer will default to grading confidence.
Confidence is cheap in this field. Everybody has built a dashboard. Few have fixed one.
Print the Measure, Hide the Answer
Before any candidate sees these questions, give them to the person on your team you trust most with the model. Time them. Strike anything they find ambiguous, and add a measure from your own tenant that once returned something strange. A real bug from your own reports is worth more than anything on this page, because it is the bug the new hire will meet.
Then write down what a right answer sounds like, before the first interview. Panels that do this argue less in the debrief. They also hire faster. Noticeably.
If you would like a second read on the loop, or a shortlist of Power BI developers who have already been through this kind of reading exercise, send the role to our analytics recruiters. Our own numbers, since this page keeps telling you to check them. Our IT searches average 17 days from intake to accepted offer, and 92 percent of the people we place are still with the client twelve months later.
