You Know Angular. But Can You Explain Why? 7 Questions That Expose Senior-Level Gaps

If you've been working with Angular for 3+ years, you probably know how to build an application.

Components.
Services.
Routing.
Forms.
RxJS.
APIs.

You know the framework.

But senior Angular interviews are different.

At some point, the interviewer stops asking:

"How do you implement this?"

And starts asking:

"Why did you implement it this way?"

That's where things get interesting.

Here are 7 questions I'd use to test whether an Angular developer understands the engineering behind the framework.

1. Why would you use switchMap instead of mergeMap?

A common mistake is treating switchMap as the default answer whenever an Observable contains another Observable.

But the correct operator depends on the business requirement.

For example:

switchMap makes sense when only the latest operation matters.
mergeMap is useful when operations can run concurrently.
concatMap is appropriate when operations must execute sequentially.
exhaustMap is useful when new requests should be ignored while the current operation is running.

Consider a search box.

If the user types:

ang
angu
angul
angula
angular

you generally care about the latest search.

That's a very different requirement from processing every event.

So the interview isn't really testing whether you remember four operator names.

It's testing whether you can connect an operator to a system requirement.

1. How does Angular resolve a dependency?

This is another question where memorization isn't enough.

Angular has different injector hierarchies, and where you provide a dependency affects its scope and lifecycle.

Imagine a workspace application with multiple tabs.

If all tabs accidentally share the same state service, one tab can overwrite another tab's data.

Providing the service at the appropriate local container level can create an isolated instance for each workspace.

That's not just an Angular syntax question.

It's an architecture question.

The interviewer wants to know whether you understand:

dependency scope
instance lifetime
isolation
injector hierarchy
application architecture

1. When would you use Signals instead of RxJS?

This is becoming an increasingly important conversation in modern Angular applications.

But answering:

"Signals are the new Angular feature."

isn't enough.

You need to understand what problem you're solving.

Signals provide fine-grained reactive state.

RxJS is particularly useful for asynchronous streams and more complex event/data-flow orchestration.

The interesting interview question is not:

"What are Signals?"

It's:

"Why would you choose Signals here instead of RxJS?"

Your answer should connect the technology to the problem.

1. Why would you use OnPush?

A weak answer:

"Because it improves performance."

A better answer explains what changes in Angular's rendering behavior and why that matters for the particular component tree.

Senior-level interviews often move from:

"What does OnPush do?"

to:

"Where would you use it?"

and then:

"What problems could it create?"

That's the difference between knowing a feature and understanding its trade-offs.

1. What happens when a component is destroyed but a subscription is still active?

This is where real-world experience matters.

Manual subscriptions can create lifecycle problems if they aren't cleaned up correctly.

You should be able to reason about:

component destruction
subscription lifetime
memory leaks
long-running streams
declarative reactive patterns
debugging with browser tooling

Don't just memorize:

"Always unsubscribe."

Understand why the subscription needs to end and what happens if it doesn't.

1. How would you improve the performance of an Angular application?

This is one of my favorite interview questions because there isn't one magic answer.

You need to investigate the actual bottleneck.

Depending on the application, you might need to think about:

change detection
OnPush
unnecessary rendering
large component trees
bundle size
lazy loading
@defer
expensive synchronous work
unnecessary subscriptions
Zone-related work

A senior engineer shouldn't immediately throw optimization techniques at the application.

First identify the problem.

Then choose the appropriate solution.

1. How would you structure a large Angular application?

This is where an Angular interview starts becoming an architecture interview.

For a large application, I'd expect a candidate to think about:

domain boundaries
feature isolation
shared functionality
state management
dependency boundaries
scalability
maintainability
team ownership

The interesting part isn't whether you know a particular folder structure.

It's whether you can explain:

"Why did you structure the application this way?"

Because the architecture that works for a small application may become painful as the application, team and domain grow.

The real Angular interview problem

After working with Angular for years, you can become very good at implementing features.

But interviews can expose a different gap.

You know what to do.

The interviewer wants to know whether you understand why.

That's why I'd prepare around these areas:

JavaScript & TypeScript runtime
Angular internals
Dependency Injection
RxJS
Signals
Performance
Architecture
System Design
Real-world scenarios
Follow-up questions

I put together a 30-day Angular Interview Roadmap around these areas.

It includes structured preparation across JavaScript/TypeScript, Angular core mechanics, performance, scaling, architecture and system design, along with interview follow-up questions, practice exercises and a final self-assessment checklist.

If you're preparing for an Angular interview, you can find the roadmap here:

https://topmate.io/sandip_jaiswar/2207243

The goal isn't to memorize more Angular.

It's to become better at explaining the engineering decisions behind the Angular code you already write.