React-Frontend-Entwickler-Interviewfragen, die wirklich funktionieren

Einen React-Frontend-Entwickler einzustellen sieht auf dem Papier einfach aus und wird in der Produktion teuer. Viele Interview-Loops optimieren noch immer auf Trivia oder Framework-Keywords – und wundern sich dann, wenn der neue Mitarbeiter mit echter Arbeit kämpft: unordentlicher State, langsame Seiten, Accessibility-Fehler, fragile Tests und unklare Grenzen zwischen UI und API.

Dieser Artikel bietet eine Reihe von React-Frontend-Entwickler-Interviewfragen, die wirklich funktionieren, weil sie an überprüfbare Ergebnisse gebunden sind: Änderungssicherheit, Performance, Accessibility, Wartbarkeit und Produktionsreife.

Mit der Stellenbeschreibung beginnen, nicht mit der Fragenliste

Ein Interview mit hohem Erkenntnisgewinn ist „jobbezogen". Bevor man Fragen auswählt, sollte man klären, was der React-Entwickler in den nächsten 6 bis 12 Monaten tatsächlich verantworten wird.

Typische Varianten:

• Produkt-UI-Entwickler: liefert Features in einer reifen Codebasis, arbeitet mit bestehenden Mustern.
• UI-Platform-Beitragender: entwickelt ein Design-System, gemeinsame Komponenten, Tooling.
• App-Architekt: setzt Grenzen, State-Strategie, Performance-Budgets, Delivery-Standards.
• Full-Stack-naher Frontend-Entwickler: besitzt ein BFF, GraphQL/REST-Verträge, Auth-Flows.

Wer eine schnelle Referenz zu Architekturerwartungen in echten Produktteams sucht, findet in Wolf-Techs Leitfaden zur React-Frontend-Architektur für Produktteams eine gute Baseline.

Ein praktischer Interview-Loop (optimiert für Erkenntnisgewinn)

Man erhält mehr Konsistenz und weniger Bias, wenn jeder Kandidat dieselben „evidenzerzeugenden" Schritte durchläuft.

Stufe	Dauer	Was bewertet wird	Beispiel-Artefakt, das man möchte	Häufiger Fehler, den man abfängt
Screening	20–30 Min	Kommunikation, Grundlagen, Stellenfit	Klare Erklärung einer vergangenen React-Entscheidung	Flache Erfahrung, übertriebene Angaben
Technical Deep Dive	45–60 Min	React, State, Async, Korrektheit	Präzises Reasoning über einen Bug oder Trade-off	„Läuft auf meiner Maschine"-Denken
Praktische Übung	60–90 Min	Liefer-Mindset, Debugging, Qualitätsgewohnheiten	Funktionierendes Feature mit Tests oder Leitplanken	Cargo-Cult-Muster, fragiler Code
System Design (für Mid/Senior)	45–60 Min	Architektur, Grenzen, Betreibbarkeit	Modulgrenzen, Datenfluss, NFR-Denken	Over-Engineering, kein Skalierungsplan
Team-Interview	30–45 Min	Zusammenarbeit, Review-Stil, UX-Abstimmung	Gute Fragen, klare Annahmen	Schlechte Kommunikation, wenig Ownership

React-Grundlagen: Fragen, die echtes Verständnis zeigen

Das sind keine „Hook definieren"-Fragen. Sie testen, ob der Kandidat über Rendering, Effects und State-Korrektheit nachdenken kann.

Rendering und Reconciliation

Fragen:

• „Erklären Sie mir, was passiert, wenn State in einer Komponente aktualisiert wird. Wann rendert React neu, und was bedeutet das für Kind-Komponenten?"
• „Welche Probleme lösen Sie mit Keys in Listen, und welches Risiko birgt die Verwendung von Array-Indexes als Keys?"

Was gut aussieht:

• Erklärt, dass State-Updates Renders einplanen, React reconciliert, dann committet.
• Erwähnt referenzielle Gleichheit, Props-Änderungen und wie übergeordnete Renders kaskadieren können.
• Versteht Keys als Identität und Index-Keys, die State-Bugs bei Einfügen/Neuordnen verursachen.

