Angular Interview Questions

AngularJS is the original version, released in 2010, built on JavaScript with a genuinely different architecture. Angular, sometimes called Angular 2+, is a complete rewrite released in 2016, built on TypeScript with a component-based architecture. They're genuinely not compatible with each other, despite the similar name.

The Angular CLI is a command-line tool for actually creating, building, testing, and serving an Angular application, handling a genuinely large amount of configuration and boilerplate setup automatically. Commands like ng generate component actually scaffold a genuinely new component with all its associated files already properly wired together.

Angular is typically written in TypeScript, a genuine superset of JavaScript adding static typing. TypeScript catches a genuinely large class of error at compile time rather than at runtime, and its type information also powers genuinely much better tooling, like autocomplete and refactoring support, in a modern code editor.

A component is the genuinely basic building block of an Angular application's UI, combining a TypeScript class holding logic and data, an HTML template defining what's actually rendered, and CSS defining its own genuine styling. An Angular application is essentially built as a genuine tree of nested components.

Angular is a genuinely full, opinionated framework, providing routing, forms, and HTTP handling all built in. React is genuinely a library focused specifically on building UI components, with routing and state management left to genuinely separate, third-party libraries you choose yourself. Angular also uses TypeScript by default, while React more commonly, though not exclusively, uses plain JavaScript.

The component class, written in TypeScript, holding the genuine logic and data. The template, written in HTML, defining what's actually rendered on screen. The stylesheet, written in CSS (or a preprocessor), defining that specific component's own genuine visual styling.

ng generate component my-component (or the shorter ng g c my-component) creates a genuinely new folder containing the component's own class file, template file, stylesheet, and a test file, all already correctly wired together and registered in the appropriate module.

A selector is the genuinely custom HTML tag name used to actually reference a component elsewhere in a template, defined through the @Component decorator's selector property. Placing <app-my-component></app-my-component> anywhere in another template actually renders that specific component right there.

The CLI typically prefixes a generated selector with app- by default, like app-my-component, and that prefix is genuinely configurable per project. Using a consistent, genuinely project-specific prefix avoids a naming collision with a native HTML element or a genuinely different third-party component library that might otherwise happen to use the exact same tag name.

@Component is a TypeScript decorator marking a class as an Angular component, providing genuine metadata like its selector, its template (or a path to an external template file), and its associated stylesheet. Without this decorator, Angular genuinely has no way of knowing a given class is actually meant to be a component at all.

Interpolation, using double curly braces like {{ propertyName }}, displays a component class property's genuine current value directly within the template's rendered HTML. Angular automatically keeps that displayed value genuinely in sync whenever the underlying property's actual value changes.

A template defines what a component actually renders. It can genuinely be defined inline directly within the @Component decorator using the template property, or in a genuinely separate .html file referenced through templateUrl, which is the far more common approach for anything beyond a genuinely trivial component.

A directive is a genuine instruction attached to a DOM element, telling Angular to actually do something with it, like conditionally showing it, repeating it, or genuinely changing its appearance or behavior. A component is technically itself a genuinely specialized kind of directive, one that specifically has its own template.

A structural directive genuinely changes the DOM's own actual structure, adding or removing elements entirely, like *ngIf or *ngFor. An attribute directive genuinely changes an existing element's appearance or behavior without actually adding or removing it from the DOM, like ngClass or ngStyle.

*ngIf conditionally adds or genuinely, completely removes an element from the actual DOM based on a given expression's truthiness. Hiding with CSS (display: none) keeps the element genuinely in the DOM but visually invisible. *ngIf is generally preferred when the element's genuine content, especially something expensive to render, doesn't need to exist at all when the condition is false.

*ngFor repeats an element once for genuinely each item in a given array. <li *ngFor='let item of items'>{{ item }}</li> renders a genuinely separate list item for every single entry in the items array, automatically updating as that array's own contents actually change.

trackBy tells Angular how to actually identify each specific item in a list, typically by a genuinely unique ID, rather than by its raw index or object reference. Without it, Angular can end up genuinely destroying and recreating DOM elements unnecessarily when a list's contents change, even when most of the genuinely underlying items themselves haven't actually changed at all.

