Technische React‑Interviewfragen (Junior–Senior): Hooks, Testing, Performance

Warum gezielte React‑Fragen über Ihren Hiring‑Erfolg entscheiden

Frontend‑Interviews scheitern oft an zwei Punkten: Entweder werden allgemeine JavaScript‑Fragen gestellt, die wenig über echte React‑Kompetenz aussagen – oder es werden Wissensabfragen ohne Praxisbezug gemacht. Beides führt zu Fehlbewertungen, unnötig langen Prozessen und späteren Reibungen im Team.

Der Markt dreht wieder Richtung Einstellungsaktivität, und Unternehmen priorisieren messbare Skills statt Abschlüssen. Aktuelle Daten deuten auf eine Erholung der Test‑ und Interviewaktivität sowie „Skills over pedigree“ hin; zugleich bleibt das objektive Prüfen technischer Fähigkeiten schwierig (vgl. HackerRank Developer Skills Report 2024). HackerRank berichtet beispielsweise von einem signifikanten Anstieg der Test‑Einladungen seit Juli 2023, was die Relevanz belastbarer Assessments unterstreicht.

Dieser Leitfaden liefert Ihnen genau das – mit Fokus auf technische React‑Interviewfragen für Junior bis Senior. Sie erhalten konkrete Frageblöcke zu Hooks, State‑Management und Rendering, ergänzt um Testing‑Schwerpunkte (React Testing Library), Performance, Architektur und Tooling.

Die Kernbereiche einer technischen React‑Bewertung

Was Sie mindestens abdecken sollten:

Hooks, State und Rendering: Fundament für korrektes Komponenten‑Design
Testing und Qualitätssicherung: Nutzerzentrierte Tests, sinnvolle Abdeckung, realistische Mocks
Performance und Rendering‑Verhalten: Ursachen, Messmethoden, Optimierungshebel
Datenfluss & State‑Management: lokal vs. global, Fetching & Caching, Konsistenz
Architektur & Tooling: Modularisierung, Typisierung mit TypeScript, CI/CD, Linting, Build

Die folgenden Abschnitte bieten pro Bereich konkrete Fragen inklusive „Look‑fors“ (gute Signale) und „Red Flags“ (Warnsignale) – abgestuft nach Seniorität, wo sinnvoll.

Hooks und Component‑Design: Fragen mit Bewertungsankern

Warum wichtig: Hooks sind das Herz moderner React‑Entwicklung. Wer die „Rules of Hooks" nicht sicher beherrscht, produziert schwer wartbaren Code und subtile Bugs. Die offiziellen React‑Referenzen sind dafür die maßgebliche Quelle (Hooks‑Übersicht, Rules of Hooks).

Beispielfragen

Erklären Sie die Rules of Hooks und typische Verstöße. Wann brechen Entwickler:innen diese Regeln unabsichtlich?
Look‑fors: Top‑Level‑Aufrufe in Funktionskomponenten/Custom Hooks; keine Hooks in Bedingungen/Schleifen/Handlern; Verweis auf eslint‑plugin‑react‑hooks; Verständnis, warum Reihenfolge zählt.
Red Flags: „Ich nutze Hooks auch im Event‑Handler“; kein Bewusstsein für Abhängigkeitslisten oder deren Linting.
Wann nutzen Sie useState vs. useReducer?
Look‑fors: useState für einfachen lokalen Zustand; useReducer bei komplexen, eng gekoppelten Updates oder expliziterer State‑Maschine; Testbarkeit als Argument.
Red Flags: „Immer useState" oder „Immer useReducer" ohne Trade‑off.
Effekte sicher einsetzen: Wozu ist useEffect da – und wofür ausdrücklich nicht? Unterschied zu useLayoutEffect.
Look‑fors: Effekte zur Synchronisation mit externen Systemen; „Kein useEffect für reinen Datenfluss"; useLayoutEffect für Layout‑Messungen vor Paint; Verständnis von Cleanup und Abhängigkeitslisten.
Red Flags: Daten‑Orchestrierung in useEffect; unkontrollierte Effektschleifen.
refs vs. State: Wann gehört etwas in eine ref statt in den State?
Look‑fors: Nicht‑renderrelevante Werte (DOM‑Knoten, Timer‑IDs) in useRef; State triggert Re‑Render.
Red Flags: DOM‑Zugriff als Standard, unreflektierter Einsatz von imperative handles.
Fortgeschritten (Senior): Wann und wie setzen Sie useMemo/useCallback sinnvoll ein – und wann nicht?
Look‑fors: Gezielt einsetzen, typischerweise in bekannten Hotspots oder nach Messung; Verständnis stabiler Referenzen für memo‑isierte Kinder; Kosten/Nutzen‑Abwägung.
Red Flags: „Ich wrappe alles in memo/useCallback" ohne Messung.
Fortgeschritten (Senior): Erfahrungen mit useTransition/useDeferredValue oder useSyncExternalStore?
Look‑fors: Entkopplung nicht‑kritischer Updates; externe Store‑Abos sauber in React integriert; Kenntnis von Grenzen/Server‑Client‑Grenzen.
Red Flags: Falsche Erwartungen an „magische" Performance; unklare Store‑Konsistenz.

