Data Analysis Expressions (DAX)
Data Analysis Expressions (DAX) Interview with follow-up questions
1. Can you explain what Data Analysis Expressions (DAX) is and how it is used in Power BI?
Data Analysis Expressions (DAX) is a formula language used in Power BI, Analysis Services, and Power Pivot to define custom calculations in tabular data models. It was designed specifically for column-oriented data stores and is optimized for the xVelocity in-memory engine that powers Power BI's Import mode.
DAX is used in three main contexts in Power BI:
- Measures: Calculations that are evaluated dynamically at query time based on the current filter context (e.g., what slicers are selected, which visual is rendering). Measures are the primary way to build KPIs, aggregations, and business logic.
- Calculated columns: Column expressions evaluated row-by-row at data refresh time and stored in the model. They consume memory but can be useful for segmentation or row-level logic.
- Calculated tables: Entire tables derived from DAX expressions, useful for bridge tables, disconnected parameter tables, or date tables.
A key concept in DAX that interviewers probe is evaluation context: every DAX expression runs inside a filter context (the set of active filters from slicers, report filters, and row headers) and a row context (the current row when iterating). The CALCULATE function is the primary mechanism to modify filter context — it is what makes DAX both powerful and tricky.
In 2026, DAX is used across the full Microsoft Fabric platform — not just Power BI reports, but also in semantic models published to Fabric workspaces, which can be consumed by Excel, Paginated Reports, and third-party tools via the XMLA endpoint. The DAX query view in Power BI Desktop (introduced in 2023) now lets developers write and run DAX queries directly in the tool, making debugging and exploration much faster.
Follow-up 1
What are some challenges you have faced when using DAX?
Some common challenges when using DAX in Power BI include:
- Understanding the syntax and structure of DAX formulas can be complex, especially for users who are new to the language.
- Performance optimization can be challenging, as DAX calculations can be resource-intensive and may require careful consideration of data model design and formula logic.
- Handling complex calculations and aggregations may require advanced DAX functions and techniques.
- Debugging and troubleshooting DAX formulas can be time-consuming, especially when dealing with large datasets.
However, with practice and experience, these challenges can be overcome, and DAX can become a powerful tool for data analysis in Power BI.
Follow-up 2
Can you provide an example of a DAX formula you have used?
Sure! Here's an example of a DAX formula used to calculate the total sales for a product in Power BI:
Total Sales = SUM('Sales'[Amount])
In this example, 'Sales' is the name of the table and 'Amount' is the name of the column containing the sales data. The SUM function is used to calculate the sum of the values in the 'Amount' column, giving us the total sales for the product.
Follow-up 3
What are some common DAX functions?
There are several common DAX functions used in Power BI, including:
- SUM: Calculates the sum of a column of numbers.
- AVERAGE: Calculates the average of a column of numbers.
- COUNT: Counts the number of rows in a table or column.
- MAX: Returns the maximum value in a column.
- MIN: Returns the minimum value in a column.
- IF: Performs a logical test and returns different values based on the result.
- CALCULATE: Modifies the context in which a calculation is performed.
These are just a few examples of the many DAX functions available in Power BI.
Follow-up 4
How does DAX differ from Excel formulas?
DAX and Excel formulas have some similarities, but there are also key differences:
- DAX is designed for working with tabular data models, while Excel formulas are designed for working with individual cells or ranges of cells.
- DAX is optimized for performance in Power BI, while Excel formulas may be slower when working with large datasets.
- DAX has additional functions and features specifically tailored for data analysis and business intelligence, such as time intelligence functions and table functions.
- DAX uses a different syntax and formula structure compared to Excel formulas.
Overall, DAX provides more advanced data analysis capabilities and is better suited for working with large datasets in Power BI.
2. How does DAX play a role in creating calculated columns and measures in Power BI?
DAX serves distinct purposes for calculated columns and measures, and understanding the difference is a common interview focal point.
Calculated columns are evaluated row by row during data refresh and their results are stored in the model. They operate in a row context — you can reference other columns in the same row directly. Use them when you need a persistent value for filtering, grouping, or as a slicer target. Because they consume RAM in the in-memory model, they should be used sparingly.
Profit Margin % = DIVIDE([Sales] - [Cost], [Sales])
Measures are evaluated at query time in response to the current filter context — the combination of slicers, page filters, report filters, and visual axes active when the measure is called. They are not stored row by row; instead, they aggregate or compute a single result per cell in a visual. Measures are the recommended approach for aggregations and KPIs.
Total Revenue = SUMX(Sales, Sales[Quantity] * Sales[Unit Price])
The critical distinction interviewers test is context transition: when you call a measure inside a calculated column (or inside an iterator like SUMX), DAX automatically converts the current row context into an equivalent filter context. This is what allows measures to behave correctly when referenced from iterators.
Calculated tables are a third use case — entire tables defined by a DAX expression. They are useful for building date tables (CALENDAR, CALENDARAUTO), parameter tables for what-if analysis, or bridge tables in complex models.
In 2026, best practice is to prefer measures over calculated columns wherever possible. Measures are more memory-efficient, are re-evaluated with every filter change, and work correctly across composite models (which combine Import and DirectQuery sources). Calculated columns, by contrast, are computed at refresh time against the base data only.
Follow-up 1
Can you explain the difference between calculated columns and measures?
Calculated columns are columns that are created in a table based on a DAX formula. These columns are calculated during the data loading process and the results are stored in the table. Calculated columns can be used in visualizations just like any other column.
Measures, on the other hand, are calculations that are performed on the fly based on the data in the visualizations. They are not stored in the table and are calculated dynamically based on the context of the visualization. Measures are typically used for aggregations, such as sum, average, or count, and can be used across multiple visualizations.
Follow-up 2
Can you provide an example where you used DAX to create a calculated column or measure?
Sure! Here's an example of using DAX to create a calculated column:
Sales[Total Revenue] = Sales[Quantity] * Sales[Unit Price]
This formula calculates the total revenue by multiplying the quantity and unit price columns in the Sales table.
And here's an example of using DAX to create a measure:
Total Sales = SUM(Sales[Total Revenue])
This measure calculates the total sales by summing up the values in the Total Revenue column of the Sales table.
Follow-up 3
What are some best practices when creating calculated columns and measures using DAX?
When creating calculated columns and measures using DAX, it's important to follow some best practices to ensure optimal performance and maintainability:
Use calculated columns sparingly: Calculated columns can increase the size of the data model and slow down the data loading process. Only create calculated columns when necessary.
Use measures for aggregations: Instead of creating calculated columns for aggregations, use measures. Measures are more efficient and can be reused across multiple visualizations.
Use the right DAX functions: DAX offers a wide range of functions for different calculations. Use the appropriate functions to achieve the desired results.
Optimize DAX formulas: Avoid using complex or nested DAX formulas that can slow down the performance. Simplify the formulas whenever possible.
Test and validate: Always test and validate your calculated columns and measures to ensure they are producing the expected results.
3. What are some common DAX functions you often use in Power BI?
DAX has hundreds of functions. The ones that come up most in interviews and real-world usage fall into several categories:
Aggregation
SUM,AVERAGE,MIN,MAX,COUNT,COUNTA,DISTINCTCOUNT— basic column aggregationsSUMX,AVERAGEX,COUNTX,MAXX,MINX— iterator versions that evaluate an expression row by row before aggregating
Filter and context
CALCULATE— the most important DAX function; modifies filter context for any expression. Almost every non-trivial measure uses it.FILTER— returns a filtered table; used as a table argument insideCALCULATEor iteratorsALL,ALLEXCEPT,ALLSELECTED— remove filters from columns or tables, useful for percent-of-total patternsREMOVEFILTERS— cleaner alternative toALLas aCALCULATEmodifier
Table functions
RELATED— fetches a value from the one side of a relationship (used in calculated columns)RELATEDTABLE— returns all related rows from the many sideVALUES,DISTINCT— return unique values from a column as a tableSUMMARIZE,SUMMARIZECOLUMNS— produce summary tables
Time intelligence
TOTALYTD,TOTALQTD,TOTALMTD— year/quarter/month-to-date totalsSAMEPERIODLASTYEAR,DATEADD,PARALLELPERIOD— period comparisonDATESYTD— returns a set of dates for year-to-date; requires a proper date table
Logical and text
IF,SWITCH— conditional logicIFERROR,ISERROR— error handlingCONCATENATE,FORMAT,LEFT,RIGHT,LEN— text manipulation
Newer functions (2022-2024) worth knowing
OFFSET— returns a value from a row offset relative to the current row in an ordered partitionWINDOW— aggregates over a sliding window of rowsINDEX— returns a value at an absolute position in an ordered tableRANK— calculates rank within a partition
These newer functions (OFFSET, WINDOW, INDEX) enable ranking and running-total patterns that previously required complex workarounds, and interviewers in 2025-2026 increasingly ask about them.
Follow-up 1
Can you provide an example of how you have used these functions?
Sure! Here's an example of how the SUM and IF functions can be used in Power BI:
Total Sales = SUM(Sales[Amount])
Total Profit = SUM(Sales[Profit])
Profit Margin = IF(Total Sales > 0, Total Profit / Total Sales, 0)
In this example, the SUM function is used to calculate the total sales and total profit from a Sales table. The IF function is then used to calculate the profit margin by dividing the total profit by the total sales, but only if the total sales is greater than 0. Otherwise, the profit margin is set to 0.
Follow-up 2
What are some challenges or limitations of these functions?
Some challenges or limitations of DAX functions in Power BI include:
- Performance: DAX functions can sometimes be slow, especially when dealing with large datasets or complex calculations. It's important to optimize the use of DAX functions to improve performance.
- Syntax: DAX functions have a specific syntax that needs to be followed. It can be challenging to learn and remember the syntax for each function.
- Compatibility: Not all DAX functions are available in all versions of Power BI. Some functions may only be available in certain versions or editions.
- Complexity: DAX functions can be complex, especially when dealing with advanced calculations or data modeling. It may require a deep understanding of DAX and Power BI to use them effectively.
Follow-up 3
How do you handle errors in DAX functions?
There are several ways to handle errors in DAX functions in Power BI:
- IFERROR: The IFERROR function can be used to handle specific errors. It allows you to specify a value or expression to return if an error occurs.
Sales Growth = (Current Sales - Previous Sales) / Previous Sales
Sales Growth (with Error Handling) = IFERROR(Sales Growth, 0)
In this example, the Sales Growth calculation may result in an error if the previous sales value is 0. The IFERROR function is used to handle this error by returning 0 if an error occurs.
- ISERROR: The ISERROR function can be used to check if a DAX expression or function returns an error. It returns a Boolean value indicating whether an error occurred.
Sales Growth = (Current Sales - Previous Sales) / Previous Sales
Sales Growth (with Error Handling) = IF(ISERROR(Sales Growth), 0, Sales Growth)
In this example, the ISERROR function is used to check if the Sales Growth calculation returns an error. If an error occurs, the IF function is used to return 0; otherwise, the Sales Growth value is returned.
- TRY: The TRY function can be used to handle errors in a more advanced way. It allows you to specify a fallback expression or value to use if an error occurs.
Sales Growth = TRY((Current Sales - Previous Sales) / Previous Sales, 0)
In this example, the TRY function is used to calculate the Sales Growth. If an error occurs, the fallback value of 0 is used instead.
These are just a few examples of how errors can be handled in DAX functions. The approach to error handling may vary depending on the specific requirements and calculations in Power BI.
4. Can you explain how DAX handles data types and how it affects calculations?
DAX supports a fixed set of data types: Integer, Decimal (floating-point), Currency (fixed decimal, 4 places), Date/Time, Boolean, String, and Blank. Understanding how DAX handles types is important because implicit conversions can produce unexpected results.
Automatic type coercion: DAX will attempt to coerce types to match the operation being performed. For example, adding a number column and a text column that contains numeric characters ("42") will succeed, converting the text to a number. However, if the text cannot be parsed as a number, DAX returns an error rather than silently producing NULL as SQL would.
BLANK vs. NULL: DAX uses BLANK() instead of SQL's NULL. BLANK propagates through arithmetic in a way that can be surprising: BLANK() + 1 = 1 (BLANK acts as zero in arithmetic), but BLANK() = 0 evaluates to TRUE. Use ISBLANK() to test explicitly.
Integer vs. Decimal: Dividing two integers in DAX produces a decimal result. Always use DIVIDE(numerator, denominator, [alternateResult]) instead of the / operator to handle division by zero gracefully.
Date/Time: Dates are stored internally as floating-point numbers (the integer part is the date, the fractional part is the time). Mixing date columns with text representations requires explicit conversion via DATEVALUE() or DATE().
Currency: The Currency type has fixed 4 decimal places and is optimized for financial calculations. Storing money values as Currency rather than Decimal avoids floating-point rounding issues.
Practical implication: When building measures, be explicit about the data types of your inputs. Use INT(), VALUE(), or FORMAT() for explicit conversion. Implicit coercion works well for simple cases but can silently produce wrong results in complex expressions — a common source of bugs that interviewers probe with "what would this formula return?" questions.
Follow-up 1
What are some common data type issues you have encountered in DAX?
Some common data type issues in DAX include:
Incorrect data type conversions: DAX may automatically convert data types, but it is not always accurate. For example, if a column contains numbers stored as text, DAX may not convert them correctly, leading to incorrect calculations.
Inconsistent data types: DAX requires consistent data types within a calculation. If you have a column with mixed data types, such as numbers and text, it can cause errors or unexpected results.
Implicit data type conversions: DAX may perform implicit data type conversions, which can lead to unexpected results. It is important to explicitly convert data types when necessary to ensure accurate calculations.
Follow-up 2
How do you handle data type conversions in DAX?
To handle data type conversions in DAX, you can use the following functions:
CONVERT: This function allows you to explicitly convert a value to a specific data type. For example, CONVERT('123', INTEGER) will convert the text '123' to an integer.
VALUE: This function converts a text representation of a number to a numeric value. For example, VALUE('123') will convert the text '123' to the number 123.
FORMAT: This function converts a value to a text representation using a specified format. For example, FORMAT(123, '0.00') will convert the number 123 to the text '123.00'.
By using these functions, you can ensure accurate data type conversions in your DAX calculations.
Follow-up 3
Can you provide an example where data type handling in DAX affected your calculations?
Sure! Let's say you have a column named 'Quantity' that contains numbers stored as text. If you try to perform a calculation that involves this column, such as summing the values, DAX will treat the text as numbers and perform the calculation. However, if the text cannot be converted to a number, DAX will return an error. To handle this issue, you can use the VALUE function to explicitly convert the text to numbers before performing the calculation. For example, SUM(VALUE('Quantity')) will convert the text values to numbers and then sum them.
5. How do you optimize DAX expressions for better performance in Power BI?
DAX performance optimization is a frequent deep-dive topic in Power BI interviews. The key principles are:
1. Prefer measures over calculated columns Calculated columns are materialized at refresh time and stored in RAM. Measures are computed at query time only for the cells needed. For aggregations, measures are almost always more efficient.
2. Avoid unnecessary row-by-row iteration Iterator functions like SUMX, AVERAGEX, and FILTER can be expensive on large tables. If SUM or a simple aggregation achieves the same result, use it. When iterators are necessary, reduce the table they iterate over first using FILTER or CALCULATETABLE.
3. Use variables (VAR ... RETURN) Variables are evaluated once and cached within a measure execution. Using VAR eliminates repeated evaluation of expensive sub-expressions and makes filter context explicit, preventing the common "filter context leak" bug.
4. Minimize FILTER when simpler CALCULATE modifiers suffice FILTER scans a table row by row. A boolean predicate inside CALCULATE often compiles to a more efficient query plan. Replacing CALCULATE(SUM([Sales]), FILTER(ALL(Table), Table[Year] = 2025)) with CALCULATE(SUM([Sales]), Table[Year] = 2025) is both shorter and faster.
5. Avoid bidirectional cross-filter unless necessary Bidirectional relationships cause filter propagation in both directions, which can produce ambiguous or slow queries. Use them only where needed and consider using CROSSFILTER() inside specific measures instead.
6. Leverage aggregations and DirectLake (Fabric) For large models, pre-built aggregation tables let Power BI serve common queries from a small in-memory summary. In Microsoft Fabric, DirectLake mode reads data directly from Delta Parquet files in OneLake, providing near-Import performance without a full data import — reducing the need for manual aggregation tables in many scenarios.
7. Use DAX Studio and Performance Analyzer DAX Studio (free external tool) shows server timings, storage engine queries, and formula engine time for any expression. Power BI Desktop's built-in Performance Analyzer shows per-visual query times. Knowing how to profile with these tools signals seniority to interviewers.
8. Choose optimal data types Smaller data types compress better in the VertiPaq column store. Using Integer instead of Text for numeric codes, and Date instead of DateTime when time precision is not needed, reduces model size and speeds up queries.
Follow-up 1
What tools or techniques do you use to optimize DAX expressions?
To optimize DAX expressions, you can use the following tools and techniques:
DAX Studio: DAX Studio is a powerful tool for analyzing and optimizing DAX expressions. It provides features like query execution plans, formula engine tracing, and performance analysis.
Performance Analyzer in Power BI: Power BI has a built-in Performance Analyzer that allows you to analyze the performance of your DAX expressions and identify bottlenecks.
Query folding: Query folding is a technique that allows Power BI to push operations back to the data source, improving performance. By enabling query folding, you can optimize the execution of your DAX expressions.
Profiling tools: Profiling tools like SQL Server Profiler can be used to capture and analyze the queries generated by Power BI and identify areas for optimization.
Indexing and partitioning: If you have control over the data source, you can optimize performance by creating appropriate indexes and partitions.
Follow-up 2
Can you provide an example where you improved performance by optimizing a DAX expression?
Sure! Here's an example where I improved performance by optimizing a DAX expression:
Original DAX expression:
CALCULATE(SUM(Sales[Amount]), FILTER(Products, Products[Category] = "Electronics"))
Optimized DAX expression:
SUMX(FILTER(Sales, RELATED(Products[Category]) = "Electronics"), Sales[Amount])
In this example, the original DAX expression used CALCULATE and FILTER functions, which can be resource-intensive. By optimizing the expression using SUMX and RELATED functions, we were able to improve performance by leveraging the power of the VertiPaq engine in Power BI.
Follow-up 3
What are some common performance issues in DAX and how do you address them?
Some common performance issues in DAX include:
Slow calculations: Complex calculations or inefficient use of DAX functions can result in slow performance. To address this, simplify complex calculations, use efficient DAX functions, and avoid unnecessary calculations.
Large data models: Large data models with a high number of tables and relationships can impact performance. To address this, optimize data model relationships, use query folding, and consider partitioning or indexing the data.
Iterators: Iterators like SUMX and AVERAGEX can be slow, especially when used on large datasets. To address this, try to find alternative approaches that don't require iterators.
Inefficient use of calculated columns: Calculated columns can impact performance, especially if they are used excessively. Use calculated columns sparingly and consider using measures instead.
By addressing these common performance issues, you can improve the overall performance of your DAX expressions in Power BI.
Live mock interview
Mock interview: Data Analysis Expressions (DAX)
- Read your scene and goals
- Talk it out; goals tick off live
- Get a score and stronger lines
Your voice and your AI key never touch our servers; the key stays in this browser and is sent only to Google. Only your round scores are saved to track progress.