How would you instrument front-end and back-end to quantify reported slowness?

WHAT THIS TESTS: The interviewer wants to see if you can turn a subjective complaint into an objective measurement plan that spans the entire request lifecycle. They care about your mental model of full-stack observability and whether you understand that slowness is a user-perceived phenomenon, not just a server health issue.

A GOOD ANSWER COVERS: First, front-end instrumentation using real user monitoring to capture Core Web Vitals such as LCP, INP, and CLS, plus custom timers for specific dashboard component renders and user interactions like clicks or filters. Second, back-end telemetry including distributed tracing across services so you can follow a request from the edge to the database, capturing API latency percentiles like p50, p95, and p99, and profiling slow queries with execution plans. Third, correlation strategy by attaching user IDs, session IDs, device types, and browser versions to every span so you can segment the data and see whether slowness affects power users with huge datasets, mobile clients, or specific geographic regions. Fourth, a feedback loop where the quantified metrics are shared with the user who reported the issue to validate that the pain point was captured correctly.

COMMON WRONG ANSWERS: Proposing only infrastructure metrics such as server CPU, memory, or disk usage without any user-facing timing data. Suggesting synthetic monitoring alone, which misses real user conditions like cache state, auth overhead, or data size. Dumping raw logs without a structured trace or correlation ID that ties front-end events to back-end queries. Claiming you would just add more servers without first identifying whether the bottleneck is network, render, or database.

LIKELY FOLLOW-UPS: How would you distinguish between a network latency issue and a server processing issue? What would you do if metrics show the back-end is fast but the user still reports slowness? How do you prioritize which pain point to fix first when multiple bottlenecks appear? How would you instrument this without significantly impacting the user experience or bundle size?

ONE CONCRETE EXAMPLE: Suppose a user says the sales dashboard feels slow. You add a real user monitoring beacon that captures LCP and a custom timer for the chart render phase. The data shows LCP is under two seconds but the chart render timer averages six seconds on Chrome and twelve seconds on Safari. Distributed traces reveal the back-end API returns in three hundred milliseconds, yet the front-end performs five megabytes of JSON parsing and synchronous layout thrashing. You segment by user and find the complainant is on an older MacBook with a large account history. The fix is virtualized scrolling and moving JSON flattening to a web worker, not scaling the API servers.