Angular Developer Interview Questions

Direct Answer

An Angular component is the fundamental UI building block composed of a TypeScript class containing application state and logic, an HTML template defining the structure and bindings, and metadata declared via the @Component decorator that links the class, template, and styles into a coherent view.

Detailed Explanation

// Modern Standalone Angular Component:
import { Component, signal } from '@angular/core';

@Component({
  selector: 'app-counter',
  standalone: true,
  template: `
    <div class="counter-card">
      <h2>Count: {{ count() }}</h2>
      <button (click)="increment()">Increment</button>
    </div>
  `,
  styles: [`
    .counter-card { padding: 1rem; border: 1px solid #e2e8f0; }
  `]
})
export class CounterComponent {
  // Component state
  readonly count = signal<number>(0);

  // Component behavior
  increment(): void {
    this.count.update(n => n + 1);
  }
}

Common Interview Pitfalls

• Treating an Angular component as just a template HTML string without understanding how the class instance acts as the template execution context.
• Placing business logic and heavy computations directly inside template expressions rather than in the component class.
• Confusing the component CSS selector with standard HTML tags without realizing it represents an Angular-managed component boundary.
• Attempting to manipulate DOM elements directly via document.querySelector instead of utilizing Angular template reference variables and ViewChild.

Direct Answer

Interpolation ({{ value }}) renders evaluated expressions into text, property binding ([prop]="expr") passes typed values directly to DOM or component properties, and event binding ((event)="handler()") listens for user or custom events to invoke component methods.

Detailed Explanation

// Template demonstrating Interpolation, Property Binding, and Event Binding:
@Component({
  selector: 'app-user-profile',
  standalone: true,
  template: `
    <!-- 1. Interpolation: Renders string representation -->
    <h2>User: {{ user.name }}</h2>

    <!-- 2. Property Binding: Passes typed boolean to DOM property -->
    <button [disabled]="isLoading" class="btn">
      Update Profile
    </button>

    <!-- 2b. Property Binding to Child Component Input -->
    <app-status-badge [isActive]="user.isActive" />

    <!-- 3. Event Binding: Listens to DOM click event -->
    <button (click)="onDeactivate($event)">
      Deactivate
    </button>
  `
})
export class UserProfileComponent {
  user = { name: 'Sarah Connor', isActive: true };
  isLoading = false;

  onDeactivate(event: MouseEvent): void {
    console.log('Deactivated clicked at coordinates:', event.clientX, event.clientY);
    this.user.isActive = false;
  }
}

Common Interview Pitfalls

• Using interpolation for boolean properties (e.g., disabled="{{ isDisabled }}") which causes string coercion where "false" evaluates to truthy.
• Assuming that property binding modifies HTML element attributes rather than underlying DOM object properties.
• Placing complex business logic or mutating state directly inside template expressions.
• Confusing two-way banana-in-a-box binding [(ngModel)] with standard one-way property binding [ngModel].

Direct Answer

Parent components pass state downward via inputs, and children emit events upward via outputs. Modern Angular signal inputs (input()) provide reactive, read-only signals with compile-time type safety, while output() simplifies typed event emission without manual EventEmitter setup.

Detailed Explanation

// Modern Signal-based Parent-Child Communication:
import { Component, input, output, computed } from '@angular/core';

export interface Task { id: string; title: string; completed: boolean; }

// Child Component:
@Component({
  selector: 'app-task-item',
  standalone: true,
  template: `
    <div class="task-row" [class.done]="task().completed">
      <span>{{ formattedTitle() }}</span>
      <button (click)="toggleDone()">Toggle</button>
      <button (click)="deleteTask.emit(task().id)">Delete</button>
    </div>
  `
})
export class TaskItemComponent {
  // 1. Required Signal Input: creates read-only Signal<Task>
  readonly task = input.required<Task>();

  // 2. Computed derivative: automatically updates when task() changes
  readonly formattedTitle = computed(() => this.task().title.toUpperCase());

  // 3. Modern Output: typed event emitter
  readonly deleteTask = output<string>();
  readonly statusChange = output<boolean>();

  toggleDone(): void {
    this.statusChange.emit(!this.task().completed);
  }
}

Common Interview Pitfalls

• Mutating input object properties directly inside child components instead of emitting an output event for the parent to update.
• Writing verbose ngOnChanges lifecycle boilerplate to detect input changes when computed signals achieve this declaratively.
• Passing component instance references downward, tightly coupling child logic to parent internal implementations.
• Using outputs for heavy bidirectional data synchronization rather than clean, event-driven intent notification.

Direct Answer

Built-in control flow (@if, @for, @switch) provides native template branching integrated into the compiler. The mandatory track expression in @for associates items with DOM nodes by unique identity, preventing complete DOM destruction and recreation during array sorting, updates, or pagination.

Detailed Explanation

// Modern Built-In Control Flow Template:
@Component({
  selector: 'app-product-catalog',
  standalone: true,
  template: `
    <!-- Conditional rendering with type narrowing -->
    @if (isLoading()) {
      <p class="spinner">Loading products...</p>
    } @else if (hasError()) {
      <p class="error">Failed to load catalog.</p>
    } @else {
      <!-- List rendering with mandatory identity tracking -->
      <div class="product-grid">
        @for (product of products(); track product.id) {
          <div class="card">
            <h3>{{ product.title }}</h3>
            <p>{{ product.price | currency }}</p>
            
            <!-- Switch block for inventory status -->
            @switch (product.status) {
              @case ('IN_STOCK') { <span class="badge in">Available</span> }
              @case ('LOW_STOCK') { <span class="badge warn">Low Stock</span> }
              @default { <span class="badge out">Out of Stock</span> }
            }
          </div>
        } @empty {
          <!-- Rendered automatically when products() array is empty -->
          <p class="empty-state">No products found matching your search.</p>
        }
      </div>
    }
  `
})
export class ProductCatalogComponent {
  readonly isLoading = signal(false);
  readonly hasError = signal(false);
  readonly products = signal<Array<{ id: string; title: string; price: number; status: string }>>([]);
}

Common Interview Pitfalls

• Using track $index for dynamic lists that undergo sorting or item deletions, leading to corrupted form inputs and UI state mismatches.
• Continuing to import CommonModule just for structural directives when modern built-in control flow is native to the compiler.
• Tracking objects by entire object reference (track item) rather than a stable unique primitive identifier (track item.id).
• Wrapping @for loops in redundant @if checks when the built-in @empty block handles empty arrays declaratively.

Direct Answer

Default change detection traverses the entire component tree, whereas OnPush skips checks unless an input reference changes, an event fires, or a signal updates. Signals provide fine-grained dependency tracking, enabling localized view updates without checking unrelated branches.

Detailed Explanation

// OnPush Component coordinating immutable inputs and local signals:
import { Component, ChangeDetectionStrategy, input, signal, computed } from '@angular/core';

@Component({
  selector: 'app-account-summary',
  standalone: true,
  changeDetection: ChangeDetectionStrategy.OnPush, // Skips checking unless inputs/signals change
  template: `
    <div class="summary-box">
      <h3>Account: {{ accountName() }}</h3>
      <p>Balance: {{ balance() | currency }}</p>
      <p>Status: {{ statusLabel() }}</p>
      <button (click)="refreshLocalData()">Refresh</button>
    </div>
  `
})
export class AccountSummaryComponent {
  // 1. Signal input: triggers OnPush update on reference change
  readonly accountName = input.required<string>();
  readonly balance = input.required<number>();

  // 2. Local signal state
  readonly isStale = signal<boolean>(false);

  // 3. Computed signal: updates synchronously when balance() changes
  readonly statusLabel = computed(() => {
    return this.balance() < 0 ? 'Overdrawn' : 'Active';
  });