Follow-up, das Mid von Senior trennt:

• „Wie würden Sie beweisen, dass ein Re-Render-Problem real ist (und nicht raten)?"
  • Starke Kandidaten erwähnen React DevTools Profiler, Flamegraphs und Messung.

Referenz: Reacts offizielle Hooks-Dokumentation ist eine solide Erwartungs-Baseline.

Effects und Lifecycle-Fallstricke

Fragen:

• „Geben Sie ein Beispiel für einen Bug, der durch useEffect-Abhängigkeiten verursacht wurde. Wie haben Sie ihn behoben?"
• „Wann würden Sie useEffect ganz vermeiden?"

Was gut aussieht:

• Versteht Stale Closures, fehlende Abhängigkeiten und Effect-Cleanup.
• Leitet Werte bevorzugt während des Renderings ab, wenn möglich.
• Verwendet Effects für Synchronisation, nicht zum Berechnen von State, der abgeleitet werden kann.

Red Flags:

• „Ich deaktiviere die Lint-Regel, weil sie nervig ist."
• Verwendet Effects standardmäßig für Datenfluss statt für Seiteneffekte.

State und Data-Fetching: der Bereich mit dem höchsten ROI beim Interview

In Produktions-UIs kommt die meiste Komplexität aus asynchronen Daten, Caching, Invalidierung und gemischten State-Typen.

Fragen:

• „Wie trennen Sie Server-State, Client-UI-State, URL-State und Formular-State in einer React-App?"
• „Was ist Ihre Strategie zur Cache-Invalidierung nach einer Mutation?"
• „Wie verhindern Sie Race Conditions in asynchronen Flows (z. B. bei schnellem Filter-Wechsel)?"

Was gut aussieht:

• Benennt verschiedene State-Typen und wählt Tools entsprechend (z. B. URL-Search-Params, eine Server-State-Bibliothek, lokaler UI-State).
• Spricht über optimistische Updates, Invalidierung, idempotente Mutationen und Query-Keys.
• Erwähnt Abbruch von Requests, Tracking der Request-Identität oder Verlassen auf eine Bibliothek, die das verwaltet.

Wer Team-Erwartungen hier standardisieren möchte, passt der Tool-Stack in React-Tools für Produktions-UIs gut zu modernen React-Apps.

Komponenten-Design und TypeScript: auf Wartbarkeit testen

Der langfristige Wert eines React-Frontend-Entwicklers zeigt sich darin, wie er Komponenten-APIs entwirft und unbeabsichtigte Komplexität reduziert.

Fragen:

• „Zeigen Sie mir eine Komponenten-API, auf die Sie stolz sind. Warum ist sie so gestaltet?"
• „Wann bevorzugen Sie Composition gegenüber Props, und wann geht Composition zu weit?"
• „Wie nutzen Sie TypeScript, um ungültige Zustände undarstellbar zu machen?"

Was gut aussieht:

• Verwendet Discriminated Unions für Varianten-Komponenten.
• Vermeidet „Bag of Booleans"-Props.
• Hält Komponenten klein, fokussiert und testbar.

Red Flags:

• Übermäßige Abhängigkeit von any oder Typ-Assertions, um „es zum Kompilieren zu bringen".
• Zu generische Abstraktionen mit unklaren Konsumenten.

Performance: Gewohnheiten interviewen, keine Mikro-Optimierungen

Performance-Arbeit, die zählt, geht meist darum, Verschwendung zu reduzieren und Rendering vorhersehbar zu machen – nicht darum, überall useMemo zu streuen.

Fragen:

• „Welche nutzerzentrierten Metriken sind Ihnen für Frontend-Performance wichtig, und wie messen Sie sie?"
• „Sie liefern eine Dashboard-Seite aus, die sich träge anfühlt. Was ist Ihre erste Untersuchungsstunde?"
• „Was verursacht Hydration-Probleme in SSR-Apps, und wie debuggen Sie sie?" (wenn SSR-Frameworks verwendet werden)