ngClass conditionally applies one or more CSS classes to an element based on a genuine expression's evaluated result, letting you dynamically toggle styling, like [ngClass]='{active: isActive}', which adds the active class specifically whenever the isActive property is genuinely truthy.

An NgModule groups genuinely related components, directives, and services together into one genuinely cohesive unit, declaring what belongs to that module and what genuine external dependencies it actually needs. Every Angular application has at least one root module, conventionally named AppModule, that actually bootstraps the whole application.

Dependency injection provides a class with the genuine dependencies it actually needs, like a service, from an external source rather than the class itself genuinely creating those dependencies directly. Angular relies on it heavily because it genuinely makes components and services more testable and more loosely coupled, since a genuine dependency can be easily swapped out, like for a mock, during testing.

A service is a genuinely reusable class typically holding business logic, data-fetching code, or genuinely shared state, that can be injected into any component (or another service) that actually needs it. It's the standard way of genuinely sharing logic or data across multiple components without duplicating that same logic separately inside each one.

ng generate service my-service creates a genuine service class decorated with @Injectable. A component then requests it by adding it as a genuine constructor parameter, and Angular's own dependency injection system automatically provides a genuine instance of it at runtime.

@Injectable marks a class as genuinely available for Angular's dependency injection system to actually provide elsewhere. providedIn: 'root' registers that service at the genuinely application-wide root level, meaning a genuinely single, shared instance is created and reused across the entire application, rather than a genuinely separate instance being created for each component that requests it.

A component genuinely handles the UI, its own template, and the genuine user interaction tied directly to that specific piece of the screen. A service genuinely handles logic and data that isn't tied to any one single specific UI element, like fetching data from an API, and it's typically shared across multiple genuinely different components.

Interpolation, {{ value }}, displaying a genuine property's value in the template. Property binding, [property]='value', setting a genuine DOM element property from the component. Event binding, (event)='handler()', responding to a genuine user action. Two-way binding, [(ngModel)]='value', genuinely combining property and event binding together.

Interpolation, {{ value }}, is genuinely limited to displaying text content within a template. Property binding, [property]='value', can genuinely set any DOM property, beyond just text content, like an image's src attribute or a genuine boolean disabled property on a button.

<button (click)='handleClick()'>Click me</button> calls the handleClick() method genuinely defined on the component class whenever the button is actually clicked, with the parentheses around click genuinely indicating an event binding rather than a property binding.

Two-way binding genuinely keeps a component property and a DOM element's value automatically synchronized in both directions, using the banana-in-a-box syntax [(ngModel)]='propertyName']. A genuine change to the input field updates the component property, and a genuine change to the component property updates what's actually displayed in the input.

FormsModule needs to genuinely be imported into the module where you're actually using ngModel. Without it, Angular has genuinely no idea what ngModel actually is, and using it results in a genuine template parse error at compile time.

Event binding, using Angular's own (event)='handler()' syntax, calls a genuine TypeScript method on the component class, with full access to that component's own genuine properties and other methods. A plain HTML onclick attribute would genuinely require inline JavaScript, with no direct, natural access to the component's own actual TypeScript context at all.

The Router handles genuine navigation between different views within a single-page Angular application, mapping a specific URL path to a genuine component that should actually be displayed for it, without triggering an actual full-page reload from the server.

{ path: 'about', component: AboutComponent } inside the routes array tells the Router that navigating to /about should actually display AboutComponent. This array is genuinely passed to RouterModule.forRoot() in the root module's own configuration.

<router-outlet></router-outlet> is a genuine placeholder in a template marking exactly where the Router should actually render whatever component genuinely corresponds to the current active route. Without it, the Router has genuinely nowhere to actually display the routed component's content at all.

Inject the Router service into a component, then call this.router.navigate(['/about']) from within a genuine method, like after a form successfully submits, to actually navigate the application to that specific route.

routerLink is an Angular directive handling genuine navigation between routes without triggering an actual full-page reload the way a plain href attribute genuinely would. <a routerLink='/about'>About</a> navigates within the Angular application's own genuine client-side routing system instead.