  refreshLocalData(): void {
    // Template event binding automatically marks this OnPush view dirty
    this.isStale.set(false);
  }
}

Common Interview Pitfalls

• Mutating array or object properties in place (e.g., this.items.push(newItem)) and expecting an OnPush component to re-render.
• Assuming OnPush disables change detection entirely, rather than skipping unchanged subtrees until an explicit update trigger occurs.
• Replacing all RxJS asynchronous stream operators with signals where Observables are structurally better suited for complex event pipelines.
• Triggering manual ChangeDetectorRef.detectChanges() in child components instead of adhering to immutable data updates and signal dependencies.

Direct Answer

Profile using Chrome DevTools and Angular DevTools to isolate long tasks. Stabilize by replacing template method calls with computed signals, adding stable @for entity tracking, batching websocket events, and isolating rows into OnPush components or virtual scrolling with CDK Virtual Scroll.

Detailed Explanation

# High-Performance Angular List Architecture (Virtual Scroll + OnPush + Signals):
import { Component, ChangeDetectionStrategy, signal, computed } from '@angular/core';
import { ScrollingModule } from '@angular/cdk/scrolling';

export interface DashboardRow {
  id: string;
  name: string;
  status: string;
  riskScore: number;
}

@Component({
  selector: 'app-perf-dashboard',
  standalone: true,
  imports: [ScrollingModule],
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    <input 
      type="text" 
      placeholder="Filter rows..." 
      (input)="onSearch($event)" 
      class="search-input" />

    <!-- 1. CDK Virtual Scroll: Renders only ~20 visible DOM rows -->
    <cdk-virtual-scroll-viewport itemSize="48" class="viewport">
      <div 
        *cdkVirtualItem="let row of filteredRows(); trackBy: trackRowId" 
        class="row-item">
        <span class="col-name">{{ row.name }}</span>
        <span class="col-status">{{ row.status }}</span>
        <!-- Pre-computed property, zero template function execution -->
        <span class="col-risk" [class.high]="row.riskScore > 80">
          Risk: {{ row.riskScore }}%
        </span>
      </div>
    </cdk-virtual-scroll-viewport>
  `,
  styles: [`
    .viewport { height: 600px; width: 100%; border: 1px solid #cbd5e1; }
    .row-item { height: 48px; display: flex; align-items: center; padding: 0 1rem; }
  `]
})
export class PerfDashboardComponent {
  readonly allRows = signal<DashboardRow[]>([]);
  readonly searchFilter = signal<string>('');

  // 2. Computed derivative: updates efficiently on search or row updates
  readonly filteredRows = computed(() => {
    const query = this.searchFilter().toLowerCase();
    if (!query) return this.allRows();
    return this.allRows().filter(r => r.name.toLowerCase().includes(query));
  });

  trackRowId(index: number, row: DashboardRow): string {
    return row.id; // Stable entity identity
  }

  onSearch(event: Event): void {
    const input = event.target as HTMLInputElement;
    this.searchFilter.set(input.value);
  }
}

Common Interview Pitfalls

• Applying ChangeDetectionStrategy.OnPush without stopping the parent component from recreating new object references on every update.
• Calling non-memoized functions directly in template expressions that execute thousands of times per second during stream updates.
• Rendering thousands of heavy DOM nodes without viewport virtualization, bottlenecking browser style recalculations and reflow.
• Failing to track dynamic list items by their unique entity ID, forcing Angular to destroy and recreate the DOM on array modifications.

Direct Answer

Dependency injection is a design pattern where Angular provides dependencies to classes via hierarchical injectors rather than requiring classes to instantiate them manually. Services encapsulate reusable business logic, API calls, and state, with their lifetime dictated by their provider scope.

Detailed Explanation

// Modern Angular Service and Component DI using inject():
import { Injectable, Component, inject, signal } from '@angular/core';
import { HttpClient } from '@angular/common/http';

export interface User { id: string; name: string; }

// 1. Service provided in root (Application-wide singleton)
@Injectable({
  providedIn: 'root'
})
export class UserService {
  private readonly http = inject(HttpClient);
  readonly currentUser = signal<User | null>(null);

  fetchUserProfile(id: string) {
    return this.http.get<User>(`/api/users/${id}`);
  }
}

// 2. Component injecting the service via functional inject()
@Component({
  selector: 'app-user-header',
  standalone: true,
  template: `
    <header class="header">
      <span>Welcome, {{ userService.currentUser()?.name ?? 'Guest' }}</span>
    </header>
  `
})
export class UserHeaderComponent {
  // Functional dependency injection: clean, type-safe, usable outside constructors
  readonly userService = inject(UserService);
}

Common Interview Pitfalls

• Using the new operator to manually instantiate services inside components, bypassing Angular DI and losing dependency resolution benefits.
• Assuming all Angular services are global singletons without checking whether they are provided at the component or route level.
• Providing a singleton service in multiple feature component providers arrays, which accidentally instantiates separate instances and splits shared state.
• Over-relying on global root services for localized state that should be scoped and destroyed alongside a specific feature component tree.

Direct Answer

An RxJS Observable is a lazy stream blueprint that emits values over time. Subscribing activates the stream producer and registers observer callbacks (next, error, complete) to consume notifications synchronously or asynchronously, returning a Subscription object used to tear down resources.

Detailed Explanation

// Basic Observable creation, subscription, and cleanup:
import { Observable, Subscription } from 'rxjs';

// 1. Defining a lazy Observable stream
const timerStream$ = new Observable<number>(subscriber => {
  let count = 0;
  console.log('Stream activated (producer started)');

  const intervalId = setInterval(() => {
    count++;
    subscriber.next(count);

    if (count === 3) {
      subscriber.complete();
    }
  }, 1000);

  // Teardown logic invoked on completion or unsubscription
  return () => {
    console.log('Teardown: clearing interval timer');
    clearInterval(intervalId);
  };
});

// 2. Subscribing to consume emissions
console.log('Before subscribe');
const sub: Subscription = timerStream$.subscribe({
  next: val => console.log('Received:', val),
  error: err => console.error('Stream error:', err),
  complete: () => console.log('Stream completed!')
});
console.log('After subscribe');

// 3. Early cancellation if needed
// sub.unsubscribe();

Common Interview Pitfalls

• Assuming an Observable sends an HTTP request or runs an operation without being subscribed to, leading to silent bugs where API calls never fire.
• Treating Observables as identical to Promises and forgetting to unsubscribe from long-lived streams, causing memory leaks.
• Believing that subscribing offloads execution to a background OS thread, when all operations still execute on the single JavaScript event loop.
• Manually subscribing to Observables in components when the Angular async pipe handles subscription, change detection, and unsubscription automatically.

Direct Answer

Angular resolves dependencies through an injector hierarchy: EnvironmentInjectors (root and route scopes) and ElementInjectors (component scopes). Providing a service on a component instantiates an isolated instance scoped to that subtree rather than sharing an application-wide root singleton.

Detailed Explanation

// Component-scoped service creating isolated state per widget:
import { Injectable, Component, inject, signal } from '@angular/core';

// Scoped service (NOT provided in root)
@Injectable()
export class DocumentEditorState {
  readonly documentId = signal<string>('');
  readonly isDirty = signal<boolean>(false);
}

// Host Component provides DocumentEditorState at the ElementInjector level:
@Component({
  selector: 'app-document-tab',
  standalone: true,
  providers: [DocumentEditorState], // Each open tab gets its OWN isolated editor state
  template: `
    <div class="tab">
      <h2>Editing: {{ state.documentId() }}</h2>
      <app-document-toolbar />
      <app-document-body />
    </div>
  `
})
export class DocumentTabComponent {
  // Injects the locally provided DocumentEditorState instance
  readonly state = inject(DocumentEditorState);
}

// Child Component nested inside DocumentTabComponent:
@Component({
  selector: 'app-document-toolbar',
  standalone: true,
  template: `<button (click)="save()">Save Tab</button>`
})
export class DocumentToolbarComponent {
  // Automatically resolves the parent tab's DocumentEditorState instance!
  readonly state = inject(DocumentEditorState);

  save(): void {
    this.state.isDirty.set(false);
  }
}

Common Interview Pitfalls

• Assuming that a service provided in root will provide separate instances for separate feature modules or components.
• Accidentally listing a stateful singleton service in a component providers array, creating unintended multiple instances that break synchronized state.
• Failing to understand that route providers are destroyed when navigating away from that route branch.
• Using manual module declarations when standalone route providers provide cleaner and more isolated scoping.

Direct Answer

Subject multicasts events to active listeners without storing history. BehaviorSubject holds a current value and immediately replays it to new subscribers. ReplaySubject buffers a configured number of past emissions or time window to replay to new subscribers without an initial seed.

Detailed Explanation

// Encapsulated Service exposing read-only Observable streams from private Subjects:
import { Injectable } from '@angular/core';
import { Subject, BehaviorSubject, ReplaySubject, Observable } from 'rxjs';

@Injectable({
  providedIn: 'root'
})
export class NotificationService {
  // 1. Private writable Subjects (encapsulating state mutation)
  private readonly alertSubject = new Subject<string>();
  private readonly unreadCountSubject = new BehaviorSubject<number>(0);
  private readonly historySubject = new ReplaySubject<string>(5); // Buffers last 5 events

  // 2. Public read-only Observables (preventing external consumers from calling .next())
  readonly alert$: Observable<string> = this.alertSubject.asObservable();
  readonly unreadCount$: Observable<number> = this.unreadCountSubject.asObservable();
  readonly history$: Observable<string> = this.historySubject.asObservable();

  triggerAlert(message: string): void {
    this.alertSubject.next(message); // Multicast to active listeners only
    this.historySubject.next(message); // Buffered for late subscribers
    this.unreadCountSubject.next(this.unreadCountSubject.value + 1); // Update latest value
  }

  markAllAsRead(): void {
    this.unreadCountSubject.next(0);
  }
}

Common Interview Pitfalls

• Exposing public writable BehaviorSubjects (subject.next()) directly to components, breaking encapsulation and traceability of state updates.
• Using a plain Subject for component state, causing late-rendering components to miss the initial state and remain permanently empty.
• Instantiating an unbounded ReplaySubject() without a bufferSize limit, causing memory leaks in high-throughput streaming environments.
• Creating redundant BehaviorSubjects for state that can be derived synchronously using Angular signals and computed().

Direct Answer

switchMap cancels previous inner streams on new emissions (ideal for search); mergeMap runs inner streams concurrently in parallel; concatMap queues inner streams sequentially in strict order (save pipelines); and exhaustMap ignores incoming emissions until the active inner stream completes.

Detailed Explanation

// Practical comparison of the 4 flattening operators in Angular:
import { Component, inject } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Subject } from 'rxjs';
import { switchMap, mergeMap, concatMap, exhaustMap } from 'rxjs/operators';

@Component({
  selector: 'app-operator-demo',
  standalone: true,
  template: `...`
})
export class OperatorDemoComponent {
  private readonly http = inject(HttpClient);

  // 1. switchMap: Typeahead search (cancels obsolete pending search requests)
  readonly searchTerms$ = new Subject<string>();
  readonly searchResults$ = this.searchTerms$.pipe(
    switchMap(term => this.http.get(`/api/search?q=${term}`))
  );

  // 2. mergeMap: Parallel item detail fetches (order does not matter)
  readonly itemIds$ = new Subject<string>();
  readonly itemDetails$ = this.itemIds$.pipe(
    mergeMap(id => this.http.get(`/api/items/${id}`), 5) // Concurrent limit of 5
  );

  // 3. concatMap: Sequential batch saves (Order matters strictly)
  readonly reorderQueue$ = new Subject<{ id: string; rank: number }>();
  readonly saveStatus$ = this.reorderQueue$.pipe(
    concatMap(payload => this.http.post('/api/reorder', payload))
  );

  // 4. exhaustMap: Submit payment (ignore duplicate clicks until done)
  readonly submitClicks$ = new Subject<void>();
  readonly paymentResult$ = this.submitClicks$.pipe(
    exhaustMap(() => this.http.post('/api/checkout', { timestamp: Date.now() }))
  );
}

Common Interview Pitfalls

• Using switchMap for form submissions or DELETE requests, causing rapid clicks to abort pending server writes.
• Using mergeMap for search inputs, which creates race conditions where a slow response for an older query overwrites a fast response for a newer query.
• Using concatMap for user typing events, which creates a huge queue of obsolete requests that execute one after another.
• Confusing exhaustMap with debounceTime: exhaustMap executes the first event and drops later ones, whereas debounceTime delays execution until user activity pauses.

Direct Answer

Use Chrome DevTools and RxJS marble tracing to isolate stream leaks. Re-architect by flattening input streams via debounceTime, distinctUntilChanged, and switchMap for latest-wins queries, scoping side effects with tap, and replacing manual subscriptions with takeUntilDestroyed or the async pipe.

Detailed Explanation

# Resilient, declarative Angular search pipeline architecture:
import { Component, inject, DestroyRef } from '@angular/core';
import { FormControl, ReactiveFormsModule } from '@angular/forms';
import { HttpClient } from '@angular/common/http';
import { AsyncPipe } from '@angular/common';
import { Observable, of } from 'rxjs';
import { 
  debounceTime, 
  distinctUntilChanged, 
  switchMap, 
  tap, 
  catchError, 
  shareReplay 
} from 'rxjs/operators';
import { takeUntilDestroyed } from '@angular/core/rxjs-interop';

export interface SearchResponse { total: number; items: string[]; }

@Component({
  selector: 'app-resilient-search',
  standalone: true,
  imports: [ReactiveFormsModule, AsyncPipe],
  template: `
    <input [formControl]="searchInput" placeholder="Search..." />
    
    @if (results$ | async; as res) {
      <p>Total items: {{ res.total }}</p>
      <ul>
        @for (item of res.items; track item) { <li>{{ item }}</li> }
      </ul>
    }
  `
})
export class ResilientSearchComponent {
  private readonly http = inject(HttpClient);
  private readonly destroyRef = inject(DestroyRef);
  readonly searchInput = new FormControl('', { nonNullable: true });

  // Declarative stream pipeline: zero manual subscription boilerplate
  readonly results$: Observable<SearchResponse> = this.searchInput.valueChanges.pipe(
    // 1. Lifecycle safety: auto-unsubscribes when component is destroyed
    takeUntilDestroyed(this.destroyRef),
    // 2. Debounce typing bursts
    debounceTime(300),
    // 3. Prevent duplicate calls if query string did not change
    distinctUntilChanged(),
    // 4. Track telemetry exactly once per distinct user search action
    tap(query => this.trackSearchAnalytics(query)),
    // 5. switchMap ensures latest response always wins; aborts previous request
    switchMap(query => {
      if (!query.trim()) return of({ total: 0, items: [] });
      return this.http.get<SearchResponse>(`/api/search?q=${encodeURIComponent(query)}`).pipe(
        // Error isolation: keeps the outer search pipeline alive on API failures
        catchError(err => {
          console.error('Search query failed:', err);
          return of({ total: 0, items: [] });
        })
      );
    }),
    // 6. Multicast to multiple template listeners without repeating HTTP calls
    shareReplay({ bufferSize: 1, refCount: true })
  );

  private trackSearchAnalytics(query: string): void {
    console.log('Telemetry: search executed for query =', query);
  }
}

Common Interview Pitfalls

• Placing catchError on the outer pipeline instead of the inner switchMap stream, permanently breaking search inputs on a single network error.
• Using shareReplay(1) without refCount: true, causing the stream and its cached values to leak in memory after all components unmount.
• Nesting .subscribe() calls inside other .subscribe() callbacks instead of using RxJS higher-order mapping operators like switchMap.
• Allowing un-debounced search inputs to flood backend services with intermediate keystrokes on every letter typed.

Direct Answer

Angular routing enables Single Page App navigation by matching browser URLs against a hierarchical route configuration table. The Router interprets navigation requests, evaluates path matches and guards, and dynamically activates the matching component view inside a configured RouterOutlet.

Detailed Explanation

// Modern Standalone Routing Configuration and Navigation:
import { Component, inject } from '@angular/core';
import { Routes, provideRouter, Router, RouterOutlet, RouterLink, RouterLinkActive } from '@angular/router';

// 1. Standalone Route Configuration
export const APP_ROUTES: Routes = [
  { path: '', redirectTo: 'dashboard', pathMatch: 'full' },
  { 
    path: 'dashboard', 
    loadComponent: () => import('./dashboard.component').then(m => m.DashboardComponent) 
  },
  { 
    path: 'customers/:customerId', 
    loadComponent: () => import('./customer-detail.component').then(m => m.CustomerDetailComponent) 
  }
];

// 2. Host Component with RouterOutlet and Navigation Links
@Component({
  selector: 'app-root',
  standalone: true,
  imports: [RouterOutlet, RouterLink, RouterLinkActive],
  template: `
    <nav class="nav-bar">
      <a routerLink="/dashboard" routerLinkActive="active-tab">Dashboard</a>
      <button (click)="navigateToCustomer('cust-42')">Customer 42</button>
    </nav>

    <!-- RouterOutlet: Dynamic host where activated route views render -->
    <main class="content-container">
      <router-outlet />
    </main>
  `
})
export class AppComponent {
  private readonly router = inject(Router);

  navigateToCustomer(id: string): void {
    // Imperative navigation
    this.router.navigate(['/customers', id]);
  }
}

Common Interview Pitfalls

• Using standard HTML href attributes (href="/path") instead of [routerLink], which triggers full browser reloads and destroys in-memory application state.
• Forgetting pathMatch: "full" on root empty path redirects, causing infinite redirect loops on every route.
• Confusing the Router service responsible for navigation logic with the RouterOutlet directive responsible for view projection.
• Hardcoding URL strings with manual string concatenation instead of passing structured route parameter arrays to [routerLink].

Direct Answer

Template-driven forms rely on two-way ngModel directives in the template to create form controls implicitly, ideal for simple forms. Reactive forms define an explicit, immutable form control model in TypeScript, offering synchronous data access, strict typing, and reactive valueChanges streams.

Detailed Explanation

// Comparison: Template-Driven vs. Strictly-Typed Reactive Forms:
import { Component, inject } from '@angular/core';
import { FormControl, FormGroup, Validators, ReactiveFormsModule } from '@angular/forms';
import { FormsModule } from '@angular/forms';

// 1. Modern Strictly-Typed Reactive Form Component
@Component({
  selector: 'app-reactive-login',
  standalone: true,
  imports: [ReactiveFormsModule],
  template: `
    <form [formGroup]="loginForm" (ngSubmit)="onSubmit()">
      <input formControlName="email" type="email" placeholder="Email" />
      @if (loginForm.controls.email.invalid && loginForm.controls.email.touched) {
        <span class="error">Valid email required</span>
      }

      <input formControlName="password" type="password" placeholder="Password" />
      <button [disabled]="loginForm.invalid" type="submit">Log In</button>
    </form>
  `
})
export class ReactiveLoginComponent {
  // Explicit programmatic form model with strict TypeScript typing
  readonly loginForm = new FormGroup({
    email: new FormControl('', { nonNullable: true, validators: [Validators.required, Validators.email] }),
    password: new FormControl('', { nonNullable: true, validators: [Validators.required, Validators.minLength(8)] })
  });

  onSubmit(): void {
    if (this.loginForm.valid) {
      console.log('Submitted values:', this.loginForm.getRawValue());
    }
  }
}

Common Interview Pitfalls

• Mixing template-driven [(ngModel)] bindings inside a reactive [formGroup] form, which causes state collisions and console warnings.
• Assuming template-driven forms are deprecated when they remain officially supported and ideal for lightweight forms.
• Failing to use nonNullable: true in modern typed form controls, causing form.reset() to reset typed values back to null instead of initial primitives.
• Directly mutating component properties instead of using formControl.setValue() or patchValue() in reactive forms.

Direct Answer

Route params capture path variables while query params capture optional state. Route snapshot provides static values at activation but does not update on reused component navigation, whereas route paramMap Observables react to every change. Resolvers pre-fetch data before route activation.

Detailed Explanation

// Modern Route Resolver and Component Param Consumption:
import { Component, inject, input } from '@angular/core';
import { ResolveFn, ActivatedRoute } from '@angular/router';
import { HttpClient } from '@angular/common/http';
import { of } from 'rxjs';
import { catchError } from 'rxjs/operators';

export interface Customer { id: string; name: string; email: string; }

// 1. Functional Route Resolver
export const customerResolver: ResolveFn<Customer | null> = (route) => {
  const http = inject(HttpClient);
  const customerId = route.paramMap.get('customerId');
  if (!customerId) return of(null);

  return http.get<Customer>(`/api/customers/${customerId}`).pipe(
    catchError(() => of(null)) // Handle failure gracefully during transition
  );
};

// 2. Component consuming parameters via Observable paramMap & resolved data:
@Component({
  selector: 'app-customer-view',
  standalone: true,
  template: `
    <div class="profile">
      <!-- Input bound directly via withComponentInputBinding() or read via route.data -->
      <h2>Customer: {{ customer()?.name ?? 'Not Found' }}</h2>
      <p>Param ID: {{ customerId() }}</p>
    </div>
  `
})
export class CustomerViewComponent {
  // Modern withComponentInputBinding(): route parameters and resolved data bind to inputs!
  readonly customerId = input<string>('');
  readonly customer = input<Customer | null>(null);
}

Common Interview Pitfalls

• Relying on route.snapshot.paramMap in components that support switching between different IDs without leaving the component, showing stale data.
• Using heavy resolvers for slow API requests without providing a global navigation progress bar, making the application feel unresponsive.
• Failing to handle resolver errors with catchError, causing navigation to fail silently and leaving the user stuck on the current route.
• Putting sensitive business state in query parameters instead of keeping it in secure application services.

Direct Answer

Angular forms validate state using synchronous functions (returning ValidationErrors or null) and asynchronous validators (returning Observables for remote checks). Cross-field validation attaches to parent FormGroups to evaluate multi-control relationships like matching passwords.

Detailed Explanation

// Custom Cross-Field Validator and Async Validator in Reactive Forms:
import { Component, inject } from '@angular/core';
import { FormGroup, FormControl, Validators, AbstractControl, ValidationErrors, AsyncValidatorFn, ReactiveFormsModule } from '@angular/forms';
import { HttpClient } from '@angular/common/http';
import { Observable, of, timer } from 'rxjs';
import { switchMap, map, catchError } from 'rxjs/operators';

// 1. Cross-field validator for matching passwords
export function passwordMatchValidator(group: AbstractControl): ValidationErrors | null {
  const password = group.get('password')?.value;
  const confirmPassword = group.get('confirmPassword')?.value;
  return password === confirmPassword ? null : { passwordMismatch: true };
}

// 2. Factory for Async validator checking username availability
export function uniqueUsernameValidator(http: HttpClient): AsyncValidatorFn {
  return (control: AbstractControl): Observable<ValidationErrors | null> => {
    if (!control.value) return of(null);
    return timer(300).pipe( // Debounce network requests
      switchMap(() => http.get<{ available: boolean }>(`/api/check-username?u=${control.value}`)),
      map(res => (res.available ? null : { usernameTaken: true })),
      catchError(() => of(null)) // Handle API errors safely
    );
  };
}

@Component({
  selector: 'app-register-form',
  standalone: true,
  imports: [ReactiveFormsModule],
  template: `
    <form [formGroup]="registerForm">
      <input formControlName="username" placeholder="Username" />
      @if (registerForm.controls.username.pending) { <span>Checking availability...</span> }
      @if (registerForm.controls.username.hasError('usernameTaken')) { <span class="err">Username taken</span> }

      <input formControlName="password" type="password" placeholder="Password" />
      <input formControlName="confirmPassword" type="password" placeholder="Confirm Password" />
      
      @if (registerForm.hasError('passwordMismatch') && registerForm.controls.confirmPassword.touched) {
        <span class="err">Passwords must match</span>
      }
    </form>
  `
})
export class RegisterFormComponent {
  private readonly http = inject(HttpClient);

  readonly registerForm = new FormGroup(
    {
      username: new FormControl('', {
        nonNullable: true,
        validators: [Validators.required],
        asyncValidators: [uniqueUsernameValidator(this.http)]
      }),
      password: new FormControl('', [Validators.required, Validators.minLength(8)]),
      confirmPassword: new FormControl('', [Validators.required])
    },
    { validators: [passwordMatchValidator] } // Attached at FormGroup level!
  );
}

Common Interview Pitfalls

• Attaching cross-field validators to an individual FormControl instead of the parent FormGroup, preventing comparison of sibling field values.
• Running async validators on every keystroke without debouncing or using updateOn: "blur", overwhelming backend APIs.
• Treating client-side form validation as a security mechanism and omitting server-side payload validation.
• Checking control.invalid to display errors before the user has touched the field (touched), resulting in aggressive, premature error banners.

Direct Answer

Angular architecture divides responsibilities into presentational components (pure UI via inputs and outputs), container components (orchestrating state, routing, and services), and domain services (managing API calls and business logic) within modular, maintainable feature boundaries.

Detailed Explanation

// Clean Architectural Separation: Container vs. Presentational Component:

// 1. Presentational Component: Pure UI, zero service dependencies
@Component({
  selector: 'app-user-card',
  standalone: true,
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    <div class="user-card">
      <h3>{{ user().name }}</h3>
      <p>Role: {{ user().role }}</p>
      <button (click)="selectUser.emit(user().id)">Select</button>
    </div>
  `
})
export class UserCardComponent {
  readonly user = input.required<{ id: string; name: string; role: string }>();
  readonly selectUser = output<string>();
}

// 2. Container Component: Orchestrates state, routing, and domain service
@Component({
  selector: 'app-user-list-container',
  standalone: true,
  imports: [UserCardComponent, AsyncPipe],
  template: `
    <h2>Active Users</h2>
    @if (users$ | async; as users) {
      @for (u of users; track u.id) {
        <app-user-card [user]="u" (selectUser)="handleUserSelection($event)" />
      }
    }
  `
})
export class UserListContainerComponent {
  private readonly userFacade = inject(UserFacadeService);
  private readonly router = inject(Router);

  readonly users$ = this.userFacade.activeUsers$;

  handleUserSelection(userId: string): void {
    this.router.navigate(['/users', userId]);
  }
}

Common Interview Pitfalls

• Injecting HttpClient directly into presentational components, making them impossible to reuse without mocking the entire network layer.
• Creating monolithic services that mix HTTP calls, local component UI state, and global authentication rules in one file.
• Allowing child components to mutate input object references directly instead of communicating changes via outputs.
• Assuming that having separate component files guarantees good architecture when state management and data ownership remain tangled.

Direct Answer

Resolve route reuse issues by replacing static snapshots with paramMap Observables using switchMap. Scope multi-step form state to a route-level provider rather than a root singleton, consolidate data fetching under one owner, and safeguard unsaved edits using a functional CanDeactivateFn guard.

Detailed Explanation

# Route-level scoped store and CanDeactivate guard architecture:
import { Injectable, Component, inject, signal } from '@angular/core';
import { Routes, CanDeactivateFn, ActivatedRoute, RouterOutlet } from '@angular/router';
import { FormGroup, FormControl, Validators, ReactiveFormsModule } from '@angular/forms';
import { HttpClient } from '@angular/common/http';
import { switchMap, tap, map } from 'rxjs/operators';
import { toSignal } from '@angular/core/rxjs-interop';

// 1. Route-Scoped State Store (Provided at feature route level, NOT in root!)
@Injectable()
export class OnboardingStore {
  private readonly http = inject(HttpClient);
  readonly currentCustomerId = signal<string>('');

  // Master multi-step form model
  readonly masterForm = new FormGroup({
    profile: new FormGroup({
      name: new FormControl('', Validators.required),
      email: new FormControl('', [Validators.required, Validators.email])
    }),
    billing: new FormGroup({
      accountNumber: new FormControl('', Validators.required)
    })
  });

  loadCustomer(id: string) {
    this.currentCustomerId.set(id);
    return this.http.get<any>(`/api/customers/${id}`).pipe(
      tap(data => this.masterForm.patchValue(data))
    );
  }
}

// 2. Functional CanDeactivate Guard protecting unsaved edits
export const unsavedChangesGuard: CanDeactivateFn<any> = () => {
  const store = inject(OnboardingStore);
  if (store.masterForm.dirty) {
    return confirm('You have unsaved changes. Are you sure you want to leave?');
  }
  return true;
};

// 3. Parent Feature Route Configuration with Scoped Provider
export const ONBOARDING_ROUTES: Routes = [
  {
    path: 'customers/:customerId/onboarding',
    providers: [OnboardingStore], // Feature-scoped lifetime: destroyed when leaving flow!
    canDeactivate: [unsavedChangesGuard],
    children: [
      { path: 'profile', loadComponent: () => import('./profile-step.component').then(m => m.ProfileStepComponent) },
      { path: 'billing', loadComponent: () => import('./billing-step.component').then(m => m.BillingStepComponent) }
    ]
  }
];

Common Interview Pitfalls

• Storing wizard form state in an application-wide root singleton service, causing data from customer A to leak into customer B.
• Relying on route.snapshot in components that support switching between IDs via RouteReuseStrategy.
• Using switchMap for autosave writes, causing rapid navigation clicks to abort pending database persistence calls.
• Failing to implement CanDeactivate route guards, allowing accidental navigation or browser Back clicks to discard unsaved forms.

Direct Answer

Local state belongs exclusively to a single component view (such as accordion toggles or modal visibility) and is destroyed with it. Shared state coordinates data across multiple components or routes (such as user authentication or shopping carts) and lives in scoped or root services.

Detailed Explanation

// Clean separation of Local Component State vs. Shared Application State:
import { Component, Injectable, inject, signal } from '@angular/core';

// 1. Shared Application State (Service provided in root)
@Injectable({ providedIn: 'root' })
export class CartService {
  readonly itemCount = signal<number>(0);

  addItem(): void {
    this.itemCount.update(c => c + 1);
  }
}

// 2. Component managing BOTH local UI state and consuming shared state
@Component({
  selector: 'app-product-card',
  standalone: true,
  template: `
    <div class="card">
      <h3>Product Details</h3>
      <button (click)="toggleDetails()">
        {{ isExpanded() ? 'Hide Specs' : 'Show Specs' }}
      </button>

      <!-- Local state controls view visibility -->
      @if (isExpanded()) {
        <p class="specs">Weight: 1.2kg | Color: Space Gray</p>
      }

      <!-- Shared state interaction -->
      <button (click)="addToCart()">Add to Cart</button>
    </div>
  `
})
export class ProductCardComponent {
  // Shared state: injected singleton service
  private readonly cart = inject(CartService);

  // Local state: strictly private to this component instance
  readonly isExpanded = signal<boolean>(false);

  toggleDetails(): void {
    this.isExpanded.update(v => !v);
  }

  addToCart(): void {
    this.cart.addItem();
  }
}

Common Interview Pitfalls

• Lifting transient UI states (like dropdown toggles or hover flags) into global state stores, introducing unnecessary boilerplate.
• Storing shared application state (such as user authentication) inside individual components, losing the data upon route navigation.
• Allowing child components to directly mutate shared service state without going through explicit service methods or actions.
• Failing to reset feature-specific state upon user logout, causing sensitive data leakage between user sessions.

Direct Answer

Unit tests verify isolated classes, services, or pipes without rendering the DOM. Component tests render an Angular component with its template and bindings via TestBed to evaluate view interactions. Integration tests verify collaborating components, routes, and services working together.

Detailed Explanation

// Comparison: Isolated Unit Test vs. TestBed Component Test:
import { TestBed, ComponentFixture } from '@angular/core/testing';
import { Component, signal } from '@angular/core';

// Target Component
@Component({
  selector: 'app-counter',
  standalone: true,
  template: `<button (click)="inc()">Count: {{ count() }}</button>`
})
export class CounterComponent {
  readonly count = signal(0);
  inc(): void { this.count.update(n => n + 1); }
}

// 1. Pure Unit Test (Zero TestBed, instant execution)
describe('CounterComponent - Unit Test', () => {
  it('should increment count programmatically', () => {
    const comp = new CounterComponent();
    expect(comp.count()).toBe(0);
    comp.inc();
    expect(comp.count()).toBe(1);
  });
});

// 2. Component Test (With TestBed and DOM verification)
describe('CounterComponent - Component DOM Test', () => {
  let fixture: ComponentFixture<CounterComponent>;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [CounterComponent]
    }).compileComponents();

    fixture = TestBed.createComponent(CounterComponent);
    fixture.detectChanges(); // Trigger initial change detection
  });

  it('should render incremented count in the DOM on button click', () => {
    const btn = fixture.nativeElement.querySelector('button');
    expect(btn.textContent).toContain('Count: 0');

    btn.click();
    fixture.detectChanges(); // Flush view update

    expect(btn.textContent).toContain('Count: 1');
  });
});

