A Dashboard Interview Exercise With Two Conflicting Totals
Reconcile conflicting dashboard totals through definitions, record grain, filters, identifier sets and refresh timing before declaring a result.
TL;DR
- In this fictional exercise, finance and operations dashboards disagree on completed-order totals.
- Compare definitions, identifiers, joins, time boundaries, and update timing before deciding which total is correct.
- State what can be reported now, then repair the data contract and test the specific cause of the discrepancy.
Do not choose the more familiar dashboard
Use this fictional interview prompt: finance and operations dashboards show different totals for completed orders on the same day. A manager asks which one is correct before a meeting. The interviewer wants your investigation plan.
Begin by asking what each total is intended to count. The same label can conceal different definitions: orders created that day, orders completed that day, unique paid orders or all completion events. Two totals can differ without either calculation being wrong for its own definition.
Avoid settling the issue by choosing the newer dashboard, the larger number or the team with more authority. Establish the metric contract and trace the data that produced each result.
Write a comparison sheet
Record the definition, time boundary, filters, grain, source and refresh time for both dashboards. Use the same snapshot where possible so that the investigation does not compare a changing dataset with an older extract.
| Dimension | Question to resolve |
|---|---|
| Unit | Orders, line items or events? |
| State | Which status qualifies as completed? |
| Time | Creation, completion or ingestion time? |
| Scope | Which accounts, regions and test records? |
| Freshness | When was each view last updated? |
| Corrections | How are cancellations and refunds handled? |
A concise metric definition can expose the mismatch before any query is changed. If the business definition itself is disputed, name the owner who must decide it rather than burying that disagreement inside SQL.
Reconcile identifiers before amounts
For the fictional case, extract the eligible order identifiers from each system for the agreed period. Compare the sets: present in both, only in finance and only in operations. This narrows the investigation to concrete records instead of repeatedly comparing two totals.
Suppose operations counts completion events and one order has two such events after a retry. Finance counts unique order records. The difference may be a grain mismatch rather than a missing transaction. Changing a filter without understanding the grain could hide the symptom while preserving the defect.
Inspect representative mismatches and trace them to source records. Do not assume every difference has the same cause; a duplicate event and a late-arriving order can coexist.
Check joins and time boundaries
A join to order items can multiply order rows when an order has several items. If the metric is orders, the query must preserve the intended grain. A distinct count may mask the symptom, but you should still understand whether the join is appropriate and whether other measures are affected.
Time-zone differences can also move records across day boundaries. Ask whether the report uses a business-local day or another defined standard. Compare actual timestamps around the boundary rather than assuming the date displayed in the interface is the grouping rule.
Refresh timing matters too. One dashboard may include a correction that the other has not yet processed. Record the comparison time and repeat only after the expected update path has completed, preserving evidence of any remaining difference.
Decide what can be reported now
If the meeting occurs before reconciliation is complete, communicate the known definitions and uncertainty. Do not label a provisional choice as verified truth. A suitable message identifies the two measures, the suspected cause and the next check needed.
If one dashboard clearly implements the approved definition and the other does not, explain that evidence and use the appropriate figure under the organisation's process. If the definition is unresolved, escalate the metric decision rather than declaring a technical winner.
Our system design frameworks guide can help show the source, transformation and serving layers. A dashboard is the visible endpoint of that chain, not the sole place where meaning is established.
Check who can see each dashboard. Access filters may intentionally restrict one user to a subset of orders. Comparing screenshots from accounts with different permissions can create an apparent discrepancy. Reconcile with appropriately authorised views and never remove access controls merely to make two totals match.
Repair the contract and prevent recurrence
After resolving the discrepancy, update the metric definition and relevant transformation or label. Add a focused reconciliation check that would detect the actual failure mechanism, such as duplicate completion events or a changed filter. Avoid creating a generic alert that fires whenever any two unrelated totals differ.
Document legitimate differences. A near-real-time operational count and a reconciled reporting count may remain separate if their purposes require it. Clear names and freshness information can prevent a repeat argument about figures that were never intended to match.
In a mock interview rehearsal, ask a partner to introduce a late cancellation after you find the duplicate. Show that the method can handle another cause without discarding the earlier finding. The learning goal is a traceable reconciliation process: definition, grain, record sets, transformations and timing, followed by a claim no stronger than the evidence supports.