The Performance Hunt

"Users say the app got slow last week. How do you investigate?" Unlike the outage question, nothing is on fire — which means the interviewer is watching for method. The common mistake is jumping to a favorite villain ("probably needs caching") before measuring anything. The strong candidate is boringly empirical: measure, narrow, fix, prove.

Metrics first, always

Start by making "slow" concrete: "Slow for everyone or some users? Which pages? What's the p95 latency now versus two weeks ago?" Averages hide pain — say p95/p99, not "average response time," and interviewers notice. Then triangulate with the tools an Azure shop actually has: Application Insights (or any APM) for the slowest requests and their dependency breakdowns, SQL query stats for the top offenders by duration and reads, and server metrics for CPU, memory, and GC pressure. The APM dependency view usually answers the first big question in minutes: is time spent in our code, the database, or someone else's API?

Since it "got slow last week," correlate with what changed — a deployment, a data-volume milestone (that table finally crossed 10 million rows), a new integration, or traffic growth.

The usual .NET suspects

Name these fluently, with the one-line fix for each:

• N+1 queries — a loop lazy-loading children; fix with Include/projection, verify with the query count in the profiler.
• Sync-over-async — .Result or .Wait() starving the thread pool; symptoms are fine latency at low load and collapse under concurrency. Fix: async all the way down.
• Unbounded caches or collections — memory climbs for days, GC pauses grow, then the weekly recycle "fixes" it. Fix: size limits and expiration on MemoryCache.
• Chatty external calls — twelve sequential HTTP calls per page; batch them or fan out with Task.WhenAll, and add timeouts so one slow dependency doesn't own your latency.
• Missing index — the classic; confirm via the execution plan, not vibes.

Proving the fix

This is where candidates separate. State the discipline: capture the baseline number, change one thing, re-measure the same metric under comparable load, and keep the before/after in the ticket. "p95 on the search endpoint went from 3.2s to 240ms after adding the composite index" is an interview-winning sentence — and the habit that stops performance work from becoming superstition.

Red flags

• Proposing fixes before any measurement ("add caching, add servers").
• Not knowing what p95 means or why averages mislead.
• Optimizing code the profiler never flagged.
• No before/after evidence — "it feels faster now."

Practice prompts

1. "App Insights shows 80% of request time inside one SQL dependency. What are your next three steps?"
2. "The app is fast at 9 AM and crawls at 2 PM. What hypotheses does that pattern suggest?"
3. "Your index fix worked in staging but prod is still slow. Why might that be?"