Common Interview Pitfalls

• Using TestBed for simple services and pipes that could be tested 10x faster as isolated TypeScript unit tests.
• Forgetting to call fixture.detectChanges() in component tests, causing assertions to fail on un-rendered template state.
• Mocking every single internal dependency in integration tests, testing the mocks rather than actual system behavior.
• Relying exclusively on slow, flaky E2E tests for validation rules that could be verified instantaneously via component tests.

Direct Answer

Signals provide synchronous, fine-grained reactive state for UI rendering and derived values without Zone.js. Observables excel at asynchronous event streams, debounce, and cancellation. Dedicated stores (like NgRx or SignalStore) manage complex multi-entity state requiring action auditability.

Detailed Explanation

// Interoperability: Combining Signals, RxJS Observables, and a Feature Store:
import { Component, Injectable, inject, signal, computed } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { toSignal } from '@angular/core/rxjs-interop';
import { debounceTime, distinctUntilChanged, switchMap } from 'rxjs/operators';
import { Subject } from 'rxjs';

export interface User { id: string; name: string; }

// 1. Feature Store coordinating async requests with signals
@Injectable({ providedIn: 'root' })
export class UserDirectoryStore {
  private readonly http = inject(HttpClient);
  private readonly searchStream$ = new Subject<string>();

