Full-Stack-Entwickler Interviewfragen & Antworten

Beispielantwort

Ich habe einen Echtzeit-Aktivitätsfeed für ein Projektmanagement-Tool gebaut. Auf der Backend-Seite habe ich ein Event-Sourcing-System mit PostgreSQL entworfen: Jede Projektaktion (Aufgabe erstellt, Kommentar hinzugefügt, Status geändert) schrieb einen Event-Datensatz mit Zeitstempel, Akteur, Aktionstyp und Metadaten. Ich baute einen Node.js-API-Endpunkt mit cursorbasierter Paginierung und WebSocket-Kanälen für Echtzeit-Updates. Auf der Frontend-Seite erstellte ich eine React-Komponente mit einer virtualisierten Liste (react-window), um Feeds mit mehr als 10.000 Events ohne DOM-Performanceprobleme zu verarbeiten. Neue Events erschienen in Echtzeit über WebSocket mit flüssigen Einfüge-Animationen. Ich fügte auch eine Filterung nach Event-Typ und Person hinzu, die einen dedizierten partiellen PostgreSQL-Index nutzte. Das Feature wurde in 5 Wochen ausgeliefert und wurde zur meistgenutzten Seite in der Anwendung: 78 % der täglich aktiven Nutzer besuchten sie mindestens einmal pro Sitzung.

Beispielantwort

Wir benötigten Preisberechnungen für ein Angebots-Tool. Der Product Manager wollte sofortige Preisaktualisierungen, wenn Nutzer Mengen und Optionen änderten. Die erste Implementierung legte die gesamte Preislogik ins React-Frontend für sofortiges Feedback. Das funktionierte, bis wir Abweichungen entdeckten: Das Frontend berechnete 1.247 €, aber die Auftragsbestätigungs-API lieferte 1.251 € zurück, weil unterschiedliche Rundungsansätze verwendet wurden. Ich verschob die maßgebliche Preislogik in die Backend-API und erstellte einen leichtgewichtigen Frontend-Schätzer, der vereinfachte Regeln für sofortiges Feedback nutzte und klar als „Schätzpreis“ gekennzeichnet war. Wenn der Nutzer das Angebot abschloss, berechnete das Backend den exakten Preis. Dieses Muster „optimistisches Frontend, maßgebliches Backend“ löste sowohl die Anforderungen an Geschwindigkeit als auch an Genauigkeit. Die Erkenntnis: Geschäftskritische Berechnungen müssen eine einzige Quelle der Wahrheit auf dem Backend haben. Das Frontend darf für die UX schätzen, aber der Server entscheidet.

Beispielantwort

Unser Team hatte separate Frontend- und Backend-Repositories mit unterschiedlichen Deployment-Zyklen. Frontend-Entwickler warteten ständig darauf, dass Backend-APIs fertig waren, bevor sie integrieren konnten. Ich führte zwei Änderungen ein. Erstens richtete ich einen Contract-First-API-Entwicklungsworkflow mit OpenAPI-Spezifikationen ein: Wir einigten uns auf den API-Vertrag, bevor eine der beiden Seiten mit dem Bauen begann, und dann entwickelten Frontend- und Backend-Teams parallel, wobei die Spezifikation als einzige Quelle der Wahrheit diente. Ich konfigurierte Mock-Server aus der OpenAPI-Spezifikation, damit das Frontend gegen realistische Antworten entwickeln konnte, bevor das Backend fertig war. Zweitens erstellte ich ein Docker-Compose-Setup, das den gesamten Stack lokal mit einem Befehl aufsetzte, einschließlich Datenbank-Seeding und Mock-Diensten für externe Services. Integrationsprobleme, die bisher erst in der Staging-Umgebung auftauchten, wurden nun auf den Entwickler-Maschinen sichtbar. Das Ergebnis: Die Sprint-Abschlussrate verbesserte sich von 68 % auf 91 %, weil teamübergreifende Abhängigkeiten den Fortschritt nicht mehr blockierten.

Beispielantwort

