Chapter 1: Angular Fundamentals & Core Concepts (v13-v21)

Introduction

Welcome to Chapter 1 of your comprehensive Angular interview preparation guide! This chapter is meticulously crafted to solidify your understanding of Angular’s foundational elements and core concepts, essential for any Angular developer role. Whether you’re targeting an entry-level position, a mid-level professional seeking to deepen your knowledge, or a senior developer refreshing your basics, a strong grasp of these fundamentals is non-negotiable.

We’ll dive into the building blocks of Angular applications, from components and modules to data binding, dependency injection, and the component lifecycle. Special attention will be paid to the evolution of these concepts across Angular versions 13 through 21, highlighting modern best practices and recent advancements like Standalone Components and Signals, which have significantly shaped Angular development in recent years.

By mastering the content in this chapter, you’ll be well-equipped to articulate complex Angular concepts clearly, demonstrate practical knowledge, and confidently answer theoretical and practical questions that form the bedrock of any Angular interview.

Core Interview Questions

1. What is Angular, and what are its key architectural components?

A: Angular is a powerful, open-source, TypeScript-based front-end web application framework developed by Google. It’s designed for building single-page applications (SPAs) and complex enterprise-grade web solutions. As of December 2025, Angular has evolved significantly, with version 21 being the latest stable release at the time of this guide’s creation, focusing on performance, developer experience, and a more reactive paradigm.

Its key architectural components include:

• Components: The fundamental building blocks of an Angular application, consisting of a TypeScript class, an HTML template, and CSS styles. They manage a specific part of the UI.
• Modules (NgModules): While Standalone Components are now the recommended default for new applications (stable since v15), NgModules historically organized components, services, and other code into cohesive blocks. They define compilation scope and dependency injection providers.
• Templates: HTML views that define what renders on the page. They use Angular’s template syntax for data binding, directives, and more.
• Data Binding: A mechanism that synchronizes data between the component’s TypeScript logic and its HTML template.
• Directives: Classes that add additional behavior to elements in Angular templates. They come in three types: Components (directives with a template), Structural Directives (change the DOM layout), and Attribute Directives (change the appearance or behavior of an element).
• Services: Singleton classes used to encapsulate logic that isn’t directly tied to a view, such as data fetching, logging, or business logic. They are designed for dependency injection.
• Dependency Injection (DI): A core design pattern used to provide instances of dependencies (like services) to classes (like components) rather than having the class create them. This promotes modularity and testability.
• Routers: Manage navigation between different views (components) within an SPA, mapping URLs to components.
• Pipes: Used to transform data in templates before it is displayed (e.g., formatting dates, currencies).

Key Points:

• TypeScript-based, Google-maintained, focused on SPAs.
• Components are central; Standalone Components are the modern default.
• Strong emphasis on modularity, testability, and maintainability through DI and services.
• Continuous evolution (v13-v21) bringing performance and DX improvements.

Common Mistakes:

• Confusing Angular with AngularJS (the original framework).
• Not being able to name more than 2-3 core components.
• Misunderstanding the role of TypeScript in Angular.

Follow-up:

• How has the introduction of Standalone Components (Angular v14 stable in v15) impacted the traditional use of NgModules?
• Can you explain the advantages of using TypeScript in Angular?

2. Explain the Angular Component Lifecycle. List and describe the most commonly used lifecycle hooks.

A: An Angular component instance has a lifecycle that Angular manages. Angular creates it, renders it, creates and renders its children, checks it when its data-bound properties change, and destroys it before removing it from the DOM. Angular provides lifecycle hook methods that you can tap into to perform actions at specific points in this lifecycle.

The most commonly used lifecycle hooks are:

• ngOnChanges(): Called before ngOnInit() and whenever one or more data-bound input properties change. Receives a SimpleChanges object containing current and previous property values.
• ngOnInit(): Called once, after the first ngOnChanges() and after Angular has initialized all data-bound properties of a directive or component. It’s the preferred place to perform initialization logic, such as data fetching.
• ngDoCheck(): Called during every change detection run, immediately after ngOnChanges() and ngOnInit(). Useful for implementing custom change detection logic or detecting changes not caught by Angular’s default mechanism.
• ngAfterContentInit(): Called once after Angular projects external content into the component’s view.
• ngAfterContentChecked(): Called after ngAfterContentInit() and every subsequent ngDoCheck(), checking the projected content.
• ngAfterViewInit(): Called once after Angular initializes the component’s view and child views. It’s the preferred place to interact with child components and DOM elements queried with @ViewChild or @ViewChildren.
• ngAfterViewChecked(): Called after ngAfterViewInit() and every subsequent ngDoCheck(), checking the component’s view and child views.
• ngOnDestroy(): Called just before Angular destroys the component. This is the place to perform cleanup, such as unsubscribing from Observables, detaching event handlers, and preventing memory leaks.

Key Points:

• Angular manages the component’s lifecycle.
• Hooks allow custom logic at specific stages.
• ngOnInit for initial setup, ngOnDestroy for cleanup.
• Understand the order and purpose of ngOnChanges, ngOnInit, ngDoCheck, ngAfterViewInit, ngOnDestroy.