The constructor runs before Angular has genuinely set the component's input properties, so any logic genuinely depending on those inputs would run too early and see genuinely undefined or incorrect values. ngOnInit runs after inputs are genuinely set, making it the appropriate place for actual initialization logic that depends on them.

@Input() marks a component property as genuinely able to receive a value from its actual parent component, letting a parent template pass data down into a child, like <app-child [data]='parentValue'></app-child>, mirroring the general parent-to-child data flow pattern genuinely common across most component frameworks.

@Output() marks a component property as an EventEmitter that a child can actually use to emit an event upward to its genuine parent. The parent template then genuinely listens for that event, like <app-child (itemSelected)='onItemSelected($event)'></app-child>, mirroring the general child-to-parent communication pattern.

Content projection lets a parent component genuinely pass markup directly into a child component's template, rather than only passing simple data values. <ng-content></ng-content> inside the child's own template marks exactly where that genuinely projected content should actually be rendered, letting you build genuinely flexible, reusable wrapper components like a custom Card or Modal.

providedIn: 'root' creates one genuinely single, shared instance used across the entire application. Registering a service in a specific component's providers array creates a genuinely new, separate instance scoped specifically to that component and its own children, useful when you genuinely need isolated, per-component state rather than one shared, application-wide instance.

Angular's injectors are genuinely organized in a tree structure, roughly mirroring the component tree itself, and a genuine request for a dependency walks up that tree until it actually finds a matching provider. This lets different genuine parts of an application have their own, separately-scoped instance of the exact same service, rather than being forced into using one single, purely flat global instance.

An InjectionToken creates a genuinely unique identifier for injecting a value that isn't itself a class, like a plain configuration object or a genuine primitive string value. TypeScript's own type system alone genuinely can't distinguish between two unrelated string values for injection purposes, so InjectionToken provides that genuinely necessary unique identity instead.

In the testing module's providers array, use { provide: RealService, useClass: MockService } (or useValue for a genuinely simple object) to swap in a genuine test double whenever RealService is actually requested, without touching the real, production service class's own code at all.

A singleton service has genuinely exactly one shared instance used throughout an entire application. providedIn: 'root' is the standard, genuinely recommended way to actually create a singleton service in modern Angular, since Angular's own dependency injection system guarantees only one genuine instance is ever created at that root scope.

A template-driven form defines genuinely most of its logic directly within the HTML template itself, using directives like ngModel, and fits genuinely simpler forms well. A reactive form defines its actual structure and validation logic directly in the TypeScript component class instead, offering genuinely more explicit, testable control, which fits a genuinely more complex form better.

Inject FormBuilder, then use it to actually build a FormGroup, like this.form = this.fb.group({ name: [''], email: [''] });, and bind that FormGroup to the actual template using the formGroup and formControlName directives.

Pass a genuine Validators function (or an array of them) as the second argument when defining that specific form control, like name: ['', Validators.required], and check that control's own genuine valid or invalid state, and its specific errors, directly from the template or the component class.

A custom validator is a genuinely plain function accepting an AbstractControl and returning either null (if valid) or a genuine ValidationErrors object (if invalid). Passed alongside the built-in validators, like name: ['', [Validators.required, myCustomValidator]], it plugs directly into the exact same validation mechanism the built-in validators already use.

A FormControl represents a genuinely single form field's own value and validation state. A FormGroup groups genuinely several related FormControls together, like an entire form. A FormArray holds a genuinely dynamic list of FormControls (or FormGroups), useful for a genuinely variable, repeatable set of fields, like a list of phone numbers a user can actually add or remove.

Check the specific control's own errors object directly in the template, conditionally showing a genuine error message, like <div *ngIf='form.get("email").hasError("required")'>Email is required</div>, typically also checking that the field has genuinely been touched first, to avoid showing an error before the user has actually interacted with it at all.

An Observable represents a genuine stream of values over time, and it can emit multiple values, unlike a Promise, which genuinely resolves exactly once. Observables are also genuinely lazy, meaning nothing actually happens until you genuinely subscribe to them, and they support cancellation directly, through unsubscribing.

