Comparison questionEasy~6 min.NET Runtime Diagnostics Toolchain / 1 of 6

Interview question

How do you choose between counters, traces, stack snapshots, GC dumps, full process dumps, and a profiler when diagnosing a .NET service?

Choose the right .NET diagnostic evidence from a symptom

Chooses counters, traces, stack snapshots, GC dumps, full dumps, or a profiler from the production symptom and investigation cost.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I first decide whether the symptom is about behavior over time or process state at one moment. Counters show trends and narrow the hypothesis; a trace or repeated stacks explain intermittent CPU, waiting, or contention. A GC dump answers managed-heap retention questions, while a full dump captures threads and broader process state. I choose the smallest artifact that can answer the next question.

Full answer below

Practice focus

Symptom classification, artifact selection, diagnostic cost, time-based versus state-based evidence, and production safety.

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
Collecting the richest artifact first can create unnecessary risk and still answer the wrong question. The useful skill is moving from a broad symptom to the cheapest evidence that can narrow the next decision.
I first decide whether the symptom is about behavior over time or process state at one moment. Counters show trends and narrow the hypothesis; a trace or repeated stacks explain intermittent CPU, waiting, or contention. A GC dump answers managed-heap retention questions, while a full dump captures threads and broader process state. I choose the smallest artifact that can answer the next question.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I also separate time-based evidence from state-based evidence. An intermittent CPU spike or lock wait needs a bounded trace that covers the event; a dump taken after the spike may show nothing useful. A process that is currently hung may be explained by repeated stack snapshots or one full dump. Steadily growing retained memory needs counter history first, then comparable heap evidence at meaningful points. High working set alone does not prove a managed leak, and a large heap type alone does not prove ownership. Before collection I record deployment version, instance, traffic, timestamps, resource limits, and the exact symptom so the artifact can be correlated with logs, metrics, and user impact.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
Collection cost and sensitivity are part of the decision. I choose a representative affected instance and move from low-overhead counters to a bounded trace or dump only when the earlier evidence justifies it. Full dumps contain much more process data than GC dumps and need stricter handling. The artifact is useful only if it confirms or rejects a named hypothesis and changes the next investigative step.

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

Taking a full dump before confirming which resource or instance is affected.
Using a point-in-time dump to investigate an intermittent time-based spike.
Calling high working set a managed memory leak without heap evidence.
Collecting a broad trace with no time window, workload context, or question.

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

Details

Every incident begins with restarting the process and destroying the evidence.
Artifacts cannot be tied to a deployment, instance, timestamp, or user symptom.
Diagnostic collection has no owner, duration limit, or security handling.
The team gathers files it does not know how to open or interpret.

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 a dump miss an intermittent CPU spike?
When is a stack snapshot enough?
What would make you escalate from counters to a trace?

Continue the section

Next in .NET Runtime Diagnostics Toolchain: Triage with dotnet-counters

Step 2 of 6

Triage a .NET service 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.

About the creator Editorial standards

Opening drill

Comparison questionEasy~6 min.NET Runtime Diagnostics Toolchain / 1 of 6

Interview question

How do you choose between counters, traces, stack snapshots, GC dumps, full process dumps, and a profiler when diagnosing a .NET service?

Choose the right .NET diagnostic evidence from a symptom

Chooses counters, traces, stack snapshots, GC dumps, full dumps, or a profiler from the production symptom and investigation cost.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Symptom classification, artifact selection, diagnostic cost, time-based versus state-based evidence, and production safety.

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
Collecting the richest artifact first can create unnecessary risk and still answer the wrong question. The useful skill is moving from a broad symptom to the cheapest evidence that can narrow the next decision.
I first decide whether the symptom is about behavior over time or process state at one moment. Counters show trends and narrow the hypothesis; a trace or repeated stacks explain intermittent CPU, waiting, or contention. A GC dump answers managed-heap retention questions, while a full dump captures threads and broader process state. I choose the smallest artifact that can answer the next question.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I also separate time-based evidence from state-based evidence. An intermittent CPU spike or lock wait needs a bounded trace that covers the event; a dump taken after the spike may show nothing useful. A process that is currently hung may be explained by repeated stack snapshots or one full dump. Steadily growing retained memory needs counter history first, then comparable heap evidence at meaningful points. High working set alone does not prove a managed leak, and a large heap type alone does not prove ownership. Before collection I record deployment version, instance, traffic, timestamps, resource limits, and the exact symptom so the artifact can be correlated with logs, metrics, and user impact.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
Collection cost and sensitivity are part of the decision. I choose a representative affected instance and move from low-overhead counters to a bounded trace or dump only when the earlier evidence justifies it. Full dumps contain much more process data than GC dumps and need stricter handling. The artifact is useful only if it confirms or rejects a named hypothesis and changes the next investigative step.

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

Taking a full dump before confirming which resource or instance is affected.
Using a point-in-time dump to investigate an intermittent time-based spike.
Calling high working set a managed memory leak without heap evidence.
Collecting a broad trace with no time window, workload context, or question.

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

Details

Every incident begins with restarting the process and destroying the evidence.
Artifacts cannot be tied to a deployment, instance, timestamp, or user symptom.
Diagnostic collection has no owner, duration limit, or security handling.
The team gathers files it does not know how to open or interpret.

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 a dump miss an intermittent CPU spike?
When is a stack snapshot enough?
What would make you escalate from counters to a trace?

Continue the section

Next in .NET Runtime Diagnostics Toolchain: Triage with dotnet-counters

Step 2 of 6

Triage a .NET service with dotnet-counters

How do you choose between counters, traces, stack snapshots, GC dumps, full process dumps, and a profiler when diagnosing a .NET service?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

How do you choose between counters, traces, stack snapshots, GC dumps, full process dumps, and a profiler when diagnosing a .NET service?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section