Angular Interview Preparation Path: 7/14/30-Day Study Plan

Change detection, rendering triggers, and zone behavior

Why it’s asked: This is where “it works locally but the screen does not update correctly” bugs usually come from.

Typical prompts:

• Explain Default vs OnPush and what actually triggers checks.
• When to use markForCheck() vs detectChanges() and why.
• AsyncPipe behavior: mark-for-check + auto-unsubscribe.
• NgZone.runOutsideAngular() and zone-pollution mitigation.
• What zoneless mode changes in update-notification patterns.

What good looks like: You can name the exact trigger path, avoid random detectChanges patches, and choose an update strategy that stays predictable as the app grows.

RxJS semantics and stream architecture

Why it’s asked: Bad stream design creates stale UI, duplicate requests, and hard-to-reproduce bugs under real user input.

Typical prompts:

• Cold vs hot Observables, Subjects, and multicasting in practical terms.
• Operator choice: switchMap vs mergeMap vs concatMap vs exhaustMap.
• shareReplay caching trade-offs (lifetime, errors, refCount).
• Unsubscribe patterns with AsyncPipe and takeUntilDestroyed().
• Error handling and retry placement in the pipeline.

What good looks like: You choose operators based on UX behavior, explain cancellation clearly, and keep streams composable instead of stacking nested subscriptions.

Dependency Injection and provider configuration

Why it’s asked: Provider scope mistakes create intermittent bugs that are painful to debug later.

Typical prompts:

• Hierarchical injectors and resolution rules.
• Provider recipes: useClass, useValue, useFactory, useExisting.
• InjectionToken usage for configuration and contracts.
• Multi providers, especially HTTP interceptors.
• Provider scope: root vs feature vs component and lazy boundaries.

What good looks like: You can state instance lifetime and override boundaries up front, and you use tokens/providers with a clear runtime reason.

Routing architecture: guards, resolvers, lazy loading, preloading

Why it’s asked: Routing questions quickly reveal whether you think in user flows or just in API names.

Typical prompts:

• Implement guards (CanActivate, CanMatch) for auth, roles, and feature flags.
• Use resolvers for pre-activation data prefetch and explain trade-offs.
• Lazy loading patterns and fixing broken loadChildren configuration.
• Preloading strategies such as PreloadAllModules.
• Router event instrumentation and teardown without leaks.

What good looks like: You separate auth from data prefetch, keep navigation responsive, and explain lazy loading as a user-experience decision.

Forms engineering: Reactive Forms, validation, async validators, custom controls

Why it’s asked: Forms expose real engineering quality: state shape, validation timing, and reusable control behavior.

Typical prompts:

• Reactive Forms structure with FormBuilder.
• FormArray for dynamic controls and list-rendering pitfalls.
• Custom validators and async validators with updateValueAndValidity().
• ControlValueAccessor for reusable controls.
• Validator registration via tokens such as NG_ASYNC_VALIDATORS.

What good looks like: You treat forms as architecture, keep validation deterministic, and build CVAs that behave like first-class controls.

Performance optimization and rendering strategies

Why it’s asked: This checks whether you can find the real bottleneck instead of cargo-culting optimizations.

Typical prompts:

• trackBy/track usage to reduce DOM churn.
• Pure vs impure pipe trade-offs and real penalties.
• Skipping subtrees with OnPush + immutability.
• Zone-pollution diagnosis and moving work outside Angular.
• Performance tuning with before/after proof.

What good looks like: You start with evidence, pick one high-impact fix, and explain the before/after impact clearly.

State management decisions and NgRx patterns

Why it’s asked: This exposes whether your state model scales cleanly or collapses into hard-to-reason side effects.

Typical prompts:

• When a service store is enough vs when NgRx is justified.
• Actions, reducers, selectors, and effects responsibilities.
• Entity adapter usage for normalized CRUD collections.
• Effect cancellation strategy through operator choice.
• State immutability and change-detection synergy.

What good looks like: You can justify why state belongs where it does, and your async side effects stay predictable under load.