  // RxJS handles async debounce and request cancellation
  // toSignal converts stream to a clean, synchronous Signal for the UI
  readonly searchResults = toSignal(
    this.searchStream$.pipe(
      debounceTime(300),
      distinctUntilChanged(),
      switchMap(query => this.http.get<User[]>(`/api/users?q=${query}`))
    ),
    { initialValue: [] }
  );

  // Local synchronous signal state
  readonly selectedUserId = signal<string | null>(null);

  // Computed derived state
  readonly selectedUser = computed(() => {
    const id = this.selectedUserId();
    return this.searchResults().find(u => u.id === id) ?? null;
  });

  search(term: string): void {
    this.searchStream$.next(term);
  }
}

Common Interview Pitfalls

• Attempting to replace all RxJS streams with signals, resulting in messy manual setTimeout implementations for debouncing or cancellation.
• Over-engineering small applications by installing heavy global stores for state that could be managed cleanly in simple signal services.
• Calling .subscribe() inside components to assign values to signals instead of using toSignal().
• Using signal effects (effect()) to synchronize state between two signals instead of defining clean computed() derivatives.

Direct Answer

TestBed configures an isolated testing module simulating Angular DI. ComponentFixture manages the component instance, triggers change detection via detectChanges(), queries the rendered DOM via DebugElement, and allows overriding providers and services with targeted test doubles.