myObservable.subscribe(value => { ... }); actually starts listening for genuinely emitted values. Failing to eventually unsubscribe, typically in ngOnDestroy, can cause a genuine memory leak, since the subscription (and anything it genuinely references) keeps living even after the component itself has actually been destroyed and removed.

The async pipe, | async, automatically subscribes to an Observable directly within the template and automatically unsubscribes when the component is genuinely destroyed. It solves the genuine problem of manually managing a subscription's own lifecycle by hand, removing an entire genuinely common class of memory leak bug.

map transforms each emitted value. filter only lets through values genuinely matching a given condition. switchMap cancels a genuinely previous inner Observable and switches to a genuinely new one, commonly used for something like a search-as-you-type feature where only the genuinely most recent request actually matters.

Inject HttpClient, then call this.http.get('/api/users'), which returns an Observable that emits the genuine response once the actual request completes, typically subscribed to directly, or consumed through the async pipe within the template.

An interceptor intercepts genuinely every outgoing HTTP request (and incoming response) passing through HttpClient, letting you actually modify it centrally in one single place. A genuinely common use case is automatically attaching an authentication token's header to every single outgoing request, rather than manually adding it inside every genuinely individual service call.

The catchError RxJS operator, chained onto the Observable's own pipe, catches an error genuinely emitted by the HTTP request, letting you actually log it, transform it, or return a genuine fallback value instead of letting the error propagate uncaught and genuinely break the calling code.

Wrapping HTTP calls inside a genuinely dedicated service keeps that specific data-fetching logic reusable across multiple different components, and keeps components themselves focused specifically on presentation rather than being genuinely, directly responsible for handling raw HTTP concerns like URLs and headers.

switchMap cancels a genuinely previous inner Observable when a new one arrives, fitting a case like search-as-you-type where only the genuinely latest request actually matters. mergeMap runs every inner Observable genuinely concurrently, with no cancellation. concatMap runs them genuinely strictly one at a time, in order, waiting for each to actually complete before starting the next one.

combineLatest([obs1, obs2]) emits a genuinely combined value every time either source Observable actually emits, once both have genuinely emitted at least once. It's commonly used when a component genuinely depends on two independent, but related, streams of data at the exact same time.

A cold Observable genuinely starts producing values only when a subscriber actually subscribes, and each genuinely new subscriber typically gets its own genuinely independent, fresh sequence of values. A hot Observable produces values genuinely regardless of whether anyone is actually subscribed, and a genuinely new subscriber only sees values emitted after they actually joined.

The catchError operator can genuinely return a fallback Observable instead of letting the error propagate and terminate the stream entirely. The retry operator can also genuinely re-attempt the original source Observable a specified number of times before actually giving up and genuinely letting the error through.

A component subscribing to a genuinely long-lived Observable, but never actually unsubscribing when it's destroyed, keeps that subscription (and anything it genuinely references, including the component itself) alive indefinitely in memory. Using the async pipe, or explicitly unsubscribing in ngOnDestroy, or using the takeUntil pattern with a genuine destroy Subject, all prevent this specific class of leak.

Change detection is Angular's process of actually checking whether a component's own bound values have genuinely changed, and if so, actually updating the corresponding DOM to genuinely match. It's typically triggered by a genuine browser event, an HTTP response, or a timer, through a mechanism called Zone.js, which genuinely patches common async APIs to automatically notify Angular when something might have actually changed.

Default checks genuinely every single component in the entire tree on every single change detection cycle, regardless of whether anything within it actually changed. OnPush only genuinely re-checks a component when one of its own @Input() references actually changes, or when an event genuinely originates from within that component itself, which can meaningfully improve performance in a genuinely large application.

Angular DevTools' own Profiler shows exactly which components are genuinely being checked on each change detection cycle and how long each one actually takes. A component being re-checked genuinely far more often than it actually needs to be is a strong signal it might genuinely benefit from switching to the OnPush strategy.