Testing and maintainability

Why it’s asked: Teams want confidence you can ship safely and debug quickly when behavior changes.

Typical prompts:

• TestBed setup patterns and when pure logic should skip TestBed.
• HTTP mocking with HttpTestingController (expect/flush).
• Router testing utilities and modern patterns.
• Component harnesses for user-style interaction.
• Testing async streams together with change detection behavior.

What good looks like: You write behavior-driven tests that stay stable, and you can explain why a test belongs at unit or integration level.

Change detection, rendering triggers, and zone behavior

Why they ask it: Because “why did the UI not update?” and “why is this rerendering constantly?” are costly Angular production bugs.

Common trivia questions:

• Why does OnPush sometimes not update when you mutate an object?
• When would you use markForCheck() vs detectChanges()?
• What does AsyncPipe do besides subscribing in the template?
• What is NgZone.runOutsideAngular() used for?
• What does zoneless mode imply for update notification?
• How do you reduce unnecessary change-detection work without feature regressions?
• Why does mutating an @Input() in a child not always rerender with OnPush?

60-second answer skeleton:

• OnPush checks on specific triggers: input reference changes, events, manual marking, and async emissions.
• Mutating keeps the same object reference, so no input-reference trigger fires.
• Prefer immutable updates; otherwise use markForCheck() for next cycle or detectChanges() for immediate subtree checks.
• AsyncPipe subscribes, pushes latest values, marks for check on emissions, and auto-unsubscribes.
• runOutsideAngular() avoids CD from high-frequency async noise; re-enter with NgZone.run() when UI update is required.
• Zoneless mode shifts toward explicit reactive notifications instead of zone-driven triggers.

Common traps:

• Confusing detectChanges() (immediate) with markForCheck() (scheduled).
• Treating AsyncPipe as automatic caching instead of stream/lifetime management.
• Running UI-changing logic outside zone and forgetting to re-trigger updates.
• Sprinkling detectChanges() everywhere instead of fixing data flow.
• Premature optimization that makes debugging harder.

How to practice: Break one OnPush component by mutating state, then fix it with immutable updates, markForCheck, and AsyncPipe. Explain trade-offs out loud.

• OnPush real bug breakdown trivia
• Change detection strategies trivia
• Zone.js and change detection trivia

RxJS semantics and stream architecture

Why they ask it: Angular apps are async-heavy, so interviewers need to see cancellation safety, leak prevention, and predictable stream behavior.

Common trivia questions:

• Cold vs hot Observables: what changes in UI behavior?
• When do you use switchMap vs mergeMap vs concatMap vs exhaustMap?
• What are the common shareReplay footguns?
• How do you stop RxJS memory leaks in components?
• What happens to an in-flight HttpClient request when you unsubscribe?
• How do you place error handling so one failure does not kill the whole UI?
• Why is nested subscribe() a smell?

60-second answer skeleton:

• Cold Observables rerun producers per subscription; hot Observables share producers/events.
• Operator choice controls cancellation and concurrency semantics.
• switchMap cancels previous work; mergeMap runs in parallel; concatMap queues; exhaustMap ignores while busy.
• shareReplay can be correct for sharing and replay, but lifetime and invalidation must be explicit.
• Prefer AsyncPipe or takeUntilDestroyed() for lifecycle-safe teardown.
• Unsubscribing HttpClient cancels in-flight requests, which matters for navigation and typeahead.

Common traps:

• Using mergeMap for typeahead and causing stale result races.
• Applying shareReplay(1) everywhere without lifetime planning.
• Catching errors in the wrong layer and masking failures.
• Nested subscribe chains that destroy cancellation clarity.
• Forgetting teardown in long-lived subscriptions.

How to practice: Implement one search flow with switchMap, mergeMap, and concatMap variants, then compare stale-result behavior and user experience.

• Operator choice in Angular trivia
• shareReplay pitfalls trivia
• Unsubscribe patterns trivia
• Debounced search drill coding

