Angular interviews require broad technical knowledge spanning TypeScript, reactive programming, component architecture, and the Angular framework's own concepts. Modern Angular (v17+) has introduced significant changes — standalone components, signals-based reactivity, and control flow syntax — meaning interviewers now probe both the "Angular way" and awareness of these modern approaches. Here's what you need to know for a strong performance.
Angular Architecture Fundamentals
"What is the Angular component lifecycle, and which hooks are most important?" Angular components go through a defined lifecycle from creation to destruction. The most commonly used hooks: ngOnInit runs once after the component's inputs are initialized — the right place for initialization logic and data fetching (not the constructor, which runs before Angular processes inputs). ngOnChanges runs when any input property changes, receiving a SimpleChanges object with previous and current values. ngOnDestroy runs just before Angular destroys the component — the right place to unsubscribe from Observables, cancel timers, and release resources to prevent memory leaks. ngAfterViewInit runs after the component's view (and child views) are initialized — the first point where @ViewChild references are available.
"What are Angular modules, and how do standalone components change things?" Angular modules (@NgModule) were the traditional way to organize an Angular application — grouping components, directives, pipes, and providers together. Every component had to be declared in exactly one module. Angular 14+ introduced standalone components (flagged with standalone: true in the decorator), which don't belong to any module and declare their own imports directly. Angular 17 made standalone the default. Standalone components simplify the architecture significantly — no more hunting for which module to declare a component in — and they work better with Angular's lazy loading and tree-shaking capabilities.
Dependency Injection: Angular's Core Mechanism
"Explain Angular's dependency injection system." Angular's DI system is a hierarchical injector system. Services are registered as providers at various levels: root level (available application-wide, single instance), module level (available to all components in a module), component level (new instance for each component and its children). When a component or service declares a dependency (via constructor injection), Angular's injector resolves it by looking up the injector hierarchy from the current level to root. providedIn: 'root' in a service's @Injectable decorator registers the service at root level — the standard approach for singleton services. Component-level providers override root providers for that component's subtree, enabling component-scoped state.
"What is the difference between a service declared with providedIn: 'root' and one provided in a component?" A root-provided service is a singleton shared across the entire application — every component that injects it gets the same instance. A component-provided service creates a new instance for that component and is destroyed when the component is destroyed. The component-level approach is used for stateful services that should be scoped to a component's lifetime — a form state service, a selection state service, or a service that tracks state specific to one route.
RxJS: Reactive Programming with Observables
"What is an Observable and how does it differ from a Promise?" An Observable represents a stream of values over time — zero, one, or many values, delivered synchronously or asynchronously. A Promise represents a single future value — it resolves once with success or rejects with an error. Key differences: Observables are lazy (they don't execute until subscribed to), Promises execute immediately upon creation. Observables are cancellable (unsubscribe stops the stream), Promises cannot be cancelled. Observables can emit multiple values over time, Promises emit exactly one. Angular's HttpClient returns Observables rather than Promises, allowing cancellation of in-flight HTTP requests and easier chaining with RxJS operators.
"What are the most important RxJS operators and when do you use them?" map transforms each emitted value. filter passes only values meeting a condition. switchMap maps to an inner Observable and cancels previous inner Observables when a new outer emission arrives — ideal for search-as-you-type (cancel the previous search when the user types more). mergeMap runs inner Observables concurrently. concatMap queues inner Observables sequentially. debounceTime delays emissions — commonly used with form inputs to wait for the user to stop typing before making API calls. catchError handles errors in the stream. takeUntil completes the Observable when a second Observable emits — the standard pattern for unsubscribing when a component is destroyed.
Angular Signals: Modern Reactivity
"What are Angular Signals and how do they differ from RxJS?" Signals (introduced in Angular 16, stable in Angular 17) are a simpler reactive primitive. A signal is a wrapper around a value that tracks who reads it — any template or computed() that reads a signal is automatically re-evaluated when the signal changes. Signals are synchronous, always have a current value (unlike Observables which may not have emitted yet), and are simpler to understand than Observable streams. RxJS remains better for asynchronous event streams, HTTP requests, and complex operator chains. The Angular team envisions Signals for component state and derived values, RxJS for async operations. The two can be bridged with toSignal() and toObservable().
Performance and Best Practices
"What is OnPush change detection and when should you use it?" By default, Angular's change detection checks every component in the tree on every change. ChangeDetectionStrategy.OnPush restricts change detection to only run for a component when: its input references change, an event handler is triggered from the component or its children, an Observable bound via async pipe emits, or change detection is manually triggered. For components that receive immutable data (objects/arrays where changes always produce new references), OnPush dramatically improves performance by skipping unnecessary checks. It requires immutable data patterns but is highly recommended for production applications.
"How do you prevent memory leaks in Angular applications?" The most common memory leak source is unsubscribed Observables. When a component subscribes to an Observable in ngOnInit without unsubscribing in ngOnDestroy, the subscription persists even after the component is destroyed. Solutions: the async pipe automatically unsubscribes when the component is destroyed (preferred for template subscriptions); the takeUntilDestroyed() operator (Angular 16+) completes subscriptions when the injection context is destroyed; manually unsubscribing in ngOnDestroy using a Subject and takeUntil; or storing subscriptions in a Subscription array and calling unsubscribe() on all of them in ngOnDestroy.