Was gut aussieht:

• Erwähnt Core Web Vitals, Lab- vs. Field-Daten und eine Baseline vor Änderungen.
• Verwendet Browser-Performance-Tools und Profiling, kein Raten.
• Versteht häufige Ursachen für langsame UIs: zu viel JS, schwere Renders, geschwätzige APIs, große Payloads.

Glaubwürdige Referenz für Metriken: Googles Core Web Vitals.

Accessibility: „bewusst" von „kompetent" trennen

Die meisten Teams sagen, Accessibility sei wichtig, interviewen aber nie darauf. Das garantiert schmerzhafte Nachbesserungen später.

Fragen:

• „Wie stellen Sie sicher, dass ein benutzerdefiniertes Dropdown per Tastatur bedienbar ist?"
• „Erklären Sie Focus-Management für ein Modal. Was sollte beim Öffnen und Schließen passieren?"
• „Was bedeutet 'Accessible Name', und wie überprüfen Sie ihn?"

Was gut aussieht:

• Spricht zuerst über semantisches HTML, dann ARIA wenn nötig.
• Erwähnt Tab-Reihenfolge, Focus-Trapping, Escape-to-Close, Fokus wiederherstellen.
• Weiß, wie man zumindest grundlegend nur mit Tastatur und einem Screen-Reader testet.

Referenz: die WAI-ARIA Authoring Practices bieten konkrete erwartete Verhaltensweisen für häufige Komponenten.

Testing: auf Änderungssicherheit achten, nicht auf Framework-Loyalität

Es wird bewertet, ob der Kandidat ausliefern kann, ohne das Produkt zu beschädigen – nicht ob er Jest oder Vitest bevorzugt.

Fragen:

• „Wo hören Unit-Tests in React auf, nützlich zu sein, und wo beginnen Integrationstests?"
• „Wie schreiben Sie stabile UI-Tests, die bei jedem Refactoring nicht brechen?"
• „Wie gehen Sie mit dem Mocking von Netzwerkaufrufen um?"

Was gut aussieht:

• Bevorzugt das Testen von Verhalten, nicht von Implementierungsdetails.
• Kann Trade-offs zwischen Komponenten-Tests und End-to-End-Tests erklären.
• Erwähnt Flakiness-Kontrolle und deterministischen Test-Daten.

Ein nützlicher interner Vergleichspunkt ist Wolf-Techs Betonung testbarer Lieferergebnisse in Frontend-Entwicklungsleistungen: Lieferergebnisse, die zählen, auch wenn intern eingestellt wird.

Sicherheitsgrundlagen für Frontend-Entwickler (oft übersehen)

Frontend-Code beteiligt sich an Sicherheitsergebnissen: XSS-Exposition, Token-Handling und Datenlecks.

Fragen:

• „Was sind Ihre drei wichtigsten Frontend-Sicherheitsrisiken in einer typischen React-App?"
• „Wie verhindern Sie XSS in React, und was kann trotzdem schiefgehen?"
• „Wo sollten Sie Tokens speichern, und welche Trade-offs berücksichtigen Sie?"

Was gut aussieht:

• Weiß, dass React standardmäßig escaped, aber dangerouslySetInnerHTML eine scharfe Kante ist.
• Erwähnt CSP, Sanitierung beim Rendern von HTML und geringstmögliche Datenexposition.
• Versteht Token-Speicher-Trade-offs (Cookies vs. Storage) und Bedrohungsmodelle.

Referenz: OWASP Top 10 ist eine solide Baseline für Sicherheitskompetenz.

Debugging und Produktions-Mindset: der beste Prädiktor für Seniorität

Der größte Unterschied zwischen Levels zeigt sich darin, wie sie sich verhalten, wenn etwas bricht.

Fragen:

