Interview Insights · Power BI
Why Confidence Without Power BI Skills Still Fails
Quick summary — Power BI confidence
Power BI confidence is tested by building, and a confident pitch with a wrong measure loses more than a modest pitch with a right one. Dashboards look impressive in screenshots, so candidates naturally lead with them. Interviewers know a screenshot shows the visual layer only. They test the layer underneath: measures that stay correct when filters change, counts that count the right thing, and relationships set up safely. When a confident candidate builds a wrong Margin % or counts orders instead of customers, the confidence becomes a problem, because it suggests the errors would reach a manager unnoticed.
In this guide you will learn:
- Why dashboard screenshots do not convince experienced interviewers
- The live build tasks that expose confidence without skill
- The ratio and counting mistakes behind most wrong measures
- Why always-on bidirectional filters worry interviewers
- How to pitch your Power BI work so the live round confirms it
SECTION 01Why a dashboard screenshot is not evidence
Candidates often open with their best dashboard: dark theme, cards across the top, a map, a few slicers. It looks professional, and I mean it when I say it looks good. But formatting and layout can be learned in a weekend. What takes real practice is making every number on that page correct under every combination of filters.
So after the screenshot, I ask about one number. Where does this card come from? What happens to it when I select two regions? Is it a measure or a column? Confident candidates who built the report by following a tutorial often cannot answer, and the confidence suddenly works against them.
| What the screenshot shows | What I ask next | Strong answer | Answer that undoes the pitch |
|---|---|---|---|
| A Profit Margin card | Is this a measure or a column? | A measure: total profit divided by total sales | I averaged the margin column |
| Customers: a large number | Unique customers or orders? | DISTINCTCOUNT on CustomerID | COUNT of the customer column |
| A YoY growth arrow | How is last year calculated? | SAMEPERIODLASTYEAR on a marked date table | I filtered the year manually |
| Region slicer | Does it filter every visual? | Yes, except one I set with Edit interactions | I think so |
-- Calculated column (row level)
Row Margin % = DIVIDE ( Sales[Profit], Sales[Revenue] )
-- Confident but wrong card measure
Margin % (Wrong) = AVERAGE ( Sales[Row Margin %] )
Why it is wrong:
Order A: revenue 100, profit 50 -> 50%
Order B: revenue 10000, profit 1000 -> 10%
Average of rates: 30%
Real margin: 1050 / 10100 = about 10.4%
Small orders get the same weight as large ones,
so the card overstates the business margin.Total Revenue = SUM ( Sales[Revenue] )
Total Profit = SUM ( Sales[Profit] )
Margin % =
DIVIDE ( [Total Profit], [Total Revenue] )
What to say when asked:
'I build ratios from totals, not by averaging
row-level ratios. DIVIDE handles a zero
denominator by returning blank instead of an
error. Because it is a measure, it recalculates
for every region, month or product the user
selects.'
Check: put Margin % in a table by Region and
confirm one row by hand from the source totals.
The wrong version is not a beginner mistake in syntax. It runs without errors and produces a believable number, which is exactly why it is dangerous in a real business report and why interviewers test for it.
SECTION 02The live build tasks that test the confidence
In many Power BI rounds, the interviewer shares a small model and asks for two or three measures. These tasks are deliberately short. They are not testing speed. They are testing whether your measures are correct, and whether you check them.
Confident candidates sometimes rush, because they expect the task to be easy. They write the first measure that runs, drop it in a card, and announce the answer. Careful candidates put the measure in a table with a slicer and compare it with the source first. That habit is worth more than any amount of fluent talk.
| Live task | Quick but wrong | Correct approach | How to verify |
|---|---|---|---|
| Number of customers | COUNT ( Sales[CustomerID] ) | DISTINCTCOUNT ( Sales[CustomerID] ) | Compare with rows in the Customer table |
| Average order value | AVERAGE ( Sales[LineAmount] ) | DIVIDE ( [Total Sales], DISTINCTCOUNT ( Sales[OrderID] ) ) | Check one order with several lines |
| Sales of top category only | Filter the visual by hand | CALCULATE with a category filter in the measure | Change the slicer and confirm it stays fixed |
| Customers with 2+ orders | Count of rows above 2 | COUNTROWS over FILTER on customers with order count | Spot-check two customers in the source |
-- Sales has one row per order LINE, not per order
Order Lines = COUNTROWS ( Sales )
Orders = DISTINCTCOUNT ( Sales[OrderID] )
Customers = DISTINCTCOUNT ( Sales[CustomerID] )
Avg Order Value =
DIVIDE ( SUM ( Sales[LineAmount] ), [Orders] )
-- Averaging lines would give average LINE value,
-- which is lower whenever orders have many lines.Repeat Customers =
COUNTROWS (
FILTER (
VALUES ( Sales[CustomerID] ),
CALCULATE ( DISTINCTCOUNT ( Sales[OrderID] ) ) >= 2
)
)
Repeat Rate =
DIVIDE ( [Repeat Customers], [Customers] )
How it works, in words:
'VALUES gives the customers visible in the
current filter context. For each one, CALCULATE
turns the row into a filter and counts their
orders. FILTER keeps those with two or more,
and COUNTROWS counts them.'
Notice the grain comment at the top of the first tab: one row per order line. Stating the grain before writing any measure prevents most counting mistakes, and it is something interviewers rarely hear from confident but untested candidates.
In Uncodemy mock interviews, we ask candidates to say the grain out loud before they write any measure. It feels slow the first time, but it is the habit that keeps a count of customers from quietly becoming a count of order lines.
SECTION 03Confident model settings that worry interviewers
Confidence also shows up in modelling choices. Some candidates say they 'always set relationships to both directions so filters work everywhere'. It sounds decisive. To an experienced interviewer, it is a warning sign, because bidirectional filtering everywhere can create ambiguous paths, slow reports and numbers that change in unexpected ways.
The goal is not to avoid every advanced setting. It is to show you know why the default exists and when you would change it.
| Confident statement | Why it worries me | What I want to hear | Safer default |
|---|---|---|---|
| I always use both-direction filters | Ambiguous paths and confusing results | Only when needed, like a slicer of customers who bought | Single direction, dimension to fact |
| I put everything in one flat table | Large file, repeated values, hard measures | Star schema with fact and dimension tables | Separate dimensions for Date, Product, Customer |
| I use the auto date hierarchy | No proper time intelligence control | A dedicated date table marked as date table | Turn off auto date/time, add a Date table |
| Implicit measures are fine | Unclear logic, hard to reuse | Explicit measures with clear names | Write every aggregation as a measure |
Date =
ADDCOLUMNS (
CALENDAR ( DATE ( 2023, 1, 1 ), DATE ( 2025, 12, 31 ) ),
"Year", YEAR ( [Date] ),
"Month No", MONTH ( [Date] ),
"Month", FORMAT ( [Date], "MMM" ),
"Year Month", FORMAT ( [Date], "YYYY-MM" )
)
Steps after creating it:
1. Table tools -> Mark as date table -> Date column
2. Relate Date[Date] to Sales[OrderDate], one-to-many
3. Sort Month by Month No
4. Use Date fields, not Sales[OrderDate], in visuals
Sales LY = CALCULATE ( [Total Sales], SAMEPERIODLASTYEAR ( 'Date'[Date] ) )Need: a Product slicer that shows only products
the selected customer has bought.
Instead of setting the relationship to Both
permanently, apply it inside one measure:
Customer Products =
CALCULATE (
DISTINCTCOUNT ( 'Product'[ProductID] ),
CROSSFILTER ( Sales[ProductID], 'Product'[ProductID], BOTH )
)
What to say:
'I keep relationships single-direction by default.
When one calculation needs a filter to flow the
other way, I use CROSSFILTER inside that measure,
so the rest of the model stays predictable.'
Answers like these sound confident too. The difference is that the confidence is attached to a reason, and the reason shows you have thought about how the model behaves, not just whether the visual looks right.
SECTION 04Checklist: back your Power BI pitch with proof
Run this checklist on the report you plan to show in interviews. Every number you mention should pass it. Then rehearse the pitch so that each claim leads naturally to something you can demonstrate.
FOR EVERY CARD AND KEY VISUAL
Number: _________________
Measure name: ___________ (not implicit)
Grain of the fact table: one row per ______
[ ] Ratios built from totals with DIVIDE
[ ] Counts use DISTINCTCOUNT where needed
[ ] Checked against source for one filter
[ ] Correct with two slicer values selected
[ ] Correct with no slicer values selected
[ ] Time measures use a marked Date table
Fail any box -> fix before the interview.MODEL VIEW CHECK
[ ] Fact table(s) and dimension tables separated
[ ] One-to-many relationships, dimension -> fact
[ ] No unnecessary both-direction filters
[ ] No inactive relationships I cannot explain
[ ] Auto date/time turned off
[ ] Date table marked and related
[ ] Unused columns removed
[ ] Measures in a dedicated measures table
Be ready to explain any box you did NOT tick.90-SECOND REPORT PITCH
1. Business question (1 sentence)
'Which regions and categories drive margin?'
2. Data and model (2 sentences)
'Sales fact at order-line grain, with Date,
Product, Customer and Region dimensions.'
3. Two key measures and why they are correct
'Margin % divides total profit by total revenue.'
4. One problem you solved
'Customer counts were inflated; I switched to
DISTINCTCOUNT and checked against source.'
5. One insight a manager would act on
End with: 'Shall I build one of these measures live?'
SECTION 05Habits that turn Power BI confidence into trust
Confidence is welcome when it is backed by checks. These habits make your checks visible to the interviewer.
- State the grain first — Saying 'one row per order line' before writing measures prevents most counting and averaging mistakes.
- Build ratios from totals — Always divide summed numerators by summed denominators, and say why averaging row-level ratios is misleading.
- Verify with a slicer — Test new measures in a table with a slicer and compare one value with the source before calling it correct.
- Explain every non-default — If you changed a relationship or setting from its default, have one sentence ready about the reason and the risk.
- Offer to build live — Ending your pitch with an offer to build a measure live shows confidence that is grounded in real skill.
SECTION 06Interview Q&A — Power BI confidence
Q1Why should Margin % be a measure and not an average of a column?
Because averaging row-level percentages gives every row equal weight, regardless of its size, so small orders distort the result. A measure that divides total profit by total revenue weights correctly and recalculates under every filter combination. I use DIVIDE to handle zero revenue safely.
Q2What is the difference between COUNT and DISTINCTCOUNT in DAX?
COUNT counts non-blank values in a column, so a customer with five orders is counted five times in the Sales table. DISTINCTCOUNT counts unique values, so each customer is counted once. For customers or orders in a line-level fact table, DISTINCTCOUNT is usually what the business means.
Q3When would you use a bidirectional relationship?
Rarely, and only when a specific need requires filters to flow from the fact table back to a dimension, such as limiting a product slicer to products a selected customer bought. Even then I prefer CROSSFILTER inside a single measure, so the rest of the model keeps predictable single-direction filtering.
Q4Why do you need a separate date table in Power BI?
Time intelligence functions like SAMEPERIODLASTYEAR and TOTALYTD need a continuous date column with one row per day. A dedicated date table, marked as a date table and related to the fact table, provides that and lets me add fiscal years, month names and sort orders consistently across all visuals.
Q5What is a star schema and why does it matter in Power BI?
A star schema has a central fact table, such as sales transactions, linked to dimension tables such as Date, Product and Customer through one-to-many relationships. It keeps the model smaller, makes filters flow predictably and makes DAX measures simpler and faster than a single flat table.
SECTION 07Test yourself — Power BI confidence quiz
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 08Frequently asked questions
Is a good-looking dashboard enough to get a Power BI job?
Usually not on its own. Interviewers want to see that the numbers are correct and that you understand the measures and model behind them. A simpler dashboard with correct, well-explained measures is more convincing than a beautiful one you cannot defend.
What live tasks are given in Power BI interviews?
Common tasks include writing measures for totals, unique counts, averages, percentages of total, year-over-year growth and top-N rankings, fixing a broken relationship, or cleaning a column in Power Query. Tasks are usually short and focus on correctness.
How do I present my Power BI project in an interview?
Start with the business question, describe the data model and the grain of the fact table, explain two key measures and why they are correct, mention one problem you solved, and end with one insight. Offer to build a measure live.
Why is averaging percentages wrong in Power BI?
Because each row's percentage is treated equally regardless of size. An overall percentage should weight by volume, which you get by dividing a total numerator by a total denominator in a measure.
Should I use bidirectional filters in Power BI?
Only when there is a clear need, and preferably inside a specific measure using CROSSFILTER. Bidirectional relationships across a whole model can cause ambiguity and slower performance, which interviewers often ask about.
Does Uncodemy help with Power BI interview questions?
Yes. Uncodemy's Power BI Training Course in Noida (classroom and online) includes live projects, one-to-one mock interviews and resume reviews, so you practise Power BI interview questions with trainer feedback before the real interview. You can book a free demo class from this page to see how the sessions work.
SECTION 09Related reads
Classroom & online · Noida
Back your Power BI confidence with real skill
Our Power BI Training Course trains you to build correct measures, clean models and explainable dashboards, with live build practice that mirrors real interview tasks.
Talk to a counsellor for current fees- DAX measure practice
- Star schema modelling
- Live build mock rounds
- Weekday & weekend batches