25 Angular interview questions

Listen for: A strong answer starts by reproducing the issue and checking data flow: template bindings, component inputs, service calls, subscriptions, signals, and change detection boundaries. They should mention Angular DevTools, browser network logs, console tracing, and writing a small failing test. Good candidates avoid guessing and narrow whether the bug is API, state, or view update related.

Red flag: They immediately blame Angular change detection without inspecting data flow or reproducing the issue.

Listen for: Listen for practical distinctions: plain properties for local static values, signals for synchronous reactive UI state, and Observables for async streams such as HTTP, WebSockets, route params, and events over time. They should know Angular can interoperate with RxJS using helpers like toSignal and avoid converting everything blindly.

Red flag: They say signals replace RxJS everywhere or cannot explain any trade-off.

Listen for: Good answers mention splitting by responsibility, extracting presentational components, moving data access to services or facade-like helpers, keeping templates readable, and using typed inputs and outputs. They should discuss avoiding large lifecycle methods, naming signals clearly, and adding focused tests. The best junior candidates recognize when not to abstract too early.

Red flag: They only suggest moving random code into more files without explaining boundaries.

Listen for: They should discuss simplifying view models, extracting child components, using track expressions correctly, and moving formatting or decision logic out of the template when it becomes complex. Strong answers preserve accessibility and avoid hiding important UI behavior in opaque helper methods. They should understand readability and performance both matter.

Red flag: They propose putting all logic into the template because the new control flow syntax allows it.

Listen for: Look for typed reactive forms, clear validation rules, useful error messages, accessible labels and descriptions, and separation between form state and submit side effects. They may mention reusable validators, disabling duplicate submissions, handling server validation errors, and keeping tests around complex form behavior. Template-driven forms are acceptable when justified for simple cases.

Red flag: They focus only on making the submit button work and ignore validation, accessibility, and error handling.

Listen for: A strong junior answer mentions using the async pipe, takeUntilDestroyed with DestroyRef, signals interop, or ensuring subscriptions complete for HttpClient calls. They should verify by reading observable lifetimes, testing navigation away from the component, and using DevTools if needed. They should not add manual unsubscribe boilerplate everywhere without thinking.

Red flag: They believe every subscription is automatically cleaned up by Angular.

Listen for: Listen for route query params as the source of shareable state, a typed service layer, cancellation or switchMap for changing filters, distinct loading and empty states, and back/forward navigation behavior. Strong answers mention caching or stale-while-revalidate only when useful and avoid storing duplicated filter state in many places.

Red flag: They keep all state in component variables and ignore URL synchronization and cancellation.

Listen for: Strong answers start with measurement: bundle analysis, Angular DevTools, browser performance traces, Core Web Vitals signals, and network waterfalls. Improvements may include route-level lazy loading, @defer for secondary UI, reducing large dependencies, SSR or prerendering, image optimization, and fixing expensive template work. They should avoid optimizing blindly.

Red flag: They say to use lazy loading without measuring what is actually slow.

Listen for: Look for scope-based reasoning. Local state belongs in the component; shared service state fits small cross-component workflows; store libraries fit complex shared state, debugging needs, caching, undo, or many actors. Strong candidates discuss boilerplate, team familiarity, testability, and migration paths rather than treating one pattern as mandatory.

Red flag: They insist every app needs NgRx or that store libraries are always overengineering.

Listen for: They should combine focused unit tests for validation and mapping logic with component tests using TestBed or Angular Testing Library, mocked HttpClient or service boundaries, and possibly Playwright or Cypress for a happy path. Good answers test behavior visible to users, not private methods, and keep brittle DOM assertions limited.

Red flag: They only snapshot the component or test private functions while skipping user behavior.

Listen for: Listen for race conditions in RxJS chains, missing cancellation, duplicate submits, unhandled loading and error states, route reuse assumptions, hydration mismatches, and templates that assume data is immediately present. Strong candidates discuss throttling network locally, adding logging, reproducing with realistic latency, and making UI resilient to partial data.

Red flag: They say slow networks are a backend problem and do not inspect the frontend flow.

Listen for: Good answers cover domain-based folders or libraries, standalone routes, shared UI with strict ownership, path aliases, lint boundaries, and avoiding a dumping-ground shared module. They may mention Nx or Angular CLI workspaces when appropriate. Strong candidates distinguish reusable design-system components from business-specific components.

Red flag: They put most code in a single shared folder because it is easy to import.

Listen for: They should separate authentication UX from server-enforced authorization, use route guards for navigation convenience, attach tokens or cookies through a safe HTTP strategy, handle refresh and logout consistently, and avoid exposing sensitive decisions only in the client. Strong answers include role-based rendering as UX, not security, plus error handling for 401 and 403 responses.

