What to work through
Work through a dashboard of widgets as a spoken system design interview. Start by clarifying the scope, sketch a working design and explain the trade-offs behind your choices.
- Show a page of widgets, each a chart, a number or a table drawing its own data
- Add, remove, move and resize widgets, and keep the layout
- Refresh each widget's data by itself, with a time range for the page or for one widget
- Show each widget's loading, empty and error state on its own
Constraints to discuss
- A click answers within 200 milliseconds while widgets load
- A chart's update fits in a frame: about 10 milliseconds of work at 60 frames a second
- A dashboard of 100 widgets stays usable
- Data may arrive up to 10 seconds late
Need a starting point?
Watch for these common gaps as you prepare:
- Letting every widget fetch and draw the moment the page opens
- Rendering once per incoming point instead of once per frame
- Replacing a chart's whole data on each update instead of appending
- One error for the page when one widget fails
- Polling on while the tab is hidden
- Tying render scheduling to fetch scheduling, as Datadog's old scheduler did
Why this question is in the collection
These sources connect the problem to company interview reports or preparation guides. They do not guarantee what a company will ask you.
- Datadog: A senior frontend candidate in Madrid reports a system design interview in July 2025: design a dashboard that supports multiple widgets. No offer; in their own words the answer lacked detail on the architectural decisions.
- LinkedIn: An engineer at the SSE level reports an onsite system design question, about January 2026: a monitoring system with a dashboard.