150+ DAX Interview Questions and Answers (2026 Guide)

If you've made it through a Power BI dashboard-building round only to freeze the moment someone asks "why doesn't this measure total correctly when I add a slicer?" — you already understand the gap this guide is built to close. Knowing Power BI's interface is one skill. Understanding DAX's evaluation model deeply enough to predict why a formula behaves the way it does is a completely different one, and it's the one that actually gets tested.

DAX interview questions are widely considered the hardest part of a Power BI interview, and for a good reason: DAX doesn't calculate top-to-bottom like Excel or return a fixed result set like a single SQL query. Every DAX expression is evaluated inside a context — a row context, a filter context, or both — and that context can shift mid-calculation through a mechanism called context transition. Interviewers ask DAX-specific questions precisely because this evaluation model is where genuine understanding separates itself from surface-level tool familiarity. A candidate who can build a pretty dashboard by dragging fields around isn't the same as a candidate who can explain why a measure returns a different number inside a matrix visual than it does in a card.

That gap between "knows Power BI" and "understands DAX" is exactly why this topic eliminates so many otherwise-strong candidates. You can watch dozens of tutorials, follow along with every click, and still freeze the moment an interviewer asks you to reason through an unfamiliar formula live — because tutorials show you what to type, not why the engine evaluates it the way it does.

This guide is organized to close that gap completely. It starts with why DAX matters and how companies actually test it, moves through 150+ questions grouped by real DAX topic — from calculated columns and measures through row context, CALCULATE, iterator functions, time intelligence, and performance optimization — with explanations built around why each formula behaves the way it does, not just what to type. From there it covers real business scenarios across ten dashboard domains, real company interview patterns, 20+ hands-on case studies with full solutions, the mistakes that quietly sink otherwise-capable candidates, a complete cheat sheet, and a 30-day plan to get from "I can build a dashboard" to genuinely DAX-fluent.

Who this guide is for: Power BI beginners and students building their first dashboards, Data Analysts and Business Analysts who use Power BI regularly but haven't formalized their DAX understanding, and BI Developers and Reporting Analysts preparing for a technical round that will specifically probe evaluation context and optimization. Use the table of contents above to jump straight to what you need.

Why DAX Matters in 2026

Career demand. Power BI remains one of the most widely adopted BI tools in enterprise environments in India and globally, and DAX is the language that makes a Power BI report do anything beyond displaying raw numbers — job postings for Data Analyst, BI Developer, and Power BI Developer roles consistently list DAX as a core, non-negotiable requirement, not an optional extra.

Salary impact. Candidates who can write genuinely correct, efficient DAX — not just drag-and-drop visuals — typically command a meaningful premium over candidates who only know Power BI's interface superficially, because DAX fluency directly determines whether a dashboard's numbers can actually be trusted under real business conditions like filtering, drill-down, and year-over-year comparison. See the broader picture in the Data Analyst Salary in India guide.

Industries using DAX. Retail, e-commerce, BFSI, manufacturing, healthcare, and consulting all rely heavily on Power BI for executive and operational reporting — DAX is the layer that turns a raw data model into the KPIs, trends, and comparisons those industries actually make decisions from.

Power BI market growth. Power BI has continued to expand its presence in enterprise BI stacks year over year, driven by its tight integration with the Microsoft ecosystem (Excel, Azure, Microsoft Fabric) and its comparatively lower licensing cost versus some competitors — this sustained adoption is exactly why DAX skill continues to compound in value rather than becoming a niche, dated skill.

Importance for Data Analysts. For a Data Analyst, DAX is usually the second major technical skill after SQL — SQL gets the data, DAX turns it into decision-ready metrics inside a report stakeholders actually look at. Weak DAX skills cap how independently an analyst can build and maintain their own reporting without relying on someone else.

Importance for BI Developers. For a dedicated BI Developer, DAX fluency (alongside data modeling and Power Query) is the core of the job — deep, correct, and performant DAX is what separates a BI Developer from someone who merely operates the Power BI interface.

📋 Not sure how your current DAX level compares to what interviews actually expect? The Data Analyst Roadmap 2026 lays out exactly what "interview-ready" Power BI and DAX looks like at each stage.

How Companies Conduct Power BI Interviews

Resume screening. Recruiters and ATS systems scan for Power BI-specific keywords (DAX, Power Query, data modeling, specific function names) and a coherent portfolio of real dashboards — a resume claiming "Power BI skills" with no dashboard to show rarely survives this stage.

Power BI dashboard round. You're asked to build or extend a dashboard live, from a provided dataset — testing data modeling instincts, visual choice, and DAX measure-writing together, not DAX in isolation.

DAX round. A focused, conversational or live-coding segment specifically on formula-writing and evaluation context — "write a measure that calculates X," or "why does this measure return a different number here versus there?"

Case study round. More common at consulting and Big 4 firms — a business problem requiring you to design an approach (which measures, which model structure) before or instead of writing the exact DAX syntax live.

Live problem solving. Given an unfamiliar model and dataset, you're asked to solve a specific business question on the spot, often screen-shared — this tests real fluency far more than a rehearsed, memorized measure ever could.

Business scenarios. A plain-English business ask ("marketing wants year-over-year growth by campaign") that you must translate into the correct DAX approach — testing whether you can bridge business language and DAX logic.

Optimization round. More common in senior or dedicated BI Developer interviews — "this report is slow, how would you investigate and fix it?" — testing understanding of the storage engine, formula engine, and model design, not just correct syntax.

🎯 The single biggest DAX prep mistake: memorizing formulas instead of understanding evaluation context. Every question below explains the "why," not just the "what" — build your intuition there first.

Top 150+ DAX Interview Questions

Examples throughout reuse a single, realistic star-schema model so you can focus on the DAX logic itself, not re-learning a new schema every time:

Sales (fact table): SalesID, OrderDate, CustomerKey, ProductKey, EmployeeKey, Quantity, UnitPrice, SalesAmount, CostAmount
Customers (dimension): CustomerKey, CustomerName, City, Segment
Products (dimension): ProductKey, ProductName, Category, SubCategory
Employees (dimension): EmployeeKey, EmployeeName, Region
'Date' (dimension, marked as Date Table): Date, Year, MonthName, MonthNumber, Quarter

All dimension tables connect to Sales via one-to-many relationships (the standard star schema), and 'Date'[Date] is marked as the model's official Date Table for time intelligence.

Basic DAX Concepts

1. What is DAX, and what is it fundamentally designed to do? Beginner

Answer: DAX (Data Analysis Expressions) is the formula language used in Power BI, Power Pivot, and Analysis Services to create measures, calculated columns, and calculated tables. Unlike Excel formulas, which operate cell-by-cell, DAX is designed to work across entire tables and relationships in a data model, aware of filters and context applied by a report.

Why interviewers ask this: A basic warm-up question, but a candidate who describes DAX as "just like Excel formulas" without mentioning its model-and-context awareness signals a shallow understanding that usually shows up again later in the interview.

2. What is the difference between DAX and a traditional programming language? Beginner

Answer: DAX is a functional, declarative formula language purpose-built for analytical calculations over tabular data — it has no loops or traditional variable mutation in the imperative sense (VAR in DAX is more like a named, immutable intermediate result), and every expression ultimately returns either a scalar value or a table.

3. What is a data model in Power BI, and why does DAX depend on it? Beginner

Answer: A data model is the collection of tables and the relationships between them, loaded into Power BI's engine. DAX depends on it because filter propagation — how a filter on one table (like Date) affects a calculation on another table (like Sales) — flows entirely through the relationships defined in that model; the same DAX formula can behave completely differently in two models with different relationships.

Real Power BI example: Filtering a report by Products[Category] correctly filters Sales[SalesAmount] only because a relationship exists between Products and Sales — without that relationship, the filter simply wouldn't propagate, regardless of how correct the DAX formula itself is.

