The Debugging Method: Measure, Isolate, Hypothesize, Verify

Senior interviewers rarely want the "right" answer to "the page is slow." They want to hear how you would find the answer without guessing. This lesson gives you the framework that every later lesson in this series reuses. It also gives you a tool map that shows which panel answers which question.

The four moves

1. MEASURE     Turn "it feels slow" into a number, a place and a baseline.2. ISOLATE     Find which layer owns the time: network, server, database, main thread, rendering.3. HYPOTHESIZE Form ONE specific, testable explanation for that layer.4. VERIFY      Change one thing, measure again against the baseline. Keep it only if the number moved.

A baseline is the starting number you compare against. The main thread is the single thread in the browser that runs your JavaScript and updates the page. A long task is a piece of work on the main thread that runs for more than 50 ms. While it runs, the page cannot react to clicks.

Some answers jump straight to "add useMemo" or "add Redis." useMemo is a React hook that memoizes (remembers) a value, so React does not calculate it again on every render. Redis is a fast database that keeps data in memory and is often used as a cache (a saved copy of a result). Those answers skipped moves 1 and 2. This is the most common way to sound junior.

Move 1: Measure (pin down the symptom)

Before you touch code, ask questions that turn a complaint into a precise problem statement:

Use percentiles, not averages

A percentile is a number that tells you the value below which a given share of your measurements fall. For example, p50 (the median) is the time that half of the requests beat, and p95 is the time that 95% of requests beat. Only the slowest 5% take longer.

Suppose 1% of requests take 10 seconds. The average still looks fine, but thousands of users suffer. So always look at p50, p95 and p99 for latency (the time a request takes). For Core Web Vitals, look at the 75th percentile. Core Web Vitals are three measures from Google about real user experience: LCP (Largest Contentful Paint, how fast the main content appears), INP (Interaction to Next Paint, how fast the page reacts to a click or key press) and CLS (Cumulative Layout Shift, how much the page jumps around while loading). See Browser Contract, Lesson 09.

Field data vs lab data

• Field data is data measured on real users' devices while they use your site. Its sources are RUM (real user monitoring: a small script in your page that reports timings), analytics, and CrUX (the Chrome User Experience Report, a public data set of real Chrome users' timings from Google). It tells you whether there is a problem and for whom.
• Lab data is data from tests you run yourself in a controlled setup. Examples are DevTools, Lighthouse (a Google tool that audits a page and gives scores) and a load test (many fake users sent to your server). It lets you reproduce and debug the problem. Slow down the CPU (4x or 6x) and the network. Your development machine hides problems that a mid-range phone shows.

Move 2: Isolate (which layer owns the time?)

A user action passes through many layers. Your job is to find the layer that holds most of the time before you optimise anything.

User clicks ─▶ [Main thread: handler, render] ─▶ [Network] ─▶ [Edge/CDN] ─▶ [App server]                                                                              │                              ◀──────────── response ◀── [DB / cache / 3rd-party APIs]

The first fork in the road is the most important one:

Open the Network tab. Click the slow request, and read the Timing breakdown:

Then open the Performance panel. It shows what happens after the response arrives: scripting, rendering and painting on the main thread.

The decision tree

Is the page slow...├─ ...before anything appears?           → Network + server: TTFB, redirects, render-blocking CSS/JS, bundle size│                                           (Lessons 02 and 06)├─ ...after the response arrives,        → Main thread: parsing, re-rendering, long tasks, hydration│   but the API was fast?                   (Lessons 01, 03, 07)├─ ...only on interaction (click/type)?  → Handlers, re-renders, long tasks (INP)         (Lessons 01, 03, 08)├─ ...worse the longer the tab is open?  → Memory leak                                      (Lesson 04)├─ ...making the same request twice?     → Effects, double submits, races                   (Lesson 05)└─ ...jumping around as it loads?        → Layout shift (CLS)                               (Lesson 08)

The tool map

A few terms in the table: the Server-Timing header is an HTTP response header where the server can report its own timings (for example db;dur=53) so that DevTools can show them. A flame chart is a chart where each bar is a function call and its width is the time it took. A heap snapshot is a saved picture of everything in the browser's memory at one moment. APM (application performance monitoring) tools record how long each step of a request takes on the server. OpenTelemetry is an open standard for collecting this kind of trace data. EXPLAIN (ANALYZE, BUFFERS) is a PostgreSQL command that runs a query and reports how the database executed it and how long each step took. The event loop is the Node.js mechanism that takes one task at a time from a queue and runs it on a single thread.

Move 3: Hypothesize (one cause at a time)

