Angular 19 Interviewfragen: Signals, SSR und unverzichtbare Konzepte

Angular-Interviews im Jahr 2026 gehen weit über Komponenten und Services hinaus. Angular 19, im November 2024 veröffentlicht, brachte grundlegende architektonische Veränderungen: stabile Signals, SSR mit inkrementeller Hydration und Change Detection ohne Zone.js. Die Beherrschung dieser Konzepte trennt Mid-Level-Kandidaten von Senior-Entwicklern.

Angular 19 Signals: das neue Reaktivitätsmodell

Signals stellen die tiefgreifendste Veränderung in Angular seit Einführung der Change Detection dar. Ein Signal ist ein synchroner reaktiver Wert, der seine Konsumenten automatisch benachrichtigt, wenn er sich ändert.

Typische Frage: "Was ist der Unterschied zwischen einem Signal und einem RxJS Observable?"

Die erwartete Antwort unterscheidet beide Modelle klar:

import { signal, computed, effect } from '@angular/core';

// Signal: synchronous, value always available
const count = signal(0);
const doubled = computed(() => count() * 2); // Recomputed only when count changes

// Effect: reacts to signal changes
effect(() => {
  console.log(`Count: ${count()}, Doubled: ${doubled()}`);
});

count.set(5); // Immediate, synchronous notification

Signals nutzen einen feingranularen Abhängigkeitsgraphen. Anders als RxJS, das komplexe asynchrone Workflows abdeckt (retry, debounce, merge), optimieren Signals die synchrone UI-Reaktivität. Angular 19 empfiehlt Signals für Komponentenzustand und RxJS für asynchrone Streams (HTTP-Anfragen, WebSockets).

Signal Inputs und Queries: Migration von @Input()

Angular 19 stabilisiert die signal-basierten APIs für Inputs, Outputs und Queries. Diese Frage taucht regelmäßig in Interviews auf.

Typische Frage: "Wie migriert man ein klassisches @Input() zu einem Signal Input?"

import { Component, input, computed } from '@angular/core';

@Component({
  selector: 'app-user-card',
  template: `
    <div class="card">
      <h3>{{ fullName() }}</h3>
      <span>{{ role() }}</span>
    </div>
  `
})
export class UserCardComponent {
  // Signal inputs: strict typing, optional default value
  firstName = input.required<string>();
  lastName = input.required<string>();
  role = input<string>('developer'); // Default value

  // Computed derived from inputs: automatically recomputed
  fullName = computed(() => `${this.firstName()} ${this.lastName()}`);
}

Der entscheidende Vorteil: Signal Inputs ermöglichen es, computed()-Werte direkt zu erstellen, ohne Lifecycle-Hooks. Kein ngOnChanges mehr, um auf Input-Änderungen zu reagieren. Angular bietet das Schematic signal-input-migration zur Automatisierung der Migration.

linkedSignal: Synchronisation abhängiger Zustände

linkedSignal ist eine experimentelle Angular-19-API, die ein beschreibbares, an eine Quelle gekoppeltes Signal erzeugt. Dieses Konzept taucht häufig in Senior-Interviews auf.

Typische Frage: "Wie verwaltet man veränderlichen abgeleiteten Zustand mit linkedSignal?"

import { signal, linkedSignal } from '@angular/core';

// Category list that can change
const categories = signal(['frontend', 'backend', 'devops']);

// Linked selection: resets when categories change
const selectedCategory = linkedSignal({
  source: categories,
  computation: (cats) => cats[0] // Reset to first element
});

// Manual modification still possible
selectedCategory.set('backend');

// When categories changes, selectedCategory resets automatically
categories.set(['mobile', 'data', 'cloud']);
// selectedCategory() === 'mobile'

Konkreter Anwendungsfall: ein Filter-Dropdown, dessen Auswahl zurückgesetzt wird, wenn sich die Quellliste ändert. Ohne linkedSignal erforderte dieses Muster ein effect() mit set(), ein Anti-Pattern, das Update-Schleifen erzeugt.

