Technology interview warm-up
Angular interview questions and answers hub with coding prompts, concept questions, follow-ups, and common mistakes. Practice concise answers first, then expand into Study Plans, guides, and Company Prep.
On this page
Popular clusters
Short answers
Angular is a TypeScript framework for building component-based web applications. It includes routing, forms, dependency injection, templates, HTTP utilities, and a CLI-driven build workflow. The key difference from a small view library is that Angular gives the application structure and many production conventions up front.
AngularJS is the original 1.x framework based on JavaScript, scopes, controllers, and digest-cycle patterns. Angular is the modern TypeScript framework built around components, decorators, dependency injection, RxJS, and a different rendering and tooling model. They are different platforms, so migrating from AngularJS to Angular is usually a rewrite or staged migration, not a simple version bump.
Compare Angular and AngularJS →Components are the main building blocks of Angular UI. A component combines a TypeScript class, a template, styles, metadata, inputs, outputs, and lifecycle hooks. Components should own view behavior, while shared business logic usually belongs in services or facades.
Review component responsibilities →Component metadata is the configuration passed to the @Component decorator. It tells Angular the selector, template, styles, imports, providers, change detection mode, and other compile-time/runtime details. Metadata mistakes can cause missing directives, wrong provider scope, or templates that compile but behave differently than expected.
Review component metadata →Directives attach behavior to templates. Components are directives with templates, attribute directives change behavior or styling on an existing element, and structural directives change the rendered tree. The practical detail is that structural directives can create and destroy embedded views, so state and cleanup behavior can change.
Review Angular directives →Structural directives change whether a block exists in the view tree, usually by creating or destroying embedded views. Attribute directives keep the host element in place and change behavior, classes, styles, or properties. This matters because structural directives can reset component state and trigger teardown, while attribute directives normally do not.
Compare directive types →Pipes transform values for display in a template. Built-in pipes handle common formatting such as dates, numbers, and currency, while custom pipes keep presentation transforms reusable. Expensive or impure pipes can run often, so heavy work should be cached, moved to state, or handled before rendering.
Review Angular pipes →Data binding connects component state and template behavior. Interpolation and property binding move data from the component to the view, event binding moves user actions back to the component, and two-way binding combines both directions. Binding bugs often come from targeting the wrong DOM property, mutating state in place, or hiding ownership with two-way syntax.
Review Angular data binding →Interpolation writes a string expression into text content or an attribute-like position. Property binding sets a DOM or directive property with the actual value type, such as a boolean, object, or array. Use property binding when type matters, because interpolation always passes through string rendering.
Compare binding syntax →@Input() lets a parent pass data into a child component. @Output() exposes events from the child back to the parent, usually with EventEmitter or newer output APIs. The contract should stay one-way: inputs describe state, outputs describe user or child events, and the parent owns the resulting state change.
Review input and output →The constructor is for TypeScript class creation and dependency injection. ngOnInit() runs after Angular has initialized inputs, so it is the safer place for initialization that depends on bound data. DOM-dependent work still belongs later, such as ngAfterViewInit, because the view is not fully ready in ngOnInit().
Compare constructor and ngOnInit →Lifecycle hooks let a component respond to creation, input changes, content/view initialization, checks, and destruction. Common hooks include ngOnInit, ngOnChanges, ngAfterViewInit, and ngOnDestroy. The important part is timing: subscriptions, DOM reads, cleanup, and input-dependent setup belong in different hooks.
Review lifecycle hooks →Dependency injection is the Angular system for creating and supplying services, tokens, and other dependencies. Providers decide what value is created and injector scope decides who shares it. A correct answer names where the provider lives, when the instance is created, and which components or routes share it.
Review dependency injection →Services hold reusable logic that should not belong to a single template. They commonly manage API calls, feature state, mapping, permissions, logging, or coordination between components. The main trade-off is scope: a root service is shared broadly, while route or component providers create narrower instances.
Review Angular services →Hierarchical dependency injection means Angular resolves providers through an injector tree. A child injector can reuse a parent provider or override it with a more local instance. This is powerful for feature boundaries, but accidental local providers can create duplicate service state.
Debug provider scope →Change detection is how Angular checks application state and updates templates. Zone-based apps usually schedule checks from async activity, events, and framework hooks, while newer patterns can make update triggers more explicit. When debugging stale UI, first identify the trigger path before reaching for detectChanges or markForCheck.
Review change detection →OnPush tells Angular to check a component when inputs change by reference, events run, observables update through async pipe, signals update, or change detection is explicitly requested. It improves render predictability but exposes mutation bugs quickly. If the object reference stays the same after a nested mutation, an OnPush child may not update.
Debug OnPush stale UI →Zone.js patches async APIs so Angular can know when tasks finish and schedule change detection in zone-based applications. It makes many UI updates feel automatic after timers, promises, and DOM events. In zoneless setups, updates need explicit notification paths such as signals, async pipe, or manual change detection APIs.
Review Zone.js and change detection →Observables represent streams of values over time, and RxJS provides operators for transforming, combining, canceling, and sharing those streams. Angular uses Observables in HttpClient, forms, router events, and many async workflows. The practical skill is choosing operators that match user intent, such as switchMap for latest-only search.
Review Observables and RxJS →HttpClient requests are canceled when the subscription to the request Observable is unsubscribed. switchMap cancels the previous inner request when a new value arrives, and async pipe or takeUntilDestroyed can cancel work during teardown. Ignoring an old response is not the same as aborting the underlying request.
Review HttpClient cancellation →Template-driven forms keep more form behavior in the template and are fine for simple workflows. Reactive forms model controls in TypeScript, which makes dynamic fields, validation, async flows, and tests easier to control. For complex forms, reactive forms are usually the safer default because the state graph is explicit.
Compare form strategies →Lazy loading delays loading a route or feature until it is needed. It reduces initial bundle cost and creates clearer feature boundaries. The trade-off is that provider scope, preloading strategy, and route-level data loading must be planned so navigation stays predictable.
Review lazy loading →Standalone components can declare their own imports and participate in routing without being declared in an NgModule. They simplify new Angular apps and feature composition. NgModules still appear in older codebases and some library boundaries, so migration answers should cover compatibility and provider scope.
Compare standalone and NgModules →NgRx is a Redux-style state management library for Angular. It is useful when shared state has complex transitions, multiple writers, effects, optimistic updates, or audit/debugging needs. For local UI state or small feature state, component state, services, signals, or RxJS may be simpler.
Choose NgRx vs local state →Prefer async pipe when templates consume streams because Angular handles subscription cleanup. For manual subscriptions, use takeUntilDestroyed, takeUntil with a destroy subject, or explicit unsubscribe when needed. Also clean up timers, global listeners, WebSocket streams, and resolver streams that might never complete.
Review memory leak prevention →Beginner to experienced
Start with Angular, components, templates, directives, pipes, binding, inputs, outputs, services, and lifecycle timing. These questions build the vocabulary needed before RxJS, routing, testing, and performance trade-offs become useful.
Focus on change detection, provider scope, HttpClient cancellation, route boundaries, testing strategy, sanitization, standalone migration, and profiling. These topics expose whether an Angular answer can survive production edge cases.
Testing
Use plain unit tests for pure functions, validators, mapping logic, and services that do not need Angular runtime behavior. Use TestBed when the code depends on templates, dependency injection, lifecycle hooks, pipes, directives, or Angular change detection. TestBed has more setup cost, so the boundary should match the behavior you need to prove.
Open the Angular testing prep path →Set inputs through the host or fixture API, run change detection, and assert the rendered behavior instead of private fields. For outputs, trigger the user action or child method that emits and assert the parent-facing event. Useful component tests cover changed inputs, missing optional inputs, disabled states, and emitted payload shape.
Review input and output →fakeAsync runs a test inside a controlled async zone so timers and microtasks can be advanced deterministically. tick() moves virtual time forward and flushes timer work scheduled for that window. It is useful for debounce, delay, timeout, and lifecycle timing, but it should not hide unclear async ownership.
Review async testing strategy →HttpTestingController lets a test expect a request, assert its method, URL, params, and body, then flush a success or error response. It proves the service sends the right HTTP contract without making a network call. A reliable test also verifies no unexpected requests remain after the scenario.
Review HttpClient behavior →Component harnesses provide a stable testing API for interacting with components through user-facing behavior. They reduce brittle selectors and hide markup details that should not matter to the test. Harnesses are most valuable for shared UI components where many tests need the same reliable interactions.
Open the Angular prep path →Test guards by controlling route state, auth or permission services, and the expected allow, redirect, or block result. Test resolvers by asserting the data request and by checking completion behavior, because navigation can wait for a resolver. Router-focused tests should separate access control from data prefetch behavior.
Review Angular routing →Push values through a controllable Observable or subject, run change detection, and assert the text, loading state, or error state visible to the user. The async pipe owns subscription cleanup, so the test should focus on rendering transitions instead of manual unsubscribe calls. Include empty, loading, next value, and failure paths when the UI depends on them.
Review Angular Observables →Tests become brittle when they assert private methods, framework internals, or exact DOM structure that users cannot observe. They also become flaky when async work is not owned clearly, such as unflushed HTTP requests or timers. Prefer behavior assertions, stable selectors or harnesses, explicit async control, and tests at the smallest boundary that proves the risk.
Review Angular testing mistakes →Security
Angular treats template expressions as data binding, not executable template strings created at runtime. It escapes interpolated text and sanitizes values for risky contexts such as HTML and URLs. The protection is strongest when data stays in Angular templates instead of being written through direct DOM APIs.
Review Angular data binding →Interpolation renders text, so HTML markup from a user is displayed as text instead of becoming elements. [innerHTML] asks Angular to render HTML and relies on sanitization to remove unsafe content. Use interpolation or text content for ordinary user input, and treat rich HTML as a special case with strict source and sanitization rules.
Compare binding syntax →DomSanitizer is an Angular API for sanitizing values or explicitly marking a value trusted for a specific security context. It is needed only when ordinary binding and built-in sanitization are not enough for a controlled use case. The dangerous part is that trust decisions move responsibility from Angular to application code.
Review Angular security topics →bypassSecurityTrustHtml tells Angular to skip normal sanitization for that value. If the value contains user-controlled markup, the app can reintroduce XSS even though Angular templates are normally safe. Only use bypass APIs for tightly controlled, audited content and keep the trusted boundary small.
Review Angular security topics →Bind URLs through Angular properties when possible so framework sanitization can run for the target context. Validate allowed schemes and destinations before using user-controlled links, redirects, images, or resource URLs. Special contexts such as iframe sources and script-like URLs need stricter allowlists, not string concatenation.
Review safe binding →Treat CMS HTML as untrusted unless it comes from a trusted pipeline with server-side sanitization and a narrow allowlist. Client-side rendering should still avoid scripts, event-handler attributes, unsafe URLs, and unknown embeds. The safer architecture sanitizes before storage or delivery, then renders through a small component with clear ownership.
Review Angular security topics →Content Security Policy reduces the damage of injected scripts by limiting what the browser can execute or load. Backend validation and output encoding protect data before it reaches the Angular app and protect non-Angular consumers too. Angular template safety is one layer, not a replacement for server-side validation and browser policy.
Review Angular prep path →Direct DOM writes can bypass Angular binding, sanitization, and change detection assumptions. APIs such as nativeElement.innerHTML or third-party widgets need careful review because they may insert unsanitized markup. Prefer Angular templates, Renderer2 for DOM operations, and explicit sanitization boundaries for unavoidable integrations.
Review Angular binding safety →Routing + compiler + performance
Guards decide whether navigation may proceed, redirect, or stop. Resolvers fetch data before route activation so the destination can start with required data available. Access control belongs in guards, while data prefetch belongs in resolvers or component loading depending on the user experience.
Review Angular routing →CanMatch runs while the router is deciding whether a route can match at all. CanActivate runs after a route has matched and before it activates. CanMatch is useful for feature flags, role-based route trees, and lazy route selection, while CanActivate fits ordinary activation checks.
Review guard behavior →A resolver that never completes can keep navigation waiting indefinitely. HTTP Observables usually complete, but streams such as subjects, router events, or store selectors may not complete on their own. Use finite streams, take(1), or move non-blocking data to in-component loading when waiting would harm navigation.
Review resolver timing →AOT compiles Angular templates during the build, while JIT compiles them at runtime. AOT improves startup, catches more template issues earlier, and is the normal production choice. JIT can be useful in development-style workflows, but it adds runtime compilation cost.
Review template compilation →Angular compiles templates into instructions and can type-check bindings before production runtime. That catches mistakes such as misspelled properties, incompatible input types, and invalid template expressions earlier. Runtime stale UI problems still require change detection and state ownership debugging.
Review compiler behavior →Start by measuring the slow route, interaction, or render path before applying a checklist. Common bottlenecks include heavy template work, unstable list identity, excessive change detection, oversized route chunks, and repeated HTTP or derived-state work. The fix should match the measured bottleneck, such as trackBy, OnPush, lazy loading, memoized state, or moving work out of the template.
Review Angular performance →Declarations move out of NgModules, but provider scope must be handled separately. A migration can accidentally duplicate services, drop shared imports, or move providers to a broader or narrower lifetime than intended. Validate route boundaries, lazy loading, and shared UI imports as separate migration checks.
Review standalone migration →Lazy loading delays fetching a route or feature until it is needed. Preloading fetches lazy code in the background after initial load so future navigation can feel faster. The trade-off is startup cost, network timing, and whether a feature is likely enough to justify early background loading.
Review lazy loading →Scenarios + code
@Component({
changeDetection: ChangeDetectionStrategy.OnPush,
template: '{{ user.name }}'
})
export class UserCard {
@Input() user!: User;
}
this.user.name = 'Ada';OnPush checks input references, not every nested field mutation. If the parent mutates user.name while keeping the same object reference, the child can stay stale. Create a new object, emit new state, or use an explicit observable/signal update path.
Debug OnPush stale UI →results$ = search.valueChanges.pipe(
debounceTime(250),
switchMap(query => http.get('/api/search', { params: { query } }))
);switchMap unsubscribes from the previous inner request when a new query arrives. With HttpClient, that unsubscribe can abort the old request and prevents stale responses from winning. mergeMap allows parallel requests, which is correct for some workflows but risky for latest-only UI.
Choose the right RxJS operator →ngOnInit() {
this.form.valueChanges.subscribe(value => {
this.saveDraft(value);
});
}valueChanges is long-lived and can keep emitting after the component should be gone. Use async pipe where possible, or bind manual subscriptions to the component lifetime with takeUntilDestroyed or another teardown pattern. HttpClient one-shot streams are different because they usually complete.
Review teardown patterns →@Component({
selector: 'app-cart-panel',
providers: [CartService]
})
export class CartPanel {}A provider on a component creates an instance for that component subtree. If the cart state was supposed to be shared app-wide, this local provider can create a second cart. Move the provider to root or the intended route boundary and state who should share the instance.
Debug DI scope →username = new FormControl('', [], [
value => this.api.checkUsername(value)
]);Async validators can race when old requests finish after newer values. Angular handles async validator subscriptions, but the validator still needs predictable cancellation/error behavior and should return finite Observables. Add debouncing or switchMap-style ownership when validation depends on fast-changing input.
Review form validation strategy →<li *ngFor="let user of users; trackBy: trackUser">
{{ user.name }}
</li>Stable identity lets Angular reuse DOM and component instances when a list changes. Without a useful trackBy or track expression, reordering or refreshing arrays can recreate more UI than necessary. The bug is not only performance; local row state and focus can also reset unexpectedly.
Review list identity →<section *ngIf="user$ | async as user">
{{ user.name }}
</section>async pipe subscribes, updates the template, and unsubscribes when the view is destroyed. It is usually better for read-only template data because lifecycle ownership is clear. Manual subscribe is still useful for imperative effects, but then teardown and error handling are your responsibility.
Review Angular Observables →export const routes: Routes = [
{
path: 'admin',
providers: [AdminFeatureService],
loadComponent: () => import('./admin.page')
}
];Route-level providers create instances scoped to that route branch. That is useful for feature isolation, but it can split state if callers expected a root singleton. Lazy loading and provider boundaries should be explained together because both affect runtime ownership.
Review lazy loading boundaries →Modern Angular
Standalone components remove the need to declare every component in an NgModule. Imports move closer to the component or route that uses them, which makes feature boundaries easier to see. The migration risk is provider scope, because moving declarations and providers are different decisions.
Compare standalone and NgModules →Route-level providers scope services to a route branch instead of the whole app. They are useful for feature state, temporary workflows, and lazy-loaded boundaries that should not share instances globally. They can also create duplicate state if a root singleton was expected.
Review route boundaries →Signals are a good fit for local synchronous state and derived values that the template reads directly. RxJS remains stronger for event streams, cancellation, multicasting, retry, debouncing, and HTTP orchestration. Many Angular apps use both: signals for state reads and RxJS for async pipelines.
Compare streams and state →Signal-based APIs make input reads and derived state more explicit in modern Angular components. They do not remove the need for clear ownership: parents still pass state down, and children still emit meaningful events up. The main benefit is predictable reactivity with less glue code for derived template state.
Review component contracts →The newer @if, @for, and @switch syntax makes template control flow more explicit and avoids some microsyntax friction. The interview value is understanding view creation, list identity, and empty states, not only naming the syntax. The same performance and state-reset concerns still apply.
Review view creation →Deferrable views let Angular delay loading part of a template until a trigger such as viewport visibility, interaction, or idle time. They are mainly a performance and loading-strategy tool. Use them for expensive non-critical UI, but keep loading, placeholder, and error states deliberate.
Review loading strategy →Zoneless Angular removes the assumption that patched async APIs automatically notify the framework. Updates need explicit notification paths such as signals, async pipe, or change detection APIs. That can reduce hidden work, but it requires clearer state ownership and update boundaries.
Review zoneless change detection →Server-side rendering can improve first contentful paint and crawlable content by sending HTML earlier. Hydration lets Angular attach behavior to server-rendered markup instead of rebuilding the whole page from scratch. The trade-off is complexity around browser-only code, data consistency, and measuring whether SSR helps the actual route.
Review Angular performance →Critical for coding rounds and edge-case discussion.
Implement an Angular debounced search using RxJS. Use debounceTime + distinctUntilChanged + switchMap to cancel stale requests, and model loading, error, and empty states so the UI feels like a real search box. This che…
Open Angular coding interview challenge →Critical for coding rounds and edge-case discussion.
Expose a value input and a valueChange output to support two-way binding, and keep the child component stateless so the parent owns the source of truth. Concepts: components, inputs outputs, binding, event binding, temp…
Open Angular coding interview challenge →Critical for coding rounds and edge-case discussion.
Build a simple paginated data table in Angular that shows a static list of users. Display 5 rows per page, with Previous / Next controls and a "Page X of Y" indicator. Disable the navigation buttons appropriately on the…
Open Angular coding interview challenge →Critical for coding rounds and edge-case discussion.
Build an **autocomplete search bar** in Angular. As the user types, show a dropdown of suggestions filtered from a dataset. Add debounced searching, mouse selection, and keyboard navigation (↑/↓/Enter/Escape). Framework…
Open Angular coding interview challenge →Critical for coding rounds and edge-case discussion.
Build a contact form using an Angular standalone component and reactive forms. You will only work in `src/app/app.component.ts` – the HTML, CSS, and bootstrapping are already set up. On submit, validate the input and se…
Open Angular coding interview challenge →Critical for coding rounds and edge-case discussion.
Build a Material-like invite field in Angular. As users type, show autocomplete suggestions, convert selections into removable chips, and support keyboard shortcuts (Enter/comma/backspace).
Open Angular coding interview challenge →Need more implementation reps? Open the full coding list or follow a study plan.
Frequently tested in explanation-heavy rounds.
Angular data binding is mostly explicit one-way flow in one direction at a time: component state into the DOM, events back into the component, and two-way syntax only as sugar. The real production edge is debugging prop…
Open Angular interview question →Frequently tested in explanation-heavy rounds.
A directive is a class that Angular attaches to an element (or an <ng-template>) to add behavior, change styling, or control whether a chunk of template exists at all. The senior angle is not only naming structura…
Open Angular interview question →Frequently tested in explanation-heavy rounds.
Angular lifecycle hooks are framework callbacks on components/directives that run at specific moments (creation, input changes, content/view init + checks, destruction). Interviewers care less about memorizing names and…
Open Angular interview question →Frequently tested in explanation-heavy rounds.
Constructor runs when the class instance is created (mainly for DI + trivial field setup). ngOnInit() runs once after Angular has set initial @Input() bindings (after the first ngOnChanges). The stronger interview answe…
Open Angular interview question →Frequently tested in explanation-heavy rounds.
Angular DI is hierarchical, so provider location changes instance count and service lifetime. The useful angle is the real production bug: re-providing a service in a component or standalone route and silently splitting…
Open Angular interview question →Frequently tested in explanation-heavy rounds.
OnPush change detection is easiest to explain as a real stale-UI debugging story. Angular skips a component unless a narrow trigger happens, so production bugs usually come from mutating references, updating state insid…
Open Angular interview question →Need more concept coverage? Open the full concepts list or browse company packs.
Angular coverage map
HttpClient returns Observables, and real cancellation depends on unsubscribing from the active request. For typeahead or route changes, choose switchMap, AsyncPipe, or lifecycle teardown so stale responses do not win.
Practice HttpClient cancellation →Angular DI creates and supplies services, config values, and scoped dependencies. Service responsibility should be explained with provider placement, because root, route, and component providers change instance lifetime.
Review Angular dependency injection →Angular forms questions usually test state ownership, validation timing, async validation, and reusable controls. Reactive Forms are the safer default once the workflow is dynamic, validation-heavy, or needs focused tests.
Compare Angular form strategies →Change detection answers should name the trigger path, not just the API. Default, OnPush, AsyncPipe, signals, markForCheck, and detectChanges all matter when you debug stale UI or excessive rerenders.
Debug change detection strategies →Standalone components cover most new Angular composition, routing, and provider setup. NgModules still matter for legacy declarations, module-shaped libraries, and compatibility boundaries.
Compare standalone and NgModules →Good Angular tests protect behavior at the right boundary: pure validators and services without TestBed where possible, TestBed for template integration, and HTTP/router tools for async flows. Avoid tests that only prove construction.
Open the Angular testing prep path →Performance answers should start with evidence, then choose the fix: lazy loading for bundle cost, OnPush and trackBy for render churn, and moving expensive work when the main thread is blocked.
Review Angular performance optimization →State management questions test whether state is local, shared, durable, or business-critical. Use local component state for short-lived UI state, services for contained feature state, and NgRx when explicit global transitions pay for their cost.
Choose Store vs component state →Treat modern Angular as a production reasoning topic: explain the trade-off, current maturity, and migration risk instead of naming a feature in isolation.
Interview prep context
Angular prompts are curated from shipped FrontendAtlas practice routes and reviewed for interview-specific production pitfalls.
Quick answers
Yes. The page starts with beginner Angular fundamentals, then moves into experienced-developer topics such as scenarios, testing, security, routing, performance, RxJS, change detection, and modern Angular.
Yes. The testing section covers TestBed, fakeAsync, tick, HttpTestingController, component harnesses, guards, resolvers, async pipe UI, and brittle Angular test mistakes.
Yes. The security and routing sections cover Angular sanitization, DomSanitizer, XSS prevention, user-controlled URLs, guards, resolvers, AOT/JIT, template compilation, lazy loading, and performance profiling.
Start with one route first. Then expand into Question Library, Study Plans, and Company Prep only when you need them.
Recommended preparation
Start with the interview preparation guide and shared baseline, then tighten Angular coding, concepts, and follow-up depth.