Interviewfragen und Antworten für React-Entwickler 2026

React-Interviews haben sich still und leise weiterentwickelt. Ein Jahrzehnt Tutorials hat allen beigebracht, den Unterschied zwischen Props und State herunterzubeten, und Interviewer fanden das ungefähr ab 2021 nicht mehr nützlich. Was jetzt gefragt wird, ist härter und ehrlicher: Was macht React eigentlich, wenn du einen Setter aufrufst, warum rendert diese Liste neu, wo gehören diese Daten hin, und was geht kaputt, wenn du sie an die falsche Stelle legst. Hier sind die Fragen, die dir wirklich begegnen, was jede davon abklopft und wie eine starke Antwort aufgebaut ist.

Das sind die Muster für die Rolle allgemein; wenn du die engere Auswahl für ein konkretes Gespräch willst, füg die echte Stellenanzeige in den kostenlosen Question Predictor ein und du bekommst die zwanzig Fragen, die diese Anzeige am wahrscheinlichsten produziert.

Was prüfen React-Interviews 2026 wirklich?

Vier Dinge, ungefähr in dieser Reihenfolge: ob du das Rendering-Modell verstehst statt nur die API-Oberfläche, ob du State an sinnvollen Stellen ablegst, ob du ein Performance-Problem mit Belegen statt mit Raten findest, und ob du Code schreibst, den jemand anderes testen kann. Trivia ist weitgehend durch Abwägen von Kompromissen ersetzt worden, weil das Boilerplate ohnehin vom Tooling geschrieben wird.

• Hooks unter der Lupe: das Closure-Verhalten, über das alle stolpern, und zu wissen, wann ein Effect das falsche Werkzeug ist.
• Das Rendering-Modell: was einen Render auslöst, was Reconciliation mit dem Ergebnis macht, warum Keys wichtig sind.
• State-Architektur: lokal versus hochgezogen versus Context versus Store, und die Trennung zwischen Server-State und Client-State.
• Performance mit Messung: im Profiler diagnostizieren statt Memoisierung darüberzustreuen und zu hoffen.
• Gespür fürs Testen: was du testest, auf welcher Ebene, und ob du Loading-, Empty- und Fehlerzustände von selbst abdeckst.

Die Seniorität verschiebt die Gewichtung, nicht die Themen. Mid-Level-Kandidaten argumentieren korrekt über eine Komponente. Senior-Kandidaten argumentieren über eine Codebase: Konventionen, Grenzen, Migrationspfade und was sie ablehnen würden.

Wie läuft der Bewerbungsprozess für React-Entwickler ab?

Vier oder fünf Stufen: ein Recruiter-Screening, ein Technical Screen mit Live-Coding, eine längere Build-Runde, ein React-Deep-Dive und eine Verhaltensrunde. Größere Unternehmen hängen Frontend System Design dran. Die Build-Runde und der Deep Dive entscheiden über das Angebot, leg deine Vorbereitung also dort hin statt sie gleichmäßig zu verteilen.

1. Recruiter-Screening (20 bis 30 Minuten). Verfügbarkeit, Gehalt, eine Zusammenfassung deiner letzten beiden Stellen.
2. Technical Screen (45 bis 60 Minuten). Ein geteilter Editor, eine kleine Komponente oder eine Debugging-Aufgabe, manchmal reines JavaScript, um das Fundament unter dem Framework zu prüfen.
3. Build-Runde (60 bis 90 Minuten). Etwas Echtes: eine filterbare Tabelle, ein Autocomplete, ein mehrstufiges Formular gegen eine Fake-API. Bewertet werden State-Platzierung, Edge Cases und ob du beim Arbeiten redest.
4. React-Deep-Dive (45 bis 60 Minuten). Rendering, Hooks-Interna, State-Entscheidungen, Performance und zunehmend Server Components.
5. Verhaltensrunde (45 Minuten). Meinungsverschiedenheiten, Code Review, Mentoring und wie du mit einer Spec umgehst, die keinen Sinn ergibt.

Take-Home-Aufgaben werden seltener, vor allem weil Interviewer wissen, dass sie mit KI-Hilfe erledigt werden. Wo eine überlebt, folgt fast immer eine Live-Session, in der du deine eigene Abgabe erweiterst, und genau darauf lohnt sich die Vorbereitung.

