Debugging scenarioHard~12 minMemory Debugging / 5 of 8

Interview question

A production .NET service crashed with OutOfMemoryException and restarted. What would you do next?

What would you do after a .NET service crashes with OutOfMemoryException?

Practices incident response after an OOM: restore service, collect evidence, identify trigger, and prevent recurrence.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would first make sure the service is healthy after restart and users are not still affected. Then I would gather evidence: logs, memory metrics before the crash, traffic, recent deployments, endpoint mix, job activity, and any available dump or crash artifact. I would check whether the OOM happened on one instance or many. If a specific feature or job triggered it, I would limit or disable that path while investigating.

Full answer below

Practice focus

Incident response, memory evidence, mitigation, deployment correlation, recurrence prevention, and communication.

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
An OutOfMemoryException restart restores capacity temporarily but can erase the most useful evidence. Recovery must reduce current user impact while preserving the memory curve, workload, deployment, instance, and crash artifacts needed to prevent recurrence.
I would first make sure the service is healthy after restart and users are not still affected. Then I would gather evidence: logs, memory metrics before the crash, traffic, recent deployments, endpoint mix, job activity, and any available dump or crash artifact. I would check whether the OOM happened on one instance or many. If a specific feature or job triggered it, I would limit or disable that path while investigating.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would separate immediate recovery from diagnosis. Recovery might involve scaling, draining a bad instance, pausing a batch job, lowering concurrency, or rolling back a recent change. Diagnosis looks at the memory curve before the crash, allocation spikes, retained heap, payload sizes, and deployment diff. I would communicate the current mitigation and the evidence being collected. If no dump exists, I would set up safe dump capture or better memory telemetry before the next occurrence.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
After the incident, I would turn the finding into a prevention mechanism. If a large export caused the OOM, add streaming, limits, or background generation. If a leak caused it, fix the retaining owner and add a focused regression test. If the process limit was too low for legitimate workload, adjust capacity with an explanation. I would also add alerts before the cliff: memory percent, GC pressure, allocation rate, queue size, and route-level payload signals. The lesson is not simply restart faster; it is make the failure mode visible and bounded.

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

Stopping at restart because the service looks healthy again.
Deleting evidence during cleanup.
Rolling forward blindly without checking recent changes.
Ignoring whether one feature or tenant triggered the crash.

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

Details

No immediate mitigation plan.
No evidence-gathering plan.
Does not consider dumps or crash artifacts.
Cannot describe prevention beyond more memory.

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 you check in the first five minutes?
When would you roll back versus limit traffic?
What evidence can survive an OOM restart?
What alert would warn before the next OOM?

Continue the section

Next in Memory Debugging: Memory Metrics

Step 6 of 8

Which memory metrics would you monitor for a .NET service?

Opening drill

Debugging scenarioHard~12 minMemory Debugging / 5 of 8

Interview question

A production .NET service crashed with OutOfMemoryException and restarted. What would you do next?

What would you do after a .NET service crashes with OutOfMemoryException?

Practices incident response after an OOM: restore service, collect evidence, identify trigger, and prevent recurrence.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Incident response, memory evidence, mitigation, deployment correlation, recurrence prevention, and communication.

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
An OutOfMemoryException restart restores capacity temporarily but can erase the most useful evidence. Recovery must reduce current user impact while preserving the memory curve, workload, deployment, instance, and crash artifacts needed to prevent recurrence.
I would first make sure the service is healthy after restart and users are not still affected. Then I would gather evidence: logs, memory metrics before the crash, traffic, recent deployments, endpoint mix, job activity, and any available dump or crash artifact. I would check whether the OOM happened on one instance or many. If a specific feature or job triggered it, I would limit or disable that path while investigating.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would separate immediate recovery from diagnosis. Recovery might involve scaling, draining a bad instance, pausing a batch job, lowering concurrency, or rolling back a recent change. Diagnosis looks at the memory curve before the crash, allocation spikes, retained heap, payload sizes, and deployment diff. I would communicate the current mitigation and the evidence being collected. If no dump exists, I would set up safe dump capture or better memory telemetry before the next occurrence.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
After the incident, I would turn the finding into a prevention mechanism. If a large export caused the OOM, add streaming, limits, or background generation. If a leak caused it, fix the retaining owner and add a focused regression test. If the process limit was too low for legitimate workload, adjust capacity with an explanation. I would also add alerts before the cliff: memory percent, GC pressure, allocation rate, queue size, and route-level payload signals. The lesson is not simply restart faster; it is make the failure mode visible and bounded.

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

Stopping at restart because the service looks healthy again.
Deleting evidence during cleanup.
Rolling forward blindly without checking recent changes.
Ignoring whether one feature or tenant triggered the crash.

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

Details

No immediate mitigation plan.
No evidence-gathering plan.
Does not consider dumps or crash artifacts.
Cannot describe prevention beyond more memory.

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 you check in the first five minutes?
When would you roll back versus limit traffic?
What evidence can survive an OOM restart?
What alert would warn before the next OOM?

Continue the section

Next in Memory Debugging: Memory Metrics

Step 6 of 8

Which memory metrics would you monitor for a .NET service?

A production .NET service crashed with OutOfMemoryException and restarted. What would you do next?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

A production .NET service crashed with OutOfMemoryException and restarted. What would you do next?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section