Wir migrierten Nutzerdaten von Firebase nach PostgreSQL, während die React-App weiterlief. Die Herausforderung: 200.000 Nutzer mit verschachtelten Dokumentstrukturen, die in relationale Tabellen normalisiert werden mussten. Ich baute eine Migrationspipeline in drei Phasen. Phase 1: Schema-Design. Ich ordnete Firebase-Dokumentstrukturen PostgreSQL-Tabellen zu und normalisierte verschachtelte Arrays in Zwischentabellen. Phase 2: Parallelbetrieb. Die Anwendung schrieb gleichzeitig in Firebase und PostgreSQL über eine Middleware-Schicht. Lesezugriffe blieben auf Firebase. Phase 3: Validierung und Umschaltung. Ich schrieb ein Abgleich-Skript, das täglich 10.000 zufällige Datensätze zwischen beiden Datenbanken verglich. Nach 2 Wochen ohne Abweichungen wechselten wir die Lesezugriffe auf PostgreSQL und schalteten Firebase-Schreibzugriffe ab. Gesamte Migrationszeit: 4 Wochen ohne eine einzige Unterbrechung für Nutzer. Das Abgleich-Skript entdeckte 3 Randfälle in der Dual-Write-Logik, die bei einer Big-Bang-Migration zu Datenverlust geführt hätten.

Beispielantwort

Die zentrale Herausforderung ist die Konfliktlösung bei gleichzeitigen Bearbeitungen mehrerer Nutzer. Ich würde Operational Transformation (OT) oder CRDTs (Conflict-free Replicated Data Types) einsetzen. CRDTs sind moderner und benötigen keinen zentralen Server für die Konfliktlösung, was sie robuster macht. Architektur: Das Frontend nutzt einen Rich-Text-Editor (Tiptap/ProseMirror) mit einer CRDT-Bibliothek (Yjs), die lokale Bearbeitungen optimistisch verarbeitet. Änderungen werden per WebSocket an einen Node.js-Server übertragen, der sie an alle verbundenen Clients verteilt. Der Server speichert den Dokumentzustand auch in PostgreSQL als serialisiertes CRDT bei jeder Änderung (per Debouncing, um übermäßige Schreibzugriffe zu vermeiden). Für Präsenz: Jeder Client sendet Cursorposition und Auswahl über den WebSocket-Kanal, und andere Clients stellen farbige Cursor dar. Für Offline-Unterstützung: Yjs übernimmt das Zusammenführen, wenn ein Client wieder verbindet, und wendet Offline-Änderungen auf den aktuellen Dokumentzustand an. Skalierungsüberlegungen: Redis Pub/Sub für die Verteilung von Änderungen über mehrere Server-Instanzen, Partitionierung von WebSocket-Verbindungen nach Dokument-ID und Lazy Loading für sehr lange Dokumente.

Beispielantwort

Client-Side-Rendering (CSR): Der Server schickt eine minimale HTML-Hülle, JavaScript lädt herunter und rendert die Seite im Browser. Vorteile: flüssige Seitenübergänge, reduzierte Serverlast, gut geeignet für authentifizierte Dashboards. Nachteile: langsamere erste Ladezeit (leere Seite bis JavaScript ausgeführt wird), schlechte SEO (Suchmaschinen führen JavaScript möglicherweise nicht aus), schlechtere Core Web Vitals. Server-Side-Rendering (SSR): Der Server rendert das vollständige HTML für jede Anfrage. Vorteile: schnelle First-Contentful-Paint, ausgezeichnete SEO, funktioniert ohne JavaScript. Nachteile: höhere Serverlast, vollständige Seitenneuladen fühlen sich langsamer an, interaktive Funktionen schwieriger umzusetzen. Ich wähle CSR für authentifizierte Anwendungen (Dashboards, Admin-Panels, SaaS-Tools), bei denen SEO keine Rolle spielt und Interaktivität im Vordergrund steht. Ich wähle SSR für öffentlich zugängliche Inhalte (Marketing-Seiten, Blogs, E-Commerce-Produktseiten), bei denen SEO und initiale Ladezeit entscheidend sind. Moderne Frameworks (Next.js, Nuxt, Remix) erlauben die Kombination beider Ansätze: SSR für den initialen Ladevorgang mit clientseitiger Hydration für Interaktivität. Static Site Generation (SSG) ist noch besser für Inhalte, die sich nicht pro Anfrage ändern.

Beispielantwort

