Senior React Native Developer — React-Native-Interviewfragen

Erkläre Fabric und TurboModules als System, nicht nur als Definitionen.

Fabric ist der neue Renderer: Er verlagert Layout und View-Management in einen plattformübergreifenden C++-Core, sodass JS den Baum über JSI direkt in diesen Core beschreibt statt über die asynchronen UIManager-Calls der Bridge, und er ermöglicht synchrones Layout-Messen, was die alte Architektur ohne Round Trip nicht konnte. TurboModules sind das Äquivalent für native Module — lazy geladen (ein Modul wird erst instanziiert, wenn es zum ersten Mal gebraucht wird, was Startup-Kosten senkt) und aufgerufen über JSIs direkte C++-Bindings statt über den Serialize-Queue-Deserialize-Zyklus der Bridge. Zusammen entfernen sie die Bridge als den einen Serialisierungs-Flaschenhals, der die Decke der alten Architektur sowohl bei der Startzeit als auch beim UI-Thread-Durchsatz war.

Wie planst du eine Migration von der alten Architektur zur New Architecture in einer produktiven App?

Fang mit einem Audit jedes nativen Moduls und jeder Third-Party-Dependency an — das größte Risiko liegt nicht in deinem eigenen Code, sondern darin, ob die Libraries, von denen du abhängst, New-Architecture-Support ausgeliefert haben, denn ein unmaintaintes natives Modul kann die ganze Migration blockieren. Aktiviere den Interop-Modus dort, wo das Framework erlaubt, Module der alten Architektur unter Fabric/TurboModules laufen zu lassen, migriere schrittweise Screen für Screen oder Feature für Feature statt einen globalen Schalter umzulegen, und plane echte QA-Zeit ein, weil subtile Verhaltensunterschiede (Layout-Timing, Event-Reihenfolge) erst unter Last auftauchen, nicht im schnellen Smoke-Test. Behandle es als mehrsprintiges Infrastrukturprojekt mit eigenem Rollback-Plan, nicht als Versions-Bump.

Wie profilst du ein Performance-Problem, das von der JS-Seite aus nicht sichtbar ist?

Isoliere zuerst, ob es der JS-Thread, der native UI-Thread oder tatsächliche native Arbeit ist (Bilddecodierung, native Modul-Calls) — der JS-Profiler in Flipper zeigt dir nur Ersteres. Native Tools (Xcodes Instruments Time Profiler auf iOS, Android Studios Profiler auf Android) zeigen, wo der native Thread wirklich Zeit verbringt, und genau dort tauchen Dinge wie eine zu tiefe View-Hierarchie, unoptimierte Bilddecodierung oder ein geschwätziges natives Modul auf. JS-Thread und UI-Thread laufen unabhängig, blockieren sich aber an Punkten wie Layout und Animation gegenseitig, weshalb "JS ist schnell" und "die App läuft flüssig" zwei getrennte Behauptungen sind, die beide verifiziert werden müssen.

Du bist für Release und Rollout in einem wachsenden Mobile-Team verantwortlich — was bedeutet das konkret?

Eine CI/CD-Pipeline (Fastlane, EAS Build oder Bitrise), die signierte, versionierte Builds produziert, ohne dass jemand Xcode oder Android Studio manuell startet, Feature Flags, damit ein kaputtes Feature abgeschaltet werden kann, ohne einen Notfall-Store-Release zu brauchen, und ein gestaffelter Rollout (prozentbasiert im Play Store, TestFlight-Gruppen auf iOS), damit ein schlechter Build erst 5 % der Nutzer erreicht, bevor er 100 % erreicht. Es bedeutet außerdem, die OTA-vs-nativer-Release-Policy zu besitzen — zu entscheiden, was sich sofort sicher ausliefern lässt und was den vollen Review-Zyklus braucht —, und sicherzustellen, dass Crash-Reporting (Sentry, Bugsnag) exakt an Commit und Bundle-Version gekoppelt ist, damit sich ein Spike auf einen konkreten Release zurückverfolgen lässt.

Wie skalierst du eine React-Native-Codebase und ein wachsendes Team darin gleichzeitig?

Teile die App in Module oder ein Monorepo mit klaren Package-Grenzen (Nx, Turborepo oder ein eigenes Workspace-Setup), damit Teams eine vertikale Scheibe besitzen statt dass alle an denselben Screens herumschrauben, und erzwinge das mit Lint-Regeln oder Dependency-Graph-Checks statt nur mit Konvention. Standardisiere früh die Dinge, die in der Praxis die meiste teamübergreifende Reibung verursachen — Navigationsstruktur, Wahl des State Managements, Ownership nativer Module, Design-System-Komponenten —, denn einen Standard nachträglich einzuführen, nachdem fünf Squads schon auseinandergedriftet sind, kostet weit mehr, als ihn früh zu setzen. Der Mentoring-Teil dreht sich weniger um Code-Review und mehr darum, die Antwort auf "wie machen wir X hier" auffindbar zu machen, ohne jedes Mal einen Senior fragen zu müssen.