Resource API: asynchrones Laden mit Signals

Angular 19 führt die experimentelle resource-API für asynchrones Datenladen ein. Diese API ersetzt das klassische Service-+-Subscribe-Muster in Komponenten.

import { resource, signal } from '@angular/core';
import { inject } from '@angular/core';
import { HttpClient } from '@angular/common/http';

const userId = signal(42);
const http = inject(HttpClient);

// Resource: links a source signal to an async loader
const userResource = resource({
  request: () => ({ id: userId() }),  // Recomputed when userId changes
  loader: async ({ request }) => {
    const response = await fetch(`/api/users/${request.id}`);
    return response.json();
  }
});

// Access in template
// userResource.value()   -> data (or undefined)
// userResource.isLoading() -> boolean
// userResource.error()    -> error if any

Im Interview Kenntnisse über resource versus rxResource (RxJS-Variante) zu zeigen, beweist aktive technologische Wachsamkeit. rxResource nutzt Observables als Loader, was für Teams mit bestehender RxJS-Codebasis hilfreich ist.

SSR und inkrementelle Hydration in Angular 19

Angular 19 hebt SSR mit inkrementeller Hydration in Developer Preview auf das nächste Level. Dieses Feature, in Google-Search-Maßstab getestet, ist ein zunehmend häufiges Interview-Thema.

Typische Frage: "Wie funktioniert die inkrementelle Hydration von Angular 19?"

Die klassische Hydration baut nach dem Server-Rendering den gesamten Komponentenbaum auf der Client-Seite neu auf. Die inkrementelle Hydration hydratisiert nur die nötigen Komponenten, sobald sie sichtbar oder interaktiv werden.

import { Component } from '@angular/core';

@Component({
  template: `
    <app-header />
    <app-product-details [id]="productId" />

    <!-- Hydrated only when visible in viewport -->
    @defer (on viewport) {
      <app-reviews [productId]="productId" />
    }

    <!-- Hydrated only on user interaction -->
    @defer (on interaction) {
      <app-comment-form />
    }
  `
})
export class ProductPageComponent {
  productId = 'angular-19-guide';
}

Die @defer-Direktive steuert präzise, wann die Hydration erfolgt. Verfügbare Trigger: on viewport (sichtbar), on interaction (Klick, Focus), on idle (Browser im Leerlauf), on timer(5s) (verzögert). Der Inhalt bleibt vor der Hydration als statisches HTML sichtbar, ohne Flackern.

Render Mode pro Route: granulares SSR pro Route

Angular 19 führt Render Mode auf Routenebene ein und ermöglicht damit die Koexistenz von SSR, SSG und CSR innerhalb derselben Anwendung.

import { RenderMode, ServerRoute } from '@angular/ssr';

export const serverRoutes: ServerRoute[] = [
  // Marketing pages: pre-rendered at build time (SSG)
  { path: '', renderMode: RenderMode.Prerender },
  { path: 'pricing', renderMode: RenderMode.Prerender },

  // Dashboard: server-rendered on each request (SSR)
  { path: 'dashboard/**', renderMode: RenderMode.Server },

  // Interactive editor: client-side only (CSR)
  { path: 'editor/**', renderMode: RenderMode.Client },
];

Im Interview zeigt die Fähigkeit, die Wahl des Render Mode pro Route zu begründen, Verständnis für die Trade-offs zwischen Performance, SEO und Interaktivität. Statische Seiten (Landing, Blog) profitieren vom Prerendering. Dynamische Seiten mit Nutzerdaten verwenden SSR. Hochinteraktive Anwendungen bleiben bei CSR.

Zoneless Change Detection: Architektur ohne Zone.js

Zoneless Change Detection ist die bedeutendste architektonische Weiterentwicklung in Angular 19. Diese Frage ist in Senior-Interviews zur Pflicht geworden.

Typische Frage: "Wie funktioniert Change Detection ohne Zone.js?"