Common Mistakes:

• Performing complex logic in the constructor instead of ngOnInit.
• Forgetting to unsubscribe from Observables in ngOnDestroy, leading to memory leaks.
• Misunderstanding the difference between ngAfterContentInit and ngAfterViewInit.

Follow-up:

• When would you use ngDoCheck() over ngOnChanges()?
• How do lifecycle hooks interact with OnPush change detection strategy?

3. Describe the different types of Data Binding in Angular. Provide an example for each.

A: Data binding is a mechanism that allows communication between the component’s TypeScript logic and its HTML template. Angular supports four main types of data binding:

1. Interpolation ({{ }}): One-way data binding from component to view. Displays a component property’s value within the template.

   • Example:

     <p>Welcome, {{ userName }}!</p>
     

     // component.ts
     userName = 'Alice';
     

2. Property Binding ([ ]): One-way data binding from component to view. Binds a component property to an HTML element’s property.

   • Example:

     <img [src]="profileImageUrl" [alt]="userName">
     <button [disabled]="isButtonDisabled">Click Me</button>
     

     // component.ts
     profileImageUrl = 'assets/avatar.png';
     isButtonDisabled = true;
     

3. Event Binding (( )): One-way data binding from view to component. Listens for events (like click, input, submit) on HTML elements and executes a component method when the event occurs.

   • Example:

     <button (click)="saveData()">Save</button>
     <input (input)="onInputChange($event)">
     

     // component.ts
     saveData() { /* ... */ }
     onInputChange(event: Event) { console.log((event.target as HTMLInputElement).value); }
     

4. Two-way Data Binding ([( )] - ngModel): Combines property binding and event binding, allowing data to flow both ways between component and view. Changes in the component update the view, and changes in the view update the component. Primarily used with form elements via ngModel (requires FormsModule or ReactiveFormsModule).

   • Example:

     <input [(ngModel)]="searchQuery">
     <p>Search Query: {{ searchQuery }}</p>
     

     // component.ts
     searchQuery: string = '';
     

Key Points:

• Understand the direction of data flow for each type.
• Interpolation and Property Binding: component -> view.
• Event Binding: view -> component.
• Two-way Binding (ngModel): component <-> view.

Common Mistakes:

• Using interpolation for properties that should be bound (e.g., <img src="{{ url }}"> instead of <img [src]="url">).
• Forgetting to import FormsModule when using ngModel for two-way binding.
• Confusing property binding with attribute binding (though Angular handles most attribute-to-property mapping automatically).

Follow-up:

• What are the security implications of using innerHTML with interpolation? How can you mitigate them?
• When would you prefer one-way binding over two-way binding?

4. Explain Dependency Injection (DI) in Angular. How does it promote better code organization and testability?

A: Dependency Injection (DI) is a core design pattern and mechanism in Angular used to provide instances of dependencies (objects or services) to a class (e.g., a component, service, or directive) rather than having the class create them itself. This decouples the class from its dependencies.

In Angular, DI works via:

1. Providers: Tell Angular how to create an instance of a dependency. Providers are typically configured in @Injectable() decorators (providedIn: 'root'), NgModules, or directly within @Component() decorators for component-specific services.
2. Injectors: Angular’s DI system has a hierarchical tree of injectors. When a component or service requests a dependency, its injector tries to resolve it. If it can’t, it passes the request up to its parent injector until it finds a provider or fails.
3. Consumption: Classes declare their dependencies in their constructor parameters, and Angular’s DI system automatically supplies the required instances.

Benefits:

• Modularity & Decoupling: Components and services are not responsible for creating their dependencies, making them more independent and easier to reuse.
• Testability: During testing, you can easily swap real service implementations with mock or fake versions, isolating the unit under test.
• Maintainability: Changes to a dependency’s implementation don’t require changes to the consuming classes, as long as the interface remains the same.
• Scalability: Allows for easier management of complex applications with many interconnected parts.

Key Points:

• A design pattern where classes declare dependencies instead of creating them.
• Promotes loose coupling, reusability, and testability.
• Uses providers to configure how dependencies are created and injectors to resolve them.
• @Injectable() decorator with providedIn: 'root' is the modern standard for application-wide singletons.

Common Mistakes:

• Creating service instances directly using new operator inside components.
• Forgetting to provide a service, leading to runtime errors.
• Misunderstanding the hierarchical nature of injectors and how it affects service scope.

Follow-up:

• What is the difference between providedIn: 'root' and providing a service in an NgModule or a component’s providers array?
• How would you mock a service for unit testing a component that uses it?

5. What are Angular Services, and why are they used?

A: An Angular Service is a singleton class that contains business logic, data fetching operations, or any functionality that needs to be shared across multiple components, directives, or other services. Services are typically decorated with @Injectable(), which marks them as a class that can be injected into other classes.

Why they are used:

