Power BI Interview Prep: A Model-First Practice Project

Chart-building alone does not make you Power BI interview-ready. Expect questions about grain, slicer behavior, and transformation layers. Those questions test your analytical model, not your memory of the ribbon.

Use this blueprint to build, test, and explain one project from source to report. It complements SQL and portfolio preparation by focusing on Power BI modeling, DAX, validation, performance, and presentation.

Start with a decision, not a dashboard

Imagine a retail manager needs revenue and gross margin by month, product category, and customer segment, plus year-over-year comparisons and order detail. Before opening the canvas, write a one-sentence contract:

This model reports completed retail order lines by order date. Cancelled lines are excluded. Approved returns reduce sales and their associated cost on the original order date. Managers can compare net revenue, gross profit, and margin across products, customers, and time.

This return-on-order-date rule is a deliberate practice simplification. A real business may recognize returns on the return date, so confirm that policy before modeling.

Use this exact practice input

Load the following source rows. Amounts are dollars; approved return amounts are populated on line L3.

LineID,OrderID,OrderDate,ProductKey,CustomerKey,Qty,UnitPrice,GrossSales,ReturnAmount,Cost,ReturnCost,Status
L1,O100,2026-01-05,P1,C1,2,100,200,0,120,0,Completed
L2,O100,2026-01-05,P2,C1,1,150,150,0,90,0,Completed
L3,O101,2026-01-20,P1,C2,1,100,100,100,60,60,Completed
L4,O102,2026-02-10,P2,C2,2,150,300,0,180,0,Completed
L5,O090,2025-01-05,P1,C1,1,80,80,0,50,0,Completed
L6,O103,2026-02-12,P1,C2,5,100,500,0,300,0,Cancelled

Create DimProduct with P1/Accessories and P2/Equipment, and DimCustomer with C1/SMB and C2/Enterprise. Exclude L6 upstream. Build DimDate from 2025-01-01 through 2026-12-31. Your 2026 checks are: four fact rows, three orders, $750 gross sales, $100 returns, $650 net revenue, $390 net cost, $260 gross profit, and 40% gross margin.

Define the grain and build a star schema

Set the grain before creating relationships. Here, FactSales has one row per completed order line, so an order with three products has three fact rows. Store quantity, sales amount, and cost amount there; put descriptive attributes in dimensions:

• DimDate: one row per date, with year, quarter, month, and sort columns.
• DimProduct: one row per product, with name, category, and brand.
• DimCustomer: one row per customer, with segment and region.
• FactSales: identifiers, foreign keys, dates, quantity, sales, and cost.

Create one-to-many relationships from each dimension to the fact and filter in one direction, dimension to fact. The “one” side needs unique keys. Handle unmatched keys deliberately. See Microsoft's guidance on star schemas and model relationships.

Do not use bidirectional filtering to repair an unclear model. Many-to-many relationships and bridges can be valid, but they should represent the business—not hide duplicate keys.

Know what belongs in SQL, Power Query, and DAX

Assign work to the layer where it is easiest to govern, reuse, and test:

For example, remove duplicate keys upstream, set types in Power Query, and calculate revenue share in DAX.

Build a small, reusable measure layer

Create every definition below as a separate model measure. Start with base measures, then compose business measures. Explicit measures are easier to format, test, and reuse than implicit visual aggregations.

Gross Sales =
SUM ( FactSales[GrossSales] )

Returns =
SUM ( FactSales[ReturnAmount] )

Revenue =
[Gross Sales] - [Returns]

Gross Cost =
SUM ( FactSales[Cost] )

Returned Cost =
SUM ( FactSales[ReturnCost] )

Cost =
[Gross Cost] - [Returned Cost]

Gross Profit =
[Revenue] - [Cost]

Gross Margin % =
DIVIDE ( [Gross Profit], [Revenue] )

Orders =
DISTINCTCOUNT ( FactSales[OrderID] )

DIVIDE safely handles a zero or blank denominator. Format the measure as a percentage in the model rather than converting it to text.

Measures versus calculated columns

In a standard Import model, a calculated column is evaluated per row at refresh and its results are stored in the model. A measure is evaluated on demand and responds to slicers and visual filters. A stable line classification may be a column; revenue, margin, and year-over-year change should normally be measures. Microsoft's calculation-options guide compares the available choices.

If asked to create line revenue from quantity and unit price, an iterator supplies row context:

Gross Sales From Units =
SUMX (
    FactSales,
    FactSales[Qty] * FactSales[UnitPrice]
)

SUMX evaluates the expression for each visible fact row, creating row context. Row context is not the same as the filter context created by a slicer.

Explain CALCULATE and filter context clearly

Filter context is the set of filters active when a measure runs. A matrix row, year slicer, and page filter all contribute. CALCULATE evaluates an expression under modified filter context.

Revenue All Products =
CALCULATE (
    [Revenue],
    REMOVEFILTERS ( DimProduct )
)