State‑Management und Datenfluss: Fragen und Mini‑Aufgaben

Ziel: Prüfen, ob Kandidat:innen Zustände lokal halten, sinnvoll „liften", Context richtig dosieren und externe Stores begründet einsetzen.

Beispielfragen

Lokal vs. global: Nach welchen Kriterien entscheiden Sie für Context, Props‑Lifting oder eine State‑Library (z. B. Redux Toolkit, Zustand, TanStack Query für Serverzustand)?
Look‑fors: „Lokal zuerst"; Context für cross‑cutting Concerns, wenn die Änderungsfrequenz und die Auswirkungen auf Konsumenten bedacht sind; externe Stores bei vielen Konsument:innen/Komposition; Trennung UI‑State vs. Server‑State.
Red Flags: „Redux für alles" oder sechs Ebenen Props‑Drilling.

Hinweis: Context ist praktisch für geteilte Werte; bei häufigen Änderungen kann das jedoch Re‑Renders bei Konsumenten auslösen — das ist ein Trade‑off, den Kandidat:innen benennen sollten.

Data‑Fetching & Caching: Wie handhaben Sie Latenz, Fehler, Cache‑Invalidierung und parallele Requests?
Look‑fors: Erfahrung mit spezialisierten Bibliotheken oder Patterns für Fetching/Caching; spezialisierte Libraries bieten typischerweise Funktionen wie Caching, Invalidierung oder Unterstützung für Mutations/Retry‑Strategien — die konkrete Feature‑Ausprägung unterscheidet sich jedoch zwischen Bibliotheken. Erwarten Sie, dass Kandidat:innen Trade‑offs zwischen Eigenimplementierung und etablierten Lösungen nennen.
Red Flags: useEffect + fetch ohne jeden Abbruch‑Gedanken.

Empfehlung: Bei fetch‑basierten Aufrufen können Abbruchmechanismen (z. B. AbortController und Cleanup im Effekt) je nach Kontext helfen, Race Conditions und unerwünschte Nebenwirkungen zu minimieren; ihre Wirksamkeit hängt vom konkreten Anwendungsfall ab.

Debugging‑Signale: Woran erkennen Sie, dass ein State‑Design kippt – und wie migrieren Sie?
Look‑fors: Heuristiken (exzessives Props‑Drilling, duplizierte Quellen der Wahrheit, schwer zu testende Komponenten); schrittweise Extraktion in Custom Hooks/Stores; Migrationsstrategie mit Feature‑Flags.
Red Flags: „Big Bang"‑Refactor ohne Zwischenschritte.

Testing & Qualitätssicherung in React

Grundsatz: Tests sollen das Nutzungsverhalten abbilden statt Implementierungsdetails. Genau das ist das Leitprinzip der React Testing Library (Einführung).

Beispielfragen

Testphilosophie: Wie vermeiden Sie Implementation‑Detail‑Tests? Welche Queries nutzen Sie zuerst?
Look‑fors: Nutzernahe Queries wie Label‑ und Text‑Queries vor data-testid; Tests interagieren über Events und Assertions auf sichtbares Verhalten; Barrierefreiheit als Nebeneffekt besserer Tests.
Red Flags: Flächendeckend data-testid, Snapshot‑Inflation als „Qualität", Enzyme‑Denke ohne Nutzerfokus.
Unit vs. Integration in React: Wo ziehen Sie die Grenze?
Look‑fors: Bevorzugt komponentennahe Integrations‑/„slice"‑Tests über interne Units; Mocks sparsam und gezielt für Netz/Timer; Stabilität bei Refactorings.
Red Flags: Über‑Mocking (Router/Store/HTTP), fragile Tests, die bei CSS‑Änderungen brechen.
Tooling & Coverage: Welche Kennzahlen sagen Ihnen wirklich etwas?
Look‑fors: Statement/Branch‑Coverage als Hygiene, aber Fokus auf Risiko‑Hotspots und kritische Pfade; visuelle/Interaktions‑Regressionen adressieren.
Red Flags: 100% Coverage als Ziel ohne Aussagekraft über Risiken.

