Angular Interview Questions
Angular interviews tend to probe both conceptual understanding (how change detection works, what dependency injection solves) and practical fluency (how you'd structure a form, fetch data, or write a test). This topic collects the questions that come up most often across junior-to-mid and senior Angular interviews, organized by theme, with answers precise enough to actually explain the underlying mechanism rather than just naming it.
Cricket analogy: A national selector doesn't just ask a batter to define the cover drive, they want it demonstrated against a genuine Dale Steyn bouncer, testing theory and match execution together, which is exactly how Angular interviews blend mechanism and practice.
Core Concepts and Component Architecture
Interviewers frequently start with 'What is a standalone component and why did Angular move toward it?' A strong answer explains that standalone components declare their own dependencies via an imports array, removing the NgModule boilerplate of declarations/exports, and that Angular 17+ made them the default because they simplify mental overhead and improve tree-shaking. A related favorite is 'What's the difference between @Input()/@Output() and the newer signal-based input()/output()?'—signal inputs are read-only signals that integrate directly with computed()/effect() and provide better type narrowing, while decorator-based inputs are plain class properties reassigned by Angular outside the signal graph.
Cricket analogy: Standalone components are like a modern T20 franchise star who brings his own support staff wherever he plays, no longer needing the county's full administrative setup, while signal input() is like Hawk-Eye continuously tracking the ball versus a one-off umpire's call for decorator @Input().
Change Detection and Signals
'Explain how Zone.js-based change detection works' is a classic. The expected answer: Zone.js monkey-patches async browser APIs (setTimeout, DOM events, XHR/fetch) so Angular knows when async work completes, and after each such task, Angular runs change detection through the component tree by default from the root down, comparing bound expression values to previous ones (dirty checking) and updating the DOM where they differ. A strong follow-up is explaining OnPush: components marked ChangeDetectionStrategy.OnPush are only checked when an @Input() reference changes, an event originates from within the component, or an observable/signal explicitly triggers a check—dramatically reducing unnecessary checks in large trees. With signals, Angular can skip Zone.js-based dirty checking for the parts of the tree driven purely by signal reads, since the framework's reactive graph can granularly track exactly which components need to re-render.
Cricket analogy: Zone.js is like the third umpire watching every ball for a decision review, triggering a check after each event, while OnPush is like a bowler who only reviews footage when the batter's stance actually changes, and signal-driven rendering is like Hawk-Eye pinpointing only the exact fielder who needs to react.
// Common 'explain the output' interview question
import { Component, signal, computed, effect } from '@angular/core';
@Component({
selector: 'app-cart',
standalone: true,
template: `<p>Total: {{ total() }}</p>`,
})
export class CartComponent {
price = signal(10);
quantity = signal(2);
total = computed(() => this.price() * this.quantity());
constructor() {
effect(() => {
console.log('Total changed to', this.total());
});
}
increase() {
this.quantity.update((q) => q + 1);
// effect logs 'Total changed to 30' after this runs
}
}
// Q: Why does the effect re-run automatically after increase()?
// A: effect() tracks every signal read inside its callback (here, total(),
// which itself reads price() and quantity()). Any dependency change
// schedules the effect to re-run, without manual subscription management.Dependency Injection and RxJS
'What problem does hierarchical dependency injection solve?' expects an explanation that Angular's injectors form a tree mirroring the component tree, so a provider registered at a component level is scoped to that component and its descendants, enabling patterns like per-route or per-feature service instances without global singletons leaking state across unrelated parts of the app. On RxJS, 'How do you avoid memory leaks from Observable subscriptions?' is nearly universal—the expected answer covers the async pipe (which auto-unsubscribes when the component is destroyed), the takeUntilDestroyed() operator (using DestroyRef), or manually unsubscribing in ngOnDestroy().
Cricket analogy: Hierarchical DI is like each franchise having its own coaching staff scoped to that team rather than one national coach controlling every squad, and the async pipe auto-unsubscribing is like a bowler automatically stepping off the field once the innings ends rather than bowling into an empty stadium.
Senior-level interviews often probe judgment rather than trivia: 'When would you choose signals over RxJS, or vice versa?' A well-reasoned answer notes signals excel at synchronous, component-local state with automatic dependency tracking, while RxJS remains the better fit for complex async event streams—debouncing, combining multiple sources, cancellation—where its rich operator library has no direct signal equivalent yet.
A common trap in change-detection questions is conflating OnPush with 'the component never re-renders.' OnPush still re-renders on input reference changes, internal events, and explicit markForCheck()/signal calls — it only skips the default check-everything-on-every-async-event behavior.
- Be ready to explain standalone components, signal-based inputs, and why Angular moved away from NgModules as the default.
- Zone.js patches async APIs to trigger change detection; OnPush restricts checks to input reference changes, internal events, and explicit triggers.
- Signals enable more granular reactivity than Zone.js-based dirty checking by tracking exactly which reads depend on which state.
- Hierarchical DI scopes providers to a component subtree, enabling per-feature service instances instead of only global singletons.
- Async pipe, takeUntilDestroyed(), and manual unsubscription in ngOnDestroy() are the three standard answers for avoiding Observable memory leaks.
- Senior interviews increasingly ask judgment questions like signals-vs-RxJS trade-offs, not just definitions.
Practice what you learned
1. In a typical Angular interview answer, what triggers Zone.js-based change detection?
2. What does ChangeDetectionStrategy.OnPush actually restrict?
3. Why does an effect() re-run automatically when a signal it reads changes?
4. What problem does hierarchical dependency injection solve, according to standard interview answers?
5. Which of these is NOT one of the standard answers for avoiding RxJS Observable memory leaks in components?
Was this page helpful?
You May Also Like
Change Detection and Zone.js
Understand how Angular detects and applies UI updates via Zone.js, how the change detection tree works, and how zoneless change detection with signals changes the model.
Signals vs RxJS Observables
Compare Angular's synchronous signal-based reactivity model to RxJS's asynchronous stream-based Observables, and learn when to reach for each.
Hierarchical Dependency Injection
Understand how Angular's injectors form a tree mirroring the component hierarchy, how token resolution walks up that tree, and how to scope service instances deliberately.
Common Angular Pitfalls
A practical rundown of mistakes Angular developers repeatedly make—memory leaks, signal misuse, change detection surprises, and DI scoping errors—and how to avoid each.
Related Reading
Related Study Notes in Web Development
Browse all study notesWebSockets Study Notes
Web Development · 30 topics
Web DevelopmentWebAssembly Study Notes
WebAssembly · 30 topics
Web DevelopmentgRPC Study Notes
Protocol Buffers · 30 topics
Web DevelopmentSpring Boot Study Notes
Java · 30 topics
Web DevelopmentFlask Study Notes
Python · 30 topics
Web DevelopmentDjango Study Notes
Python · 30 topics