Skip to content

Interview Questions — Sales Dashboard

Questions an interviewer might ask after you present this project.

[Beginner] Walk me through this project. What was the business problem and what did you build?

Show answer

A strong answer is structured: problem → approach → outcome.

"Superstore Co. was growing revenue but leadership had no automated visibility into performance — every report was a manual two-hour Excel export. I built a Power BI dashboard that auto-refreshes and answers their key questions: revenue trend, product and regional performance, and profitability.

The most valuable part wasn't the dashboard itself — it was a finding I surfaced: 18.7% of line items were selling at a loss because of excessive discounting. Profit turned negative above 20% discount. I recommended a 20% discount cap, which could recover about $130k in lost profit — a 45% increase. So the project didn't just save reporting time, it identified a structural profit leak."

[Beginner] Why is profit more important than revenue in this analysis?

Show answer

Revenue is vanity, profit is sanity. A company can grow revenue while losing money — which is exactly what was happening here. Furniture generated 32% of revenue but only 6% of profit. If you optimise for revenue alone, you'd push Furniture and deep discounts, both of which destroy the bottom line.

The dashboard deliberately shows revenue AND profit side by side so leadership doesn't get fooled by a growing top line.

[Mid-level] How did you handle the fact that this dataset has one row per line item, not per order?

Show answer

This is a granularity issue that affects every calculation:

  • For revenue/profit: summing across line items is correct — total revenue is the sum of all line items.
  • For order counts: I used COUNT(DISTINCT order_id), not COUNT(*), because one order spans multiple rows. Counting rows would inflate the order count.
  • For average order value: SUM(sales) / COUNT(DISTINCT order_id), not AVG(sales) — AVG(sales) would give average line-item value, not average order value.

Getting this wrong is a classic mistake that inflates order counts and understates AOV.

[Mid-level] You found that discounts above 20% lose money. How would you validate that capping discounts wouldn't just lose the sales entirely?

Show answer

Good challenge — this is the elasticity question. My recommendation assumes some sales would survive without the deep discount, but I can't prove that from this dataset alone.

To validate, I'd: 1. Look at historical price changes: find products whose discount changed over time and measure the volume impact. 2. Run an A/B test (gold standard): for a subset of products, cap discounts at 20% and compare volume and profit to a control group still allowed deeper discounts. 3. Segment the deep-discount sales: are they end-of-life clearance (where some recovery is good) or routine sales that are needlessly discounted?

My recommendation would be framed as a hypothesis to test, not a certainty: "Capping at 20% should improve profit; let's pilot it on one category and measure."

[Mid-level] What DAX measures did you create and why?

Show answer

The core measures: - Total Revenue = SUM(sales[sales]) and Total Profit = SUM(sales[profit]) — base measures - Profit Margin = DIVIDE([Total Profit], [Total Revenue], 0) — used DIVIDE not / to avoid divide-by-zero errors - Total Orders = DISTINCTCOUNT(sales[order_id]) — distinct count because of the line-item granularity - Revenue YoY % = DIVIDE([Total Revenue] - [Revenue LY], [Revenue LY]) using SAMEPERIODLASTYEAR — for the trend indicators - Loss Making % = DIVIDE([Loss Making Items], COUNTROWS(sales)) — to surface the headline finding

Key point: I used measures (not calculated columns) for all aggregations so they respect the filter context from slicers.

[Senior] A regional manager disputes your dashboard, saying their region's "real" numbers are higher. How do you handle this?

Show answer

First, I treat it as a legitimate concern, not a challenge to my work. Discrepancies usually have a real cause:

  1. Definitional difference: Are we measuring the same thing? They might count bookings (orders placed) while my dashboard counts shipped/completed sales. Or different date logic (order date vs ship date).

  2. Date range / filter: Are we looking at the same period? A different fiscal calendar or an active slicer can explain it.

  3. Data freshness: Is their number from a different (more recent) source? When did each dataset last refresh?

  4. Scope: Does their number include returns, taxes, or shipping that mine excludes?

I'd sit with them, reconcile line by line, and find the gap. Often the dashboard is right and reveals a number they'd been overstating — but sometimes it surfaces a genuine data quality issue I need to fix. Either way, reconciling transparently builds trust. The worst response is to defend the dashboard without investigating.

[Senior] How would you make this dashboard production-ready and scalable to 10M+ rows?

Show answer
  1. Switch from CSV to a database source — connect Power BI to the data warehouse, not a flat file.
  2. Use a star schema — separate fact (sales) and dimension tables (date, product, customer, region) rather than one flat table. Improves performance and maintainability.
  3. Incremental refresh — only load new/changed data rather than the full 10M rows every refresh.
  4. Pre-aggregate — build summary tables (daily revenue by region/category) in the warehouse; the dashboard queries those for high-level views and drills to detail only on demand.
  5. Aggregations feature — Power BI can keep a small in-memory aggregate and fall back to DirectQuery for detail.
  6. Row-level security — regional managers only see their region's data.
  7. Refresh monitoring — alert the data team (not the CEO) if a refresh fails.
  8. Documented measures — every KPI definition accessible so there's a single source of truth.

← Insights and Recommendations · ← Project Overview · Next Project: HR Analytics →