Welche Fragen zu React Hooks kommen in fast jedem Gespräch?

Vier tauchen ständig auf: veralteter State in einer Closure, was das Dependency Array steuert, der Unterschied zwischen den Memoisierungs-Werkzeugen und einen eigenen Hook aus dem Stand schreiben. Alle vier prüfen dasselbe darunterliegende Ding, nämlich ob dir klar ist, dass eine Komponentenfunktion viele Male läuft und jeder Lauf seine eigenen Werte einfängt.

1. "Dieser Click-Handler loggt den alten Count. Warum?" Was geprüft wird: ob du verstehst, dass jeder Render über die Werte dieses Renders schließt und dass ein Setter keine Variable an Ort und Stelle verändert. Benenn die Closure ausdrücklich und zeig dann beide Lösungen: den funktionalen Updater setCount(c => c + 1), und einen Ref, wenn du den aktuellsten Wert wirklich in einem langlebigen Callback brauchst.

2. "Was steuert das Dependency Array, und wann solltest du gar keinen Effect nehmen?" Was geprüft wird: ob du Effects als allgemeinen Lifecycle-Hook behandelst (das Junior-Signal) oder als Synchronisation mit etwas außerhalb von React. Das Array entscheidet, wann der Effect erneut läuft; das Cleanup läuft vor dem nächsten Lauf und beim Unmount. Nenn dann, was kein Effect sein sollte: abgeleitete Werte (beim Rendern berechnen), State, der bei einer Prop-Änderung zurückgesetzt wird (ein key am Kind), und Reaktionen auf Events (die gehören in den Handler).

3. "useMemo, useCallback, React.memo: was ist der Unterschied?" Was geprüft wird: ob deine Memoisierung gemessen oder Aberglaube ist. useMemo cacht einen Wert, useCallback cacht eine Funktionsreferenz, React.memo überspringt das Neurendern eines Kindes, wenn die Props flach gleich sind, und die ersten beiden sind sinnlos, solange nicht ein memoisiertes Kind oder eine andere Dependency-Liste die Referenz konsumiert. Ergänze, dass Memoisierung selbst Kosten hat, du also erst profilest.

4. "Schreib einen Hook, der einen Wert debounced." Was geprüft wird: Komposition, Cleanup und Disziplin bei Dependencies in etwa zehn Zeilen. State für den debouncten Wert, ein Effect, der einen Timer setzt, ein Cleanup, das ihn löscht, Dependencies auf Wert und Delay. Der Teil, den die meisten Kandidaten übersehen: Erst das Cleanup macht daraus ein Debounce statt einer Schlange wartender Updates.

Wie prüfen Interviewer Rendering und Reconciliation?

Indem sie fragen, was nach einem State-Update passiert, nicht davor. Eine starke Antwort trennt drei Phasen: React lässt die Komponente erneut laufen und erzeugt einen Element-Tree, Reconciliation vergleicht diesen Tree mit dem vorherigen, und die Commit-Phase wendet die kleinstmögliche Menge an DOM-Mutationen an. Wer diese Phasen verwischt, kann weder Keys noch Effect-Timing noch Concurrent Features erklären.

5. "Erklär mir, was passiert, wenn ich einen State-Setter aufrufe." Was geprüft wird: die Tiefe des mentalen Modells. Das Update wird eingereiht und mit anderen im selben Tick gebatcht, React plant einen Render, die Komponente und ihre Kinder laufen erneut, der neue Tree wird mit dem alten abgeglichen, vorherige Effects werden aufgeräumt, DOM-Mutationen werden committet, dann laufen Layout-Effects synchron und Passive Effects nach dem Paint. Ergänze, dass Strict Mode in der Entwicklung doppelt aufruft, um Effects offenzulegen, die sich nicht sauber zurücknehmen lassen.