• Separation of Concerns: Services help keep components lean and focused solely on presenting data and handling user interactions. Business logic, data persistence, and utility functions are delegated to services.
• Code Reusability: A single service can be injected and used by multiple components, preventing code duplication.
• Data Sharing: Services can hold and manage application state or data, allowing different parts of the application to access and modify the same data consistently. This is particularly useful for cross-component communication.
• Testability: Because services are injected, they can be easily mocked or replaced during testing, making components and other services easier to unit test in isolation.
• Maintainability: Centralizing logic in services makes the application easier to understand, debug, and maintain.

Key Points:

• Singleton classes for shared logic and data.
• Decorated with @Injectable().
• Promote separation of concerns, reusability, and testability.
• Often used for HTTP requests, logging, and state management.

Common Mistakes:

• Putting complex business logic directly into components.
• Creating a new instance of a service in every component that needs it, rather than injecting it.
• Using services for UI-specific logic that should reside in a component.

Follow-up:

• How do you make an Angular service available throughout your application?
• Can a service inject another service? Provide an example.

6. Differentiate between Structural and Attribute Directives, providing examples of each.

A: Directives are classes that add additional behavior to elements in Angular templates. They are categorized into three types: components (directives with a template), structural directives, and attribute directives.

1. Structural Directives:

   • Purpose: Change the DOM layout by adding, removing, or manipulating elements and their sub-trees. They fundamentally alter the structure of the DOM.
   • Syntax: Always prefixed with an asterisk (*). This is syntactic sugar for a <ng-template> element.
   • Examples:
     • *ngIf (Angular v13-v17+): Conditionally adds or removes an element from the DOM.

       <div *ngIf="isLoggedIn">Welcome, User!</div>
       

     • *ngFor (Angular v13-v17+): Repeats a given element for each item in a collection.

       <ul>
         <li *ngFor="let item of items">{{ item }}</li>
       </ul>
       

     • *ngSwitch (Angular v13-v17+): Conditionally renders elements based on a switch value.

       <div [ngSwitch]="status">
         <span *ngSwitchCase="'active'">Active</span>
         <span *ngSwitchCase="'inactive'">Inactive</span>
         <span *ngSwitchDefault>Unknown</span>
       </div>
       

     • @if, @for, @switch (Angular v17+): The new built-in control flow syntax replaces the need for *ngIf, *ngFor, *ngSwitch directives for improved performance and developer experience.

       @if (isLoggedIn) {
         <div>Welcome, User!</div>
       }
       @for (item of items; track item.id) {
         <li>{{ item }}</li>
       }
       @switch (status) {
         @case ('active') { <span>Active</span> }
         @case ('inactive') { <span>Inactive</span> }
         @default { <span>Unknown</span> }
       }
       

2. Attribute Directives:

   • Purpose: Change the appearance or behavior of an existing element, component, or another directive. They do not add or remove elements from the DOM.
   • Syntax: Applied as attributes on host elements.
   • Examples:
     • *ngClass: Adds or removes CSS classes conditionally.

       <div [ngClass]="{'highlight': isActive, 'error': hasError}">Content</div>
       

     • *ngStyle: Applies inline CSS styles conditionally.

       <p [ngStyle]="{'color': textColor, 'font-size.px': fontSize}">Styled Text</p>
       

     • Custom Attribute Directive:

       <input appHighlight="yellow">
       

Key Points:

• Structural: * prefix (or new @ syntax v17+), changes DOM structure.
• Attribute: No * prefix, changes element appearance/behavior.
• *ngIf, *ngFor (old) vs. @if, @for (new v17+).

Common Mistakes:

• Trying to use *ngIf without the asterisk.
• Confusing the purpose of ngClass (classes) and ngStyle (styles).
• Not understanding that structural directives manipulate the <ng-template> behind the scenes.

Follow-up:

• How would you create a custom structural directive? What about an attribute directive?
• What are the performance benefits of the new built-in control flow (@if, @for) introduced in Angular v17?

7. What is Change Detection in Angular, and what are the two main strategies?

A: Change Detection is the mechanism Angular uses to synchronize the application’s state with its UI. When data changes (e.g., a user input, an HTTP response, a timer event), Angular detects these changes and re-renders the affected parts of the DOM to reflect the new state. This process is highly optimized.

Angular provides two main change detection strategies:

1. Default (or CheckAlways) Strategy:

   • Behavior: Angular checks every component in the component tree during every change detection cycle, regardless of whether its input properties have changed.
   • Mechanism: It relies on Zones.js (specifically NgZone) to patch asynchronous browser APIs (like setTimeout, addEventListener, XHR) and notify Angular whenever an asynchronous operation completes. This triggers a change detection cycle from the root of the application.
   • Use Case: Simplest to use, suitable for most small to medium applications, or when fine-grained control isn’t necessary.

2. OnPush Strategy:

   • Behavior: Angular only runs change detection for a component (and its sub-tree) if one of the following occurs:
     • An input property of the component changes, and the new value is a different object reference (shallow comparison).
     • An event originated from the component or one of its children (e.g., a click event).
     • async pipe emits a new value in the component’s template.
     • Change detection is explicitly triggered using ChangeDetectorRef methods (markForCheck() or detectChanges()).
   • Mechanism: OnPush components expect immutable data. If an input property is mutated (e.g., modifying an object’s property directly instead of replacing the object), OnPush won’t detect the change unless explicitly told to.
   • Use Case: Highly recommended for large applications to improve performance by reducing the number of checks performed, especially when dealing with large component trees or frequently updated data.

