Angular Developer Interview Questions for AI Training Work

I use two-way binding for simple form controls where the convenience outweighs the tradeoff, but I lean toward one-way binding with explicit events in more complex components, since two-way binding can make it harder to trace where a state change actually originated as an app grows.

Dependency injection lets a component or service receive its dependencies from outside rather than constructing them internally, which makes it possible to substitute a mock implementation in tests. I've used this to swap a real API service for a mock in unit tests without changing the component under test at all.

I prefer the async pipe when possible, since it handles subscription and unsubscription automatically, which avoids the memory leak risk of a manual subscription that isn't properly cleaned up. I use a manual subscription when I need to react to a value with side effects beyond just rendering it in the template.

I choose the combination operator based on the actual relationship between the sources, like combineLatest when I need the latest value from each whenever any changes, or forkJoin when I need all of them to complete once. Picking the wrong operator for the relationship is a common source of subtle bugs in RxJS code.

I use a takeUntil pattern tied to the component's destruction lifecycle hook, or the equivalent teardown mechanism the version of Angular provides, so subscriptions are cleaned up automatically when the component is destroyed rather than relying on manually tracking and unsubscribing from each one.

I'd check whether OnPush change detection is being used appropriately and whether any bindings are creating new object references on every render, since that forces unnecessary re-evaluation. I'd profile with the Angular DevTools to see the actual change detection cycles rather than guessing at the cause.

I'd use the official upgrade tooling and go version by version rather than jumping multiple major versions at once, since each version's migration guide addresses specific breaking changes that compound if skipped. I'd prioritize fixing compile errors first, then address deprecation warnings before they become breaking in a future version.

I'd look at lazy-loading feature modules that aren't needed on initial render first, since that's usually the highest-impact change, before considering more granular optimizations like bundle size reduction for individual components. I'd measure actual load time improvements at each step rather than assuming a change helped.

A subscription wasn't being cleaned up when a component was destroyed, causing it to keep firing and update a component that no longer existed, throwing intermittent console errors. I traced it to a manual subscription without proper teardown and fixed it by switching to a takeUntil pattern, then audited the rest of the codebase for the same issue.

A component had accumulated form logic, API calls, and display logic all in one place. I extracted the API and business logic into a service and split the display into smaller presentational components, which made the remaining logic much easier to test and reason about.