import { bootstrapApplication } from '@angular/platform-browser';
import {
  provideExperimentalZonelessChangeDetection
} from '@angular/core';
import { AppComponent } from './app.component';

bootstrapApplication(AppComponent, {
  providers: [
    provideExperimentalZonelessChangeDetection()
  ]
});

Ohne Zone.js patcht Angular die asynchronen Browser-APIs (setTimeout, Promise, addEventListener) nicht mehr. Change Detection wird ausschließlich durch Signals ausgelöst. Messbare Vorteile:

• Bundle-Größe um 10-15 KB reduziert (zone.js entfernt)
• Saubere Stack Traces ohne Zone.js-Frames
• Gezielte Change Detection: nur Komponenten, die ein modifiziertes Signal betrifft, werden neu gerendert

Standalone als Standard: das Ende der NgModules

Angular 19 macht Standalone-Komponenten zum Standardverhalten. Das Flag standalone: true ist nicht mehr nötig. Diese Entscheidung vereinfacht die Architektur und reduziert Boilerplate.

Typische Frage: "Welche Auswirkungen hat standalone-by-default auf die Architektur einer Angular-Anwendung?"

@Component({
  selector: 'app-dashboard',
  imports: [CommonModule, RouterModule, UserCardComponent],
  template: `
    <nav>
      <a routerLink="/home">Home</a>
    </nav>
    @for (user of users(); track user.id) {
      <app-user-card [firstName]="user.firstName" [lastName]="user.lastName" />
    }
  `
})
export class DashboardComponent {
  users = signal<User[]>([]);
}

Jede Komponente deklariert ihre Abhängigkeiten explizit über imports. NgModules bleiben für Abwärtskompatibilität verfügbar, neue Angular-19+-Anwendungen brauchen sie aber nicht mehr. Im Interview wird geschätzt, eine inkrementelle Migration (Komponente für Komponente) statt eines Big-Bang-Ansatzes zu erläutern.

Antwortstrategien für Angular-19-Interviews

Technische Interviewer bewerten drei Dimensionen rund um Angular 19:

• Architektonisches Verständnis: erklären, warum Signals Zone.js progressiv ersetzen, nicht nur, wie sie verwendet werden
• Trade-offs: wissen, wann computed() versus linkedSignal versus effect() einzusetzen ist und wann RxJS beibehalten werden sollte
• Migration: eine inkrementelle Migrationsstrategie von einer klassischen Angular-Anwendung zu Signals und zoneless Modus beschreiben

Der Schlüssel: nicht die offizielle Angular-Dokumentation wiedergeben. Jede Antwort sollte mit einem konkreten Anwendungsfall aus einem realen Projekt veranschaulicht werden, einem komplexen Formular, einer E-Commerce-Seite mit SSR, einem Echtzeit-Dashboard.

Für die grundlegenden Angular-Konzepte vor dem Interview, der vollständige Leitfaden zu den 25 Angular-Interviewfragen.

Fazit

• Angular 19 Signals ersetzen die Muster @Input() + ngOnChanges durch ein feingranulares synchrones reaktives Modell. signal(), computed() und input() decken 90 % der Anwendungsfälle ab
• linkedSignal löst veränderlichen abgeleiteten Zustand, ohne auf das Anti-Pattern effect() + set() zurückzugreifen
• Inkrementelle Hydration über @defer reduziert die Time to Interactive ohne Einbußen beim SEO. Jede Komponente wird gemäß ihrem Trigger hydratisiert
• Der zoneless Modus entfernt Zone.js aus dem Bundle und richtet die Change Detection ausschließlich auf Signal-betroffene Komponenten
• Render Mode pro Route ermöglicht das Mischen von SSG, SSR und CSR in derselben Anwendung je nach Anforderung jeder Seite
• Standalone-by-default-Komponenten machen NgModules in neuen Anwendungen überflüssig
• Im Interview zählt das Aufzeigen der Trade-offs (Signals vs RxJS, SSR vs CSR, zoneless vs Zone.js) mehr als Syntax