Detailed Explanation

// Testing an Angular Component with TestBed and Provider Overrides:
import { TestBed, ComponentFixture } from '@angular/core/testing';
import { Component, inject, input } from '@angular/core';
import { By } from '@angular/platform-browser';
import { UserService } from './user.service';
import { of } from 'rxjs';

@Component({
  selector: 'app-user-greeting',
  standalone: true,
  template: `
    <div class="greeting">
      <h1>Hello, {{ user() }}!</h1>
      <button (click)="logout()">Sign Out</button>
    </div>
  `
})
export class UserGreetingComponent {
  private readonly userService = inject(UserService);
  readonly user = input<string>('Guest');

  logout(): void {
    this.userService.logout();
  }
}

describe('UserGreetingComponent', () => {
  let fixture: ComponentFixture<UserGreetingComponent>;
  let mockUserService: jasmine.SpyObj<UserService>;

  beforeEach(async () => {
    // 1. Create a controlled spy object for the dependency
    mockUserService = jasmine.createSpyObj('UserService', ['logout']);

    // 2. Configure TestBed with provider override
    await TestBed.configureTestingModule({
      imports: [UserGreetingComponent],
      providers: [
        { provide: UserService, useValue: mockUserService }
      ]
    }).compileComponents();

    fixture = TestBed.createComponent(UserGreetingComponent);
  });

  it('should call userService.logout when sign out button is clicked', () => {
    fixture.componentRef.setInput('user', 'Alice');
    fixture.detectChanges(); // Render updated input to DOM

    const heading = fixture.debugElement.query(By.css('h1')).nativeElement;
    expect(heading.textContent).toBe('Hello, Alice!');

    const button = fixture.debugElement.query(By.css('button')).nativeElement;
    button.click();

    expect(mockUserService.logout).toHaveBeenCalledTimes(1);
  });
});