Write your hypothesis so that it can be proved wrong:

• Weak: "Maybe the database is slow."
• Strong: "The /orders endpoint runs one query for each order line (this is called an N+1 problem: 1 query for the list, then N more queries, one for each item in it). So the delay grows with the number of lines. If this is true, a customer with 200 lines should show about 200 queries in the trace. Using include (an ORM option that loads the related rows in one extra query, instead of one query per row) should drop it to 2 queries."

A good hypothesis says what you will see if it is true. It also points to the cheapest experiment.

Ways to narrow it down

• Bisect. This means cutting the search space in half again and again. If the page used to be fast, find the bad commit with git bisect (a Git command that tests commits in halves until it finds the first bad one). Or turn feature flags and bundles on and off.
• Remove, don't add. Turn off third-party scripts, browser extensions (use an incognito window), or a suspect component. See if the symptom goes away.
• Compare a fast case with a slow case. Take the same endpoint with a small account and a large account. What is different?
• Look at the shape of the cost. If it grows in a straight line with list size, think N+1 or rendering every row. If it jumps at a deploy, think regression (a new change broke something). If it grows over time, think leak. If it spikes now and then, think cron jobs, GC (garbage collection, the memory clean-up) or cache expiry.
• Reproduce at scale. A bug that needs 10,000 rows will not show up in your small test data. Create realistic amounts of data.

Move 4: Verify (change one thing, compare to the baseline)

1. Record the baseline first. Use the same device and the same throttling. Do several runs and take the median (the middle value).
2. Change one variable only.
3. Measure again and compare. A real fix moves the number by a clear amount, not just by noise.
4. Check for new problems elsewhere. For example, a cache can fix latency and break freshness.
5. Add a guard so the problem cannot return quietly. A guard can be a performance budget in CI (an automatic check that fails the build if a number, such as bundle size, goes over a limit), an alert, a regression test (a test that stops an old bug from coming back), or a dashboard panel.

// A minimal, repeatable in-browser measurementperformance.mark("filter:start");applyFilter(rows, query);performance.mark("filter:end");performance.measure("filter", "filter:start", "filter:end");console.table(performance.getEntriesByName("filter"));

Talking it through in an interview

This structure works for any scenario question:

1. Clarify. ("Is it slow on load or on interaction? For everyone? Since a deploy?")
2. State the plan. ("First I'd split the time between network, server and main thread.")
3. Name the tool for each step. ("The Network tab timing, then the Performance panel.")
4. Give 2 or 3 ranked hypotheses. Say how you would confirm each one.
5. Suggest fixes with trade-offs. Say what each fix costs and risks.
6. End with prevention. (Budgets, monitoring, tests.)

Say your thinking out loud. The interviewer is judging your process, not whether you guess the exact bug.

Anti-patterns

An anti-pattern is a habit that looks helpful but usually causes harm.

A worked mini-example

Report: "The orders page takes 4 seconds."

1. Measure: in the Network tab, GET /orders has Waiting (TTFB) = 3.4 s. Content download is 40 ms. The Performance panel shows that the main thread is idle for most of that time.
2. Isolate: the time is on the server, not in the browser.
3. Hypothesize: the trace shows 120 almost identical SELECT … FROM order_items WHERE order_id = $1 queries. This is an N+1. The prediction: a customer with 5 orders is fast, and one with 200 orders is slow.
4. Verify: switch to two queries in total (the orders, then all their items with IN or include). TTFB drops from 3.4 s to 180 ms. Check it again with the 200-order customer. Add a test that says "at most 3 queries" and an alert on p95 latency.

Two minutes, four moves, no guessing. That is the whole series in a small form.

Common mistakes

1. Starting with a solution instead of a measurement.
2. Looking only at the layer you know best. (Frontend engineers blame React. Backend engineers blame the network.)
3. Using averages and a single run.
4. Debugging in conditions that are unlike production (no throttling, tiny data).
5. Changing several things, then giving credit to the wrong one.
6. Never adding a guard, so the same regression comes back months later.

Interview questions

Key takeaways

• Measure, isolate, hypothesize, verify. Do them in this order, and change one thing at a time.
• The first fork: is the time before the response (network and server) or after it (main thread)? The Network timing tab answers this in seconds.
• Use percentiles. Use field data to decide what matters and throttled lab data to debug.
• Write hypotheses that predict what you will see. Use bisecting and comparisons.
• Add a guard (budget, test, alert) so the fix lasts.

What's next

Lesson 01: "The API Is Fast but the UI Is Slow". This is the first scenario. The Network tab says 80 ms, but users wait two seconds. We follow the time onto the main thread.