Konkrete Mini‑Aufgabe (30–40 Min, Live oder Take‑home ≤3 Std.)

„Schreiben Sie einen Integrationstest für eine Suchliste mit Debounce und Fehlerstatus."
Look‑fors: Nutzerzentrierte Queries, async/await‑Handhabung, Fake Timers nur wenn nötig, robuste Fehler‑Assertions.
Red Flags: Testen interner Hooks/Implementierungen, fragile Zeit‑und DOM‑Annahmen.

Performance, Rendering und Optimierungsfragen

Ziel: Versteht die Person, warum Komponenten neu rendern, wie man das misst und erst dann optimiert?

Beispielfragen

Wie identifizieren Sie unnötige Re‑Renders? Welche Tools nutzen Sie?
Look‑fors: React DevTools/Profiler; gezielte Messungen; Analyse props‑getriebener Re‑Renders; Schlüssel‑Strategien; Virtualization für Listen.
Red Flags: Pauschales memo/useMemo/useCallback ohne Profiling.
Welche Optimierungen setzen Sie in der Praxis ein – und wann kippen sie ins Over‑Engineering?
Look‑fors: Code‑Splitting, Suspense/Transitions für nicht‑kritische Updates, Stabilisierung von Callback‑Identitäten nur bei Bedarf; Messbarkeit und Rückbaukompetenz.
Red Flags: „Immer optimieren", kein Blick auf Netzwerk/Server als Flaschenhals.

Praxisaufgabe Junior vs. Senior

Junior: „Finden und beheben Sie doppelte Re‑Renders in einer Formular‑Komponente."
Senior: Architekturgespräch zu „Suchseite mit infinite scroll, Caching, Offline‑Fallback und Feature‑Flags" – Fokus auf Trade‑offs.

Tooling, Typisierung und Build/Deploy im DE‑Kontext

Warum relevant: TypeScript, Linting, CI/CD und Storybook sind in vielen deutschen Produktteams gebräuchliche Werkzeuge; gute Kandidat:innen erklären Trade‑offs statt nur Tools aufzuzählen.

Beispielfragen

TypeScript im React‑Stack: Wo hilft es Ihnen konkret – und wo bremst es?
Look‑fors: Strenge Props‑Typen, Discriminated Unions für Zustände, Utility‑Typen maßvoll; Grenzen bei dynamischen Daten/externen APIs; pragmatischer Umgang mit any/unknown an den Rändern.
Red Flags: „TS hält immer auf" oder „TS löst alle Bugs" – fehlende Nuance.
CI/CD, Linting und Qualitätsgates: Was ist „MVP" für eine React‑Codebase?
Look‑fors: eslint (inkl. react‑hooks‑Regeln), Prettier, Type‑Checks im CI, Preview‑Umgebungen/Storybook, Basis‑Tests im PR‑Gate, Bundling/Chunk‑Analyse.
Red Flags: Linting ignorieren, kein Pre‑Merge‑Signal, „wir testen später".
Monorepo/Design‑Systeme/Storybook: Wie halten Sie Komponenten stabil und wiederverwendbar?
Look‑fors: Versionierung, semantische Releases, Visuelle Regressionstests wo sinnvoll, klare Dependenzgrenzen.
Red Flags: Kopieren statt Teilen, unklare Ownership.

Praxisrelevanz in Deutschland

Datenschutz/Compliance: Vorsicht bei Telemetrie/3rd‑Party‑SDKs, klare Doku und Freigaben.
Teamgrößen: Von 3–5er Produktteams bis Enterprise‑Monorepos – Kandidat:innen sollten beide Welten einordnen können.
Produktivität: Erwartungsmanagement zu Lead Time und WIP‑Limits; Fokus auf Outcome statt Lines of Code.

Hinweis: Die Beobachtung zur Verbreitung von Tools in deutschen Teams ist eine redaktionelle Einordnung und kein repräsentativer Befund.

Interviewformate, Bewertungsmatrix und Prozesshinweise

Struktur schlägt Bauchgefühl. Nutzen Sie über alle Stufen hinweg dieselben Kernfragen pro Kompetenz und werten Sie unabhängig aus. Ein kompakter Rahmen (Gewichtungen anpassbar):