Common Interview Pitfalls

• Forgetting to call fixture.detectChanges() after changing component inputs or clicking buttons, causing DOM assertions to test stale markup.
• Failing to use TestBed.overrideComponent for services declared directly in the component providers array, leaving the real service active.
• Over-mocking child components instead of testing the integrated template interaction when testing container workflows.
• Testing private component methods directly instead of verifying public inputs, outputs, and DOM behavior.

Direct Answer

An Angular production build compiles TypeScript, AOT-compiles templates into JavaScript instructions, tree-shakes dead code, minifies assets, and outputs code-split lazy bundles. Build environments swap configuration values, while source maps map minified bundles to original source code.

Detailed Explanation

// Production Build Configuration in angular.json:
{
  "projects": {
    "enterprise-app": {
      "architect": {
        "build": {
          "builder": "@angular-devkit/build-angular:application",
          "options": {
            "outputPath": "dist/enterprise-app",
            "index": "src/index.html",
            "browser": "src/main.ts"
          },
          "configurations": {
            "production": {
              "optimization": true,
              "extractLicenses": true,
              "sourceMap": false, // Disable public source maps for security
              "namedChunks": false,
              "fileReplacements": [
                {
                  "replace": "src/environments/environment.ts",
                  "with": "src/environments/environment.prod.ts"
                }
              ],
              "budgets": [
                {
                  "type": "initial",
                  "maximumWarning": "500kB",
                  "maximumError": "1MB"
                }
              ]
            }
          }
        }
      }
    }
  }
}

