Power BI Interview Questions with Detailed Answers

A Power BI interview case study is where many candidates win or lose the job. Question lists test what you know; a case study shows what you do with an unfamiliar dataset in limited time. A typical brief: "Here are two years of daily bike rentals. Build a model and a one-page report that answers four questions. You have three hours." This guide works through exactly that task on the UCI Bike Sharing data (UCI: Bike Sharing).

Step 1: model before you visualise

Reviewers look at the model first. Microsoft's guidance describes the star schema as classifying tables into dimensions, which describe entities such as dates or weather, and facts, which hold the measurable events, with a date dimension the most consistent table you will find (Microsoft Learn: star schema). For this task:

• Fact: one row per day with weather code, casual, registered and total rentals.
• Date dimension: date, year, month, weekday, holiday and working-day flags. Mark it as the date table.
• Weather dimension: code and a readable label.

Relationships run one-to-many from each dimension to the fact table, single direction.

Step 2: write the measures

Rentals = SUM ( Fact[cnt] )
Rentals PY = CALCULATE ( [Rentals], SAMEPERIODLASTYEAR ( 'Date'[Date] ) )
YoY Growth = DIVIDE ( [Rentals] - [Rentals PY], [Rentals PY] )
Casual Share = DIVIDE ( SUM ( Fact[casual] ), [Rentals] )
Avg Daily Rentals = AVERAGEX ( VALUES ( 'Date'[Date] ), [Rentals] )

Step 3: check your answers independently

Before presenting, confirm your numbers another way. Here the same logic is reproduced in pandas to give reference answers:

import pandas as pd

# A pandas reproduction of the answers a Power BI take-home would ask for (not run in Power BI).
# Task: "Using two years of daily bike rentals, build a model and a one-page report answering four questions."
day = pd.read_csv("day.csv", parse_dates=["dteday"])

# Star schema: one fact table (rentals per day) and small dimension tables
dim_date = day[["dteday", "yr", "mnth", "weekday", "holiday", "workingday"]].assign(
    year=day.dteday.dt.year, month=day.dteday.dt.strftime("%b"))
dim_weather = pd.DataFrame({"weathersit": [1, 2, 3, 4],
                            "weather": ["Clear", "Mist or cloud", "Light rain or snow", "Heavy rain or snow"]})
fact = day[["dteday", "weathersit", "casual", "registered", "cnt"]]
print(f"Q0 model: fact {len(fact)} rows | date dimension {len(dim_date)} rows | weather dimension {len(dim_weather)} rows")
print(f"   weather codes present in the fact table: {sorted(int(c) for c in fact.weathersit.unique())} (code 4 never occurs)")

model = fact.merge(dim_date, on="dteday").merge(dim_weather, on="weathersit")

# Q1: total rentals and year-over-year growth
by_year = model.groupby("year").cnt.sum()
print(f"\nQ1 rentals {by_year[2011]:,} (2011) -> {by_year[2012]:,} (2012), growth {by_year[2012] / by_year[2011] - 1:.1%}")

# Q2: which month grew most?
month_year = model.pivot_table(index="mnth", columns="year", values="cnt", aggfunc="sum")
growth = (month_year[2012] / month_year[2011] - 1).sort_values(ascending=False)
names = dict(zip(model.mnth, model.month))
print(f"Q2 fastest-growing month: {names[growth.index[0]]} ({growth.iloc[0]:+.0%}); slowest: {names[growth.index[-1]]} ({growth.iloc[-1]:+.0%})")

# Q3: share of casual riders on working days vs non-working days
share = model.groupby("workingday")[["casual", "cnt"]].sum()
print(f"Q3 casual share: working days {share.loc[1, 'casual'] / share.loc[1, 'cnt']:.1%} | "
      f"weekends and holidays {share.loc[0, 'casual'] / share.loc[0, 'cnt']:.1%}")