Zone.js patches common asynchronous browser APIs, like setTimeout and event listeners, so Angular genuinely knows when an async operation has actually completed and might have changed something, automatically triggering a change detection cycle in response. Without Zone.js, Angular would have genuinely no automatic way of knowing when to actually re-check the application for changes at all.

OnPush checks whether an @Input()'s own reference has genuinely changed, not whether its internal contents have. Mutating an existing object or array in place leaves the genuine reference unchanged, so OnPush wouldn't actually detect that mutation at all, which is exactly why immutable update patterns are so commonly paired with OnPush.

Without trackBy, Angular genuinely, by default, tracks list items by object identity, so replacing an entire array with a genuinely new array of otherwise-identical items causes Angular to actually destroy and recreate every single DOM element unnecessarily. trackBy, keyed on a genuinely stable ID instead of raw object identity, lets Angular correctly recognize an item as genuinely the same one and reuse its existing DOM element.

NgRx is a Redux-inspired state management library for Angular, built on RxJS. It brings a genuinely single, immutable store, state genuinely changed only through dispatched actions and genuinely pure reducer functions, and Effects for genuinely handling side effects like an actual HTTP call cleanly, keeping them genuinely separate from the pure reducer logic itself.

Lazy loading defers loading a genuinely specific feature module's own code until a user actually navigates to a route requiring it, rather than shipping the entire application's genuinely full JavaScript bundle upfront on initial load. This meaningfully reduces initial load time, especially for a genuinely large application with many distinct feature areas most users won't actually visit on every single session.

In the routing configuration, use loadChildren pointing to a genuinely dynamic import of that specific feature module, like loadChildren: () => import('./admin/admin.module').then(m => m.AdminModule), which tells Angular to genuinely load that module's code only when a route actually within it is genuinely navigated to.

Ivy is Angular's own genuinely current compilation and rendering pipeline, introduced to genuinely improve bundle size (through better tree-shaking), compilation speed, and genuine debugging capability compared to the previous engine. It's genuinely been the default rendering engine in Angular for several major versions now.

Module Federation, a Webpack capability, lets genuinely separate Angular applications share code and be composed together at genuine runtime, without each one needing to be built and deployed as a genuinely single, monolithic bundle. This fits an organization where genuinely different, separate teams own genuinely different parts of a larger application independently.

I'd weigh the actual size and genuine complexity of the existing application, and whether Angular's own official ngUpgrade tooling can genuinely support a gradual, incremental migration, against the real cost and genuine risk of a full rewrite. A genuinely large, actively-used application usually favors an incremental migration path over a risky, disruptive full rewrite.

Using Angular's TestBed, configure a genuinely testing module with the component and its own actual dependencies (or mocks of them), create the component, and then genuinely assert on its actual rendered output or its class's own genuine behavior, typically using Jasmine or Jest as the underlying genuine test framework.

In the TestBed configuration's providers array, use { provide: RealService, useValue: mockServiceObject } to genuinely substitute a simplified mock object in place of the real service, letting the test genuinely control exactly what that dependency returns without needing the actual real service's genuine implementation at all.

A unit test verifies one genuinely specific component or service in isolation, typically with its dependencies mocked. An e2e test verifies genuinely complete user workflows through the fully running application, using a tool like Cypress or Playwright, simulating real genuine user interaction across multiple actual components and routes together.

Enable production mode (ng build --configuration production) to actually apply Ahead-of-Time compilation and tree-shaking automatically. Beyond that, lazy loading genuinely infrequently-used feature modules, and analyzing the bundle with a tool like webpack-bundle-analyzer to find and genuinely trim unexpectedly large dependencies, both meaningfully reduce the final bundle size.

AOT compiles Angular templates into genuinely efficient JavaScript during the actual build process itself, before the application is genuinely ever shipped to a browser. JIT compiles templates genuinely in the browser at runtime instead, which is slower for the actual end user and results in a genuinely larger bundle, since the compiler itself has to ship along with the application.

Organize the application into genuinely feature modules, each owning its own components, services, and routing, rather than one single, enormous, flat module containing genuinely everything. A genuinely shared module holds common, reusable components and directives used across multiple genuinely different feature modules.