4. What is the difference between DAX and M (Power Query's language)? Intermediate

Answer: M is used in Power Query to import, clean, and shape data before it enters the model. DAX operates after the data is loaded, calculating measures and columns based on the model's existing structure. A useful way to frame it: M answers "how do I get and clean the data," DAX answers "how do I calculate something from the data I already have."

More DAX basics questions to be ready for:

Measures, Calculated Columns & Calculated Tables

1. What is the difference between a measure and a calculated column? Beginner

Example:

-- Calculated Column (row-by-row, stored)
Profit = Sales[SalesAmount] - Sales[CostAmount]

-- Measure (dynamic, recalculated per filter context)
Total Profit = SUM(Sales[SalesAmount]) - SUM(Sales[CostAmount])

Detailed Answer: A calculated column is computed once per row at data refresh time, using row context, and its result is physically stored in the model — increasing model size. A measure is calculated dynamically at query time, based on whatever filter context is active (the selected region, date range, or category on the report), and isn't stored anywhere; it recalculates fresh every time.

Why interviewers ask this: It's the single most frequently asked DAX question because it tests the foundational distinction the rest of DAX builds on — get this wrong, and most follow-up questions about context become impossible to answer correctly.

Common mistake: Using a calculated column for something that should be a measure (like a total that needs to respond to filters) — the calculated column locks in its value at refresh time and won't update dynamically with report interaction the way a measure does.

Follow-up you should expect: "When would you deliberately choose a calculated column over a measure?" — Answer: when you need the value for slicing, sorting, grouping, or building a relationship — measures can't be used in any of those roles.

2. What is an implicit measure, and why do experienced DAX developers avoid them? Intermediate

Answer: An implicit measure is created automatically when you drag a numeric column directly into a visual and Power BI auto-aggregates it (e.g., defaulting to Sum), without you writing any DAX. Experienced developers generally avoid relying on them because implicit measures can't be reused across other measures, don't support custom logic, and are harder to maintain and audit at scale in a larger model.

3. What is an explicit measure? Beginner

Example: Total Sales = SUM(Sales[SalesAmount]) written manually in the modeling view — an explicit measure, deliberately created and named, as opposed to Power BI auto-generating one.

Why it matters: Explicit measures are considered best practice specifically because they're documented, reusable in other DAX expressions, and testable — a mature Power BI model relies almost entirely on explicit measures rather than implicit ones.

4. What is a calculated table, and what's a real use case? Intermediate

Example:

Top Customers = 
TOPN(10, SUMMARIZE(Sales, Customers[CustomerName], "Total", SUM(Sales[SalesAmount])), [Total], DESC)

Explanation: A calculated table is generated entirely by a DAX expression rather than imported from a source — here, producing a physical table of the top 10 customers by sales, refreshed alongside the rest of the model.

Real Power BI example: Building a disconnected date table with CALENDAR/CALENDARAUTO when no date table exists in the source data, or creating a what-if parameter table for scenario analysis.

5. Why is it considered best practice to build a dedicated Date table rather than relying on auto date/time? Intermediate

Answer: A dedicated Date table (marked explicitly as the model's Date Table) gives full control over the calendar — fiscal years, custom holidays, working-day flags — and is required for time intelligence functions like TOTALYTD and SAMEPERIODLASTYEAR to behave correctly and predictably. Power BI's auto date/time feature generates a hidden, less flexible calendar per date column, which is generally discouraged in production models both for performance and consistency reasons.

More measures, columns & tables questions to be ready for:

📈 The measure-vs-column distinction is the single highest-leverage concept to nail before any Power BI interview — everything else in this guide builds on it. Get hands-on practice building real measures inside the DataVix Power BI curriculum.

Row Context, Filter Context & Context Transition

This is consistently the topic that separates strong DAX candidates from average ones — expect at least one deep question here in any technical round beyond pure entry-level screening.

1. What is row context in DAX? Intermediate

Example:

Profit = Sales[SalesAmount] - Sales[CostAmount]

Explanation: Row context is the engine's awareness of a "current row" during evaluation. It exists naturally when defining a calculated column (evaluated once per row of the table) and inside iterator functions like SUMX — but critically, it does not exist automatically in a plain measure.

Why interviewers ask this: Nearly every "why doesn't this DAX work the way I expected" bug traces back to a misunderstanding of when row context does or doesn't exist — this question checks that foundational awareness directly.

2. What is filter context in DAX? Intermediate

Example: In a Power BI matrix visual showing SalesAmount by Region, each cell's filter context includes "Region = the row's specific value" — the measure SUM(Sales[SalesAmount]) recalculates for every cell based on that specific filter.

Explanation: Filter context is the set of active filters — from slicers, visual rows/columns, page filters, and report filters — that determines exactly which rows are visible to a calculation at any given evaluation point.

Real Power BI example: The same measure, Total Sales = SUM(Sales[SalesAmount]), returns a different number in a card visual with no filters (grand total) than it does in a table row filtered to a specific region — because filter context, not the formula itself, changed.

3. What is context transition, and why is it one of the most misunderstood DAX concepts? Advanced

Example:

Sales Per Employee Avg = AVERAGEX(Employees, [Total Sales])

Explanation: Context transition happens when a row context needs to be converted into an equivalent filter context — this occurs automatically whenever CALCULATE is used (explicitly, or implicitly inside an iterator that calls a measure). In this example, AVERAGEX iterates row by row over Employees; for each row, referencing the [Total Sales] measure triggers context transition — the current employee's row context is converted into a filter context of "Employees[EmployeeKey] = this employee," so [Total Sales] correctly returns just that employee's sales, not the whole table's.

Why interviewers ask this: It's considered the single most conceptually difficult DAX topic, and specifically distinguishes candidates with genuine, hands-on DAX experience from those who've only followed tutorials — very few surface-level learners can explain it correctly and confidently.

Common mistake: Assuming a measure referenced inside a row-context situation (like a calculated column or an iterator) automatically "knows" the current row without realizing that context transition — triggered by CALCULATE under the hood — is the actual mechanism making that possible.

Follow-up you should expect: "Does referencing a column directly (not a measure) inside a row-context calculation also trigger context transition?" — Answer: no, context transition is specifically triggered by CALCULATE (explicit or implicit); a direct column reference inside row context just reads that row's value directly, no transition needed.

4. What is the difference between evaluation context and filter propagation? Advanced

Answer: Evaluation context (row context + filter context) determines what's visible to a calculation at a given point. Filter propagation is the separate mechanism by which a filter on one table flows to related tables through relationships — evaluation context is about the calculation itself; filter propagation is about how that context reaches across the model's tables in the first place.

More context questions to be ready for:

CALCULATE, CALCULATETABLE & Filter Modifiers

1. What does CALCULATE do, and why is it considered DAX's most important function? Intermediate

Example:

Sales 2025 = CALCULATE([Total Sales], 'Date'[Year] = 2025)

Explanation: CALCULATE evaluates an expression (here, the [Total Sales] measure) within a modified filter context — overriding the normal filter context to force the calculation to only consider rows where Year equals 2025, regardless of what's selected elsewhere on the report.

Why interviewers ask this: CALCULATE is the only DAX function that can directly modify filter context, making it the foundation for nearly every advanced DAX pattern — time intelligence, ranking, percent-of-total, and more are all built on top of it in some form.

Common mistake: Assuming CALCULATE's filter arguments simply "add" a condition on top of the existing context — in reality, a filter argument on a column replaces any existing filter on that same column, rather than combining with it (unless KEEPFILTERS is used).

2. What is the difference between CALCULATE and CALCULATETABLE? Intermediate

Answer: CALCULATE modifies filter context and returns a scalar (single value); CALCULATETABLE does the same filter-context modification but returns a table instead — used when you need the actual filtered rows, not just an aggregated number.

3. What does the FILTER function do, and how is it different from a simple filter argument in CALCULATE? Intermediate

Example:

High Value Sales = CALCULATE([Total Sales], FILTER(Sales, Sales[SalesAmount] > 10000))

Explanation: FILTER builds a custom table of rows matching a row-by-row condition, iterating over the full Sales table — used inside CALCULATE for logic too complex for a simple column-based filter argument (like 'Date'[Year] = 2025), which CALCULATE can evaluate more efficiently on its own without a full row-by-row FILTER.

Why interviewers ask this: A common trap question — many candidates default to wrapping every condition in FILTER out of habit, when a simple boolean filter argument would be both simpler and better-performing; knowing when each is actually necessary is the real signal.

4. What does ALL do, and what's a real example? Intermediate

Example:

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

Explanation: ALL removes filters from a table (or specified columns), most commonly used inside CALCULATE to compute a total unaffected by whatever's currently selected — here, calculating a percent-of-grand-total that stays meaningful no matter how the report is filtered.

5. What is the difference between ALL, ALLSELECTED, and ALLEXCEPT? Advanced

Example:

All Sales = CALCULATE([Total Sales], ALL(Sales))
Selected Sales = CALCULATE([Total Sales], ALLSELECTED(Sales))
Sales Except Region = CALCULATE([Total Sales], ALLEXCEPT(Sales, Sales[Region]))

Explanation: ALL removes every filter on the table entirely, ignoring even slicers. ALLSELECTED removes filters added within the current visual's own context but respects filters applied outside it (like a report-level slicer) — commonly used for "percent of what the user has currently selected" calculations. ALLEXCEPT removes all filters from a table except the specific columns listed, useful when you want most filters cleared but one or two preserved.

Why interviewers ask this: This trio is one of the most consistently confused areas in real-world Power BI development — a wrong choice among the three produces a plausible-looking but subtly incorrect number, exactly the kind of bug interviewers want to confirm you can avoid.

6. What does REMOVEFILTERS do, and how is it different from ALL? Advanced

Answer: REMOVEFILTERS (introduced as a more explicit, readable alternative) removes filters exactly like ALL does when used inside CALCULATE — the difference is primarily naming clarity; REMOVEFILTERS makes the intent unambiguous to someone reading the code later, whereas ALL can be confused with its table-returning usage outside of CALCULATE.

7. What does KEEPFILTERS do? Advanced

Example:

Sales Keep Filters = CALCULATE([Total Sales], KEEPFILTERS('Date'[Year] = 2025))

Explanation: By default, a filter argument inside CALCULATE replaces any existing filter on that column. KEEPFILTERS changes this behavior so the new filter is instead combined (intersected) with the existing filter context, rather than overriding it — useful when you want to narrow down further, not reset entirely.

More CALCULATE & filter modifier questions to be ready for:

VALUES, DISTINCT, SELECTEDVALUE & Filter State Functions

1. What is the difference between VALUES and DISTINCT? Intermediate

Answer: Both return a single-column table of unique values, but VALUES also includes an extra blank row representing unmatched rows (rows that exist due to a relationship with no match), if such unmatched rows exist in the model's data — DISTINCT never includes that blank row.

2. What does SELECTEDVALUE do, and why is it preferred over checking HASONEVALUE manually? Intermediate

Example:

Selected Category = SELECTEDVALUE(Products[Category], "Multiple Categories")

Explanation: SELECTEDVALUE returns the single value of a column if exactly one value is currently in filter context (e.g., one category is selected in a slicer), or a specified fallback value otherwise — it's a clean shorthand for the older, more verbose pattern of IF(HASONEVALUE(...), VALUES(...), "fallback").

Real Power BI example: Displaying a dynamic card title that shows the specific product category name when a user filters to one, or a generic label like "All Categories" when they haven't.

3. What does HASONEVALUE do? Intermediate

Answer: Returns TRUE if exactly one distinct value remains in the current filter context for a specified column, FALSE otherwise — commonly used to control conditional logic, like showing a specific value only when a slicer selection has been narrowed to a single item.

4. What is the difference between ISFILTERED and ISCROSSFILTERED? Advanced

Answer: ISFILTERED checks whether a specific column has a direct filter applied to it. ISCROSSFILTERED checks whether a column is filtered either directly or indirectly through a relationship (cross-filtering from a related table) — a broader check than ISFILTERED alone.

More VALUES, DISTINCT & filter state questions to be ready for:

Relationships: RELATED, RELATEDTABLE, LOOKUPVALUE & Filter Direction

1. What is the difference between RELATED and RELATEDTABLE? Intermediate

Example:

-- RELATED: pulls a single value from the "one" side into the "many" side
Category = RELATED(Products[Category])

-- RELATEDTABLE: pulls a full related table from the "one" side, used inside an iterator
Product Count = COUNTROWS(RELATEDTABLE(Sales))

Explanation: RELATED is used within row context on the "many" side of a relationship to pull a single value from the related "one" side (like getting each sale's product category). RELATEDTABLE does the reverse — from the "one" side, it returns the full related table of matching rows on the "many" side, used inside an iterator or aggregate function.

Why interviewers ask this: A frequent, direct comparison question — mixing these up (or not understanding which direction each works) signals a shaky grasp of how relationships and row context interact.

2. What is LOOKUPVALUE, and when would you use it instead of RELATED? Advanced

Example:

Employee Region = LOOKUPVALUE(Employees[Region], Employees[EmployeeKey], Sales[EmployeeKey])

Explanation: LOOKUPVALUE retrieves a value from a table by matching one or more specified conditions — similar in spirit to Excel's VLOOKUP. Unlike RELATED, it works even without an existing modeled relationship between the tables, though it comes at a performance cost compared to using a proper relationship where one is possible.

Common mistake: Reaching for LOOKUPVALUE as a default habit when a proper relationship (using RELATED) would be simpler, more maintainable, and better-performing — LOOKUPVALUE should generally be a fallback, not a first choice.

3. What is the difference between USERELATIONSHIP and CROSSFILTER? Advanced

Example:

Sales by Ship Date = CALCULATE([Total Sales], USERELATIONSHIP(Sales[ShipDate], 'Date'[Date]))
Bidirectional Sales = CALCULATE([Total Sales], CROSSFILTER(Sales[CustomerKey], Customers[CustomerKey], BOTH))

Explanation: USERELATIONSHIP activates a specific inactive relationship for the duration of one CALCULATE expression — useful when a table has multiple possible relationships to another (like both OrderDate and ShipDate connecting Sales to the Date table), only one of which can be active by default. CROSSFILTER instead changes the filter direction (single vs both) of a relationship, or disables it entirely, for that expression's evaluation.

4. What is the difference between a single-direction and bidirectional relationship, and what's the risk with bidirectional? Advanced

Answer: A single-direction relationship lets filters flow only from the "one" side to the "many" side (the standard, recommended default in a star schema). A bidirectional relationship also lets filters flow the other way — from "many" back to "one" — which can be useful in specific scenarios but risks creating ambiguous filter paths and unexpected results in more complex models, especially with multiple fact tables, and can also introduce performance overhead.

More relationships questions to be ready for:

🔗 Relationship-and-context questions are where DAX interviews most reward real, hands-on model-building experience over textbook memorization — practicing on a genuine multi-table star schema, not a single flat table, is what actually builds this intuition.

Iterator (X) Functions: SUMX, AVERAGEX, COUNTX, MINX, MAXX

1. What is the difference between SUM and SUMX? Intermediate

Example:

-- SUM: aggregates an already-existing column directly
Total Sales = SUM(Sales[SalesAmount])

-- SUMX: calculates an expression per row first, then sums the results
Total Sales Calculated = SUMX(Sales, Sales[Quantity] * Sales[UnitPrice])

Explanation: SUM directly aggregates a single existing column. SUMX is an iterator — it evaluates a given expression row-by-row across a table first (creating implicit row context for each row), then sums those per-row results. SUMX is required whenever the calculation itself, not just the aggregation, must happen per row.

Why interviewers ask this: Tests whether you understand that "X" functions iterate — this is foundational to understanding every other iterator function that follows the same pattern.

Common mistake: Using SUM on a column that doesn't actually exist pre-calculated (like SalesAmount when only Quantity and UnitPrice are stored separately) instead of correctly using SUMX to calculate it row-by-row first.

2. What does AVERAGEX do, and what's a real business example? Intermediate

Example:

Avg Order Value = AVERAGEX(VALUES(Sales[SalesID]), [Total Sales])

Explanation: AVERAGEX evaluates an expression for each row of a table (here, each unique order), then averages those results — different from a plain AVERAGE on an existing column, since the per-order total itself has to be calculated first via context transition on the [Total Sales] measure.

Real business example: Calculating true average order value when SalesAmount is recorded at the line-item level, not the order level — a plain AVERAGE on line items would incorrectly average individual line amounts instead of full order totals.

3. What do COUNTX, MINX, and MAXX do? Intermediate

Example:

Orders Above Threshold = COUNTX(Sales, IF(Sales[SalesAmount] > 5000, 1))
Best Single Sale = MAXX(Sales, Sales[SalesAmount])

Explanation: COUNTX counts non-blank results of an expression evaluated per row (here, counting rows where the condition is true); MAXX/MINX find the highest/lowest result of an expression evaluated per row, which is different from MAX/MIN on a stored column when the value itself needs to be calculated first.

4. Why are iterator functions generally slower than their non-iterator equivalents, and when is that trade-off worth it? Advanced

Answer: Iterators evaluate their expression row-by-row, which the Formula Engine typically handles less efficiently than the Storage Engine's optimized bulk aggregation used by plain SUM/AVERAGE/COUNT. The trade-off is worth it whenever the calculation genuinely requires row-level logic before aggregating (like Quantity × UnitPrice) — in those cases, there's no non-iterator alternative that produces a correct result.

More iterator function questions to be ready for:

Ranking & Top N: RANKX, TOPN

1. What does RANKX do, and how does it respect filter context? Advanced

Example:

Product Rank = RANKX(ALL(Products), [Total Sales], , DESC)

Explanation: RANKX calculates the rank of the current row's value (here, [Total Sales] for the current product) within a specified table expression — using ALL(Products) ensures the ranking is calculated against every product, not just the ones currently visible after filtering, so the rank stays meaningful even inside a filtered visual.

Why interviewers ask this: A very common practical dashboard requirement (rank products, salespeople, or regions), and it directly tests whether you understand how the ranking table argument interacts with filter context — a frequent source of "the rank looks wrong" bugs.

Common mistake: Forgetting to wrap the ranking table in ALL (or an equivalent), causing RANKX to rank only within the currently filtered subset instead of the full intended population — producing a rank of 1 for nearly everything inside a filtered view.

2. What does TOPN do, and how is it different from just sorting and taking the top rows in a visual? Intermediate

Example:

Top 5 Products = TOPN(5, SUMMARIZE(Sales, Products[ProductName], "Total", [Total Sales]), [Total], DESC)

Explanation: TOPN returns a table of the top N rows from a specified table, ordered by a given expression — used inside a calculated table or another DAX expression, as opposed to a visual's built-in "Top N" filter, which only affects what's displayed, not what's available for further DAX calculation.

Real business example: Building a calculated table of the top 10 customers to use as the basis for a separate, dedicated "VIP Customers" report page, which a visual-level Top N filter alone couldn't provide.

More ranking & Top N questions to be ready for:

Table Functions: ADDCOLUMNS, SUMMARIZE, SUMMARIZECOLUMNS, GENERATE, UNION, INTERSECT, EXCEPT

1. What does ADDCOLUMNS do? Advanced

Example:

Sales with Margin = ADDCOLUMNS(Sales, "Margin", Sales[SalesAmount] - Sales[CostAmount])

Explanation: ADDCOLUMNS takes an existing table expression and adds one or more new calculated columns to it, evaluated in row context — commonly used to build an intermediate table for further calculation, often inside a calculated table or a more complex nested expression.

2. What is the difference between SUMMARIZE and SUMMARIZECOLUMNS? Advanced

Example:

-- SUMMARIZECOLUMNS: the modern, recommended approach
Category Summary = SUMMARIZECOLUMNS(Products[Category], "Total Sales", [Total Sales])

-- SUMMARIZE (older approach)
Category Summary Old = SUMMARIZE(Sales, Products[Category], "Total Sales", SUM(Sales[SalesAmount]))

Explanation: Both group data and calculate aggregates per group, but SUMMARIZECOLUMNS is the newer, generally recommended function — it handles filter context more predictably and is what Power BI itself generates internally for most visuals. Microsoft's own guidance now recommends against using SUMMARIZE's extended syntax (adding aggregated columns directly within it) due to known filter-context edge cases, preferring SUMMARIZECOLUMNS or SUMMARIZE combined with ADDCOLUMNS instead.

Why interviewers ask this: A strong, senior-signaling answer specifically mentions the modern best-practice guidance, not just the mechanical syntax difference.

3. What does GENERATE do? Advanced

Answer: GENERATE returns a table that's the result of evaluating a second table expression for each row of a first table (similar to a SQL cross-apply/correlated join), commonly used to combine a table with a per-row calculated table result that a simple ADDCOLUMNS can't express.

4. What do UNION, INTERSECT, and EXCEPT do? Advanced

Example:

All Customers Combined = UNION(OnlineCustomers, StoreCustomers)
Customers In Both = INTERSECT(OnlineCustomers, StoreCustomers)
Online Only Customers = EXCEPT(OnlineCustomers, StoreCustomers)

Explanation: UNION stacks rows from two tables with matching structure (like SQL's UNION ALL — it keeps duplicates); INTERSECT returns only rows present in both tables; EXCEPT returns rows present in the first table but not the second — all requiring the same number and compatible types of columns across both tables.

More table function questions to be ready for:

Variables, Logical & Conditional Functions

1. What does VAR and RETURN do, and why are variables considered best practice? Intermediate

Example:

Profit Margin % = 
VAR TotalRevenue = SUM(Sales[SalesAmount])
VAR TotalCost = SUM(Sales[CostAmount])
RETURN DIVIDE(TotalRevenue - TotalCost, TotalRevenue)

Explanation: VAR defines a named, calculated-once intermediate value within a single expression; RETURN specifies the final result using those variables. Using variables avoids recalculating the same expression multiple times (each reference to SUM(Sales[SalesAmount]) without a variable would be evaluated fresh every time it appears), improving both readability and performance.

Why interviewers ask this: A strong, senior-signaling habit — candidates who default to VAR/RETURN in their example measures demonstrate real production experience, not just tutorial-level familiarity.

2. What does SWITCH do, and how is it different from nested IF? Intermediate

Example:

Sales Tier = 
SWITCH(
  TRUE(),
  [Total Sales] > 100000, "Platinum",
  [Total Sales] > 50000, "Gold",
  [Total Sales] > 10000, "Silver",
  "Bronze"
)

Explanation: SWITCH evaluates a series of value/result pairs and returns the result for the first match — using TRUE() as the tested expression (a very common pattern) lets each branch be an independent boolean condition, functioning like SQL's searched CASE WHEN. It's generally preferred over deeply nested IF statements for readability once there are more than 2-3 conditions.

3. What does the DIVIDE function do differently from the standard division operator? Beginner

Example: DIVIDE(Sales[Profit], Sales[Revenue], 0) returns 0 instead of an error when Revenue is zero, rather than Sales[Profit] / Sales[Revenue], which would return a divide-by-zero error.

Why it matters: DIVIDE is DAX best practice specifically because it safely handles division by zero — returning a specified alternate result (defaulting to BLANK if the third argument is omitted) instead of breaking the visual with an error.

4. What does COALESCE do in DAX? Intermediate

Example: COALESCE(Sales[DiscountCode], "No Discount") returns the first non-blank value from a list of expressions.

Why it matters: Functionally similar to Excel's or SQL's COALESCE, this is used to substitute a clean default value for BLANK results, common when combining data from multiple optional sources.

More variables & logical function questions to be ready for:

🧮 VAR/RETURN and SWITCH show up constantly in real production DAX — building the habit of using them by default, even in simple measures, is exactly the kind of practice built into real project work in the DataVix Data Analyst course.

Time Intelligence Functions

1. What does TOTALYTD do, and what does it depend on to work correctly? Intermediate

Example:

Sales YTD = TOTALYTD([Total Sales], 'Date'[Date])

Explanation: TOTALYTD calculates a running year-to-date total for the given expression, based on the currently active date filter — it depends entirely on 'Date'[Date] being part of a properly marked Date Table with a continuous, gap-free calendar for the calculation to behave correctly.

Why interviewers ask this: Time intelligence questions are asked in nearly every Power BI round because year-over-year and YTD comparisons are among the most universally requested business metrics — and getting them wrong due to a missing or improperly configured Date table is an extremely common real-world bug.

2. What is the difference between TOTALYTD and DATESYTD? Advanced

Example:

Sales YTD (TOTALYTD) = TOTALYTD([Total Sales], 'Date'[Date])
Sales YTD (DATESYTD) = CALCULATE([Total Sales], DATESYTD('Date'[Date]))

Explanation: TOTALYTD is a direct shortcut that returns the aggregated year-to-date value in one step. DATESYTD instead returns just a table of dates from the start of the year through the current filter context's latest date — you then wrap it in CALCULATE yourself with whatever aggregate expression you need, offering more flexibility when combining with other filter logic in the same CALCULATE call.

3. What does SAMEPERIODLASTYEAR do? Intermediate

Example:

Sales Last Year = CALCULATE([Total Sales], SAMEPERIODLASTYEAR('Date'[Date]))
Sales YoY Growth % = DIVIDE([Total Sales] - [Sales Last Year], [Sales Last Year])

Explanation: SAMEPERIODLASTYEAR shifts the current date filter context back exactly one year, returning the equivalent period from the prior year — combined with the current period's value, this is the standard building block for year-over-year growth calculations.

Real business example: A sales dashboard KPI card showing "+12% YoY" — built directly from this exact pattern.

4. What does DATEADD do, and how is it more flexible than SAMEPERIODLASTYEAR? Advanced

Example:

Sales Prior Month = CALCULATE([Total Sales], DATEADD('Date'[Date], -1, MONTH))

Explanation: DATEADD shifts the date filter context by any specified number of periods (days, months, quarters, or years) in either direction — SAMEPERIODLASTYEAR is functionally a convenient shortcut equivalent to DATEADD('Date'[Date], -1, YEAR).

5. What is the difference between PARALLELPERIOD and DATEADD? Advanced

Answer: DATEADD shifts the filter context by a specified count while preserving the exact day-level granularity of the current selection; PARALLELPERIOD shifts by whole periods (returning the entire prior month/quarter/year, not just the equivalent days), which matters specifically when the current selection is a partial period (e.g., only the first 10 days of the current month).

6. What do TOTALQTD and TOTALMTD do? Intermediate

Answer: Direct parallels to TOTALYTD, but for quarter-to-date and month-to-date running totals respectively — same underlying dependency on a properly configured Date table.

More time intelligence questions to be ready for:

📅 Time intelligence is one of the highest-frequency topics in real Power BI interviews — practicing TOTALYTD, SAMEPERIODLASTYEAR, and DATEADD on a real, properly-marked date table (not just reading the syntax) is what makes these instantly usable under interview pressure.

DAX Performance Optimization

1. What is the difference between the Storage Engine and the Formula Engine? Advanced

Answer: The Storage Engine (VertiPaq, in Import mode) handles fast, simple data retrieval and basic aggregation directly from the compressed, in-memory columnar data — it's highly parallelized and generally fast. The Formula Engine handles more complex DAX logic the Storage Engine can't compute directly (like many iterator and context-transition-heavy calculations) — it's single-threaded and comparatively slower. Optimizing a slow measure usually means restructuring it to push more work to the Storage Engine and less to the Formula Engine.

Why interviewers ask this: A genuinely senior-level distinction — knowing it exists (and how to reason about which engine handles which part of a query) is a strong signal of real, hands-on performance-tuning experience, not just tutorial familiarity.

2. What is the VertiPaq engine, and why does it matter for DAX performance? Advanced

Answer: VertiPaq is Power BI's in-memory, columnar storage engine used in Import mode — it compresses and stores data column by column (rather than row by row), which is highly efficient for the kind of aggregate calculations DAX performs constantly, and is a major reason Import mode significantly outperforms DirectQuery for most reporting workloads.

3. What is query folding, and why is it relevant to overall report performance? Advanced

Answer: Query folding is a Power Query concept — when Power Query pushes its transformation steps back to the source system (like a SQL Server database) to execute there, instead of pulling raw data and transforming it locally. It's relevant to a DAX-adjacent optimization conversation because refresh performance and DAX query performance are both part of the same overall report-performance picture an interviewer may probe together.

4. What are common causes of a slow DAX measure, and how would you investigate one? Advanced

Answer: Common causes include heavy reliance on iterator functions over very large tables, unnecessary calculated columns bloating the model, bidirectional relationships creating ambiguous or expensive filter paths, and repeated recalculation of the same sub-expression without using variables. A structured investigation uses Performance Analyzer (built into Power BI Desktop) to isolate which specific visual/measure is slow, then DAX Studio to examine the query plan and see the actual Storage Engine vs Formula Engine time split.

Real business example: "This dashboard takes 15 seconds to load — how would you investigate?" — Answer: start with Performance Analyzer to find the slowest visual, then examine that specific measure's DAX for unnecessary iterators, missing variables, or an overly complex filter chain, rather than guessing at a fix.

5. Why is it generally recommended to avoid calculated columns for anything that could be a measure? Intermediate

Answer: Calculated columns are computed and physically stored for every row at refresh time, increasing model size (and thus memory usage and refresh duration), and — unlike measures — don't recalculate dynamically in response to filter context. A measure is almost always the better default choice unless the row-level value is specifically needed for slicing, sorting, grouping, or as a relationship key.

More optimization questions to be ready for:

Statistical, Text & Information Functions

1. What do STDEV.P and STDEV.S calculate, and why does the choice between them matter? Advanced

Example: Sales Std Dev = STDEV.P(Sales[SalesAmount]) calculates standard deviation treating the current data as the entire population; STDEV.S(Sales[SalesAmount]) treats it as a sample and applies a small statistical correction.

Why interviewers ask this: Choosing the wrong one produces a subtly different number that's easy to miss — the correct choice depends on whether your table genuinely represents the full population being analyzed (use .P) or a sample drawn from a larger one (use .S).

2. What does MEDIAN do, and when would you prefer it over AVERAGE in a dashboard? Intermediate

Example: Median Order Value = MEDIAN(Sales[SalesAmount]).

Real business example: Reporting median deal size instead of average for a sales team with a few very large outlier deals — the same "resistant to outliers" reasoning that applies to Excel and SQL's median, carried over directly into DAX.

3. What does CONCATENATEX do, and what's a real use case? Advanced

Example:

Selected Products = CONCATENATEX(VALUES(Products[ProductName]), Products[ProductName], ", ")

Explanation: CONCATENATEX iterates over a table and joins a text expression from each row into a single delimited string — commonly used to build a dynamic "Selected Products: A, B, C" label reflecting the current filter context, something a plain measure returning a single value can't express.

4. What does ISBLANK check, and how is BLANK() different from an empty string? Intermediate

Answer: ISBLANK(expression) returns TRUE specifically when a DAX expression evaluates to BLANK — DAX's internal representation of "no value," distinct from an empty text string "" or a numeric 0. Many aggregate functions and visuals treat BLANK differently from either of those (for example, a card visual may render nothing at all for BLANK, but will still render "0").

5. What does FORMAT do in DAX? Intermediate

Example: FORMAT([Total Sales], "₹#,##0") converts a numeric measure result into a formatted text string for display purposes.

Common mistake: Using FORMAT on a value that's still being used in further numeric calculations — FORMAT returns text, not a number, so any downstream arithmetic on that result will fail; formatting should generally be the very last step, applied only for display.

More statistical, text & information function questions to be ready for:

Data Modeling for DAX: Star Schema, Calculation Groups & Storage Modes

1. What is a star schema, and why is it the recommended structure for Power BI models? Intermediate

Answer: A star schema has one central fact table (like Sales) connected to multiple dimension tables (Customers, Products, Date) via one-to-many relationships, forming a star shape. It's recommended because VertiPaq and DAX's filter-propagation model are both optimized around this structure — it simplifies relationships, improves query performance, and makes DAX calculations far more predictable compared to a flat, single denormalized table or a deeply snowflaked structure.

2. What is a snowflake schema, and when might it still make sense? Intermediate

Answer: A snowflake schema further normalizes dimension tables into sub-dimensions (e.g., splitting Products into Products and a separate Categories table). It generally adds unnecessary relationship complexity and slightly hurts DAX performance in Power BI compared to a flat star schema, but can make sense when a dimension is very large and genuinely shared across multiple fact tables in a way that benefits from normalization.

3. What is a calculation group, and what problem does it solve? Advanced

Answer: A calculation group lets you define a reusable set of DAX calculation items (like time intelligence variations — YTD, QTD, Prior Year) that can be applied dynamically to any measure in the model, selected via a slicer, without duplicating that logic across dozens of near-identical individual measures (Sales YTD, Profit YTD, Units YTD, and so on).

Real business example: Instead of building separate YTD, QTD, and PY versions of every single measure in a large model, a single calculation group lets users pick "YTD" from a slicer and have it apply correctly to whichever base measure (Sales, Profit, Units) they're currently viewing.

4. What is a composite model, and why would you use one? Advanced

Answer: A composite model combines both Import mode and DirectQuery data sources within the same Power BI model — used when some data needs the speed of Import mode while other data (often very large or requiring real-time freshness) is better left in DirectQuery, avoiding the need to fully commit to one storage mode for the entire model.

5. What is the difference between Import mode and DirectQuery, and what's the DAX performance implication of each? Intermediate

Answer: Import mode loads a full copy of the data into Power BI's fast, in-memory VertiPaq engine — DAX calculations run against this local, compressed copy, generally offering the best performance. DirectQuery instead sends a live query back to the source system for every interaction — trading performance for real-time data freshness and avoiding data duplication, but making every DAX calculation's speed dependent on the source system's own query performance, not VertiPaq.

More data modeling questions to be ready for:

⚡ Optimization and data-modeling questions are where interviews shift from "can you write a formula" to "have you actually built and maintained a real, production-scale Power BI model" — exactly the kind of depth built through real project work in the DataVix Power BI curriculum.

Scenario-Based DAX Questions by Dashboard Domain

Scenario questions test whether you can translate a plain-English business ask into the right DAX approach — interviewers grade your reasoning as much as the exact formula.

1. Sales Dashboard: "Show year-over-year sales growth by region, filterable by any month." Intermediate

Structured Answer: "I'd build a base Total Sales measure, then a Sales PY measure using CALCULATE([Total Sales], SAMEPERIODLASTYEAR('Date'[Date])), and a growth % measure combining both with DIVIDE to safely handle any region with zero prior-year sales. Region filtering works automatically through the existing relationship, so no extra logic is needed there."

2. Finance Dashboard: "Build a measure showing budget variance that stays accurate no matter how the report is filtered." Advanced

Structured Answer: "Assuming Budget and Actuals live in separate fact tables both related to a shared Date and Department dimension, I'd build Actual Amount and Budget Amount as separate measures, then Variance = [Actual Amount] - [Budget Amount] and Variance % = DIVIDE([Variance], [Budget Amount]) — relying on the shared dimensions to keep both sides correctly filtered together automatically."

3. HR Dashboard: "Calculate average employee tenure, updated dynamically as new hires and departures are added." Intermediate

Structured Answer: "I'd use AVERAGEX(Employees, DATEDIFF(Employees[HireDate], IF(ISBLANK(Employees[TerminationDate]), TODAY(), Employees[TerminationDate]), DAY)/365.25) — an iterator that calculates each employee's tenure individually (using today's date for still-active employees) before averaging, since tenure itself isn't a stored value."

4. Marketing Dashboard: "Calculate campaign ROI, where cost and conversions come from two different fact tables." Advanced

Structured Answer: "With CampaignCost and Conversions as two fact tables both related to a shared Campaigns dimension, I'd build Total Cost and Total Revenue as separate measures each aggregating from their own fact table, then ROI = DIVIDE([Total Revenue] - [Total Cost], [Total Cost]) — the shared Campaigns dimension keeps both sides correctly aligned without needing a direct relationship between the two fact tables themselves."

5. Retail Dashboard: "Show each store's sales rank compared to all other stores, visible even when the report is filtered to one region." Advanced

Structured Answer: "I'd use RANKX(ALL(Stores), [Total Sales], , DESC) — wrapping the ranking table in ALL specifically so the rank reflects each store's position against every store company-wide, not just the stores currently visible within the filtered region."

6. Healthcare Dashboard: "Calculate average patient wait time while keeping detailed patient identifiers restricted from general viewers." Advanced

Structured Answer: "The DAX itself — AVERAGEX(Appointments, DATEDIFF(Appointments[CheckInTime], Appointments[SeenTime], MINUTE)) — is straightforward; the access control is handled separately through Row-Level Security (RLS) restricting which rows/columns different user roles can see, layered on top of the measure rather than built into the DAX itself."

7. Manufacturing Dashboard: "Flag production lines with a defect rate more than 1.5 standard deviations above the plant average." Advanced

Structured Answer: "I'd build Defect Rate = DIVIDE([Defective Units], [Total Units Produced]) per line, then compare each line's rate against CALCULATE(AVERAGEX(VALUES(Lines[LineID]), [Defect Rate]), ALL(Lines)) plus a standard-deviation-based threshold calculated similarly with ALL to keep the comparison company-wide rather than filtered."

8. Supply Chain Dashboard: "Estimate days-of-stock-remaining for each product based on recent sales velocity." Intermediate

Structured Answer: "I'd calculate Avg Daily Sales = DIVIDE([Total Units Sold], DATEDIFF(FIRSTDATE(DATESINPERIOD('Date'[Date], MAX('Date'[Date]), -30, DAY)), MAX('Date'[Date]), DAY)) for a trailing 30-day window, then Days of Stock = DIVIDE([Current Stock], [Avg Daily Sales]) — a straightforward ratio, but one that depends on getting the trailing-window date logic right."

9. Customer Analytics: "Segment customers into value tiers based on their total spend, updated dynamically." Intermediate

Structured Answer: "I'd wrap total spend per customer in a SWITCH(TRUE(), ...) measure with threshold conditions — 'Platinum' above a defined amount, 'Gold' above a lower one, and so on — as shown earlier in the SWITCH example, keeping thresholds as named measures or parameters rather than hardcoded numbers so they're easy to adjust later."

10. Inventory Dashboard: "Show which products haven't sold in the last 60 days, even though they still appear in the product catalog." Advanced

Structured Answer: "I'd build a measure like No Recent Sales = IF(ISBLANK(CALCULATE([Total Sales], DATESINPERIOD('Date'[Date], TODAY(), -60, DAY))), 1, 0), applied against the full Products table (not just Sales) — this specifically requires iterating the dimension table so products with zero recent sales still appear, which a measure built only from the Sales fact table would silently exclude."

Power BI DAX Practical Case Studies

These 20 case studies mirror what you'll actually be asked to solve live — a real business requirement, translated into a working measure, using the shared star-schema model introduced earlier in this guide.

1. Total revenue that responds correctly to every filter. → Total Sales = SUM(Sales[SalesAmount]). Why: a plain SUM measure automatically respects whatever filter context the report applies — no CALCULATE needed for the base case.

2. Gross margin percentage, safe against zero-revenue edge cases. → Margin % = DIVIDE(SUM(Sales[SalesAmount]) - SUM(Sales[CostAmount]), SUM(Sales[SalesAmount])). Optimization tip: always use DIVIDE, not /, for any ratio measure shipped to production.

3. Percent of grand total, unaffected by the report's current filters. → % of Total = DIVIDE([Total Sales], CALCULATE([Total Sales], ALL(Sales))).

4. Year-over-year growth by product category. → YoY Growth % = DIVIDE([Total Sales] - CALCULATE([Total Sales], SAMEPERIODLASTYEAR('Date'[Date])), CALCULATE([Total Sales], SAMEPERIODLASTYEAR('Date'[Date]))). Alternative: define Sales PY as its own measure first, then reference it in the growth formula for readability.

5. Top 5 customers by revenue, as a dedicated table for a separate report page. → Top 5 Customers = TOPN(5, SUMMARIZE(Sales, Customers[CustomerName], "Total", [Total Sales]), [Total], DESC).

6. Running total of sales across the full date range. → Running Total = CALCULATE([Total Sales], FILTER(ALL('Date'[Date]), 'Date'[Date] <= MAX('Date'[Date]))).

7. Number of unique customers who purchased in the current filter context. → Unique Customers = DISTINCTCOUNT(Sales[CustomerKey]).

8. Average basket size (items per order), where each order can have multiple line items. → Avg Basket Size = AVERAGEX(VALUES(Sales[SalesID]), CALCULATE(SUM(Sales[Quantity]))). Explanation: iterates per unique order, using context transition to correctly total each order's quantity before averaging.

9. Sales rank by product, respecting whatever category filter is applied. → Product Rank = RANKX(ALLSELECTED(Products), [Total Sales], , DESC). Why ALLSELECTED here, not ALL: the rank should reflect the currently-selected category (via slicer), not reset to every product company-wide.

10. Customer segment label based on total spend, using named thresholds. → Uses the SWITCH(TRUE(), ...) pattern shown earlier, with thresholds ideally stored as separate measures for easy adjustment.

11. Month-to-date sales, correctly reset at the start of each month. → Sales MTD = TOTALMTD([Total Sales], 'Date'[Date]).

12. Sales from the previous quarter, for a quarter-over-quarter comparison. → Sales Prior Quarter = CALCULATE([Total Sales], DATEADD('Date'[Date], -1, QUARTER)).

13. Number of distinct products purchased by each customer. → Products Per Customer = DISTINCTCOUNT(Sales[ProductKey]), evaluated per customer row in a table visual.

14. Flag orders significantly larger than a customer's typical order (outlier detection). → Order vs Avg = DIVIDE([Total Sales], CALCULATE(AVERAGEX(VALUES(Sales[SalesID]), [Total Sales]), ALLEXCEPT(Sales, Sales[CustomerKey]))). Explanation: compares the current filtered total against that specific customer's own historical average order, using ALLEXCEPT to keep the customer filter while clearing the order-level filter.

15. New vs returning customer revenue split in the same period. → Requires a First Purchase Date calculated column (CALCULATE(MIN(Sales[OrderDate]), ALLEXCEPT(Sales, Sales[CustomerKey]))), then a measure splitting revenue based on whether OrderDate equals that customer's first purchase date.

16. Days since a customer's last purchase, for a churn-risk flag. → Days Since Last Purchase = DATEDIFF(CALCULATE(MAX(Sales[OrderDate]), ALLEXCEPT(Sales, Sales[CustomerKey])), TODAY(), DAY).

17. Cumulative percentage contribution of each product to total revenue (Pareto/80-20 analysis). → Cumulative % = DIVIDE(CALCULATE([Total Sales], FILTER(ALL(Products), [Total Sales] >= CALCULATE([Total Sales], REMOVEFILTERS(Products), VALUES(Products[ProductName])))), CALCULATE([Total Sales], ALL(Products))). Optimization tip: this pattern is genuinely expensive on large models — for very large product lists, consider pre-calculating rank in a calculated column instead.

18. Sales target attainment, where the target is stored in a separate, unrelated table. → Requires a disconnected Targets table; measure references SELECTEDVALUE(Targets[TargetAmount]) compared against [Total Sales], since no relationship links them directly.

19. Dynamic KPI card title that changes based on the current slicer selection. → Selected Region = SELECTEDVALUE(Customers[Region], "All Regions"), used directly as a card visual's text.

20. Employee performance ranked within their own region only (not company-wide). → Regional Rank = RANKX(FILTER(ALL(Employees), Employees[Region] = MAX(Employees[Region])), [Total Sales], , DESC).

21. Highlight the single best-performing month in a trend chart using conditional formatting driven by DAX. → Is Best Month = IF([Total Sales] = CALCULATE(MAX([Total Sales]), ALL('Date'[MonthName])), 1, 0), referenced in a visual's conditional formatting rule rather than displayed directly.

22. Calculate the average number of days between consecutive orders for each customer. → Avg Days Between Orders = AVERAGEX(Customers, CALCULATE(DIVIDE(DATEDIFF(MIN(Sales[OrderDate]), MAX(Sales[OrderDate]), DAY), DISTINCTCOUNT(Sales[OrderDate]) - 1))). Explanation: iterates per customer, using context transition so MIN/MAX/DISTINCTCOUNT each resolve to that specific customer's orders only.

23. Show sales for the current period compared against a rolling 3-month average. → Rolling 3M Avg = AVERAGEX(DATESINPERIOD('Date'[Date], MAX('Date'[Date]), -3, MONTH), [Total Sales]).

24. Calculate what percentage of total employees are above the company-wide average salary. → % Above Avg Salary = DIVIDE(CALCULATE(COUNTROWS(Employees), Employees[Salary] > CALCULATE(AVERAGE(Employees[Salary]), ALL(Employees))), CALCULATE(COUNTROWS(Employees), ALL(Employees))). Optimization tip: calculate the average salary once as a variable rather than repeating the inner CALCULATE, to avoid the Formula Engine re-evaluating it twice in the same measure.

💡 Case studies 14, 17, 20, and 22 deliberately combine multiple concepts (context transition, ALLEXCEPT, filtered ranking, per-customer iteration) the way real interview questions do — if those felt hard, that's the exact gap worth closing before your next Power BI interview.

How DAX Concepts Map to SQL and Excel

If you've already worked through the SQL Interview Questions or Excel Interview Questions guides, several DAX concepts will feel familiar — though the underlying mechanics differ in ways worth understanding explicitly, not just assuming they're identical.

Why this matters for an interview: Explicitly connecting a new DAX concept back to SQL or Excel knowledge you already have is a genuinely effective way to explain your reasoning live — interviewers respond well to "this is conceptually similar to a SQL JOIN, but resolved through the model's relationships instead of query syntax," since it signals real transferable understanding, not memorized, isolated facts.

Real Company Power BI & DAX Interview Patterns

Every company runs a slightly different process, and the patterns below reflect commonly reported structures from public interview experiences and each company's general hiring approach — not confidential or verbatim leaked questions. Use this as a guide to what kind of round to expect, not a script to memorize.

What's consistent across all of them: every company tests core measure-writing and CALCULATE usage in some form, and the differentiator is how much of the process leans toward business case reasoning (Big 4 and consulting) versus deep, live DAX problem-solving (Microsoft, Amazon, and product/e-commerce companies, which test context transition and optimization far more consistently than IT services firms do for entry-level hiring).

🏆 Product companies and Big Tech weight live, unaided DAX reasoning far more heavily than IT services firms do — if that's your target, prioritize timed, hands-on practice over reading definitions.

Most Common DAX Mistakes

Using the wrong context for the task. Writing a calculated column when a measure was needed (or vice versa) is the single most common DAX mistake — always ask "does this need to respond dynamically to filters?" before choosing.

Misusing CALCULATE's filter arguments. Assuming a filter argument adds to existing context instead of replacing it (without KEEPFILTERS) produces plausible-looking but subtly wrong numbers — one of the hardest classes of DAX bug to spot without knowing to look for it.

Wrong or missing relationships. A missing relationship, or a relationship with the wrong cardinality/direction, silently breaks filter propagation — RELATED returning blank or a measure not responding to a slicer almost always traces back here first.

Circular dependencies. A measure or calculated column that directly or indirectly references itself through a chain of other calculations — fixed by restructuring the logic, often by introducing a variable or rethinking which calculation should genuinely depend on which.

Incorrect FILTER usage. Wrapping every condition in FILTER out of habit, even when a simple boolean filter argument in CALCULATE would be simpler and better-performing — a sign of not yet understanding when full row-by-row iteration is actually necessary.

Overusing calculated columns instead of measures. Defaulting to calculated columns because they're easier to reason about (closer to Excel's row-by-row mental model) bloats the model and produces values that don't respond to filters — almost always the wrong default for anything aggregatable.

Ignoring star schema principles. Building on top of a single flat, denormalized table (or a deeply snowflaked one) instead of a proper star schema makes DAX behave less predictably and hurts performance — model structure problems, not DAX syntax problems, are often the real root cause of "my formula isn't working" bugs.

Performance issues from unnecessary iterators and missing variables. Repeating the same expensive sub-expression multiple times in one measure (instead of a VAR) and reaching for iterator functions where a direct aggregation would work both quietly hurt performance in ways that only show up at scale.

DAX Cheat Sheet

Core function categories

Evaluation context quick reference

Syntax quick reference

Total Sales = SUM(Sales[SalesAmount])

Sales YTD = TOTALYTD([Total Sales], 'Date'[Date])

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

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

Product Rank = RANKX(ALL(Products), [Total Sales], , DESC)

Safe Ratio = DIVIDE(numerator, denominator, 0)

Best Practice Measure =
VAR x = SUM(Sales[SalesAmount])
VAR y = SUM(Sales[CostAmount])
RETURN DIVIDE(x - y, x)

Data modeling & normalization essentials

Transaction & optimization essentials

Interview tips

• Always explain evaluation context out loud when writing a measure — interviewers grade your reasoning, not just the final formula.
• Default to VAR/RETURN in every example measure you write live — it signals production-quality habits immediately.
• If asked "why doesn't this work," check relationships and filter context before assuming the DAX syntax itself is wrong.
• When two approaches are both valid, mention the trade-off (readability vs performance) rather than silently picking one.

30-Day DAX Interview Preparation Plan

Use this as a realistic, day-by-day structure if you have roughly one month before your interview and can dedicate 1-2 hours a day.

Week 1 — Foundations: Measures, Columns & Context

• Days 1-2: Measures vs calculated columns vs calculated tables — build 5 of each on a real dataset.
• Days 3-4: Row context and filter context — deliberately break a formula by misusing each, then fix it.
• Days 5-6: CALCULATE fundamentals — basic filter arguments, then ALL/ALLSELECTED/ALLEXCEPT.
• Day 7: Review — explain 10 concepts from this guide out loud, from memory, no notes.

Week 2 — Relationships, Iterators & Context Transition

• Days 8-9: RELATED, RELATEDTABLE, LOOKUPVALUE — build measures across a proper multi-table star schema.
• Days 10-11: SUMX, AVERAGEX, COUNTX, and RANKX — solve 5 problems from the case studies section.
• Days 12-13: Context transition — deliberately write measures that require it, and explain why each does.
• Day 14: Build one small end-to-end dashboard using only what you've practiced so far.

Week 3 — Time Intelligence, Optimization & Modeling

• Days 15-16: TOTALYTD, SAMEPERIODLASTYEAR, DATEADD — build a full YoY/YTD comparison dashboard.
• Days 17-18: Star schema principles, calculation groups, and Import vs DirectQuery.
• Days 19-20: Storage Engine vs Formula Engine, DAX Studio basics, Performance Analyzer.
• Day 21: Complete 10 of the 20 case studies from this guide, timed.

Week 4 — Scenarios, Mock Interviews & Company Research

• Days 22-23: Practice 8-10 scenario-based questions out loud, using the structured-answer format from this guide.
• Days 24-25: Complete the remaining case studies; review the cheat sheet daily.
• Days 26-27: Do 1-2 full mock interviews (live, shared-screen practice) with a friend, mentor, or recorded self-review.
• Days 28-29: Redo your weakest topic area based on mock interview feedback.
• Day 30: Light review only — re-read the cheat sheet and rest before the interview.

📅 Want this exact plan with structured lessons, real dashboards, and mentor-reviewed projects instead of self-guided prep? The DataVix Power BI curriculum is built around this same sequence, end to end.

Free DAX Learning Resources

You don't need paid tools to prepare properly — here's how to practice for free, roughly in order of what actually moves the needle most.

• Build real dashboards from real (even messy) datasets. Following a tutorial's exact clicks teaches syntax, not intuition — invent your own business questions against a public dataset and write the DAX from scratch to answer them.
• Microsoft Learn's official DAX documentation. The authoritative, always-current reference for exact function syntax and behavior — the right place to resolve a specific question precisely once you're past the basics.
• SQLBI's articles and DAX Guide. Widely regarded as the deepest, most technically rigorous free resource for understanding evaluation context, context transition, and optimization in real depth.
• The Power BI Community forums. A genuinely active place to see real, messy, unresolved problems (and their solutions) — closer to real-world debugging than any curated tutorial.
• DAX Studio. Free, and the single best way to actually see how a query executes — profiling your own measures here builds the Storage Engine vs Formula Engine intuition faster than reading about it alone.
• Practice SQL and Excel alongside DAX. The underlying logic — filtering, grouping, conditional aggregation — transfers directly between all three. See the SQL Interview Questions and Excel Interview Questions guides to build all three in parallel.

Frequently Asked Questions

How many DAX interview questions should I prepare? Preparing 40-50 questions in real depth — measures vs calculated columns, row vs filter context, CALCULATE and context transition, the X-iterator functions, and a few time intelligence functions — covers roughly 80% of what's actually asked.

What is the most commonly asked DAX interview question? "What's the difference between a calculated column and a measure?" comes up in nearly every Power BI round, with row vs filter context and CALCULATE close behind.

Is DAX harder to learn than SQL? Most people find DAX's syntax easy but its evaluation model (row context, filter context, context transition) genuinely harder to build intuition for, since it operates on an entire data model, not a single query's rows.

Can a fresher clear a DAX interview round? Yes, if they can build and confidently explain at least one real dashboard end-to-end, including basic CALCULATE and one time intelligence measure.

What is the difference between a Power BI interview and a DAX interview? A Power BI interview covers the whole tool — modeling, Power Query, visuals — together; a DAX-specific round drills into formula logic and evaluation context specifically.

Do I need to memorize every DAX function for an interview? No — understanding evaluation context and reasoning through unfamiliar formulas matters more than memorizing every function's exact syntax.

What is the difference between DAX interview questions for freshers and experienced professionals? Freshers are tested on measures, basic CALCULATE, and simple time intelligence; experienced candidates get deeper on context transition, optimization, and modeling trade-offs.

Are DAX interview questions and answers available as a PDF? This guide works as your complete reference and can be saved as a PDF directly from your browser to study offline.

What is the single most important DAX concept to understand before an interview? Evaluation context — nearly every advanced DAX question is really testing this one underlying concept from a different angle.

What is CALCULATE, and why is it considered DAX's most important function? It's the only function that can directly modify filter context, and nearly every advanced DAX pattern is built on top of it in some form.

What is context transition in DAX? The conversion of row context into an equivalent filter context, triggered by CALCULATE — it's what lets a measure return a row-specific result inside an iterator.

What is the difference between a measure and a calculated column? A calculated column is computed row-by-row and stored; a measure is calculated dynamically at query time based on filter context.

What is row context in DAX? The awareness of a "current row" during evaluation, present in calculated columns and iterators but not in plain measures by default.

What is filter context in DAX? The set of active filters from slicers, visuals, and page/report filters that determines which rows are visible to a calculation.

What does the ALL function do in DAX? Removes filters from a table or columns, commonly used inside CALCULATE to compute a total unaffected by current selections.

What is the difference between ALL, ALLSELECTED, and ALLEXCEPT? ALL removes every filter entirely; ALLSELECTED respects filters set outside the current visual; ALLEXCEPT keeps only specified filters active.

What is a star schema, and why does it matter for DAX performance? A fact table connected to dimension tables via one-to-many relationships — VertiPaq and DAX filter propagation are both optimized for this structure.

What is the difference between SUMX and SUM in DAX? SUM aggregates an existing column directly; SUMX evaluates an expression per row first, then sums the results.

What is RANKX used for? Calculating a value's dynamic rank within a filter-context-aware table expression, commonly for leaderboards and top-performer visuals.

What is the difference between Import mode and DirectQuery in Power BI? Import loads data into the fast in-memory VertiPaq engine; DirectQuery queries the source live on every interaction.

What is a calculation group in Power BI? A reusable set of DAX calculation logic (like time intelligence variants) applicable to any measure without duplicating that logic across many measures.

What is TOTALYTD used for? Calculating a running year-to-date total based on the active date filter and a properly configured Date table.

What is the difference between TOTALYTD and DATESYTD? TOTALYTD directly returns a YTD value; DATESYTD returns a table of dates you wrap in CALCULATE yourself for more flexibility.

What does DIVIDE do differently from the standard division operator in DAX? It safely handles division by zero, returning an alternate result instead of an error.

What is the difference between VALUES and DISTINCT in DAX? Both return unique values, but VALUES also includes a blank row for unmatched relationship rows when they exist; DISTINCT doesn't.

What is the VertiPaq engine? Power BI's in-memory, columnar storage engine used in Import mode, optimized for fast aggregate calculations.

What is the difference between the Storage Engine and Formula Engine in DAX query execution? The Storage Engine handles fast, simple retrieval; the Formula Engine handles complex logic and is generally slower.

How do I optimize a slow DAX measure? Reduce reliance on iterators over large tables, use variables to avoid recalculation, and profile with Performance Analyzer or DAX Studio to find the actual bottleneck.

What is asked in a Power BI interview at Accenture? A dashboard-building or DAX measure task combined with a business case study, reflecting Accenture's client-project-based work.

What is asked in a Power BI interview at TCS? Foundational Power BI and DAX — basic measures, simple CALCULATE, and data modeling fundamentals.

How difficult are DAX interviews for freshers? Moderately difficult but learnable — fresher rounds focus on fundamentals and your ability to explain your own dashboard project.

What is a calculated table in Power BI? A table generated by a DAX expression rather than imported from a source, used for things like disconnected parameter tables or summarized data.

What is SUMMARIZECOLUMNS, and how is it different from SUMMARIZE? SUMMARIZECOLUMNS is the modern, recommended function for grouped summaries with more predictable filter-context behavior; SUMMARIZE is the older approach.

What is the difference between RELATED and RELATEDTABLE? RELATED pulls a single value from the "one" side to the "many" side; RELATEDTABLE returns a full related table from the "one" side.

What is LOOKUPVALUE used for? Retrieving a value by matching conditions, similar to VLOOKUP, working even without an existing relationship — at some performance cost.

What is the difference between USERELATIONSHIP and CROSSFILTER? USERELATIONSHIP activates a specific inactive relationship; CROSSFILTER changes filter direction or disables a relationship for one expression.

What is a circular dependency in DAX, and how do you fix it? A calculation that references itself directly or indirectly — fixed by restructuring the logic, often using a variable.

Why shouldn't you use a calculated column when a measure would work? Calculated columns are stored and don't respond dynamically to filters, increasing model size without the flexibility a measure provides.

What is query folding in Power Query, and why does it matter for a DAX interview? It's when Power Query pushes transformations back to the source system for better refresh performance — sometimes discussed alongside DAX optimization.

What is the best way to practice DAX before an interview? Build real dashboards from real datasets, writing your own measures for questions you invent yourself, rather than passively following tutorials.

📚 Keep preparing with the rest of the DataVix guide library — Data Analyst Interview Questions (covers SQL and Power BI together), the SQL Interview Questions guide, and the Data Analyst Roadmap.

Ready to Move from "Knows Power BI" to "Interview-Ready in DAX"?

Reading 150+ questions and 20 case studies is a strong start, but real interview confidence comes from writing measures yourself, on a real model, under pressure — not from reading solutions. Here's the fastest path to being genuinely ready:

• Context — Build genuine intuition for row context, filter context, and context transition — the concept nearly every other DAX question is really testing.
• CALCULATE — Get fluent in ALL, ALLSELECTED, ALLEXCEPT, and KEEPFILTERS until choosing the right one is automatic, not a guess.
• Iterators & Ranking — Practice SUMX, AVERAGEX, and RANKX on real, multi-table data until the pattern feels natural.
• Time Intelligence — Build a full YTD/YoY dashboard from scratch using a properly configured Date table.
• Optimization — Profile at least one of your own measures with Performance Analyzer or DAX Studio — reading about the Storage Engine isn't the same as seeing it.

This is exactly the sequence taught inside the DataVix Data Analyst course — Power BI, DAX, SQL, and Excel, built around real projects and reviewed by mentors, with dedicated interview preparation and mock interviews included.

🚀 Ready to stop guessing and start preparing with a real structure? Enroll in the DataVix Data Analyst course — one-time fee, lifetime access, real project reviews, mentor support, and placement guidance. Or start with the free Data Analyst Roadmap to plan your path first.