Dashboarding — Interview Q&A
Q: Walk through your actual process for building a new dashboard from scratch.
A: Start before touching any tool: identify the specific user (not "the team" — a named role), the decision they actually make with this dashboard, and the single most important metric — if I can't name one clear hero metric, that's a sign the requirements aren't focused enough yet. From there, a rough wireframe reviewed with the actual stakeholder catches layout and priority mistakes while they're still free to fix, before any real building. Only after that do I connect data sources, build measures, and lay out visuals — starting from available data instead of the actual decision is the most common reason a dashboard gets built, launched, and then quietly stops being used.
Q: Why does a dashboard sometimes go unused even when it's technically accurate?
A: Almost always because it was built data-first rather than question-first — it shows correct numbers that don't actually map to how the intended user makes a decision day-to-day. A good diagnostic: ask the dashboard's primary intended user to describe, unprompted, what decision it helps them make. If they can't answer clearly, the dashboard likely wasn't built around an actual decision in the first place, and no amount of visual polish fixes that — the fix is going back to define the actual question the dashboard needs to answer.
Q: Explain what CALCULATE does in DAX, and why time-intelligence functions like SAMEPERIODLASTYEAR depend on it.
A: CALCULATE re-evaluates an expression under a modified filter context rather than the currently-active one — SAMEPERIODLASTYEAR uses exactly this mechanism, computing the same measure but as if the current date filter were shifted back a year, while still respecting whatever other filters (region, category) are already active from slicers. Understanding this as the underlying mechanism, rather than memorizing time-intelligence functions as separate magic syntax, is what lets you build correct custom measures instead of just copying known patterns.
Q: Why do you need a dedicated date table instead of just filtering on the fact table's own date column?
A: Time-intelligence functions like SAMEPERIODLASTYEAR and TOTALYTD require a continuous date sequence to compute correctly — a raw fact-table date column has gaps on any day with zero transactions, which silently breaks those calculations. A dedicated Date Table, generated to cover the full analysis range continuously and explicitly marked as a Date Table in the model, guarantees that continuity. This is a genuinely common, hard-to-catch bug specifically because it works fine for date ranges with no gaps and only produces wrong numbers for ranges that happen to include one — easy to miss during initial testing against a "normal" range.
Q: A stakeholder says they don't trust the numbers on a dashboard you built, even though you've verified they're correct. How do you address that?
A: Trust gaps are usually not about actual accuracy — they're about an unexplained discrepancy against a number the stakeholder already has from another source, with no visible reason for the difference. The fix is making data lineage and definitions explicit: a visible "last refreshed" timestamp, and a documented, precise definition of what each metric includes (does "Revenue" include tax or refunds, for instance) — an unexplained gap erodes trust in every number on the dashboard, even the correct ones, so making the definitions and freshness visible is what actually rebuilds confidence, more than re-verifying accuracy the stakeholder can't see for themselves.
Q: What's row-level security, and what's its real value beyond "convenience"?
A: RLS filters the data a single published dashboard returns based on the logged-in viewer's identity — a regional manager sees only their region's data from one shared report definition, rather than needing a separate dashboard built per region. The value beyond convenience is maintainability: a layout or metric change made once applies correctly to every viewer's filtered view automatically. Without RLS, achieving the same per-region data separation means maintaining N separate dashboard copies, which reliably drifts out of sync as changes get applied to some copies and missed on others.
Q: How would you diagnose a dashboard that's become slow to load, without just guessing at the cause?
A: Use the platform's built-in profiling tool (Power BI's Performance Analyzer, Tableau's Performance Recording) to get actual per-visual and per-query timing, rather than guessing which visual "feels slow." The common real causes, in rough order of likelihood: an inefficient underlying query (DirectQuery hitting the live source on every interaction instead of a pre-aggregated extract), too many visuals on one page each issuing their own query, a high-cardinality visual rendering thousands of individual rows, or genuinely inefficient DAX logic recalculating an expensive aggregation from scratch. The profiler data turns a vague "it's slow" into a specific, fixable diagnosis rather than a guess.