Dependency Injection and provider configuration

Why they ask it: Large Angular systems depend on DI boundaries; tiny provider mistakes can create “works here, breaks there” failures.

Common trivia questions:

• Explain hierarchical injectors and scope in practical terms.
• What is an InjectionToken and when do you need it?
• How do useClass, useValue, useFactory, and useExisting differ?
• What is a multi provider and why does it matter for interceptors?
• How do you safely override dependencies in a feature boundary?
• What is injection context and why can inject() throw?

60-second answer skeleton:

• Angular resolves dependencies by walking injector hierarchy; scope controls lifetime and sharing.
• Lazy boundaries can create distinct instances based on provider placement.
• InjectionToken is required for config/interfaces without runtime type metadata.
• Provider recipe defines creation semantics (constant, factory, alias, class).
• Multi providers aggregate chain values, such as HTTP interceptors.
• inject() must run inside an Angular injection context.

Common traps:

• Trying to inject interfaces directly.
• Forgetting multi: true and replacing interceptor chains accidentally.
• Using mutable singleton config where scoped instances are needed.
• Overriding providers at root when feature scope is intended.
• Calling inject() from random module-level code.

How to practice: Build a tiny config token plus feature override. Then break and fix an interceptor chain by toggling multi: true.

• Dependency injection fundamentals trivia
• Hierarchical DI bug example trivia
• forRoot / forChild boundaries trivia

Routing architecture: guards, resolvers, lazy loading, preloading

Why they ask it: Routing reveals whether you can structure production apps with access control, prefetch timing, and bundle strategy.

Common trivia questions:

• What is the difference between guards and resolvers?
• When should you use CanMatch vs CanActivate?
• What does lazy loading buy you and when?
• What is preloading and how should strategy vary by network conditions?
• How do router events support analytics and observability safely?
• What lazy route configuration mistakes appear most often?

60-second answer skeleton:

• Guards decide if navigation may proceed; resolvers fetch data before route activation.
• CanMatch controls whether a route matches at all; CanActivate blocks activation after match.
• Lazy loading reduces initial bundle by loading feature code on demand.
• Preloading warms lazy chunks in the background to reduce first-navigation delay.
• Router events can power page-view metrics when subscriptions are lifecycle-safe.
• Choose resolver-wait vs component-skeleton UX intentionally based on user flow.

Common traps:

• Using resolvers for access control instead of guards.
• Preloading everything without strategy on slow connections.
• Mixing standalone and module routing syntax incorrectly.
• Eager-importing features to hide lazy route config bugs.
• Leaking router-event subscriptions.

How to practice: Compare resolver-wait navigation against in-component skeleton loading for the same route and explain UX and complexity trade-offs.

• Angular routing fundamentals trivia
• Lazy loading interview patterns trivia
• forRoot / forChild routing boundaries trivia

Forms engineering: Reactive Forms, validation, async validators, custom controls

Why they ask it: Enterprise Angular is form-heavy, so interviewers check correctness, scalability, and reusable-control discipline.

Common trivia questions:

• Why do complex apps prefer Reactive Forms?
• How do async validators behave and what commonly goes wrong?
• What problem does ControlValueAccessor solve?
• FormArray vs FormGroup: when does each fit best?
• What does setValue vs patchValue communicate?
• How do you prevent validation storms and flicker?

60-second answer skeleton:

• Reactive Forms are model-driven, explicit, and easier to test for dynamic workflows.
• Async validators return Observable/Promise and move status to PENDING until completion.
• ControlValueAccessor lets custom inputs behave like native form controls.
• FormGroup maps keyed structures; FormArray maps dynamic sequences.
• setValue requires full shape; patchValue applies partial updates intentionally.
• Use debounce, distinctUntilChanged, and switchMap on valueChanges for API-backed checks.

Common traps:

• Treating template-driven as always wrong instead of context-driven choice.
• Async validators that spam backend with no debounce/cancellation.
• CVA implementations that ignore touched/disabled state.
• Forgetting multi: true when registering validator providers.
• Silent patchValue shape mismatches with no transform/validation.

How to practice: Implement one reusable CVA input and one async uniqueness validator, then verify fast typing does not cause stale validation flicker.

• Reactive vs template-driven forms trivia
• ControlValueAccessor deep dive trivia
• Contact Form + HTTP drill coding
• Multi-step Reactive Form drill coding

Performance optimization and rendering strategies

Why they ask it: Teams want proof you can reduce UI jank and DOM churn with measured fixes, not cargo-cult optimization.

Common trivia questions:

• Why does trackBy matter and what makes a good trackBy function?
• Pure vs impure pipes: when does each hurt or help?
• Where do you investigate first when an Angular view feels janky?
• How do you reduce work in large lists without harming UX?
• What is zone pollution and how do you mitigate it?
• Why does immutability keep coming up with OnPush performance?

60-second answer skeleton:

• trackBy preserves DOM nodes by stable identity and reduces unnecessary re-creation.
• Impure pipes rerun frequently; pure pipes with immutable inputs are safer by default.
• Start from profiling CD and template evaluation before changing architecture.
• Use pagination/virtualization and move expensive logic out of templates.
• Run noisy async sources outside zone and re-enter only for required UI updates.
• Immutability improves reference-based change detection and limits rerender cascades.

Common traps:

• Using index as trackBy in reorderable lists.
• Using impure pipes to mask mutation issues.
• Blaming change detection when template work is the actual bottleneck.
• Sprinkling detectChanges() as a performance strategy.
• Micro-optimizing without before/after measurements.

How to practice: Take a slow list, add stable trackBy, move heavy template logic to pure transforms, and compare before/after behavior.

• Angular performance optimization trivia
• trackBy correctness and cost trivia
• Paginated table drill coding

State management decisions and NgRx patterns

Why they ask it: State questions show whether you can scale complexity without subscription spaghetti and stale update chaos.

Common trivia questions:

• When is a service-based store enough vs when is NgRx justified?
• Why must reducers stay pure?
• How do you choose effect mapping operators for cancellation behavior?
• How do you prevent stale responses from updating state?
• Why are selectors pure and what does memoization buy?
• How do you avoid turning NgRx into ceremony-heavy architecture?

60-second answer skeleton:

• Use service-level state for small/local scopes; use NgRx for large cross-feature event complexity.
• Reducers are pure so updates remain deterministic and replayable.
• Effects handle side effects, and operator choice defines cancellation/concurrency rules.
• Prevent stale updates with explicit cancellation and action-scoped identity.
• Selectors should stay pure so memoization can eliminate recomputation noise.
• Draw boundaries early: local UI state vs shared domain state.

Common traps:

• Adopting NgRx for trivial local state.
• Placing side effects inside reducers.
• Using mergeMap everywhere and creating duplicate in-flight calls.
• Breaking selector memoization with unstable object creation.
• Building one giant god-state object with weak boundaries.

How to practice: Pick one feature, split local vs global state explicitly, then explain effect operator choices for cancellation and replay behavior.

• Component vs service boundaries trivia
• Observables in Angular architecture trivia
• Shopping cart state drill coding

Testing and maintainability (unit/integration, HTTP, router)

Why they ask it: Teams hire engineers who can ship safely, isolate dependencies, and validate async UI without flaky test suites.

Common trivia questions:

• When should you use TestBed vs plain unit tests?
• How do you mock HTTP requests in Angular tests?
• How do you test interceptors and routing behavior safely?
• How do you test async-pipe-driven components without brittle timing?
• What makes a test behavior-focused instead of DOM-fragile?

60-second answer skeleton:

• Use plain unit tests for pure logic and TestBed when DI/templates/lifecycle matter.
• Mock HTTP with HttpTestingController and assert request/flush behavior explicitly.
• Keep routing tests focused on navigation outcomes, not implementation internals.
• Drive async UI with controlled emissions and stabilization, not detectChanges spam.
• Prefer behavior assertions so markup refactors do not create false failures.

Common traps:

• Allowing tests to hit real network dependencies.
• Overusing detectChanges() to force green tests.
• Coupling tests tightly to DOM structure.
• Mocking the wrong layer and skipping request-level behavior checks.
• Creating tests that hide scheduling and teardown bugs.

How to practice: Run one async-heavy coding prompt, then write a short behavior-focused test checklist before implementation to force maintainability thinking.

• Angular coding drills (filter: coding) list
• Angular trivia drills (filter: trivia) list
• Debounced search async behavior drill coding

1) Data table with filtering, sorting, and pagination

Prompt template: Implement an Angular data table from a mockup, load JSON data, add filtering/sorting/pagination, and include basic unit tests.

What they’re testing: Component composition, template correctness, reactive derived state, performance hygiene (stable identity), and testability.

What good looks like: Clear state model (filter/sort/page inputs), derived rows via Observable + AsyncPipe, stable row identity, and behavior-focused tests for filter/sort/page.

Common pitfalls:

• Mutating arrays in place, causing fragile OnPush/performance behavior later.
• No stable row identity, leading to avoidable DOM churn.
• Doing heavy filtering in template with impure pipes.

Variation (easy / medium / hard): easy: local JSON + client filtering / medium: reactive filter form + debounced search + cached results / hard: server pagination + cancellation + shared caching.

• Angular paginated data table coding
• Angular dynamic table coding
• Angular filterable user list coding
• trackBy pitfalls in ngFor trivia

2) “Fix this broken Angular app” debugging exercise

Prompt template: Open a broken Angular app with 3–5 issues. Fix each and explain symptom → root cause → solution.

What they’re testing: Unfamiliar-code debugging speed, Angular internals reasoning (CD/DI/router/forms), and explanation quality.

What good looks like: Each bug is isolated and documented with concise root-cause notes, and fixes avoid scope regressions or random detectChanges band-aids.

Common pitfalls:

• Local patching (detectChanges everywhere) instead of architecture-level fixes.
• Disabling tests/types instead of resolving root causes.
• Fixing one bug while breaking DI scope or lazy routing config.

Variation (easy / medium / hard): easy: template and typing issues / medium: lazy route misconfig or missing provider registration / hard: zone pollution + OnPush update failures.

• OnPush debugging in production-like bug trivia
• Hierarchical DI real bug trivia
• Angular coding drills (full set) list

3) RxJS typeahead search with cancellation + caching

Prompt template: Build search with debounce, cancellation of old requests, loading/error states, and no duplicate refetch on re-subscribe.

What they’re testing: Operator choice, cancellation semantics, duplicate-request prevention, subscription lifecycle management, and safe caching.

What good looks like: Single valueChanges stream with debounce + switchMap, clean loading/error modeling, no nested subscriptions, and intentional cache lifetime.

Common pitfalls:

• Using mergeMap and introducing race-driven stale UI.
• Applying shareReplay blindly with no invalidation/lifetime plan.
• Manual subscriptions that leak or duplicate requests.

Variation (easy / medium / hard): easy: debounce + switchMap / medium: cache latest result / hard: per-query Map cache + invalidation + tests.

• Angular debounced search coding
• Angular autocomplete search bar coding
• switchMap vs mergeMap vs others trivia
• shareReplay pitfalls trivia
• What cancels Angular HTTP requests trivia

4) Auth gating via route guards + HTTP interceptors

Prompt template: Protect routes, redirect unauthenticated users, attach token headers, and keep error-handling flow consistent.

What they’re testing: Guard correctness, navigation flow, interceptor chain setup, DI boundaries, and routing/HTTP testability.

What good looks like: Guards return UrlTree for redirects, interceptor chain remains intact, and flow is testable with routing + HTTP mocks.

Common pitfalls:

• Missing multi: true and unintentionally replacing interceptor chain.
• Guard logic that blocks without proper redirect behavior.
• Mixing UI-side effects into interceptors.

Variation (easy / medium / hard): easy: CanActivate + token header / medium: refresh flow + single retry / hard: role-based trees + authorized preloading strategy.

• Angular routing fundamentals trivia
• Angular lazy loading trivia
• Angular dependency injection trivia
• Hierarchical DI bug case trivia

5) Custom form control (ControlValueAccessor) + async validation

Prompt template: Build a reusable search-select control with CVA, disabled support, async option loading, and uniqueness validation.

What they’re testing: CVA protocol correctness, validator lifecycle, async cancellation behavior, and true forms integration.

What good looks like: Correct writeValue/registerOnChange/registerOnTouched/disabled wiring; debounced async checks with cancellation; form state remains trustworthy.

Common pitfalls:

• Ignoring touched/disabled state and breaking parent-form behavior.
• Async validators that spam backend and flicker state.
• Value-propagation loops that cause inconsistent form updates.

Variation (easy / medium / hard): easy: simple masked CVA input / medium: debounced search-select / hard: CVA + async validator token registration + tests.

• ControlValueAccessor vs custom two-way trivia
• Reactive vs template-driven forms trivia
• Contact form + HTTP coding
• Multi-step signup form coding
• Invite chips input (autocomplete) coding

6) Lazy-loaded feature + resolver + preloading strategy

Prompt template: Add a lazy feature area, preload required data with a resolver, and define a preloading strategy for faster first navigation.

What they’re testing: Correct lazy-route configuration, resolver semantics and UX trade-offs, and practical preload strategy decisions.

What good looks like: Lazy setup works reliably, resolver only blocks for truly required data, and preloading strategy matches likely user paths.

Common pitfalls:

• Broken loadChildren configuration or mixed routing syntax.
• Resolver doing too much and freezing navigation UX.
• Preloading everything blindly on constrained networks.

Variation (easy / medium / hard): easy: lazy module only / medium: resolver + loading UX strategy / hard: custom behavior-based preloading strategy.

• Angular lazy loading trivia
• Angular routing trivia
• forRoot / forChild boundaries trivia

7) NgRx feature slice with effects + Entity adapter

Prompt template: Load entities from API, store normalized data, expose derived selectors, and handle side effects with explicit operator strategy.

What they’re testing: Reducer/selector/effect wiring, immutability discipline, normalized entity thinking, and cancellation/concurrency decisions.

What good looks like: State boundaries are clear, entity state is normalized, selectors preserve memoization, and effect operators are chosen intentionally by flow semantics.

Common pitfalls:

• Denormalized nested state that makes updates fragile.
• Wrong flattening operators causing duplicate or ignored requests.
• Side effects inside reducers or unstable selector outputs.

Variation (easy / medium / hard): easy: load list + render / medium: CRUD + optimistic updates / hard: cache + route-driven pagination + effect tests.

• Observables and RxJS in Angular trivia
• Component vs service boundaries trivia
• Shopping cart state drill coding
• Transfer list state drill coding

8) Tests for async + routing + HTTP-heavy components

Prompt template: Write tests for a component that uses HttpClient, async pipe, and navigation behavior under user actions.

What they’re testing: HTTP mocking discipline, router-testing reliability, and understanding async + change-detection timing in tests.

What good looks like: Tests assert request/flush behavior, verify AsyncPipe-driven rendering, simulate navigation cleanly, and avoid implementation-coupled assertions.

Common pitfalls:

• Brute-force fixture.detectChanges() usage to hide scheduling issues.
• Mocking the wrong layer and skipping request-level behavior.
• Brittle router timing assumptions.

Variation (easy / medium / hard): easy: service + HttpTestingController / medium: component + async pipe / hard: router + guards/resolvers + interaction harness.

• Contact form + HTTP behavior coding
• Debounced search async behavior coding
• Angular routing fundamentals trivia
• HTTP cancellation semantics trivia

Signal 1: You clarify constraints before coding

What they’re evaluating: Can you reduce ambiguity quickly and prevent expensive rewrites mid-solution?

What good looks like:

• You ask focused questions on data shape, loading/error UX, route behavior, and test expectations.
• You restate scope in one sentence, then commit to a minimal-first implementation plan.

Red flags:

• Coding immediately and discovering requirements late.
• Long requirement discussions with no concrete implementation direction.

Signal 2: You choose a change-detection strategy intentionally

What they’re evaluating: Do you understand update triggers and performance trade-offs instead of patching symptoms?

What good looks like:

• You can explain when OnPush is safe, where immutable updates are required, and when markForCheck() is better than detectChanges().
• You model update triggers explicitly (input reference changes, events, async emissions) and keep template work predictable.

Red flags:

• Sprinkling detectChanges() as a default fix.
• Using OnPush without adapting state-update patterns and then blaming Angular for stale views.

Signal 3: You design RxJS flows with lifecycle discipline

What they’re evaluating: Can you prevent stale UI, duplicate requests, and subscription leaks under real interaction load?

What good looks like:

• You choose mapping operators by behavior (cancel, queue, parallel, ignore-while-busy) and explain why.
• You use AsyncPipe or takeUntilDestroyed() for teardown and keep side effects out of nested subscribe chains.

Red flags:

• mergeMap-by-default causing race-driven stale UI.
• Manual subscriptions with no teardown strategy.

Signal 4: You control DI scope and provider boundaries

What they’re evaluating: Can you predict service lifetime, override behavior, and interceptor chaining correctly?

What good looks like:

• You place providers intentionally (root vs feature vs component) and explain lazy-boundary implications.
• You use InjectionToken for configuration, and keep interceptor registration safe with multi providers.

Red flags:

• Accidentally replacing interceptor chains by misconfigured providers.
• Overriding dependencies at overly broad scope and creating cross-feature side effects.

Signal 5: You keep router flow reliable and user-centered

What they’re evaluating: Can you design navigation behavior that is both correct and predictable for users?

What good looks like:

• You separate authorization (guards) from prefetching concerns (resolvers) and justify that split.
• You explain lazy-loading and preloading decisions using likely navigation paths, not generic rules.

Red flags:

• Using resolvers for access control.
• Blocking navigation without clear fallback/redirect behavior.

Signal 6: You treat forms as architecture, not template glue

What they’re evaluating: Can you build scalable, testable forms with reusable controls and stable validation behavior?

What good looks like:

• You model forms with clear structure (FormGroup/FormArray), keep validation explicit, and prevent async validation storms.
• Your CVA implementations correctly handle writeValue, change/touched callbacks, and disabled state propagation.

Red flags:

• Validation logic scattered across template conditionals.
• Custom controls that look correct visually but break parent-form state semantics.

Signal 7: You justify state-management level and NgRx trade-offs

What they’re evaluating: Do you pick the smallest state model that remains predictable as complexity grows?

What good looks like:

• You separate local UI state from shared domain state and justify when a service store is enough vs when NgRx is worth the overhead.
• You keep reducers pure, selectors memoization-friendly, and effects operator choices aligned with cancellation needs.

Red flags:

• NgRx for trivial local state or one giant global state without boundaries.
• Effect/reducer responsibilities mixed, causing hidden side effects and hard-to-debug flows.

Change detection and OnPush reliability

What to review: Review trigger rules, immutable update expectations, and practical fixes when views do not update as expected.

Micro-drills:

• Explain OnPush trigger paths in 60 seconds (input reference, events, async emissions, manual mark).
• Diagnose one “view did not update” symptom and name the root cause before proposing a fix.
• State one case where markForCheck() is safer than detectChanges() in shared components.

Practice items:

• What are change detection strategies in Angular, and how do they work?angular-change-detection-strategies
• Explain OnPush Change Detection in Angular Like You’re Debugging a Real Production Bugangular-onpush-change-detection-debugging-real-bug
• How does Angular’s Zone.js help in change detection?angular-zonejs-change-detection
• Angular Filterable / Searchable User Listangular-filterable-user-list

RxJS cancellation, concurrency, and request control