Red flag: They believe hiding buttons or using route guards is sufficient security.

Listen for: Strong answers stage the migration: update versions incrementally, remove deprecated patterns, adopt standalone components and new control flow where valuable, tighten TypeScript and template checks, improve tests, and manage risk with feature flags or slices. They should discuss dependency compatibility, build tooling, CI, and not rewriting everything at once.

Red flag: They propose a full rewrite as the default before assessing risk and value.

Listen for: Listen for a measured approach: keep Observables for async streams, convert to signals near the component boundary when it improves template clarity, avoid mixed duplicated sources of truth, and establish conventions. Strong candidates mention effects sparingly, cleanup behavior, testing impact, and educating the team through examples rather than mandates.

Red flag: They want to replace all Observables with signals immediately.

Listen for: Strong answers combine technical and process fixes: clear component contracts, Storybook or similar examples, visual and interaction tests, semantic versioning or ownership rules for shared libraries, changelogs, and deprecation paths. They should mention accessibility and design-system alignment. The best answers reduce coupling instead of adding more approval gates only.

Red flag: They solve it only by requiring a senior engineer to approve every change.

Listen for: They should weigh SEO, first contentful render, perceived performance, personalization, server cost and complexity, third-party scripts, authentication, and operational ownership. Strong answers discuss Angular Universal or current SSR setup, hydration constraints, transfer state, caching, and measuring before and after. They should know SSR can create new failure modes.

Red flag: They say SSR is always better for performance without discussing complexity or user journeys.

Listen for: Look for layered handling: HTTP interceptors for cross-cutting concerns, domain-specific error mapping in services, user-friendly component states, global ErrorHandler for unexpected failures, logging with context, and retry only where safe. Strong candidates distinguish validation errors, authorization failures, offline states, and fatal app errors.

Red flag: They catch errors everywhere and show the raw backend message to users.

Listen for: A strong senior answer includes a concrete problem, options considered, trade-offs, a thin vertical slice or proof of concept, migration guidance, documentation, code review examples, and follow-up. Listen for collaboration with product, design, QA, and backend peers. They should measure success through maintainability and delivery, not personal preference.

Red flag: They describe imposing a pattern without involving the people who had to maintain it.

Listen for: They should review behavior, state ownership, typing, accessibility, performance hotspots, test coverage, API boundaries, and whether the implementation fits team conventions. Strong seniors leave specific, respectful comments and separate blocking issues from preferences. They may pull the branch locally for risky changes and suggest smaller follow-ups when appropriate.

Red flag: They focus mostly on formatting or rewrite the code themselves instead of coaching through the review.

Listen for: Strong answers separate public and authenticated shells, use lazy routes, guards for UX, server-enforced auth, and decide where SSR, prerendering, hydration, or client rendering apply. They should discuss transfer state, caching, environment configuration, error pages, and monitoring hydration mismatches. Look for pragmatic boundaries, not a single rendering mode everywhere.

Red flag: They apply SSR to every route without considering auth, caching, or operational complexity.

Listen for: Listen for URL-addressable steps, server-backed checkout state, typed reactive forms, idempotent submissions, clear recovery from redirects, and validation split between client and server. Strong answers cover guards against invalid navigation, draft persistence, accessibility, analytics events, and duplicate-submit protection. They should avoid storing sensitive payment data in browser state.

Red flag: They keep the entire checkout state only in a singleton service.

Listen for: Good answers model server streams, user commands, and view filters separately. They should cover reconnection, backpressure or batching, optimistic versus confirmed acknowledgements, ordering, stale data indicators, and teardown on navigation. Strong candidates explain where RxJS streams, signals, or a store fit and how they would test race conditions.

Red flag: They append every WebSocket message directly to an array in the component.

Listen for: Strong answers define ownership, API stability, accessibility standards, theming tokens, documentation, examples, and automated tests. They may use Angular libraries, Storybook, visual regression, and semantic release-style versioning. Listen for guidance on when not to add business-specific logic to the shared library and how to deprecate safely.

Red flag: They treat the library as a shared folder where anyone can add anything.

Listen for: They should discuss module federation or web-component-style integration, routing ownership, shared dependencies, design-system consistency, authentication, observability, and deployment rollback. Strong candidates also identify costs: runtime failures, duplicated Angular versions, cross-team contracts, and local development complexity. They should recommend micro-frontends only for real organizational independence needs.

Red flag: They choose micro-frontends mainly because the app is large, without organizational reasons.