Common Interview Pitfalls

• Storing private API keys or database credentials in environment.ts files, exposing them publicly to any user opening browser DevTools.
• Deploying uncompressed, non-minified development builds to production due to missing --configuration=production flags.
• Shipping public source maps to external CDNs, exposing intellectual property and internal architecture details to the public.
• Setting initial bundle size budgets too high, masking performance regressions and slow mobile startup times.

Direct Answer

Diagnose test flakiness by auditing shared root service state, active background subscriptions, and unsynchronized async tasks. Resolve flakiness by re-providing store instances per test, tearing down effects and streams via DestroyRef, and awaiting explicit conditions rather than retries.

Detailed Explanation

# Hermetic Angular Test Suite with Isolated DI Scope and Clean Teardown:
import { TestBed, ComponentFixture } from '@angular/core/testing';
import { provideHttpClient } from '@angular/common/http';
import { HttpTestingController, provideHttpClientTesting } from '@angular/common/http/testing';
import { Component, inject, DestroyRef } from '@angular/core';
import { takeUntilDestroyed } from '@angular/core/rxjs-interop';
import { UserSessionStore } from './user-session.store';

@Component({
  selector: 'app-user-profile-widget',
  standalone: true,
  template: `<h1>{{ store.userName() }}</h1>`
})
export class UserProfileWidgetComponent {
  readonly store = inject(UserSessionStore);
  private readonly destroyRef = inject(DestroyRef);

  ngOnInit(): void {
    // Correctly lifecycle-bound stream: cleanly terminated when fixture is destroyed
    this.store.refreshStream$.pipe(
      takeUntilDestroyed(this.destroyRef)
    ).subscribe();
  }
}

describe('UserProfileWidgetComponent - Hermetic Test Suite', () => {
  let fixture: ComponentFixture<UserProfileWidgetComponent>;
  let httpMock: HttpTestingController;
  let freshStore: UserSessionStore;

  beforeEach(() => {
    // 1. Explicit fresh instance per test prevents cross-test state leakage
    freshStore = new UserSessionStore();

    TestBed.configureTestingModule({
      imports: [UserProfileWidgetComponent],
      providers: [
        provideHttpClient(),
        provideHttpClientTesting(),
        // 2. Override root singleton with fresh test instance
        { provide: UserSessionStore, useValue: freshStore }
      ]
    });

    httpMock = TestBed.inject(HttpTestingController);
    fixture = TestBed.createComponent(UserProfileWidgetComponent);
  });

  afterEach(() => {
    // 3. Destroy fixture to trigger ngOnDestroy and unsubscribe streams
    fixture.destroy();
    // 4. Verify no orphan requests leaked into subsequent tests
    httpMock.verify();
  });

  it('should render initial user name deterministically', () => {
    freshStore.userName.set('Alice');
    fixture.detectChanges();

    const h1 = fixture.nativeElement.querySelector('h1');
    expect(h1.textContent).toBe('Alice');
  });
});

Common Interview Pitfalls

• Applying test retries in CI pipelines to ignore flaky failures instead of diagnosing shared state or async leakages.
• Allowing root-scoped stateful services to persist dirty data across test cases without fresh instantiation in beforeEach.
• Using arbitrary setTimeout sleeps instead of fixture.whenStable() or fakeAsync tick() to wait for asynchronous operations.
• Failing to verify HttpTestingController at the end of each test, masking un-cancelled background requests.

Direct Answer

Lazy loading and code splitting divide an Angular application into asynchronous JavaScript chunks loaded on demand when a user navigates to a route. This minimizes initial bundle download size and bootstrap latency, though it introduces a network request during subsequent navigation transitions.

Detailed Explanation

// Modern Standalone Route-Level Lazy Loading with Preloading:
import { Routes, provideRouter, withPreloading, PreloadAllModules } from '@angular/router';

export const APP_ROUTES: Routes = [
  // Eagerly loaded home page (immediate rendering)
  { 
    path: '', 
    loadComponent: () => import('./home.component').then(m => m.HomeComponent) 
  },

  // Lazily loaded feature branch (split into separate chunk)
  {
    path: 'admin',
    loadChildren: () => import('./admin/admin.routes').then(m => m.ADMIN_ROUTES)
  },

  // Lazily loaded standalone component
  {
    path: 'reports',
    loadComponent: () => import('./reports/reports.component').then(m => m.ReportsComponent)
  }
];

// In main.ts: configure router with PreloadAllModules for background prefetching
export const appConfig = {
  providers: [
    provideRouter(APP_ROUTES, withPreloading(PreloadAllModules))
  ]
};

Common Interview Pitfalls

• Importing a lazy component directly into an eagerly loaded component imports array, inadvertently bundling it into main.js and defeating lazy loading.
• Assuming code splitting magically shrinks total code size rather than optimizing initial bundle transfer and execution timing.
• Failing to configure preloading strategies for high-frequency routes, causing perceptible UI pauses on first-time route clicks.
• Over-fragmenting applications into hundreds of tiny lazy chunks, creating excessive HTTP request overhead on high-latency mobile connections.

Direct Answer

Angular mitigates XSS by treating template interpolations and property bindings as untrusted by default, automatically sanitizing values against HTML, URL, and style injection vectors. Developers must avoid direct DOM manipulation and never bypass sanitization on untrusted user inputs.

Detailed Explanation

// Safe vs. Dangerous HTML Rendering in Angular:
import { Component, inject, SecurityContext } from '@angular/core';
import { DomSanitizer, SafeHtml } from '@angular/platform-browser';

@Component({
  selector: 'app-security-demo',
  standalone: true,
  template: `
    <!-- 1. Safe default: Angular automatically strips <script> tags and onerror handlers -->
    <div [innerHTML]="rawUserComment"></div>

    <!-- 2. Trusted CMS content: Sanitized with DomSanitizer only if strictly verified -->
    <div [innerHTML]="safeCmsArticle"></div>
  `
})
export class SecurityDemoComponent {
  private readonly sanitizer = inject(DomSanitizer);

  // Safe: Angular strips the malicious script tag automatically
  readonly rawUserComment = '<p>Great job! <script>alert("XSS")</script></p>';

  // Trusted content: only bypass after strict server-side validation!
  readonly safeCmsArticle: SafeHtml = this.sanitizer.bypassSecurityTrustHtml(
    '<article class="cms-body"><h3>Official Announcement</h3><p>Verified text.</p></article>'
  );

  // DANGEROUS ANTI-PATTERN (NEVER DO THIS):
  // injectDangerousInput(userInput: string) {
  //   return this.sanitizer.bypassSecurityTrustHtml(userInput); // Instant XSS!
  // }
}

Common Interview Pitfalls

• Using ElementRef.nativeElement.innerHTML to insert HTML, which bypasses Angular sanitization and exposes the app to XSS.
• Passing unsanitized user query strings or chat messages into DomSanitizer.bypassSecurityTrustHtml().
• Assuming Angular templates eliminate the need for server-side input validation and Content Security Policies.
• Using template template-expression javascript: links in [href] bindings.

Direct Answer

Optimizing Angular bundle size involves auditing initial vs lazy chunks, configuring fine-grained route boundaries, eliminating dead code via tree-shaking, and replacing heavy dependencies. Developers use source-map explorers to evaluate transfer size, parse costs, and caching strategies.

Detailed Explanation

