Debugging scenarioMedium~10 min

Interview question

An important API endpoint suddenly became slow in production. How would you investigate?

Diagnose a slow API endpoint with telemetry

Explains a telemetry-driven path from slow endpoint symptoms to database, cache, dependency, CPU, or payload root cause.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would confirm the slowdown with p95 and p99 latency, affected endpoint, time window, status codes, traffic volume, and whether all users or only some tenants are affected. Then I would compare slow traces with normal traces to see where time is spent: SQL, Redis, downstream HTTP, queue wait, CPU, serialization, or application code. That keeps the investigation evidence-led instead of guessing from the endpoint name.

Full answer below

Practice focus

Latency percentiles, request volume, deployment correlation, dependency timing, SQL, Redis, traces, and mitigation.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A slow endpoint can originate in application code, data access, a remote dependency, saturation, or a release change. Evidence must narrow the layer before the mitigation changes system behavior.
I would confirm the slowdown with p95 and p99 latency, affected endpoint, time window, status codes, traffic volume, and whether all users or only some tenants are affected. Then I would compare slow traces with normal traces to see where time is spent: SQL, Redis, downstream HTTP, queue wait, CPU, serialization, or application code. That keeps the investigation evidence-led instead of guessing from the endpoint name.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would correlate the slowdown with recent deployments, data growth, traffic spikes, dependency incidents, cache misses, and database metrics. If SQL dominates, I would inspect generated SQL, query plan, reads, blocking, and indexes. If Redis or HTTP dominates, I would check timeout rate, retry behavior, payload size, and dependency latency. Mitigation might be rollback, disabling an expensive feature, reducing load, adding a temporary limit, or serving degraded data.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I avoid fixing symptoms blindly. Raising timeouts, adding cache, or scaling out can help briefly, but each can hide the cause or move pressure into SQL, Redis, or a provider. I preserve representative traces and query evidence before mitigation, record the expected recovery signal, and compare user-facing latency, errors, saturation, and business completion afterward. The permanent fix includes a regression guard appropriate to the failure: query-count or plan check, load scenario, dependency alert, dashboard panel, or bounded limit. Ownership and a follow-up date ensure the new guard remains effective after traffic and data shape change.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Looking only at average latency.
Changing code before comparing traces and dependencies.
Assuming the database is slow without checking the query plan.
Adding cache without a freshness or miss-path plan.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

No p95/p99 thinking.
No dependency breakdown.
No deployment or traffic correlation.
No verification after mitigation.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

What would a slow trace show?
How would you tell SQL from API CPU?
What temporary mitigation might be safe?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

2 linked

Go deeper

Practice the next layer of the same subject.

Slow API Diagnosis Slow EF Query

Opening drill

Debugging scenarioMedium~10 min

Interview question

An important API endpoint suddenly became slow in production. How would you investigate?

Diagnose a slow API endpoint with telemetry

Explains a telemetry-driven path from slow endpoint symptoms to database, cache, dependency, CPU, or payload root cause.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Latency percentiles, request volume, deployment correlation, dependency timing, SQL, Redis, traces, and mitigation.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A slow endpoint can originate in application code, data access, a remote dependency, saturation, or a release change. Evidence must narrow the layer before the mitigation changes system behavior.
I would confirm the slowdown with p95 and p99 latency, affected endpoint, time window, status codes, traffic volume, and whether all users or only some tenants are affected. Then I would compare slow traces with normal traces to see where time is spent: SQL, Redis, downstream HTTP, queue wait, CPU, serialization, or application code. That keeps the investigation evidence-led instead of guessing from the endpoint name.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would correlate the slowdown with recent deployments, data growth, traffic spikes, dependency incidents, cache misses, and database metrics. If SQL dominates, I would inspect generated SQL, query plan, reads, blocking, and indexes. If Redis or HTTP dominates, I would check timeout rate, retry behavior, payload size, and dependency latency. Mitigation might be rollback, disabling an expensive feature, reducing load, adding a temporary limit, or serving degraded data.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I avoid fixing symptoms blindly. Raising timeouts, adding cache, or scaling out can help briefly, but each can hide the cause or move pressure into SQL, Redis, or a provider. I preserve representative traces and query evidence before mitigation, record the expected recovery signal, and compare user-facing latency, errors, saturation, and business completion afterward. The permanent fix includes a regression guard appropriate to the failure: query-count or plan check, load scenario, dependency alert, dashboard panel, or bounded limit. Ownership and a follow-up date ensure the new guard remains effective after traffic and data shape change.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Looking only at average latency.
Changing code before comparing traces and dependencies.
Assuming the database is slow without checking the query plan.
Adding cache without a freshness or miss-path plan.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

No p95/p99 thinking.
No dependency breakdown.
No deployment or traffic correlation.
No verification after mitigation.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

What would a slow trace show?
How would you tell SQL from API CPU?
What temporary mitigation might be safe?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

2 linked

Go deeper

Practice the next layer of the same subject.

Slow API Diagnosis Slow EF Query

An important API endpoint suddenly became slow in production. How would you investigate?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

An important API endpoint suddenly became slow in production. How would you investigate?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper