Debugging scenarioHard~15 min

Interview question

How would you diagnose an Angular memory leak that grows after every navigation?

Uses repeatable navigation, heap evidence, retained-object paths, and ownership checks to find subscriptions, listeners, and DOM retained past teardown.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I create a repeatable route-away-and-back scenario, force comparable idle points, and use heap snapshots or allocation profiling to see what remains. I inspect retaining paths for destroyed component instances, DOM nodes, subscriptions, timers, listeners, and caches. Then I fix the owner that failed to release the resource and rerun the same cycle to verify memory reaches a stable plateau.

Full answer below

Practice focus

Angular lifecycle, memory profiling, subscriptions, event listeners, overlays, third-party widgets, DestroyRef, and leak verification.

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.
Overview
Growing memory becomes actionable when repeated navigation retains component graphs that should have been released.
I create a repeatable route-away-and-back scenario, force comparable idle points, and use heap snapshots or allocation profiling to see what remains. I inspect retaining paths for destroyed component instances, DOM nodes, subscriptions, timers, listeners, and caches. Then I fix the owner that failed to release the resource and rerun the same cycle to verify memory reaches a stable plateau.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Common causes include manual subscriptions without teardown, global listeners, intervals, observers, overlays, and third-party widgets that keep callbacks or DOM references. The async pipe, signal interop, and takeUntilDestroyed reduce subscription mistakes, but they do not clean up arbitrary browser or library resources automatically. I check provider scope because a root service retaining route-specific state can look like a component leak. One snapshot is not enough because caches and runtime warm-up can grow legitimately.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I correlate the retained path with lifecycle ownership rather than adding blanket cleanup calls. A cache needs an explicit size and eviction policy; a shared stream needs deliberate replay and ref-count behavior; a widget wrapper owns both creation and destruction. Automated regression tests can repeat the navigation and assert bounded object or listener counts, while production telemetry watches long-session memory and crashes. The repair should remove the retaining edge without breaking reconnection or shared state semantics.

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

Calling every increase a leak after one navigation.
Assuming takeUntilDestroyed cleans up timers and external widgets.
Clearing a global cache without defining its intended lifetime.

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

Details

Destroyed component instances remain reachable from a root service.
Each navigation adds another global event listener.
A replayed stream retains an unbounded response graph.

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 look for in a retaining path?
How do legitimate caches differ from leaks?
Which resources need manual teardown?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Prerequisite

Review this first if the current drill feels shaky.

Profile Angular renderingUses browser evidence and repeatable scenarios rather than speculative fixes.

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

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

Was this drill useful?