Scenario. Operations managers are complaining that the real-time incident response dashboard shows conflicting vehicle locations during peak hours, causing delayed dispatch decisions. You are tasked with designing a new module to reconcile these signals into a single source of truth without obscuring necessary uncertainty. Walk us through your approach to diagnosing the signal conflicts, selecting the appropriate reconciliation logic, and designing the user interface to communicate confidence levels to operators.
Problem to solve. Reconcile conflicting real-time GPS and AVL signals into a single, uncertainty-aware dashboard module for incident response.
Format
discovery-interview · 35 min · ~2 hr prep
Success criteria
- Identifies root causes of signal conflict such as latency, GPS drift, and AVL polling intervals
- Designs a reconciliation strategy that balances accuracy with real-time performance
- Proposes UI patterns that transparently display data uncertainty to non-technical operators
What to review beforehand
- Real-time transit data architecture basics including GTFS-Realtime, AVL, and GPS
- Principles of uncertainty visualization
Ground rules
- You will lead the discovery conversation with the Lead Systems Architect.
- The architect will provide honest technical details only when asked.
- Focus on your diagnostic reasoning and design tradeoffs.
Roles in scenario
Lead Systems Architect (Maya Rodriguez) (informed_partner, played by cross_functional)
Motivation. Needs a reliable real-time module that reduces dispatch latency but is constrained by legacy AVL polling rates and network bottlenecks.
Constraints
- AVL system polls every 30 seconds, GPS updates every 5 seconds but drops packets during tunnels
- Backend cannot support sub-100ms reconciliation due to current server load
- Operators need to know when data is estimated versus live
Tensions to introduce
- The 30-second AVL poll creates noticeable jumps on the map
- GPS drift causes false off-route alerts in dense urban corridors
- If candidate proposes heavy server-side smoothing, explain backend latency constraints
In-character guidance
- Provide exact polling intervals and packet drop rates when asked
- Clarify that UI must work on low-bandwidth field tablets
- Acknowledge tradeoffs between smoothing algorithms and raw data latency
Do not
- Do not volunteer the exact polling intervals or backend constraints unless asked
- Do not suggest the reconciliation algorithm or UI pattern
- Do not coach the candidate on real-time data best practices
Scoring anchors
- Exceeds
- Diagnoses root causes systematically, designs a lightweight reconciliation logic, and creates an uncertainty-aware UI that directly improves operator decision speed.
- Meets
- Identifies key latency and polling constraints, proposes a feasible reconciliation method, and includes basic uncertainty indicators in the design.
- Below
- Ignores real-time constraints, proposes architecturally infeasible solutions, or fails to communicate data uncertainty to end users.