6. "Warum sind Keys wichtig, und was geht mit Array-Indizes schief?" Was geprüft wird: ob du tatsächlich schon mal eine Liste debuggt hast. Keys sagen der Reconciliation, welches Element über Renders hinweg zu welchem Item gehört. Mit Index-Keys ordnet React beim Löschen oder Umsortieren die falschen Items einander zu, also hängen Komponenten-State und DOM-State (ein fokussiertes Input, ein halb getippter Wert) an der falschen Zeile. Nenn auch die Kehrseite: Einen Key absichtlich zu ändern ist ein legitimer Weg, einen Teilbaum zurückzusetzen.

7. "Wofür sind useTransition und useDeferredValue da?" Was geprüft wird: das Bewusstsein, dass Rendering unterbrechbar sein kann. Beide halten ein dringendes Update (Tippen) reaktionsschnell, während ein schweres Update mit niedrigerer Priorität rendert: useTransition markiert das State-Update als nicht dringend und gibt dir ein Pending-Flag, useDeferredValue lässt einen Wert hinterherhinken. Sag klar, dass keines von beiden langsames Rendering schnell macht, sie ändern nur, worauf der Nutzer wartet.

Welche Fragen zum State Management sollte ich erwarten?

Zwei, ziemlich zuverlässig: wo ein Stück State hingehört, und wie du Serverdaten anders behandelst als Clientdaten. Die erwartete Antwort startet bei lokalem State, behandelt Context als Auslieferungsmechanismus für selten wechselnde Werte statt als Store, und packt alles, was aus einer API kam, hinter eine Caching-Schicht.

8. "Context oder eine State-Library, und wie entscheidest du?" Was geprüft wird: ob du weißt, was Context kostet. Erst lokaler State, nur bis zum nächsten gemeinsamen Elternteil hochziehen, Context für Werte, die sich selten ändern und breit gelesen werden (Theme, Locale, aktueller Nutzer), und ein Store, wenn Updates häufig sind oder über unverwandte Teilbäume hinweg gelesen wird. Die Begründung zählt: Jeder Consumer rendert neu, wenn sich der Context-Wert ändert, ein schnell wechselnder Wert im Context ist also ein Performance-Bug, der nur darauf wartet, gemeldet zu werden.

9. "Wie gehst du mit Server-State um?" Was geprüft wird: ob du je etwas mit echten Daten ausgeliefert hast. Serverdaten sind ein Cache von etwas, das dir nicht gehört, also brauchen sie Deduplizierung, Regeln zur Veraltung, Revalidierung im Hintergrund und Invalidierung nach einer Mutation, und das per Hand in Effects nachzubauen geht langsam schief. Benenn das Muster statt nur die Library: auf dem Server holen, wo das Framework es erlaubt, auf dem Client cachen, lokalen UI-State getrennt halten.

Wie werden Performance-Fragen in der Praxis gestellt?

Als Szenario mit einem Symptom, nicht als Definition. Du bekommst "das Tippen in diesem Filterfeld ruckelt" oder "diese Seite braucht vier Sekunden, bis sie interaktiv ist", und der Interviewer schaut zu, ob du misst, bevor du irgendwas änderst. Direkt zu useMemo zu greifen, ist der falsche Eröffnungszug; den Profiler zu öffnen und zu fragen, was da neu rendert, ist der richtige.

10. "Das Tippen in einem Suchfeld, das zehntausend Zeilen filtert, hakt. Diagnostizier das." Was geprüft wird: Methode. Mit dem React Profiler und dem Performance-Panel des Browsers aufzeichnen und feststellen, ob die Kosten daher kommen, dass viele Komponenten neu rendern oder dass eine Komponente viele Nodes rendert. Ist es die Anzahl der Nodes, virtualisieren; ist es die Breite des Neurenderns, den State des Inputs dorthin holen, wo er hingehört, damit der Baum darüber stehen bleibt, und dann die Zeile memoisieren; ist der Filter selbst teuer, ihn memoisieren oder verzögern.

11. "Das Bundle ist zu groß. Was machst du?" Was geprüft wird: ob du je einen Bundle-Analyzer geöffnet hast. Erst messen, dann Splitting auf Routen-Ebene mit lazy und Suspense, dynamische Imports für schwere Widgets (Editoren, Charts, Datepicker), eine überdimensionierte Abhängigkeit ersetzen und Arbeit auf den Server verlagern, wo das Framework es unterstützt. Häng es an eine Metrik, die das Business interessiert, meist LCP oder Interaktionslatenz, statt an Kilobyte um ihrer selbst willen.