Product Revenue Share =
DIVIDE ( [Revenue], [Revenue All Products] )

The denominator removes product filters but keeps date and customer filters, so it gives each category's share within the remaining context. Also recognize context transition: CALCULATE inside row context turns that row context into filter context.

Add a proper date table and time intelligence

The formulas below use classic, column-based time intelligence. For this approach, DimDate[Date] must contain unique, nonblank, continuous dates and span full years. Mark DimDate as the date table, add a month or year-month sort key, and connect its date column to the active order date. Microsoft's date-table design guidance explains these requirements.

Revenue Previous Year =
CALCULATE (
    [Revenue],
    DATEADD ( DimDate[Date], -1, YEAR )
)

Revenue YoY % =
DIVIDE (
    [Revenue] - [Revenue Previous Year],
    [Revenue Previous Year]
)

Revenue YTD =
TOTALYTD ( [Revenue], DimDate[Date] )

Test month, quarter, and year levels. Previous year may correctly be blank when history is absent. Encode fiscal calendars explicitly. If ship date is also needed, keep one active default relationship and invoke the inactive date relationship with USERELATIONSHIP. Always state which date a KPI uses.

Validate the model before polishing visuals

Build a temporary diagnostic page and keep a short test log:

1. Reconcile row count, revenue, and cost to the source using the same status and date rules.
2. Manually verify one order, then one day-and-category slice, against the source.
3. Confirm cancelled L6 is absent and returned L3 contributes $100 returns and $60 returned cost.
4. Test unknown keys, blank dates, zero revenue, and duplicate dimension keys.
5. Check totals for ratios. The correct overall margin is total profit divided by total revenue, not the average of row percentages.
6. Test share measures under slicers and check a boundary period such as January.

When a number is wrong, inspect source rows, then relationships, then the measure's active filters. Do not rewrite DAX at random.

Cover performance basics without guessing

Start with evidence and high-value model choices:

• Use a star schema and remove columns that the report does not need, especially high-cardinality text.
• Push stable, large transformations upstream and preserve query folding where supported.
• Avoid unnecessary bidirectional relationships and whole-fact-table filters.
• Use variables to make repeated expressions readable and evaluate performance with Performance Analyzer before optimizing.
• For DirectQuery, inspect source-query cost, relationship design, and visual query volume; do not apply Import-mode advice blindly.

For a slow page, identify the slow visual, change one model or measure choice, and measure again.

Turn the dashboard into a 90-second business story

A useful page could contain revenue, profit, and margin KPIs; a monthly prior-year trend; category contribution; and an order-detail table. Give every visual a question.

Practice this walkthrough:

1. Purpose: name the user and the decision the page supports.
2. Model: state the fact grain and the main one-to-many filter paths.
3. Measures: explain one base measure and one context-changing measure.
4. Finding: investigate one visible trend with a category or region slice.
5. Evidence: name your validation and one real limitation.

This connects model design to a business decision without touring every visual.

Practice scenario questions out loud

• A product slicer does not change revenue. What do you check first?
• A margin total differs from the average of the visible row percentages. Why might the total be correct?
• Previous year is blank. Is history missing, or is the date model wrong?
• Two dimensions create an ambiguous path. How would you redesign it?
• A stakeholder wants a customer tier to change with the selected period. Why is a static calculated column probably unsuitable?
• What determines whether logic belongs in SQL, Power Query, or DAX?
• A DirectQuery page is slow. What evidence do you gather before changing measures?

Clarify expected behavior, inspect one slice, identify the layer, change one thing, and retest.

Use a timed interview rehearsal

Repeat with a different date role or new dimension. Make the reasoning repeatable under pressure.

Final Power BI interview checklist

• I can state the fact-table grain in one sentence.
• I can justify each relationship and filter direction.
• I can explain why a calculation belongs in SQL, Power Query, a column, or a measure.
• I can distinguish row context from filter context.
• I can explain what CALCULATE changes in one of my measures.
• I have tested my date table and comparison periods.
• I reconciled totals and tested at least one order-level slice.
• I measured a slow visual before attempting to optimize it.
• I can present the decision, model, finding, validation, and limitation in 90 seconds.

FAQ

How much DAX should I know for a Power BI interview?

Know explicit measures, SUMX, CALCULATE, filter removal, safe division, and basic time intelligence. More importantly, predict how a slicer changes a measure and validate it.

Should I learn SQL before Power BI?

Be comfortable validating source data with SQL when the role uses a relational warehouse. SQL prepares durable datasets; the Power BI model and DAX provide interactive behavior.

Are calculated columns bad?

No. Use them for stable row-level attributes needed in grouping, sorting, or relationships. Use a measure when the result must respond to filter context.

When should I use bidirectional filtering?

Use it only when the relationship requires it and you understand the resulting paths. In a standard star, single-direction dimension-to-fact filters are clearer.