Angular Developer interview questions
Angular interviews rarely stop at framework trivia. Interviewers want to know whether you understand what Angular does behind the template: how it decides to re-render, how observables flow through a feature, and how you'd keep a big app healthy through upgrades. Expect at least one round where you write or debug real component code while someone watches.
What happens in each round
- 1
Recruiter screen
What happens
Whether your Angular experience is recent and hands-on, which parts of the framework you've used (forms, routing, state management), and whether you've worked on a large or long-lived app rather than only tutorials.
- 2
Technical phone screen
What happens
Core concepts out loud: change detection, the component lifecycle, dependency injection scopes and the common RxJS operators. They listen for whether you explain the why or only recite definitions.
- 3
Live coding or take-home
What happens
Usually a small feature: a search box that calls an API, a reactive form with validation, or a list with filtering. They watch how you handle subscriptions, typing, error states and whether you write a unit test without being asked.
- 4
Architecture and code review round
What happens
How you'd structure feature areas, where state should live, when to reach for NgRx or signals, and how you'd plan a framework upgrade. Some teams hand you an existing pull request and ask what you'd flag.
- 5
Team and hiring manager conversation
What happens
How you work with designers, back end developers and QA, how you handle disagreement in review, and whether you can explain technical trade-offs to a product owner without drowning them in detail.
Questions you're likely to get
1.How does change detection work in Angular, and what does OnPush change?
Why they ask
Most real performance problems in Angular apps trace back to change detection. This question separates people who've tuned a slow screen from people who've only built demos.
How to answer
- Explain that Zone.js patches async events and triggers a check of the component tree from the root
- Say that OnPush only checks a component when an input reference changes, an event fires inside it, an async pipe emits or you mark it for check
- Mention that signals let Angular track exactly which views depend on which values, which is why zoneless apps are possible
- Give a real case where switching to OnPush exposed a bug caused by mutating an object instead of replacing it
2.What's the difference between switchMap, mergeMap, concatMap and exhaustMap?
Why they ask
Picking the wrong flattening operator causes race conditions and duplicate requests, and it's one of the most common bugs in Angular code reviews.
How to answer
- switchMap cancels the previous inner observable, so it suits typeahead search
- mergeMap runs everything in parallel, fine for independent writes
- concatMap queues and preserves order, good for saves that must happen in sequence
- exhaustMap ignores new values while one is running, which stops double-submits on a save button
3.How do you avoid memory leaks from subscriptions?
Why they ask
Long-lived enterprise screens stay open all day, and leaked subscriptions slowly make them unusable. Interviewers want to see habits, not just knowledge.
How to answer
- Prefer the async pipe in templates so Angular handles unsubscribing
- Use takeUntilDestroyed or DestroyRef for subscriptions in component classes
- Know that HTTP observables complete on their own but router and form streams don't
- Describe how you'd find a leak with Chrome DevTools heap snapshots
4.When would you use signals instead of RxJS, and when wouldn't you?
Why they ask
Teams are moving toward signals, and they want someone who can adopt them sensibly rather than rewrite everything or ignore them.
How to answer
- Signals suit synchronous component state and derived values through computed
- RxJS still wins for events over time: debouncing, retries, websockets, combining several async sources
- Mention toSignal and toObservable for the boundary between the two
- Talk about migrating a screen gradually, not in one big pull request
5.Walk me through how you'd build a complex reactive form with conditional fields.
Why they ask
Angular apps are often form-heavy, and reactive forms are where juniors and seniors look most different.
How to answer
- Use typed FormGroup and FormArray, with sections split into child components
- Add or disable controls based on valueChanges rather than hiding fields with the template alone
- Write custom sync and async validators, and debounce any validator that calls an API
- Cover how errors are shown, and how the form behaves for keyboard and screen reader users
6.How does dependency injection work, and what does providedIn root actually do?
Why they ask
DI is the backbone of Angular, and misunderstanding injector scope leads to shared state bugs that are painful to trace.
How to answer
- Explain the injector hierarchy: environment injectors and element injectors
- providedIn root gives one shared instance and lets unused services be tree-shaken
- Providing a service on a component gives each instance its own copy
- Mention the inject function and injection tokens for config values
7.When would you bring in NgRx, and when is it overkill?
Why they ask
State management choices shape a codebase for years. They want judgment, not loyalty to a library.
How to answer
- Use a store when many unrelated features read and change the same data, or when you need action logging and time-travel debugging
- For a feature's local state, a service with signals or ComponentStore is often enough
- Describe effects for side effects and selectors for memoized reads
- Give an example of a time you removed or avoided store code because it added ceremony without benefit
8.How would you plan an upgrade across several major Angular versions?
Why they ask
Most Angular jobs involve an app that's behind. They need someone who can upgrade without freezing feature work.
How to answer
- Go one major version at a time using ng update and the official update guide
- Check third-party libraries like Angular Material and NgRx for matching versions first
- Rely on the test suite and a staging environment, and ship each step separately
- Mention schematics for migrations such as standalone components and the new control flow syntax
9.How do you test an Angular component that depends on a service and an HTTP call?
Why they ask
Plenty of Angular test suites are slow and brittle. They want someone who writes tests that catch bugs without testing Angular itself.
How to answer
- Use TestBed with a mocked or stubbed service, or HttpTestingController for the HTTP layer
- Test what the user sees: rendered text, button states, error messages
- Mention Jest or Jasmine with Karma, and Cypress or Playwright for end-to-end flows
- Avoid asserting on private methods or internal subscriptions
10.Tell me about a time a screen you built was slow. What did you do?
Why they ask
This is the behavioral version of the change detection question. They want a real story with evidence, not theory.
How to answer
- Describe the symptom users reported and how you measured it with Angular DevTools or the Chrome performance panel
- Name the cause, such as a function call in a template, a huge ngFor without trackBy, or a leaking subscription
- Explain the fix and how you confirmed it helped
- Say what you changed in your habits or the team's review checklist afterward
11.Tell me about a disagreement in a code review and how it ended.
Why they ask
Angular teams on big apps review a lot of code. They want to know you can push back politely and also accept being wrong.
How to answer
- Pick a real technical disagreement, like store versus service or a naming convention
- Show that you backed your view with a concrete example or a quick prototype
- Say how it was resolved and whether a team convention came out of it
12.How would you structure a large Angular app so several teams can work in it?
Why they ask
Senior roles in particular involve shaping the codebase so it doesn't collapse under its own size.
How to answer
- Split by feature with lazy-loaded routes, and keep shared UI in a separate library
- Mention Nx or Angular workspace libraries with enforced module boundaries
- Keep smart container components separate from presentational ones
- Talk about lint rules and code owners so conventions don't depend on memory
Mistakes that sink good candidates
Talking about AngularJS experience as if it were the same framework, without being clear about the difference
Calling subscribe inside another subscribe in a live coding exercise instead of using a flattening operator
Dismissing testing, accessibility or upgrades as someone else's job
Answering every architecture question with one library you like instead of weighing the trade-offs
Need more Angular Developer interviews to prep for?
HeroApply applies to Angular Developer jobs that match you, every day. 166 jobs are open today.