Key Points:

• Synchronizes app state with UI.
• Default: Checks everything, triggered by NgZone events.
• OnPush: Checks only if inputs change (by reference), events occur, or explicitly marked.
• OnPush requires immutable data for optimal performance.

Common Mistakes:

• Using OnPush without ensuring immutability for input properties, leading to missed updates.
• Not understanding that OnPush still checks the component if an event originates from within it.
• Overusing markForCheck() or detectChanges() when OnPush is not strictly necessary, potentially negating performance benefits.

Follow-up:

• When would you choose OnPush over the Default strategy?
• How do Angular Signals (v16+) impact or potentially simplify change detection?

8. What are Angular Pipes, and how are they used? Can you create a custom pipe?

A: Angular Pipes are simple functions that allow you to transform data in your templates before displaying it to the user. They are used to format data for display, such as dates, currencies, text cases, and more. Pipes are applied using the pipe (|) operator in templates.

How they are used:

<p>Current Date: {{ currentDate | date:'fullDate' }}</p>
<p>Price: {{ productPrice | currency:'USD':'symbol':'1.2-2' }}</p>
<p>Welcome: {{ 'hello world' | uppercase }}</p>

Creating a Custom Pipe: You can create custom pipes by implementing the PipeTransform interface.

1. Generate the pipe:

   ng generate pipe my-custom
   

2. Implement the pipe logic:

   // src/app/pipes/my-custom.pipe.ts
   import { Pipe, PipeTransform } from '@angular/core';
   
   @Pipe({
     name: 'myCustom',
     // pure: true // Default. Set to false for impure pipes.
     standalone: true // For Angular v14+ standalone components/pipes
   })
   export class MyCustomPipe implements PipeTransform {
     transform(value: string, prefix: string = 'Hello'): string {
       if (!value) {
         return '';
       }
       return `${prefix}, ${value}!`;
     }
   }
   

3. Use the custom pipe in a template:

   • If standalone: standalone: true (Angular v14+):

     // component.ts
     import { MyCustomPipe } from './pipes/my-custom.pipe';
     
     @Component({
       standalone: true, // If component is standalone
       selector: 'app-my-component',
       template: `
         <p>{{ 'World' | myCustom }}</p>
         <p>{{ 'Angular' | myCustom:'Greetings' }}</p>
       `,
       imports: [MyCustomPipe] // Import directly
     })
     export class MyComponent {}
     

   • If not standalone (traditional NgModule):

     // app.module.ts
     import { MyCustomPipe } from './pipes/my-custom.pipe';
     
     @NgModule({
       declarations: [
         // ... other components/directives
         MyCustomPipe // Declare the pipe
       ],
       exports: [MyCustomPipe] // Export if used in other modules
       // ...
     })
     export class AppModule { }
     

     <!-- component.html -->
     <p>{{ 'World' | myCustom }}</p>
     <p>{{ 'Angular' | myCustom:'Greetings' }}</p>
     

Pure vs. Impure Pipes:

• Pure Pipes (default): Only re-execute if their input values change (shallow comparison for objects/arrays). They are efficient.
• Impure Pipes (pure: false): Re-execute during every change detection cycle, regardless of input changes. Use with caution as they can impact performance. Examples include AsyncPipe and JsonPipe.

Key Points:

• Transform data for display in templates.
• Applied with | operator.
• Custom pipes implement PipeTransform.
• Understand pure vs. impure pipes and their performance implications.
• Standalone pipes (v14+) are imported directly into standalone components.

Common Mistakes:

• Forgetting to declare/import a custom pipe.
• Creating an impure pipe when a pure one would suffice, leading to performance issues.
• Putting complex logic in a pipe that should belong in a service or component method.

Follow-up:

• When would you use an impure pipe? Can you give an example?
• What are the benefits of using pipes over component methods for data transformation in templates?

9. What are Standalone Components, and what problem do they solve? (Angular v14+)

A: Standalone Components (stable since Angular v15, introduced in v14) are a significant feature that allows developers to build Angular applications without the need for NgModules. A standalone component, directive, or pipe can manage its own dependencies (other components, directives, pipes) by directly importing them via its imports array within its @Component() decorator.

Problem Solved: Historically, every component, directive, and pipe in Angular had to belong to an NgModule. While NgModules provide a powerful way to organize code, they also introduced:

• Boilerplate: Even for simple applications, developers needed to create NgModules, declare components, and import other modules, adding overhead.
• Learning Curve: The concept of NgModules could be confusing for newcomers, especially regarding declarations, imports, and exports.
• Bundle Size: Though optimized, NgModules could sometimes contribute to larger bundle sizes due to their broader scope, especially in lazy-loaded scenarios.
• Tree-shaking limitations: While Ivy improved tree-shaking, NgModules still defined a compilation context that could sometimes prevent optimal removal of unused code.

Standalone components simplify the Angular development experience by:

