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. - 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. - 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 - 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. - 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. - 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. - 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. - 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. Top comments (0)