What to review: Review operator selection, teardown behavior, and stale-response handling in interactive UIs.

Micro-drills:

• Given one scenario, choose switchMap/mergeMap/concatMap/exhaustMap and justify in one sentence.
• Describe what actually cancels an HttpClient request and when that matters for UX.
• Patch one stale-result bug by changing operator strategy and stream boundaries.

Practice items:

• switchMap vs mergeMap vs exhaustMap vs concatMap: When Would You Use Each in Angular?rxjs-switchmap-mergemap-exhaustmap-concatmap-angular-when-to-use
• How Do You Prevent Memory Leaks in Angular? All Real-World Unsubscribe Patterns Explainedangular-prevent-memory-leaks-unsubscribe-patterns
• What Actually Cancels an HTTP Request in Angular?angular-http-what-actually-cancels-request
• Angular Debounced Search with Fake API (RxJS)angular-debounced-search

Forms architecture, CVA, and validation flow

What to review: Review form-model structure, CVA contract behavior, and async validation lifecycle under typing pressure.

Micro-drills:

• Explain when Reactive Forms should be preferred and one case where template-driven is acceptable.
• List CVA responsibilities in order: writeValue, change callback, touched callback, disabled state.
• Name one anti-pattern that causes validation storms and how to prevent it.

Practice items:

• Template-Driven vs Reactive Forms in Angular: Which One Scales and Why?angular-template-driven-vs-reactive-forms-which-scales
• What Is ControlValueAccessor in Angular and Why Is It Better Than Custom Two-Way Binding?angular-controlvalueaccessor-vs-custom-two-way-binding
• Contact Form (Standalone Component + HTTP)angular-contact-form-starter
• Multi-step Signup Form (Reactive Forms)angular-multi-step-form-starter
• Invite Chips Input (Tags + Autocomplete)angular-chips-input-autocomplete

Dependency injection boundaries and architecture decisions

What to review: Review injector hierarchy, provider recipes, and service/component responsibility boundaries.

Micro-drills:

• Explain root vs feature vs component provider scope with one concrete bug example.
• Given a config object requirement, justify InjectionToken usage and provider recipe.
• Describe one case where service extraction improves testability and one case where it adds noise.

Practice items:

• What is dependency injection in Angular?angular-dependency-injection
• Explain Hierarchical Dependency Injection in Angular With a Real Bug Exampleangular-hierarchical-dependency-injection-real-bug
• What responsibilities belong inside an Angular component vs a service?angular-component-vs-service-responsibilities
• Shopping Cart Mini (Standalone Component)angular-shopping-cart-mini

Routing flow and lazy-loading trade-offs

What to review: Review guard/resolver responsibilities, lazy loading behavior, and module-boundary implications.

Micro-drills:

• Explain CanMatch vs CanActivate with one route-tree example.
• Describe one case where resolver improves UX and one where in-component loading is better.
• State one lazy-loading misconfiguration symptom and how you would validate it quickly.

Practice items:

• What is Angular routing and how do you define routes?angular-routing
• What is lazy loading in Angular?angular-lazy-loading
• What are Angular modules’ forRoot() and forChild() methods used for?angular-forroot-forchild
• Angular Transfer List (Select + Move Between Two Lists)angular-transfer-list

State transitions, interaction reliability, and pressure-proof delivery

What to review: Review deterministic state transitions and interaction guards in prompt-style components.

Micro-drills:

• Define state transitions before coding (idle, running, success/error, reset).
• Identify one repeated-action bug and add an explicit guard.
• Run one scenario where rapid interaction order would otherwise break correctness.

Practice items:

• Observables in Angular: what they are, why RxJS matters, and how to use them correctly (async pipe, cancellation, operators)angular-observables-rxjs
• Autocomplete Search Bar (Standalone Component)angular-autocomplete-search-starter
• Angular Chessboard Click/Highlight (N×N Board)angular-chessboard-click-highlight
• Angular Snake Game (Grid + Food + Collision)angular-snake-game