12. "Macht der React Compiler manuelle Memoisierung überflüssig?" Was geprüft wird: ob du das Ökosystem verfolgst und eine differenzierte Position halten kannst. Automatische Memoisierung entfernt den größten Teil des Routine-Rauschens aus useMemo und useCallback , was eine echte Verbesserung ist, aber sie repariert keinen zu hoch platzierten State, keinen zu breiten Context, keine unvirtualisierte Liste und keinen teuren Effect. Sag, was du weiterhin von Hand machen würdest und was du gern löschen würdest.

Wie sehen Fragen zum Testen in React aus?

Meist ein Szenario plus eine Frage nach dem Verhältnis. Interviewer wollen Tests, die Verhalten über die Oberfläche prüfen, die ein Nutzer anfasst, das Netzwerk an der Grenze gemockt statt eigener Module gestubbt, und eine ehrliche Aufteilung: Unit-Tests für reine Logik, Integrationstests auf Komponentenebene für den Großteil der UI, und eine dünne Schicht End-to-End-Tests über den Flows, die Geld kosten, wenn sie kaputtgehen.

13. "Wie testest du eine Komponente, die Daten lädt und eine Liste anzeigt?" Was geprüft wird: ob deine Tests Refactorings überleben. Komponente rendern, auf Netzwerkebene mocken, über Accessible Role und Name abfragen, dann Loading-State, geladene Zeilen, Empty-State und Fehlerzustand prüfen. Vermeide Assertions auf Props oder Hook-Interna, und erwähne Flakiness: awaited Queries statt willkürlicher Timeouts.

Fragen Interviewer nach React Server Components?

Zunehmend ja, meist um zu prüfen, ob du die Grenze verstehst, nicht um Framework-Trivia abzufragen. Du solltest sagen können, was wo läuft, was eine Server Component nicht kann und woher die üblichen Hydration- und Caching-Fehler kommen. Ehrlich zu sagen, dass deine Praxiserfahrung begrenzt ist, ist völlig in Ordnung; so tun als ob nicht, denn die Nachfrage fliegt dir um die Ohren.

14. "Was ist der Unterschied zwischen einer Server Component und einer Client Component?" Was geprüft wird: die Grenze. Server Components laufen auf dem Server, holen Daten direkt per await, schicken ihren Code nie an den Browser und können weder State noch Effects noch Event-Handler nutzen; Client Components hydratisieren im Browser und können alle drei. Die Direktive "use client" markiert einen Einstiegspunkt in Client-Gebiet, alles darunter Importierte landet also ebenfalls auf dem Client, und genau deshalb löscht eine unbedachte Direktive weit oben im Baum den ganzen Vorteil weg.

15. "Wo holst du Daten, und was sind die Caching-Fallen?" Was geprüft wird: Narben aus der Produktion. Auf dem Server holen, nah an der Stelle, wo die Daten gerendert werden, und das Framework identische Requests innerhalb eines Renders deduplizieren lassen. Die Fallen, die es wert sind, benannt zu werden: versehentlich statisch gerendert, was dynamisch sein sollte, veraltete Daten nach einer Mutation, weil nichts revalidiert hat, und Hydration-Mismatches, weil im Server-Durchlauf ein Zeitstempel gerendert wurde.

Welche Fehler kosten React-Kandidaten die Absage?

Meistens Prozessfehler, keine Wissenslücken. Interviewer lehnen selten jemanden ab, weil er einen Hook nicht kennt; sie lehnen den Kandidaten ab, der schweigend gearbeitet, einen Fix geraten und den Fehlerzustand offen gelassen hat. Diese sechs machen den größten Teil der Absage-Begründungen in React-Loops aus.