• „Erzählen Sie mir von einem Produktions-Incident, an dem Sie beteiligt waren. Was war die Ursache, und was hat sich danach geändert?"
• „Wie machen Sie UI-Fehler in der Produktion sichtbar (und handlungsrelevant)?"
• „Wie entwerfen Sie eine Error-Boundary-Strategie?"

Was gut aussieht:

• Kann einen Incident mit Zeitstempeln, Hypothesen, Belegen und Fixes schildern.
• Erwähnt Logging mit Kontext, clientseitige Fehlerberichte und Rollback-Sicherheit.
• Behandelt Beobachtbarkeit als Teil der Delivery, nicht als Aufgabe eines separaten Teams.

Architektur und Skalierung: Fragen für Mid- und Senior-Kandidaten

Wenn die App mehrere Teams, mehrere Domänen oder langjährige Komplexität hat, ist Architekturdenken nicht optional.

Fragen:

• „Wie würden Sie eine React-Codebasis für ein Produkt strukturieren, das über die Zeit 20+ Ingenieure haben wird?"
• „Welche Grenzen setzen Sie zwischen Features und gemeinsam genutztem Code durch?"
• „Wo leben API-Verträge, und wie stellen Sie sicher, dass sie korrekt sind?"

Was gut aussieht:

• Feature-First-Module, dünne gemeinsame Schichten, Abhängigkeitsregeln.
• Explizite Nähte zwischen UI, Datenzugriff und Domain-Logik.
• Typisierte Verträge, Schema-Validierung oder Contract-Tests je nach Stack.

Für Enterprise-UI-Muster ist JS React Patterns für Enterprise-UIs ein nützlicher Maßstab dafür, wie „gut" im großen Maßstab aussehen kann.

Praktische Übungen, die niemandes Zeit verschwenden

Eine gute Übung ist kurz, realistisch und produziert Belege. Lange Take-Homes, die Freizeit mehr messen als Fähigkeiten, sollten vermieden werden.

Eine aussagekräftige 60–90-minütige Übung

Prompt-Idee:

• Einen kleinen „Users"-Screen mit Filterung und Paginierung bauen.
• Anforderungen umfassen: Ladezustände, Fehlerzustände, Leerzustand und grundlegende Accessibility.
• Eine produktionsnahe Einschränkung hinzufügen: Caching, Abbruch laufender Requests oder URL-synchronisierte Filter.

Was überprüft wird:

• Korrektheit unter State-Änderungen (Filter-Änderungen, schnelles Tippen, Vor/Zurück-Navigation).
• Komponentengrenzen und Lesbarkeit.
• Test-Strategie (auch ein kleiner Test ist ein Signal).
• Performance-Hygiene (keine offensichtlichen Re-Render-Stürme, keine riesigen eingezogenen Abhängigkeiten).

Eine Debugging-Übung (noch besser als Greenfield-Coding)

Dem Kandidaten ein kleines Repo mit folgendem geben:

• Einem Re-Render-Performance-Problem.
• Einem Effect-Dependency-Bug.
• Einer kaputten Tastaturinteraktion in einer Komponente.

Fragen, wie er:

• Das Problem reproduziert hat.
• Welche Belege er verwendet hat.
• Den kleinsten sicheren Fix vorschlägt.

Das spiegelt echte Arbeit wider und sagt den Berufserfolg stark voraus.

Erwartungen nach Level kalibrieren (damit man keine guten Kandidaten ablehnt)

Bereich	Junior	Mid-Level	Senior
React-Grundlagen	Kann Features mit Anleitung bauen	Kann Trade-offs und häufige Fallstricke erklären	Schult andere, verhindert ganze Fehlerklassen
State und Async	Verwendet etablierte Muster	Wählt Muster nach State-Typ, vermeidet Races	Definiert eine kohärente App-weite Strategie
Testing	Schreibt grundlegende Tests	Baut änderungssichere Test-Suites	Gestaltet die Testing-Pyramide und Zuverlässigkeit
Performance	Folgt Best Practices	Profilert und behebt Engpässe	Setzt Budgets, verhindert Regressionen
Accessibility	Verwendet semantisches HTML	Implementiert zugängliche Custom-Komponenten	Etabliert Standards und Review-Checks
Architektur	Arbeitet innerhalb von Strukturen	Verbessert Strukturen inkrementell	Erstellt durchsetzbare Grenzen und gepflasterte Pfade