Ich implementiere JWT-basierte Authentifizierung mit einer spezifischen Token-Strategie. Das Access-Token (JWT) ist kurzlebig (15 Minuten), enthält Nutzeridentität und Rollen und wird im Authorization-Header übertragen. Das Refresh-Token ist langlebig (7 Tage), undurchsichtig (kein JWT), in einem HTTP-Only Secure SameSite-Cookie gespeichert und einem Datenbankdatensatz zugeordnet, damit es widerrufen werden kann. Der Ablauf: Der Nutzer meldet sich an, der Server prüft die Anmeldedaten, gibt das Access-Token im Antwort-Body zurück und setzt das Refresh-Token-Cookie. Das Frontend speichert das Access-Token im Arbeitsspeicher (nicht in localStorage, das ist XSS-anfällig). Wenn das Access-Token abläuft, ruft das Frontend stillschweigend den Refresh-Endpunkt auf, der das Cookie prüft und ein neues Access-Token zurückgibt. Beim Abmelden werden beide Token serverseitig invalidiert. Für OAuth (Google, GitHub) verwende ich den Authorization-Code-Flow: Weiterleitung zum Anbieter, Code-Empfang beim Callback, Austausch des Codes gegen Anbieter-Token serverseitig, Erstellung oder Verknüpfung des Nutzerkontos und Ausgabe unseres eigenen JWT. Ich vertraue clientseitigen Token von OAuth-Anbietern niemals direkt.

Beispielantwort

Ich implementiere Fehlerbehandlung auf vier Ebenen. Backend-API: Alle Fehler geben ein einheitliches JSON-Format zurück mit Statuscode, Fehlercode (maschinenlesbar), Nachricht (menschenlesbar) und optionalem Details-Feld. Ich verwende HTTP-Statuscodes korrekt: 400 für Validierung, 401 für Authentifizierung, 403 für Autorisierung, 404 für nicht gefunden, 409 für Konflikte, 500 für Serverfehler. In Produktionsantworten gebe ich niemals Stack-Traces oder interne Details preis. Backend-Service-Schicht: try/catch bei externen Aufrufen und Datenbankoperationen, mit spezifischen Fehlertypen (NotFoundError, ValidationError, ConflictError), die auf HTTP-Antworten abgebildet werden. Unbehandelte Fehler landen in einem globalen Fehlerbehandler, der den vollständigen Fehler protokolliert und einen generischen 500 zurückgibt. Frontend-API-Schicht: Ein zentralisierter API-Client, der häufige Fehler verarbeitet: 401 löst eine Token-Aktualisierung aus, 403 zeigt eine Zugriffsverweigerungs-Meldung, 429 zeigt eine Rate-Limit-Nachricht, 500 zeigt einen generischen Fehler mit Retry-Option. Frontend-UI: Error Boundaries fangen Rendering-Fehler ab, Toast-Benachrichtigungen für nicht-blockierende Fehler und Inline-Validierung für Formularfehler. Jeder Fehler wird protokolliert: Serverfehler in strukturiertes Logging (Pino), Client-Fehler an einen Fehler-Tracking-Dienst (Sentry).

Beispielantwort

Ich würde mit einem Monolithen starten, sofern es keinen zwingenden Grund dagegen gibt. Microservices erhöhen die operative Komplexität (Netzwerke, Deployment, Monitoring, Debugging verteilter Systeme), die sich nur bei bestimmten Teamgrößen und Skalierungsanforderungen rechtfertigt. Ich wähle einen Monolithen, wenn das Team weniger als 10 Entwickler hat, das Produkt noch kein Product-Market-Fit gefunden hat (schnelle Iteration ist wichtiger als Skalierbarkeit) und kein unmittelbarer Bedarf an unabhängiger Skalierung oder Deployment spezifischer Komponenten besteht. Ich wähle Microservices, wenn verschiedene Komponenten grundlegend unterschiedliche Skalierungsanforderungen haben (ein CPU-intensiver Bildprozessor gegenüber einer leichtgewichtigen API), Teams unabhängig deployen müssen (mehr als 10 Entwickler, mehrere Squads) oder die Domäne sich natürlich in abgegrenzte Bounded Contexts aufteilt. Der pragmatische Mittelweg: einen modularen Monolithen mit klaren internen Grenzen bauen. Wenn ein Modul später ein eigener Service werden muss, ist die Trennung bereits sauber. Das vermeidet die Komplexität verteilter Systeme und bewahrt gleichzeitig die Möglichkeit zur Aufteilung, wenn der Bedarf real ist.

Beispielantwort