• Schweigend coden. In der Build-Runde ist der laufende Kommentar der größte Teil des Signals.
• Zuerst nach einem Effect greifen. Daten holen, ableiten und State in Effects synchronisieren, obwohl es einfacher geht, ist das häufigste architektonische Warnsignal.
• Memoisieren ohne zu messen. Interviewer fragen genau deshalb "was hat das verbessert", weil die meisten Kandidaten das nicht beantworten können.
• Den unglücklichen Pfad ignorieren. An Loading-, Empty- und Fehlerzuständen wird herumgestochert. Deck sie ungefragt ab.
• Bei der Definition stehen bleiben. "useCallback memoisiert eine Funktion" ist die Stelle, an der die interessante Hälfte der Antwort erst anfängt.
• Bei Server Components zu dick auftragen. An der Client-Grenze zu stolpern kostet mehr, als zuzugeben, dass du ein Projekt damit ausgeliefert hast.

Wie bereite ich mich auf ein React-Interview vor?

Bau zwei Dinge, statt über zehn zu lesen. Eine filterbare, sortierbare Tabelle mit serverseitiger Paginierung zwingt dich durch State-Platzierung, Caching, Keys und Virtualisierung. Ein mehrstufiges Formular mit Validierung und echtem Absenden zwingt dich durch unkontrollierte Inputs, Fehlerbehandlung und Fokus-Management. Zusammen erzeugen sie ehrliche Antworten auf die meisten Fragen oben, und ehrliche Antworten überleben Nachfragen.

Dann profil etwas Echtes. Öffne den Profiler in einer App, an der du arbeitest, find die Komponente, die am häufigsten neu rendert, und reparier sie richtig, denn das gibt dir eine Geschichte mit Zahlen darin. Für die Grundlagen unter dem Framework deckt der Guide zu Interviewfragen für Frontend-Entwickler das JavaScript- und Browser-Material ab, an dem der Technical Screen weiterhin hängt, und bei einem großen Arbeitgeber lohnt sich ein Überflug über den Fragenkatalog des Unternehmens , um die typischen Muster des Hauses mitzunehmen.

Dann üb gegen die richtige Liste: Jag die Stellenanzeige durch den kostenlosen Question Predictor , damit die zwanzig Fragen, die du laut übst, die sind, die dieses Team wahrscheinlich stellt, statt eines generischen Sets.

Wo ein Live-Copilot reinpasst

Vorbereitung deckt das meiste ab, und dann landet in Minute vierzig eine Frage schräg und dein Kopf ist leer. GhostPilot AI ist ein Echtzeit-Copilot für genau diesen Moment: Es läuft im Side Panel einer Chrome-Erweiterung oder als Windows-Desktop-App, hört den Call mit, fängt die Frage ab und hat rund zwei Sekunden später eine strukturierte Antwort bereit, was meistens reicht, um aus einer leeren Pause einen sauberen ersten Satz zu machen. Der Gratis-Tarif enthält 10 Minuten Live-Session pro Woche, keine Karte. Es ist ein Sicherheitsnetz für den Blackout, kein Ersatz dafür, deine eigene Arbeit zu kennen.

FAQ

Wie lange sollte ich mich auf ein React-Interview vorbereiten? Zwei bis drei Wochen fokussiertes Üben, wenn du täglich React schreibst. Wenn du eine alte Codebase mit Klassenkomponenten wartest, plan vier bis sechs Wochen ein, vor allem um dich mit Hooks-Patterns, Server-State und dem aktuellen Rendering-Vokabular anzufreunden.

Kommen in React-Interviews noch Algorithmus-Fragen vor? In manchen schon, besonders bei großen Unternehmen mit standardisiertem Loop. Der Trend bei Produktunternehmen geht klar Richtung Bauen und Debuggen echter Komponenten. Halte einfache Datenstrukturen warm, steck den Großteil deiner Zeit aber in praktische UI-Arbeit.

Wie viel muss ich über React Server Components wissen? Genug, um die Grenze souverän zu erklären und die typischen Fehler zu benennen. Tiefe Praxiserfahrung ist für die meisten Rollen ein Bonus, keine Voraussetzung, außer die Stelle dreht sich um ein Framework, das darauf aufbaut.

Soll ich erwähnen, dass ich KI-Tools nutze, um React zu schreiben? Ja, wenn du gefragt wirst, und sag dazu, wie du den Output prüfst. Interviewer gehen ohnehin davon aus. Sie kontrollieren, ob du den Code verteidigen und debuggen kannst, und genau deshalb sind die Nachfragen im Deep Dive härter geworden.