Eine einfache Scorecard, die man tatsächlich nutzen kann

Eine Scorecard verhindert „Bauchgefühl-Einstellungen" und hilft, Kandidaten konsistent zu vergleichen.

Dimension	Was bewertet wird	Aussagekräftiger Beleg	Red Flags
Produkt-Delivery	Liefert Ergebnisse, nicht nur Code	Klare Beispiele mit messbarem Einfluss	Spricht nur über Aufgaben, nicht Ergebnisse
React-Korrektheit	Rendering, Effects, State	Erklärt einen echten Bug und Fix	Vages mentales Modell
Async und Daten	Caching, Invalidierung, Races	Vorhersehbare Strategie für Server-State	Zufällige useEffect-Ketten
Wartbarkeit	Komponenten-APIs, Typen, Grenzen	Entfernt Komplexität, fügt sie nicht hinzu	Over-Abstraktion, unklare Ownership
Performance	Messung-zuerst-Verbesserungen	Profiling-Workflow + Ergebnisse	Vorzeitige Memoisation überall
Accessibility	Tastatur, Semantik, Fokus	Kann Modal/Dropdown korrekt implementieren	Behandelt a11y als „Nice to have"
Testing	Änderungssicherheit	Verhaltensorientierte Tests, wenig Flakiness	Nur Snapshots oder fragile Tests
Zusammenarbeit	Kommunikation, Reviews	Gibt strukturiertes Feedback, stellt gute Fragen	Defensiv, unklar, gibt anderen die Schuld

Wer breitere Einstellungssignale über React hinaus sucht, ergänzt Wolf-Techs Leitfaden zu Einstellungssignalen für Software-Programmierer, die Erfolg vorhersagen diese Scorecard gut.

Häufige Interview-Anti-Muster (und was stattdessen zu tun ist)

Anti-Muster: Trivia-lastige Fragen

Wenn man nach auswendig gelernten Details fragt, selektiert man auf Interview-Training, nicht auf Jobperformance.

Stattdessen:

• Kandidaten bitten, über ein reales Szenario nachzudenken.
• Verlangen, Trade-offs und Verifikationsschritte zu erklären.

Anti-Muster: ein „hartes Problem" für alles

Ein einzelnes Puzzle (oder eine LeetCode-artige Frage) korreliert schwach mit der täglichen React-Arbeit.

Stattdessen:

• Mehrere kleinere Sonden über Korrektheit, Async, Accessibility und Testing verwenden.

Anti-Muster: kein explizites Rubrik

Ohne Rubrik wird man Selbstsicherheit übergewichten und Belege untergewichten.

Stattdessen:

• Einig werden, was „gut" bedeutet pro Level.
• Eine Scorecard mit schriftlichen Belegen verwenden, nicht nur eine numerische Bewertung.

Wenn es kein Einstellungsproblem ist

Manchmal stellt man ein, weil man schnell Output braucht, aber die Einschränkungen machen Einstellen langsam oder riskant. Wenn eine React-Codebasis modernisiert, Architektur-Leitplanken eingerichtet oder ein dünner vertikaler Slice schnell geliefert werden muss, kann es effektiver sein, einen erfahrenen Delivery-Partner für ein zeitlich begrenztes Engagement einzubeziehen.

Wolf-Tech arbeitet an Full-Stack-Delivery und Code-Qualitäts-Consulting über moderne Stacks hinweg, einschließlich React und Next.js. Wer ein externes Review der Frontend-Architektur, des Interview-Loops oder der „Was gut aussieht"-Standards möchte, beginnt mit einer kurzen Discovery und einem evidenzbasierten Plan auf wolf-tech.io.