• Reducing Boilerplate: No need for NgModules for individual components.
• Improved Developer Experience: Easier to reason about dependencies as they are declared directly where they are used.
• Better Tree-shaking: The compiler can more accurately identify and remove unused code, potentially leading to smaller bundles.
• Streamlined Learning: Makes Angular more accessible by removing a core concept that was often a hurdle.

While NgModules are not deprecated and remain fully supported, Standalone Components are the recommended default for new applications and are becoming the preferred way to build Angular applications as of Angular v21.

Key Points:

• Stable since Angular v15 (introduced v14).
• Allows components, directives, and pipes to be self-contained.
• Removes the need for NgModules for individual units.
• Simplifies development, reduces boilerplate, improves tree-shaking, and enhances developer experience.

Common Mistakes:

• Thinking NgModules are deprecated or removed; they are still supported.
• Forgetting to import necessary standalone dependencies (components, pipes, directives) into the imports array of a standalone component.
• Not understanding the benefits beyond just “less code.”

Follow-up:

• How would you migrate an existing NgModule-based application to use Standalone Components?
• Can a standalone component and an NgModule-based component coexist in the same application?

10. Explain the concept of Signals in Angular (v16+). How do they differ from RxJS Observables for reactivity?

A: Angular Signals (stable in v17, introduced in v16 as developer preview) are a new reactive primitive that provides a simple, efficient, and granular way to manage state and react to changes in an Angular application. They are designed to be a core part of Angular’s reactivity model, offering a more explicit and less error-prone way to handle reactivity compared to traditional RxJS streams for local component state.

Core Concepts of Signals:

• signal(): A function that creates a writable signal, which holds a value that can be read and updated.

  import { signal } from '@angular/core';
  const count = signal(0);
  count.set(1); // Update value
  const currentCount = count(); // Read value
  

• computed(): Creates a read-only signal that derives its value from other signals. It automatically re-evaluates only when its dependencies change, and its value is cached.

  import { signal, computed } from '@angular/core';
  const firstName = signal('John');
  const lastName = signal('Doe');
  const fullName = computed(() => `${firstName()} ${lastName()}`);
  console.log(fullName()); // "John Doe"
  firstName.set('Jane');
  console.log(fullName()); // "Jane Doe" (re-evaluated)
  

• effect(): Registers a side-effect that runs whenever the signals it reads change. Useful for logging, DOM manipulations, or interacting with non-Angular code.

  import { signal, effect } from '@angular/core';
  const counter = signal(0);
  effect(() => console.log(`Current count is: ${counter()}`));
  counter.set(1); // Logs "Current count is: 1"
  

Signals vs. RxJS Observables:

Key Points:

• New reactive primitive (v16+, stable v17+), designed for state management.
• signal(), computed(), effect() are core functions.
• Pull-based (Signals) vs. Push-based (Observables).
• Signals are for synchronous, granular state, Observables for asynchronous streams.
• They are complementary, not replacements; often used together.

Common Mistakes:

• Thinking Signals completely replace RxJS; they are complementary.
• Trying to use Signals for complex asynchronous data flows that are better suited for Observables.
• Forgetting to call the signal function (mySignal()) to read its value.

Follow-up:

• How do Signals contribute to better performance in Angular applications?
• When would you still prefer using RxJS Observables over Signals in an Angular application?

11. What is the purpose of NgZone in Angular, and how does it relate to change detection?

A: NgZone is an Angular wrapper around Zone.js, a library that patches asynchronous browser APIs (like setTimeout, setInterval, XMLHttpRequest, Promise, EventTarget). Its primary purpose is to detect when asynchronous operations, which occur outside of Angular’s direct control, have completed.

Purpose and Relation to Change Detection:

1. Change Detection Trigger: In the Default change detection strategy, NgZone acts as the primary trigger. After any asynchronous operation patched by Zone.js completes (e.g., an HTTP response arrives, a button click event fires, a setTimeout callback executes), NgZone notifies Angular that a potential change has occurred.
2. Running Code “Inside” or “Outside” Angular Zone:
   • Inside NgZone: By default, all Angular application code runs inside the Angular zone. When an async operation completes within this zone, Angular automatically triggers a change detection cycle.
   • Outside NgZone: For performance-critical operations that don’t need to trigger change detection (e.g., frequent third-party library callbacks, complex animations), you can run code outside the Angular zone using NgZone.runOutsideAngular(). This prevents unnecessary change detection cycles, improving performance. If a change needs to be reflected in the UI after such an operation, you can manually re-enter the zone or trigger change detection using ChangeDetectorRef.

Key Points:

• Angular’s wrapper around Zone.js.
• Patches async browser APIs.
• Automatically triggers change detection after async operations complete (in Default strategy).
• runOutsideAngular() for performance optimization.

Common Mistakes:

• Not understanding why async operations automatically trigger UI updates in Angular.
• Misusing runOutsideAngular() without a clear performance benefit or not manually triggering CD when needed.
• Confusing NgZone with ChangeDetectorRef.

Follow-up:

• Can you describe a scenario where you would explicitly run code outside the Angular zone?
• How might the increasing adoption of Signals and more explicit reactivity affect the future role of NgZone? (As of v21, NgZone is still central, but future versions might see more fine-grained control outside it with Signals).