35% Technische/rollenbezogene Mastery (React, TypeScript)
25% Outcome‑Ownership (belegte Ergebnisse der letzten 12 Monate)
20% Kommunikation & Zusammenarbeit
10% Lernkurve/Anpassungsfähigkeit
10% Werte/Arbeitsstil

Formatempfehlungen

Live‑Coding/Pairs für kleine, realitätsnahe Aufgaben (30–45 Min)
Take‑home‑Aufgabe mit klarer Abnahme und Zeitlimit ≤3 Stunden; idealerweise kompensiert
Architektur‑Gespräch für Senior (Trade‑offs statt Whiteboard‑Rätsel)
Debrief binnen 24 Stunden, schriftlich‑first, zwei Personen, gleiche Kernfragen – senkt Groupthink

KI‑Policy und Fairness

Erlauben Sie Hilfs‑Tools transparent oder untersagen Sie sie klar – und prüfen Sie Verständnis, nicht Copy‑Paste. Studien zeigen, dass KI‑Nutzung im Entwickleralltag verbreitet ist; zugleich besteht Sorge um Plagiate in Assessments (vgl. HackerRank 2024).
Wenn Sie KI zur Auswertung nutzen, sorgen Sie für menschliche Endentscheidung und Nachvollziehbarkeit. Hinweise aus Anbieterempfehlungen betonen, dass automatisierte Entscheidungen besonders sorgfältig geprüft werden sollten; in der Praxis empfiehlt sich: Use AI für Transkription/Pattern‑Spotting, nicht für finale automatisierte Scoring‑Entscheidungen.

Hinweis: Empfehlungen zur regulatorischen Einordnung (z. B. EU‑AI‑Act) sind in einigen Anbieter‑Guides zu finden; prüfen Sie rechtliche Anforderungen vor Ort und berücksichtigen Sie diese bei Ihrer KI‑Policy.

Konkrete Fragepakete nach Seniorität

Junior (Fokus: Grundlagen sicher anwenden)

Hooks‑Grundlagen und Rules of Hooks an Beispielen erklären
useState vs. useReducer mit einfachen Szenarien begründen
Ein kleiner Integrationstest mit React Testing Library: Nutzerfluss statt Interna
Einfaches Performance‑Problem lokalisieren (Profiler) und beheben

Mid‑Level (Fokus: Trade‑offs im Alltag)

Datenfluss: Lokal vs. Context vs. externer Store – Entscheidung am echten Modul begründen
Fetching & Caching mit TanStack Query/SWR: Fehlerfälle, Invalidierung, optimistic update (bibliotheksabhängige Features)
Performance‑Gespräch: Wo messen, wo optimieren, wo bewusst nicht
Tooling: TS‑Patterns in Komponenten, Hooks‑Linting, CI‑Checks

Senior (Fokus: Architektur und Skalierung)

Custom‑Hook‑Design: API‑Gestaltung, Testbarkeit, „escape hatches" bewusst wählen
Server/Client‑Grenzen, Suspense/Transitions für wahrgenommene Performance
Systemdesign der letzten App: Engpässe, Observability, Migrationspfade
Teststrategie auf Feature‑Ebene: Integrations‑ vs. End‑to‑End‑Balance, Flakiness‑Kontrolle

Kurz‑Checkliste für bessere Interviews

Prioritäten je Rolle: Junior = Grundlagen/Coachability; Mid = Trade‑offs/Ownership; Senior = Architektur/Impact
Standardisierte Fragen je Kompetenz, konsistente Bewertungsanker, zwei Personen pro technischem Gespräch
Mini‑Aufgaben realitätsnah, Take‑home ≤3 Stunden, klarer Bewertungsrahmen
Hooks/Rendering, State/Daten, Testing‑Philosophie, Performance, Typisierung/Tooling immer abdecken
KI‑Umgang vorab klären; Endentscheidung bleibt bei Menschen

Fazit

Gute React‑Interviews messen nicht, wer die meisten API‑Namen aufsagen kann, sondern wer im Alltag robuste Entscheidungen trifft: Hooks korrekt anwenden, Datenflüsse klar schneiden, nutzerzentriert testen, nur das optimieren, was messbar ist – und Tooling so einsetzen, dass Teams schneller und sicherer liefern. Mit den obigen Frageblöcken und Bewertungsankern erhalten Sie schnell vergleichbare, belastbare Signale – von Junior bis Senior.