Angular interview questions — what change detection questions are actually checking

Angular interviews lean harder on framework internals than React ones do, and that trips people up who learned Angular by building features rather than by reading how the framework works underneath. The questions look like trivia. They're actually checking whether you've debugged the specific class of bug Angular is famous for producing.

Change detection — the question everyone gets half right

What gets recited: Angular checks the component tree for changes and updates the DOM. OnPush makes it check less often, for performance.

What actually gets tested: "You set changeDetection: OnPush on a component, and now part of the UI stopped updating. Why?" This is the real question hiding behind the definition. OnPush tells Angular to only re-check a component when its @Input reference changes, an event fires inside it, or you trigger change detection manually. Mutate an object inside an @Input — push to an array, change a property — and the reference stays the same, so OnPush never notices. The fix is either creating a new reference ([...array, newItem] instead of array.push(newItem)) or manually calling markForCheck(). Naming this unprompted is the difference between having read about OnPush and having been paged about it.

Observables vs Promises — not "what's the difference," but "why does it matter here"

Both resolve async values. The distinction worth having ready: a Promise resolves once and is done; an Observable can emit multiple values over time and is cancellable via unsubscribe(). That second property is the one with real consequences — an HTTP call wrapped in a Promise that the user navigates away from still resolves and can try to update a destroyed component. The same call as an Observable, unsubscribed in ngOnDestroy, doesn't. This is also the "why did I get a memory leak" question in disguise: forgetting to unsubscribe from a long-lived Observable (like a Subject in a shared service) keeps every component that ever subscribed alive in memory.

Dependency injection — Angular's version of the same question every framework asks

Angular's DI system gets asked about specifically because of hierarchical injectors — providing a service at the component level versus the module level produces genuinely different behaviour, not just a style preference. Provide a service in providedIn: 'root' and every part of the app shares one instance. Provide the same service in a component's providers array, and that component (and its children) get their own instance, separate from anywhere else in the app. Candidates who've only ever used providedIn: 'root' often can't explain why you'd ever want the second option — the honest answer is per-instance state, like a wizard component that needs its own isolated form state even if ten of them are open on the page at once.

Two-way binding — what [(ngModel)] is actually doing

[(ngModel)] looks like magic syntax until you know it's shorthand for [ngModel]="value" (ngModelChange)="value = $event" — a property binding and an event binding combined. The follow-up worth being ready for: "how would you build two-way binding on your own component?" The answer is a @Input() plus an @Output() named with the Change suffix (value and valueChange), which Angular's banana-in-a-box syntax recognises as a pair automatically.

Why Angular questions go deeper than "define this term"

Angular is opinionated and has more moving parts than lighter frontend libraries — DI, change detection strategies, RxJS, a module system — and each one has a specific, well-known failure mode that experienced developers have personally hit. That's exactly why the interview rarely stops at the definition. The definition is table stakes; the follow-up about what breaks is where the interview actually happens.

---

If you want to practice Angular and frontend questions with real follow-ups instead of a static list, try role-specific mock interviews for Angular — free to start.