12. Explain the purpose of async pipe and trackBy function in Angular.

A:

1. async Pipe:

   • Purpose: The async pipe (| async) is a powerful built-in pipe that automatically subscribes to an Observable or Promise and unwraps its emitted values. When the component is destroyed, it automatically unsubscribes, preventing memory leaks.
   • Benefits:
     • Automatic Subscription/Unsubscription: Simplifies reactive programming in templates by handling the subscription and unsubscription lifecycle.
     • Memory Leak Prevention: Ensures resources are properly released when the component is destroyed.
     • Change Detection Optimization: Works well with OnPush change detection strategy because it emits new values, signaling Angular to check for changes.
   • Example:

     <div *ngIf="data$ | async as data">
       <p>Data loaded: {{ data }}</p>
     </div>
     

     // component.ts
     import { Observable, of } from 'rxjs';
     data$: Observable<string> = of('Hello from Observable!');
     

2. trackBy Function (*ngFor / @for):

   • Purpose: Used with structural directives like *ngFor (and the new @for control flow in v17+) to provide a unique identifier for each item in a list. When the list changes (items are added, removed, or reordered), Angular uses the trackBy function to determine which items correspond to which elements.
   • Benefits:
     • Performance Optimization: Without trackBy, Angular re-renders the entire DOM subtree for all items whenever the list changes, even if only a few items were modified. With trackBy, Angular can efficiently add, remove, or reorder only the DOM elements that correspond to the changed items, significantly improving performance, especially for large lists.
     • State Preservation: Helps preserve the state of child components or DOM elements that remain in the list (e.g., input field values, scroll positions).
   • Example (*ngFor):

     <ul>
       <li *ngFor="let user of users; trackBy: trackByUserFn">
         {{ user.name }}
       </li>
     </ul>
     

     // component.ts
     users = [{ id: 1, name: 'Alice' }, { id: 2, name: 'Bob' }];
     trackByUserFn(index: number, user: any): number {
       return user.id; // Return a unique identifier
     }
     

   • Example (@for v17+):

     <ul>
       @for (user of users; track user.id) {
         <li>{{ user.name }}</li>
       }
     </ul>
     

Key Points:

• async pipe: auto-subscribes/unsubscribes to Observables/Promises in templates; prevents memory leaks.
• trackBy: used with *ngFor or @for to optimize list rendering and preserve element state; requires a unique identifier.

Common Mistakes:

• Forgetting to use async pipe with Observables in templates, leading to memory leaks and no UI updates.
• Not using trackBy for large, dynamic lists, resulting in poor performance.
• Providing a trackBy function that doesn’t return a truly unique identifier.

Follow-up:

• Can you explain why trackBy is particularly important for performance in applications with frequently updated lists?
• How does the async pipe work with OnPush change detection?

MCQ Section

Instructions: Choose the best answer for each question.

1. Which Angular lifecycle hook is called only once after all data-bound properties are initialized? A) ngOnChanges() B) ngDoCheck() C) ngOnInit() D) ngAfterViewInit()

Correct Answer: C Explanation:

• A) ngOnChanges(): Called whenever one or more data-bound input properties change. Can be called multiple times.
• B) ngDoCheck(): Called during every change detection run. Can be called multiple times.
• C) ngOnInit(): Called once after the first ngOnChanges() and after Angular has initialized all data-bound properties. It’s the standard for initialization logic.
• D) ngAfterViewInit(): Called once after Angular initializes the component’s view and child views.

2. Which of the following is an example of Property Binding in Angular? A) {{ userName }} B) (click)="submitForm()" C) [src]="imageUrl" D) [(ngModel)]="searchQuery"

Correct Answer: C Explanation:

• A) {{ userName }}: Interpolation (one-way, component to view).
• B) (click)="submitForm()": Event Binding (one-way, view to component).
• C) [src]="imageUrl": Property Binding (one-way, component to view), binding the src property of an <img> element.
• D) [(ngModel)]="searchQuery": Two-way Data Binding.

3. What is the primary benefit of using Dependency Injection in Angular? A) To reduce the amount of HTML in templates. B) To make components responsible for creating their own dependencies. C) To promote loose coupling and enhance testability. D) To speed up initial application load time.

Correct Answer: C Explanation:

• A) To reduce the amount of HTML in templates: Not a primary benefit of DI; that’s more about template syntax or component design.
• B) To make components responsible for creating their own dependencies: This is the opposite of DI; DI removes this responsibility from components.
• C) To promote loose coupling and enhance testability: DI allows components to declare dependencies without knowing how to create them, leading to decoupled, testable code.
• D) To speed up initial application load time: While DI can contribute to a well-structured app, it’s not its primary role in load time optimization.

4. Which type of directive is used to add or remove elements from the DOM? A) Attribute Directive B) Component Directive C) Structural Directive D) Custom Directive

Correct Answer: C Explanation:

