.NET Developer interview question
How do you diagnose a slow .NET service?
Correlate .NET latency and throughput metrics with traces, inspect thread-pool starvation, GC and allocations using dotnet-counters or traces, profile hot paths, check database calls, then benchmark the measured fix.
Direct answer
What a strong answer covers
How it works
The investigation follows the evidence from the outside in. Request metrics and traces identify which endpoints are slow and whether the time is in the application, the database, or an external call. dotnet-counters shows thread-pool queue length and starvation, GC frequency, and allocation rate in real time; dotnet-trace or a continuous profiler attributes CPU to methods under production load. Database time is checked through EF Core logging and query plans. The fix targets the dominant cost, and BenchmarkDotNet or a load test with the same request mix confirms it before release.
Example
An API with rising latency showed a thread-pool queue climbing in dotnet-counters; a trace found a synchronous .Result call inside a hot path that blocked worker threads while awaiting Redis. Making the path fully async dropped p95 from 900 ms to 120 ms with no hardware change, and a follow-up trace found a LINQ query materialising a whole table that was then filtered in memory.
Common mistakes
- Increasing the minimum thread count to mask sync-over-async instead of fixing it.
- Optimising a method a profiler never flagged.
- Benchmarking with a warm cache and an empty database, then being surprised in production.
A useful answer structure
Answer from your own work.
Do not memorise a script: use only examples you can explain honestly in follow-up questions.
Open the desktop workspace and rehearse a clear answer in your own words.