A flame-chart profiler should keep captured samples and intervals as immutable evidence, then derive every stack, rectangle, search result, selection, and detail view from that evidence and one visible time domain. Parsing and indexing belong in workers. Dense pixels can use Canvas or WebGL, but keyboard and screen-reader access need a smaller semantic DOM view.
A flame chart looks simple because the finished screen is mostly colored blocks. The difficult work sits behind those blocks. The product has to ingest a large, sometimes incomplete trace, reconstruct shared stacks, switch resolution while zooming, answer hit tests quickly, preserve selection across projections, and explain what sampled evidence can and cannot prove.
The frontend should own the current viewport, renderer, hover state, selection, filters, search, comparison range, and bounded indexes needed for interaction. A capture service or privileged host should own profiling permission, durable trace storage, redaction, symbol resolution policy, collaboration access, and audited export.
Clarify which profiler you are building
Start with the evidence source. A statistical CPU profiler samples stacks at intervals. An instrumented trace records explicit begin and end events. Browser performance tools often combine samples, tasks, rendering events, network markers, screenshots, and process or thread tracks. These sources do not carry the same certainty, so the UI must label them honestly.
For this design, assume an authenticated browser performance product that imports or streams traces containing monotonic timestamps, thread IDs, samples, explicit intervals, and markers. Desktop is the primary exploration surface. Mobile supports an overview, search, saved findings, and focused stack inspection rather than the full dense authoring workspace.
The profiler will not implement the operating-system sampler, guess missing symbols, or claim that a sampled stack proves exact continuous execution. Source editing and arbitrary query languages are also outside the first release.
The public interview prompt
Design a frontend flame-chart profiler for large browser and application traces. Explain:
- trace import, streaming, schema versions, capture generations, parsing, and cancellation;
- samples, explicit intervals, stack interning, markers, missing symbols, and truncated evidence;
- time-domain indexes, aggregation, semantic zoom, pan, selection, search, and comparison ranges;
- Canvas, WebGL, workers, tile caches, device-pixel ratio, hit testing, and context loss;
- keyboard and screen-reader access, touch, reduced motion, localization, and source navigation;
- memory budgets, privacy, safe sharing, observability, tests, and rollout.
What the premium solution covers
The complete solution builds the profiler from an immutable trace model. It explains how samples become weighted stack nodes, how worker indexes support range queries, how one semantic zoom transform drives rendering and hit testing, how the visual surface and accessibility tree cooperate, and how the UI survives incomplete captures, missing symbols, worker failure, and GPU context loss.
Original media includes an aligned sample-to-stack icicle, a semantic zoom loop with frame-level continuity tests, a braided rendering pipeline, and an evidence-quality comparison. A deterministic lab lets the reader change trace density, viewport width, pixel ratio, stack depth, and zoom while observing renderer mode and bounded work.