• A) Attribute Directive: Changes the appearance or behavior of an element (e.g., ngClass, ngStyle).
• B) Component Directive: A directive with a template (i.e., a component itself).
• C) Structural Directive: Changes the DOM layout by adding, removing, or manipulating elements (e.g., *ngIf, *ngFor, @if v17+).
• D) Custom Directive: Can be either structural or attribute, but “structural” is the specific type.

5. In Angular v17, what is the modern equivalent for *ngFor that offers improved performance and developer experience? A) *ngEach B) @for C) ng-repeat D) forEach

Correct Answer: B Explanation:

• A) *ngEach: Does not exist in Angular.
• B) @for: Angular v17 introduced new built-in control flow syntax, including @for, to replace directives like *ngFor.
• C) ng-repeat: An AngularJS (legacy) directive, not Angular.
• D) forEach: A JavaScript array method, not an Angular template syntax.

6. When using OnPush change detection, under which condition will a component NOT detect changes to an input property data? A) An event originates from the component. B) The data input property is mutated (e.g., component.data.property = 'new'). C) The data input property is reassigned to a new object reference (e.g., component.data = { ...oldData, property: 'new' }). D) ChangeDetectorRef.markForCheck() is called for the component.

Correct Answer: B Explanation:

• A) An event originates from the component: This will trigger change detection for OnPush components.
• B) The data input property is mutated: OnPush relies on shallow comparison. If the object reference itself doesn’t change, Angular won’t detect the mutation. This is a common pitfall.
• C) The data input property is reassigned to a new object reference: This will trigger change detection for OnPush components because the reference has changed.
• D) ChangeDetectorRef.markForCheck() is called for the component: Explicitly tells Angular to check the component.

7. What is the primary benefit of the async pipe in Angular templates? A) To perform complex data transformations. B) To automatically subscribe to Observables/Promises and unsubscribe on destruction. C) To improve the performance of *ngFor loops. D) To enable two-way data binding.

Correct Answer: B Explanation:

• A) To perform complex data transformations: While pipes transform, async pipe’s primary role is subscription management, not complex data logic.
• B) To automatically subscribe to Observables/Promises and unsubscribe on destruction: This is the key benefit, preventing memory leaks and simplifying reactive UI.
• C) To improve the performance of *ngFor loops: That’s the role of trackBy.
• D) To enable two-way data binding: That’s the role of ngModel.

8. Which of the following is TRUE about Standalone Components (Angular v15+)? A) They completely deprecate and remove NgModules. B) They require a new special syntax to define input and output properties. C) They manage their own dependencies by directly importing them via the imports array in @Component(). D) They can only be used in new Angular projects, not existing ones.

Correct Answer: C Explanation:

• A) They completely deprecate and remove NgModules: False. NgModules are still fully supported and widely used.
• B) They require a new special syntax to define input and output properties: False. Inputs/Outputs (@Input(), @Output()) work the same way.
• C) They manage their own dependencies by directly importing them via the imports array in @Component(): True. This is the core mechanism that removes the need for NgModules for individual components.
• D) They can only be used in new Angular projects, not existing ones: False. They can be gradually adopted in existing projects.

Mock Interview Scenario: User Profile Editor

Scenario Setup: You are interviewing for a Mid-Level Angular Developer position. The interviewer wants to assess your understanding of fundamental Angular concepts by having you discuss a common UI task: building a user profile editor component.

Interviewer: “Imagine you need to create a UserProfileEditorComponent. This component will display a user’s name and email, and allow them to edit these fields. It should also have a ‘Save’ button. When saved, the updated user data should be sent to a backend service. Let’s walk through how you would approach this.”

Expected Flow of Conversation:

Interviewer Question 1: “Okay, let’s start with the basics. How would you structure this UserProfileEditorComponent? What would be its main parts?”

• Candidate’s Expected Answer: I’d define a component using @Component decorator. It would have a TypeScript class (UserProfileEditorComponent) to hold the user data and logic, an HTML template (user-profile-editor.component.html) for the UI, and a CSS file (user-profile-editor.component.css) for styling. The user data would be a property in the TypeScript class, perhaps an interface like User { id: number; name: string; email: string; }.

Interviewer Question 2: “Good. Now, how would you get the initial user data into this component from a parent component (e.g., a DashboardComponent)? And how would you display the name and email fields in the template for editing?”

• Candidate’s Expected Answer: I would use an @Input() decorator to pass the User object from the parent component into UserProfileEditorComponent.
  • Parent: <app-user-profile-editor [user]="currentUser"></app-user-profile-editor>
  • Child: @Input() user!: User;
• For displaying and editing, I’d use two-way data binding with [(ngModel)] on <input> elements.
  • <input type="text" [(ngModel)]="user.name" name="userName">
  • <input type="email" [(ngModel)]="user.email" name="userEmail">
  • (Mentioning FormsModule import if not using Standalone components, or ensuring it’s imported in a standalone component’s imports array).

Interviewer Question 3: “Excellent. Now, when the user clicks the ‘Save’ button, we need to send this updated data to a backend. How would you handle the ‘Save’ button click and then communicate with a backend API? Where would the logic for API calls reside?”

