Dashboard Discussions — Interview Questions¶
Dashboard questions test design thinking, stakeholder communication, and tool judgment. Interviewers want to see that you build dashboards for the audience — not to show off your technical skills.
Tags: #Dashboard #PowerBI #Tableau #InterviewPrep #DataViz
Design Principles¶
[Beginner] What is the difference between a report and a dashboard?
Show answer
| Report | Dashboard | |
|---|---|---|
| Purpose | Detailed answer to a specific question | Real-time monitoring of key metrics |
| Audience | Analysts, people who want the full story | Executives, operators — decision-makers |
| Format | Long, narrative, static | Concise, visual, interactive |
| Update frequency | Periodic (weekly/monthly) | Continuous or daily |
| Depth | Deep — tables, commentary, methodology | Shallow — KPIs and trends, no explanatory text |
A report explains what happened and why. A dashboard tells you what's happening right now and whether it needs your attention.
[Mid-level] How do you decide what goes on a dashboard vs what stays in a report?
Show answer
A dashboard shows metrics that drive decisions and actions — things the audience monitors regularly and acts on when they move.
Filters for dashboard inclusion: 1. Is it actionable? Seeing it change should trigger a specific response 2. Is it time-sensitive? Would acting on it 24 hours later be too late? 3. Does the audience understand it? A metric your CEO doesn't understand doesn't belong on their dashboard
Everything else goes in a report or a drill-through detail page.
Example: "Return rate" belongs on an operations dashboard — a spike means investigate sourcing or quality immediately. "Return reason breakdown" belongs in a report — it explains the spike but isn't a daily monitor metric.
[Mid-level] A stakeholder asks you to add 15 more metrics to an already-busy dashboard. How do you handle this?
Show answer
I'd start by understanding why — what question are they trying to answer that the current dashboard doesn't address?
Then I'd propose alternatives: 1. If the metrics are truly operational: create a second, focused dashboard for that use case 2. If they're diagnostic/investigative: build a drill-through or linked report instead 3. If they're nice-to-have: archive them in a "data explorer" tab the stakeholder can self-serve
If the metrics really do belong on the dashboard, I'd remove something else first. Dashboards should be edited, not grown indefinitely.
Interview signal: never just say yes. A good analyst pushes back on dashboard bloat — every metric added dilutes focus and increases cognitive load.
Power BI vs Tableau¶
[Mid-level] When would you recommend Power BI over Tableau, and vice versa?
Show answer
| Power BI | Tableau | |
|---|---|---|
| Best for | Microsoft-heavy environments, self-service analytics | Advanced visualisations, large data, design-heavy work |
| Pricing | Cheaper for mid-size orgs (part of M365 ecosystem) | More expensive, better for enterprise scale |
| Data modelling | Superior — DAX is powerful, relationships handled well | Limited modelling — better to prep data externally |
| Collaboration | Teams integration, natural in Microsoft orgs | Tableau Server/Cloud — separate infrastructure |
| Learning curve | Moderate (DAX can be hard) | Moderate (intuitive drag-and-drop, but advanced features take time) |
| Direct query | Good | Excellent |
| Custom visuals | Via marketplace | Limited — but Tableau is catching up |
My rule of thumb: - The organisation uses Microsoft 365 → Power BI - Complex visualisation requirements, large datasets, polished design → Tableau - The team already has a tool → use what exists (switching costs are high)
[Mid-level] What is a calculated column vs a measure in Power BI? When do you use each?
Show answer
Both are created using DAX (Data Analysis Expressions) in Power BI Desktop.
| Calculated Column | Measure | |
|---|---|---|
| Computed | At data refresh time | At query time (when the visual renders) |
| Stored in | The data model (uses memory) | Not stored — calculated on demand |
| Context | Row context — can reference other columns in same row | Filter context — depends on what filters/slicers are active |
| Best for | Creating categories, labels, row-level groupings | Aggregations: SUM, AVERAGE, DIVIDE, % calculations |
Example:
-- Calculated column: order size classification (row-level)
Order Size = IF(orders[Total] > 300, "Large", IF(orders[Total] > 100, "Medium", "Small"))
-- Measure: total revenue (aggregate, respects filters)
Total Revenue = SUM(orders[Total])
-- Measure: % of total (filter-context aware)
Revenue % = DIVIDE([Total Revenue], CALCULATE([Total Revenue], ALL(orders[Category])))
[Senior] How do you design a dashboard for two different audiences: a CEO and a warehouse operations manager?
Show answer
They need fundamentally different dashboards — even if they're looking at the same underlying data.
CEO dashboard: - 4-6 KPIs: Revenue vs target, CLV, Gross Margin %, NPS, Churn rate - Monthly/quarterly time horizon - Trend direction is more important than precision — "Revenue is up 12% YoY" not "Revenue is £1,249,432.87" - No operational detail — they need to know if the business is healthy, not what's happening in warehouse 3
Warehouse operations manager dashboard: - Real-time or hourly updates: orders queued, orders shipped, SLA compliance, stockouts by location - Daily and weekly time horizon - Alerts and exceptions: "42 orders past SLA", "Product X stockout in Zone B" - Drill-through to individual orders or SKUs
Key principle: the CEO dashboard answers "Is the business on track?" The operations dashboard answers "What do I need to act on right now?"
[Senior] A dashboard you built is being criticised as "slow" — queries take 5-8 seconds to load. How do you investigate and fix it?
Show answer
Step 1 — Diagnose the bottleneck: - Is the slow step in the query, the data model, or the rendering? - In Power BI: use Performance Analyzer (View → Performance Analyzer) to see which visual is slowest - In Tableau: use Dashboard > Actions > View Data to inspect query duration
Step 2 — Common causes and fixes:
| Cause | Fix |
|---|---|
| Query hitting a 100M-row live table | Use Direct Query only where real-time matters; switch to Import for historical data |
| Complex DAX measure with nested CALCULATE | Simplify or pre-aggregate in the data source |
| Many row-level calculated columns | Move calculations to the source database query |
| Too many visuals on one page | Split into multiple pages; reduce visual count |
| No aggregation table | Build a pre-aggregated summary table for common queries |
| Large imported dataset | Add incremental refresh — only import new/changed data |
Step 3 — Quick wins: - Disable auto-refresh while editing - Reduce the date range of default filters - Remove visuals the audience doesn't use
[Senior] What makes a dashboard "production-ready"?
Show answer
A production dashboard is one that: the audience trusts, refreshes reliably, is maintained, and can be used without the person who built it in the room.
Checklist: - [ ] Data accuracy verified — numbers match the source system or agreed calculations - [ ] Refresh schedule set — automated, not manual - [ ] Refresh failure alerting — you're notified if the refresh fails (not the CEO) - [ ] Row-level security — users only see data they're allowed to see - [ ] Consistent date filters — all charts use the same date range, clearly labelled - [ ] Documented calculations — definitions of every KPI are accessible (tooltip or linked doc) - [ ] Tested on different screen sizes — especially if executives use it on mobile - [ ] Change management — audience knows what the dashboard shows and how to read it - [ ] Version control or backup — you can roll back if something breaks