Run it incrementally, using Angular's own official update schematics (ng update) wherever genuinely possible, leaning on existing test coverage to catch a genuine regression early, and migrating feature module by feature module rather than attempting one single, large, disruptive upgrade all at once. A full stop-everything migration is rarely something the business will actually tolerate.

I look at whether it's genuinely solving the real problem or just its symptom, whether state management is genuinely scoped sensibly rather than defaulting everything to a global store, and whether it's genuinely consistent with patterns already established elsewhere in the codebase. An inconsistent one-off pattern becomes a genuine maintenance burden the whole team inherits later.

Automate what can genuinely be automated, linting with ESLint, formatting, and Angular-specific style checks, enforced directly in CI so standards aren't purely a matter of individual opinion during manual code review. For architectural conventions that genuinely resist full automation, I'd document the handful of decisions that actually matter most, along with the real reasoning behind each one.

I'd weigh consistency across teams, easier for an engineer to genuinely move between projects, against the real cost of forcing NgRx's own real complexity onto a genuinely smaller application that would honestly be fine with simpler, service-based state. A shared, documented default with a genuine, sensible opt-out for smaller applications often works better than a genuinely rigid, one-size-fits-all mandate.

First check whether it correlates with device or browser differences, since a genuinely heavy change detection cycle or a large, unoptimized list rendering fine on a powerful desktop can genuinely block the main thread and freeze the page on a genuinely weaker mobile device. Real user monitoring, capturing actual performance data from genuinely real users, often reveals a genuinely different picture than a controlled local test alone.

A global ErrorHandler, implemented by extending Angular's own ErrorHandler class, catches genuinely unhandled errors application-wide, at minimum logging them for later visibility rather than letting them fail completely silently. Structuring the application so a genuine failure in one feature module doesn't necessarily crash genuinely unrelated parts of the page also matters.

Treat the library's actual exported public API, its component inputs and outputs, as a genuine contract with every consuming team. Adding a genuinely new optional input is generally safe. Changing or removing an existing one needs a documented deprecation period and direct communication with consuming teams well before removal.

I'd check first for an external dependency change, a third-party script or API the page genuinely depends on that may have changed or gone down entirely, since that's a genuinely common cause of exactly this kind of symptom with no corresponding code deploy of your own to blame. Browser console errors and error-monitoring tool reports from genuinely affected users usually point fairly directly at the actual specific failing piece.

Set and actually enforce a genuine performance budget, a defined maximum acceptable bundle size and load time, checked automatically in CI, rather than letting it silently and gradually creep up feature by feature with nobody deliberately deciding that trade-off. Regular bundle analysis catches an unexpectedly large new dependency before it ever actually ships to every single user.

This is a judgment question interviewers use to see how you reason under genuine uncertainty, not to test a specific textbook fact. A strong answer names the actual constraint that forced the decision, the realistic options that were genuinely on the table, why you picked one knowing it wasn't guaranteed to be right, and what you'd do differently with what you know now.

I'd walk through one of their actual components together, asking specifically which other parts of the application genuinely need that piece of state, and let them see firsthand that the honest answer is often just the one component itself. Seeing the actual, concrete answer to that question tends to change their instincts far more than a general rule about preferring local state.

I wouldn't push a full, disruptive rewrite of everything that already exists. I'd introduce reactive forms on a genuinely new, sufficiently complex form first, letting the team directly see the concrete benefit in testability and explicit control on something they already recognize, rather than mandating the change immediately across the entire existing codebase.

I'd bring concrete performance data or a working prototype demonstrating the actual trade-off, rather than a vague, unsubstantiated concern about difficulty. Often there's a version that gets most of the desired user experience with meaningfully less performance cost, and showing that concrete alternative resolves the disagreement faster than simply pushing back on the original ask.

I'd translate the performance work into terms leadership already tracks: a conversion or bounce-rate metric that correlates with load time, a specific competitor comparison, or a customer complaint pattern already tied to slowness. Framed as a business metric with a number attached, it competes far better for prioritization than framed as a technical improvement for its own sake.