• Candidate’s Expected Answer: I’d use event binding to handle the ‘Save’ button click: <button (click)="onSave()">Save</button>.
• The actual logic for making the API call would reside in a dedicated Angular Service, say UserService. I would inject this UserService into my UserProfileEditorComponent’s constructor using Dependency Injection.
• The onSave() method in the component would then call a method on the UserService (e.g., userService.updateUser(this.user)), which would use Angular’s HttpClient to send a PUT or POST request to the backend. I would handle the Observable returned by HttpClient by subscribing to it in onSave().

Interviewer Question 4: “Good. What if the parent component needs to know that the user profile has been successfully saved, perhaps to display a success message or refresh a list? How would you communicate this event back to the parent?”

• Candidate’s Expected Answer: I would use an @Output() decorator with an EventEmitter.
  • In UserProfileEditorComponent: @Output() userSaved = new EventEmitter<User>();
  • After a successful save in onSave() method: this.userSaved.emit(this.user);
  • In the parent component’s template: <app-user-profile-editor [user]="currentUser" (userSaved)="handleUserSaved($event)"></app-user-profile-editor>
  • The handleUserSaved method in the parent would then receive the updated user object.

Interviewer Question 5: “Finally, considering performance, if this UserProfileEditorComponent is part of a larger application with many components, what change detection strategy might you consider for it, and why?”

• Candidate’s Expected Answer: I would strongly consider using the OnPush change detection strategy for UserProfileEditorComponent.
• Why: Because the user input is an object, and OnPush would only re-render the component if the user object reference itself changes, or if an event originates from within the component. This prevents unnecessary checks if other parts of the application change but the user object passed to this component remains the same reference. This improves performance by reducing the number of change detection cycles. I’d also ensure that when the parent updates the user, it passes a new object reference (e.g., this.currentUser = { ...this.currentUser, name: 'New Name' }) to trigger OnPush correctly.

Red Flags to Avoid:

• Mixing Angular and AngularJS concepts: Referring to ng-model instead of [(ngModel)], or scope.
• Putting all logic in the component: Not suggesting services for backend calls.
• Forgetting @Input()/@Output(): Using direct parent-child communication or localStorage.
• Ignoring memory leaks: Not mentioning unsubscribing from Observables manually (though async pipe handles it in templates).
• No mention of DI: Creating services with new keyword.
• Poor explanation of OnPush: Not explaining the importance of immutability.

Practical Tips

1. Master the Official Docs: The Angular documentation (angular.dev) is your authoritative source. Stay updated with the latest versions (v13-v21) and new features like Standalone Components, Signals, and the new control flow.
2. Practice, Practice, Practice: Build small Angular applications or components focusing on one concept at a time. Create a simple component, pass data with @Input, emit events with @Output, fetch data with a service, apply a custom pipe.
3. Understand “Why”: Don’t just memorize definitions. Understand why Angular uses Dependency Injection, why lifecycle hooks exist, or why OnPush improves performance. This allows you to answer follow-up questions effectively.
4. Hands-on with CLI: Be proficient with the Angular CLI (ng new, ng generate component, ng generate service, ng build, ng test).
5. Review Core Concepts Regularly: Even senior developers benefit from refreshing their understanding of components, modules, services, directives, pipes, routing, and change detection. These are the bedrock.
6. Be Ready for Version-Specific Questions: While fundamentals remain, be aware of key advancements from Angular v13 (Ivy only) through v21 (Standalone, Signals, new control flow). Know when these features became stable and their impact.
7. Explain Your Thought Process: During a mock interview, verbalize your approach. If you’re unsure, explain what you know and how you would find the answer.

Summary

This chapter has provided a robust foundation for tackling Angular interview questions related to core concepts and fundamentals, with a focus on versions 13 through 21. We’ve covered the essential building blocks: components, lifecycle hooks, various data binding techniques, the power of Dependency Injection and services, the role of directives and pipes, and the critical aspects of change detection. We also delved into modern Angular advancements like Standalone Components and Signals, which are increasingly important as of late 2025.

By internalizing these concepts, practicing their application, and understanding the “why” behind Angular’s design choices, you’ll be well-prepared to articulate your knowledge clearly and confidently. Remember that a strong grasp of fundamentals is the cornerstone of success in any Angular role.

Next Steps: Continue your preparation by exploring more advanced topics like RxJS, State Management, Testing, Performance Optimization, and System Design for Angular applications.

References:

1. Angular Official Documentation: https://angular.dev/
2. InterviewBit - Angular Interview Questions: https://www.interviewbit.com/angular-interview-questions/
3. Hackr.io - Top Angular Interview Questions and Answers in 2025: https://hackr.io/blog/angular-interview-questions
4. Medium - Top Angular Interview Questions and Answers (2025 Edition): https://medium.com/@iammanishchauhan/top-angular-interview-questions-and-answers-2025-edition-intermediate-level-35b996a7567b
5. Angular University - Angular Change Detection Explained: https://blog.angular-university.io/angular-2-change-detection/
6. Netanel Basal - Angular Signals: The Future of Reactivity: https://www.netanelbasal.com/blog/angular-signals-the-future-of-reactivity/

This interview preparation guide is AI-assisted and reviewed. It references official documentation and recognized interview preparation resources.