Ich würde es zuerst prototypisch umsetzen, statt zu spekulieren. Ich würde die Animation mit CSS-Transforms und Opacity bauen (die GPU-beschleunigt sind und kein Layout-Reflow auslösen) und sie auf einem repräsentativen Mid-Range-Android-Gerät testen, nicht auf meinem MacBook Pro. Wenn sie auf diesem Gerät mit 60fps läuft, wird sie ausgeliefert. Falls nicht, würde ich den Engpass mit dem Chrome-DevTools-Performance-Panel analysieren: Handelt es sich um Layout-Thrashing, Paint-Operationen oder Main-Thread-Blockierung? Dann würde ich auf Basis des konkreten Problems Alternativen vorschlagen. Vielleicht können wir die Web Animations API für besseres Frame-Scheduling einsetzen. Vielleicht reduzieren wir die Anzahl der animierten Elemente. Vielleicht nutzen wir will-change, um Ebenen in die GPU zu befördern. Vielleicht wird die Animation nur einmal statt kontinuierlich abgespielt. Ich würde dem Designer ein Spektrum präsentieren: „Hier ist die vollständige Animation mit 30fps auf dem Mobilgerät. Hier ist eine vereinfachte Version mit 60fps. Hier ist ein statischer Fallback.“ Der Designer soll den Kompromiss wählen. Oft bevorzugen Designer die flüssige einfache Version gegenüber der ruckelnden komplexen.

Beispielantwort

Ich würde zuerst verstehen warum: Sind diese Aufrufe unabhängig oder haben sie Abhängigkeiten? Sind sie alle für das initiale Rendering notwendig? Meine Optimierungsstrategien nach Auswirkung geordnet: Erstens, Aufrufe identifizieren, die nicht für das initiale Rendering benötigt werden, und sie verschieben. Daten unterhalb des sichtbaren Bereichs beim Scrollen laden, sekundäre Panels bei Interaktion laden. Das könnte die initialen Aufrufe von 15 auf 5 reduzieren. Zweitens, verwandte Aufrufe bündeln: Wenn wir Nutzerprofil, Nutzereinstellungen und Benachrichtigungen separat abrufen, einen BFF-Endpunkt (Backend for Frontend) erstellen, der alle Nutzerdaten in einem Aufruf zurückgibt. Drittens, GraphQL oder ein Composite-API-Muster einsetzen, wenn die Fragmentierung ein systemisches Problem ist. Das Frontend soll genau die benötigten Daten in einem Aufruf anfordern können. Viertens, aggressiv cachen: React Querys Stale-While-Revalidate-Muster für Daten nutzen, die sich selten ändern. Fünftens, Prefetching: Wenn der Nutzer wahrscheinlich von Seite A zu Seite B navigiert, mit dem Abrufen der Daten von Seite B beim Hover beginnen. Ich würde die Auswirkung messen: Gesamte Seitenladezeit, Time to Interactive und Anzahl der Netzwerkanfragen.

Beispielantwort

Ich würde die Schulden quantifizieren, statt sie nur als „technische Schulden“ zu bezeichnen. Was genau wird dadurch schwieriger oder kaputt gehen? Wie viele zukünftige Features sind betroffen? Was sind die Wartungskosten über 12 Monate? Dann würde ich Alternativen vorschlagen. Option A: Es auf die richtige Weise bauen. Dauert länger, hinterlässt aber keine Schulden. Option B: Die Kundenlösung hinter einem Feature-Flag als benutzerdefinierte Erweiterung bauen, mit einem Plan, sie zu verallgemeinern, wenn andere Kunden ähnliche Funktionen benötigen. Option C: Die schnelle Version bauen mit einem dokumentierten Schulden-Eintrag, einem verbindlichen Zeitplan für das Refactoring und der Zustimmung des Product Owners, dass dadurch Wartungskosten entstehen. Ich würde den Kompromiss klar darstellen: „Wir können in 2 Wochen mit Ansatz C ausliefern, aber dadurch wird Feature X im nächsten Quartal um 1 Woche und Feature Y um 3 Tage verzögert.“ Wenn man die nachgelagerten Kosten so quantifiziert, wird die Entscheidung meist offensichtlich. Wenn das Unternehmen entscheidet, dass die Schnelligkeit die Schulden wert ist, ist das eine legitime Entscheidung. Aber sie sollte explizit getroffen werden.