// Optimizing Third-Party Dependency Imports for Tree-Shaking:

// BAD (Pulls in entire monolithic library, defeating tree-shaking):
// import * as lodash from 'lodash';
// import { format } from 'date-fns'; // If unoptimized commonjs version

// GOOD (Fine-grained ES module import: only bundles the specific function):
import debounce from 'lodash-es/debounce';

// Component leveraging optimized imports and Angular defer syntax:
import { Component } from '@angular/core';

@Component({
  selector: 'app-heavy-dashboard',
  standalone: true,
  template: `
    <header class="header">
      <h1>Dashboard Overview</h1>
    </header>

    <!-- @defer: heavy charting component is code-split and loaded only on scroll -->
    @defer (on viewport) {
      <app-heavy-chart />
    } @placeholder {
      <div class="chart-skeleton">Loading chart visualization...</div>
    }
  `
})
export class HeavyDashboardComponent {}

Common Interview Pitfalls

• Importing from commonjs packages instead of ES module alternatives (e.g. lodash vs lodash-es), preventing tree-shaking.
• Allowing heavy third-party charting or PDF generation libraries to be imported into root services, inflating the initial bundle.
• Ignoring build budget warnings in angular.json and raising limits without analyzing dependency bloat.
• Including polyfills for legacy browsers that are not required for the application target support matrix.

Direct Answer

Route guards control client-side UI navigation transitions, while HTTP interceptors centrally attach bearer tokens and handle 401 refresh flows. Neither replaces backend security; the server must independently authenticate every request and enforce access control regardless of client guards.

Detailed Explanation

// Modern Functional Route Guard and HTTP Interceptor:
import { inject } from '@angular/core';
import { Router, CanActivateFn } from '@angular/router';
import { HttpInterceptorFn, HttpRequest, HttpHandlerFn } from '@angular/common/http';
import { AuthService } from './auth.service';
import { catchError } from 'rxjs/operators';
import { throwError } from 'rxjs';

// 1. Functional Route Guard (CanActivateFn)
export const authGuard: CanActivateFn = (route, state) => {
  const authService = inject(AuthService);
  const router = inject(Router);

  if (authService.isAuthenticated()) {
    return true; // Navigation allowed
  }

  // Redirect to login preserving return URL
  return router.createUrlTree(['/login'], { queryParams: { returnUrl: state.url } });
};

// 2. Functional HTTP Auth Interceptor (HttpInterceptorFn)
export const authInterceptor: HttpInterceptorFn = (req: HttpRequest<unknown>, next: HttpHandlerFn) => {
  const authService = inject(AuthService);
  const token = authService.getAccessToken();

  // Clone request to attach Bearer header if token exists
  const authReq = token 
    ? req.clone({ setHeaders: { Authorization: `Bearer ${token}` } })
    : req;

  return next(authReq).pipe(
    catchError(err => {
      if (err.status === 401) {
        authService.handleSessionExpiry();
      }
      return throwError(() => err);
    })
  );
};

Common Interview Pitfalls

• Assuming client-side route guards prevent unauthorized access to backend data without enforcing API authorization.
• Mutating HttpRequest objects directly instead of using req.clone(), which throws runtime immutability errors.
• Creating circular dependency loops between HttpClient and AuthService inside HTTP interceptors.
• Failing to handle 401 response cascades when multiple concurrent requests fail upon token expiration.

Direct Answer

Production Angular error handling combines a custom ErrorHandler class for logging uncaught runtime exceptions with RxJS catchError operators on inner HTTP streams for localized user recovery. Interceptors handle transversal concerns like 401 redirects without swallowing business errors.

Detailed Explanation

// Robust Layered Error Handling Architecture:
import { Injectable, ErrorHandler, Component, inject, signal } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { of } from 'rxjs';
import { switchMap, catchError, retry } from 'rxjs/operators';

// 1. Custom Global ErrorHandler for Remote Telemetry
@Injectable()
export class GlobalLoggingErrorHandler implements ErrorHandler {
  handleError(error: unknown): void {
    const message = error instanceof Error ? error.message : String(error);
    const stack = error instanceof Error ? error.stack : '';

    console.error('Unhandled Application Exception:', message);
    // Dispatch to enterprise telemetry endpoint (e.g. Sentry / Datadog)
    // telemetryService.logCrash({ message, stack, url: window.location.href });
  }
}

// 2. Component demonstrating local HTTP error recovery
@Component({
  selector: 'app-data-widget',
  standalone: true,
  template: `
    @if (errorMessage()) {
      <div class="error-banner">
        <span>{{ errorMessage() }}</span>
        <button (click)="retryLoad()">Retry</button>
      </div>
    }
  `
})
export class DataWidgetComponent {
  private readonly http = inject(HttpClient);
  readonly errorMessage = signal<string | null>(null);

  loadData(): void {
    this.errorMessage.set(null);

    this.http.get('/api/critical-data').pipe(
      // Retry transient failures up to 2 times before giving up
      retry({ count: 2, delay: 500 }),
      // Local recovery: capture error and surface friendly UI state
      catchError(err => {
        this.errorMessage.set('Unable to load critical data. Please try again.');
        return of(null); // Keeps stream alive
      })
    ).subscribe();
  }

  retryLoad(): void {
    this.loadData();
  }
}

Common Interview Pitfalls

• Swallowing errors silently in catchError without logging or alerting the user, creating mysterious blank screens.
• Placing catchError on the outer stream instead of the inner HTTP observable, permanently terminating search inputs on network errors.
• Using the global ErrorHandler to handle expected HTTP 404 or form validation errors.
• Throwing raw strings instead of standard Error objects, losing stack trace information in telemetry logs.

Direct Answer

Treat cross-user data leakage as an active security incident. The root cause is public CDN caching of personalized SSR HTML keyed solely by URL. Immediately purge and disable shared caching on authenticated routes, isolate request-scoped state, and separate public SSR shells from private data.

Detailed Explanation

# Secure SSR Cache-Control Header Configuration and Request Isolation:
import { provideServerRendering } from '@angular/platform-server';
import { ApplicationConfig, REQUEST, inject } from '@angular/core';
import { HttpInterceptorFn } from '@angular/common/http';
import { Request, Response } from 'express';

// 1. Express / Node.js Server Middleware enforcing safe Cache-Control
export function enforceSsrSecurityHeaders(req: Request, res: Response, next: () => void): void {
  // If the request contains an authentication cookie or header, NEVER cache in public CDN
  if (req.headers.cookie?.includes('auth_session') || req.headers.authorization) {
    res.setHeader('Cache-Control', 'private, no-cache, no-store, must-revalidate');
    res.setHeader('Pragma', 'no-cache');
    res.setHeader('Expires', '0');
  } else {
    // Public unauthenticated routes only
    res.setHeader('Cache-Control', 'public, max-age=300, s-maxage=600');
  }
  next();
}

// 2. Request-scoped SSR HttpInterceptor ensuring server requests use the current caller's context
export const ssrAuthForwardingInterceptor: HttpInterceptorFn = (req, next) => {
  // Access the current request in the server injection context
  const serverRequest = inject(REQUEST, { optional: true }) as Request | null;

  if (serverRequest && serverRequest.headers.cookie) {
    // Forward caller's session cookie to internal backend API
    const cloned = req.clone({
      setHeaders: { Cookie: serverRequest.headers.cookie }
    });
    return next(cloned);
  }

  return next(req);
};

Common Interview Pitfalls

• Configuring public CDN caching on authenticated routes, causing users to see cached server HTML belonging to previous visitors.
• Treating cross-user data exposure as a minor hydration bug instead of an active confidentiality security incident.
• Storing request-specific or user-specific data in server-side singleton services, leaking state between concurrent SSR requests.
• Embedding sensitive authorization tokens or private credentials in Angular TransferState payloads.