# Q4: how much does bad weather cost, per day, compared with clear days?
avg = model.groupby("weather").cnt.mean()
print(f"Q4 average rentals per day: clear {avg['Clear']:,.0f} | light rain or snow {avg['Light rain or snow']:,.0f} "
      f"({avg['Light rain or snow'] / avg['Clear'] - 1:.0%})")

Q0 model: fact 731 rows | date dimension 731 rows | weather dimension 4 rows
   weather codes present in the fact table: [1, 2, 3] (code 4 never occurs)

Q1 rentals 1,243,103 (2011) -> 2,049,576 (2012), growth 64.9%
Q2 fastest-growing month: Mar (+157%); slowest: Jun (+41%)
Q3 casual share: working days 13.2% | weekends and holidays 31.7%
Q4 average rentals per day: clear 4,877 | light rain or snow 1,803 (-63%)

The model check found something worth mentioning: the weather dimension has four codes, but code 4, heavy rain or snow, never occurs in the data. A candidate who notices and says so shows care for the data, not just the tool.

Step 4: answer the questions, not just the brief

1. How fast did rentals grow? From 1,243,103 in 2011 to 2,049,576 in 2012, 64.9%.
2. Which month grew most? March, up 157% year on year; June grew least, 41%. Point out that a single month's growth can reflect weather in that particular year, so treat it with care.
3. Who rides when? Casual riders made up 13.2% of rentals on working days and 31.7% on weekends and holidays, which suggests different marketing for the two groups.
4. What does bad weather cost? Days with light rain or snow averaged 1,803 rentals against 4,877 on clear days, 63% fewer, though only a handful of such days exist.

Each answer is a number plus one sentence of interpretation and one caveat. That combination is what reviewers are looking for, because it is exactly what a stakeholder would need from you at work.

Step 5: design one clear page

Four answers, four visual areas: a card with growth, a column chart of monthly growth, a comparison of casual share by day type, and a bar chart by weather. A title stating the main finding, consistent colours, and nothing decorative. Add a small text box with assumptions and data issues, such as the unused weather code.

How reviewers score a case study

• Model: a clean star schema with a date table, correct relationships and no unnecessary columns.
• Measures: correct results, reusable base measures, DIVIDE for safe division, sensible names.
• Answers: each question answered directly, with interpretation and caveats.
• Design: readable, uncluttered, focused on the questions.
• Communication: a short write-up or walkthrough explaining choices and limitations.

When the case study is live

Some interviews run the same exercise live, with an interviewer watching your screen for forty-five minutes to an hour. The priorities change slightly. Talk through what you are doing as you do it: why you are splitting a table into fact and dimension, why a measure rather than a column, what you would check if you had more time. Interviewers in a live round care more about your reasoning than a finished page, and narrating lets them give hints when you head in the wrong direction. If you get stuck on a DAX formula, say what you are trying to calculate in plain words first; the interviewer can then judge your understanding even if the syntax takes a moment.

Presenting your solution

Most take-homes end with a short walkthrough. Start with the answers, not the process: "Rentals grew 65%, March grew fastest, casual riders are a weekend story, and rain cuts demand by about two-thirds." Then show the model in one slide or screen, explain one decision you are proud of and one limitation, and invite questions. Keep it to ten minutes. Practise once aloud beforehand, because explaining your own work clearly under time pressure is a skill in itself.

Managing the time

Spend roughly a quarter of the time understanding and modelling the data, half on measures and checking answers, and the rest on the page and the write-up. Do not spend an hour on colours or custom visuals. If something is unfinished, say so in your notes; reviewers respect honesty about scope far more than a polished page with a wrong number.

For conceptual questions in the same interview, see Power BI interview questions and DAX interview questions.

Modelling, DAX and report design for case studies are taught in the Power BI course.

Sources

• Understand star schema and the importance for Power BI (Microsoft Learn) — Microsoft
• Bike Sharing Dataset (UCI Machine Learning Repository) — UCI Machine Learning Repository