Debugging scenarioHard~10 min

Interview question

An ASP.NET Core API has rising latency and timeouts but CPU is not saturated. How would you prove or disprove ThreadPool starvation?

Prove ThreadPool starvation with counters, stacks, and traces

Combines ThreadPool counters, repeated stack snapshots, and wait-event traces to distinguish blocked workers from CPU or dependency pressure.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

ThreadPool starvation usually appears as rising queued work and thread count while request latency climbs without CPU being fully saturated. I confirm that pattern over time, then inspect repeated stacks or wait events for synchronous I/O, long locks, or another blocking path. One blocked thread is not proof; many workers waiting on the same cause is. The combined evidence distinguishes starvation from a simply slow dependency.

Full answer below

Practice focus

ThreadPool queueing, thread injection, completed work, sync-over-async, blocking stacks, wait events, dependency latency, and bounded concurrency.

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
ThreadPool starvation is often blamed whenever an API is slow. The diagnosis needs both a queueing pattern and evidence of what keeps workers unavailable.
ThreadPool starvation usually appears as rising queued work and thread count while request latency climbs without CPU being fully saturated. I confirm that pattern over time, then inspect repeated stacks or wait events for synchronous I/O, long locks, or another blocking path. One blocked thread is not proof; many workers waiting on the same cause is. The combined evidence distinguishes starvation from a simply slow dependency.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I look for a dominant repeated pattern rather than one blocked thread. A slow database or HTTP dependency can create starvation when code waits synchronously, but the dependency latency is still part of the cause. Lock contention may show many workers waiting behind one owner, while unbounded parallel work may flood the queue even with async code. I compare healthy and unhealthy endpoints and include request volume because the same blocking path can appear harmless at low concurrency. The fix follows the evidence: async I/O end to end, shorter lock scope, bounded concurrency, backpressure, a worker boundary for CPU-heavy work, or a dependency timeout and bulkhead.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
Increasing minimum threads may reduce symptoms briefly, but it does not remove the blocking or unbounded work that caused starvation. Runtime improvements can change how quickly the pool responds, so I interpret the pattern in the deployed runtime version. The repair follows the stacks—async I/O, shorter locks, or bounded concurrency—and the same load must show queue recovery afterward. That proves capacity was restored rather than temporarily hidden.

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

Calling low CPU and high latency proof of starvation without queue or stack evidence.
Finding one blocked thread and assuming it represents the process.
Converting method signatures to async while a synchronous dependency still blocks underneath.
Increasing minimum threads before identifying the blocking or concurrency boundary.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Thread count rises continuously while the dependency receives unbounded concurrent work.
Stack snapshots are taken after traffic stops and no longer contain the blocking pattern.
The investigation ignores lock owners, downstream latency, or CPU-heavy background jobs.
The proposed fix has no burst-load or tail-latency verification.

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.

Why can starvation happen without high CPU?
When are repeated stack snapshots better than one dump?
Why might raising minimum threads make another service fail?

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.

Thread Pool Starvation

Prerequisite

Review this first if the current drill feels shaky.

Triage with dotnet-counters

Practice route

Read core answer Review checklist Follow-up prompts Track progress

Finished this drill?

Practice freely. Sign in only when you want to save completion, confidence, notes, or bookmarks.

New to Aporeon? Create account

Drill details

Share the question with a concise Core-answer excerpt and invite other developers to add their perspective.

Was this drill useful?

Help improve the interview library.

Found this answer useful?

Say thanks with a standalone, one-time $5 contribution. No account required.

No subscription or perks.Choose another amount

Human editorial direction

Aporeon is shaped by Aleksandar Tomovski, a software developer with experience on both sides of technical interviews. Content is reviewed for accuracy, natural spoken delivery, useful depth, and honest trade-offs.