Debugging scenarioHard~12 min

Interview question

A .NET API's memory grows throughout the day and only drops after restart. How would you investigate?

How would you investigate memory growth in a production .NET service?

Gives a practical incident flow for memory growth using metrics, traffic correlation, heap evidence, and safe mitigation.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would start by confirming the pattern: process memory, managed heap size, GC counts, request volume, and recent deployments. If memory keeps growing after traffic settles or after full collections, I would suspect retained objects. I would look for correlations with specific endpoints, jobs, or payload sizes. If needed, I would capture a dump safely and compare retained object types and roots before changing code.

Full answer below

Practice focus

Production debugging, GC metrics, heap dumps, traffic correlation, mitigation, and root-cause discipline.

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
Sustained process growth can come from retained managed objects, intentional queues or caches, native memory, thread growth, or workload changes. Safe diagnosis correlates traffic and deployments with runtime counters, then captures focused heap evidence when needed.
I would start by confirming the pattern: process memory, managed heap size, GC counts, request volume, and recent deployments. If memory keeps growing after traffic settles or after full collections, I would suspect retained objects. I would look for correlations with specific endpoints, jobs, or payload sizes. If needed, I would capture a dump safely and compare retained object types and roots before changing code.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
My first goal is to protect the service while preserving evidence. I would check alerts, memory limits, restart history, traffic shape, and whether one route or job started producing larger objects. Then I would inspect runtime counters such as allocation rate, Gen 2 collections, LOH size, and thread count. If a dump is allowed, I would capture it during high memory and compare it to a healthier point. The root path matters more than the largest type name, because it tells me who is keeping objects alive.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would split mitigation from root cause. Mitigation might be scaling out, lowering concurrency, disabling a feature flag, restarting one instance at a time, or limiting a heavy job. Root cause needs evidence: heap comparisons, endpoint traces, deployment diff, and object retention paths. I would avoid collecting repeated huge dumps without a plan because dumps can expose sensitive data and stress the machine. After the fix, I would add a regression test or a focused metric so the same memory pattern is visible before it becomes another outage.

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

Restarting repeatedly without collecting any evidence.
Looking only at total process memory.
Capturing dumps without considering sensitive data.
Changing random code before finding the retaining path.

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

Details

Cannot describe a safe incident flow.
Does not distinguish mitigation from root cause.
Ignores deployment and traffic correlation.
Has no plan for heap evidence or runtime counters.

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.

Which metrics would you check first?
When would you capture a memory dump?
How do you compare healthy and unhealthy heap states?
What mitigations can reduce risk while investigation continues?

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.

Heap Dump ComparisonHeap comparison is the deeper diagnostic step.

Prerequisite

Review this first if the current drill feels shaky.

Leak vs PressureThe incident flow depends on separating leaks from pressure.

Debugging scenarioHard~12 min

Interview question

A .NET API's memory grows throughout the day and only drops after restart. How would you investigate?

How would you investigate memory growth in a production .NET service?

Gives a practical incident flow for memory growth using metrics, traffic correlation, heap evidence, and safe mitigation.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Production debugging, GC metrics, heap dumps, traffic correlation, mitigation, and root-cause discipline.

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
Sustained process growth can come from retained managed objects, intentional queues or caches, native memory, thread growth, or workload changes. Safe diagnosis correlates traffic and deployments with runtime counters, then captures focused heap evidence when needed.
I would start by confirming the pattern: process memory, managed heap size, GC counts, request volume, and recent deployments. If memory keeps growing after traffic settles or after full collections, I would suspect retained objects. I would look for correlations with specific endpoints, jobs, or payload sizes. If needed, I would capture a dump safely and compare retained object types and roots before changing code.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
My first goal is to protect the service while preserving evidence. I would check alerts, memory limits, restart history, traffic shape, and whether one route or job started producing larger objects. Then I would inspect runtime counters such as allocation rate, Gen 2 collections, LOH size, and thread count. If a dump is allowed, I would capture it during high memory and compare it to a healthier point. The root path matters more than the largest type name, because it tells me who is keeping objects alive.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would split mitigation from root cause. Mitigation might be scaling out, lowering concurrency, disabling a feature flag, restarting one instance at a time, or limiting a heavy job. Root cause needs evidence: heap comparisons, endpoint traces, deployment diff, and object retention paths. I would avoid collecting repeated huge dumps without a plan because dumps can expose sensitive data and stress the machine. After the fix, I would add a regression test or a focused metric so the same memory pattern is visible before it becomes another outage.

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

Restarting repeatedly without collecting any evidence.
Looking only at total process memory.
Capturing dumps without considering sensitive data.
Changing random code before finding the retaining path.

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

Details

Cannot describe a safe incident flow.
Does not distinguish mitigation from root cause.
Ignores deployment and traffic correlation.
Has no plan for heap evidence or runtime counters.

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.

Which metrics would you check first?
When would you capture a memory dump?
How do you compare healthy and unhealthy heap states?
What mitigations can reduce risk while investigation continues?

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.

Heap Dump ComparisonHeap comparison is the deeper diagnostic step.

Prerequisite

Review this first if the current drill feels shaky.

Leak vs PressureThe incident flow depends on separating leaks from pressure.

A .NET API's memory grows throughout the day and only drops after restart. How would you investigate?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

Prerequisite

A .NET API's memory grows throughout the day and only drops after restart. How would you investigate?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

Prerequisite