Interviewfrage für Full-Stack-Entwickler

Wie verändern React Server Components die Art, wie du eine Anwendung strukturierst?

Worauf der Interviewer abzielt, wie du deine Antwort aufbaust und ein gesprochenes Beispiel zum Anpassen.

Kurzantwort

Server Components laufen nur auf dem Server, liefern kein JavaScript an den Browser und können Daten direkt awaiten, was den meisten Klempnerkram aus fetch plus useEffect plus Loading-State überflüssig macht. Client Components, markiert mit use client, besitzen weiterhin Interaktivität, State und Browser-APIs. Du schiebst das Datenladen nach oben in Server Components und hältst Client Components als kleine Blätter, was das Bundle schrumpft und den Daten-Wasserfall auf den Server verlagert.

Warum Interviewer das fragen

Das ist die größte Änderung in React seit Jahren, der Interviewer prüft also, ob du am Ball geblieben bist und eine Grenze beschreiben kannst statt Marketingtexte nachzuplappern. Er will hören, dass du verstehst, was die Serialisierungsgrenze überquert, wo State leben kann und wo nicht, und welche Abwägungen dazugehören. Vage Begeisterung wirkt hier schlecht; wer eine echte Einschränkung nennt, wirkt wie jemand, der es ausgeliefert hat.

So baust du deine Antwort auf

  • Definier die zwei Komponententypen in je einem Satz.
  • Erklär, was die Grenze überqueren kann und was nicht.
  • Beschreib die daraus folgende Form des Komponentenbaums.
  • Nenn eine konkrete Abwägung, die dir begegnet ist.

Beispielantwort

Gesprochenes Beispiel, erste Person

Das mentale Modell, bei dem es bei mir klick gemacht hat, ist, dass die Grenze eine Serialisierungsgrenze ist und kein Ordner. Server Components rendern auf dem Server und ihr Code erreicht den Browser nie, eine schwere Markdown- oder Datumsbibliothek, die dort genutzt wird, kostet auf dem Client also null Kilobyte. Sie können direkt im Komponentenkörper einen Datenbankaufruf awaiten. Alles mit State, Effects oder einem Event-Handler muss eine Client Component mit use client ganz oben sein, und Props, die dorthin übergehen, müssen serialisierbar sein, du übergibst also Daten und keine Funktionen oder Klasseninstanzen. In der Praxis sehen meine Bäume deshalb so aus: Server Components bis ganz nach unten mit kleinen interaktiven Blättern, und die serverseitig geladenen Daten reiche ich als Props hinein. Die Abwägung, die mich in einem neueren Projekt getroffen hat, war der mentale Aufwand im Code Review, weil Leute für einen kleinen Button use client an einem Parent ergänzt und damit still einen ganzen Teilbaum auf den Client gezogen haben. Wir haben am Ende eine Lint-Regel und einen Bundle-Size-Check in der CI ergänzt, um das zu fangen.

Steht dieses Vorstellungsgespräch bald an? GhostPilot hört bei deinem Live-Call mit, erkennt die Frage in dem Moment, in dem sie gestellt wird, und bringt dir eine strukturierte Antwort in Echtzeit auf den Bildschirm. Probier es im nächsten Mock aus, oder hol dir einen $29 Session Pass, kein Abo, für den Ernstfall.

So funktioniert es

Nachfragen, mit denen du rechnen solltest

  • Wo passt der use-Hook hier hinein?
  • Wie behandelst du ein Formular, das einen Server-Roundtrip braucht?
  • Wie würdest du Daten cachen, die in einer Server Component geladen werden?

Weitere Fragen für Full-Stack-Entwickler

Dein Interviewer stellt seine eigene Version davon. Kopier deine echte Stellenbeschreibung in den kostenlosen Question Predictor und bekomm die 20 Fragen, die diese Rolle am wahrscheinlichsten stellt, samt dem, worauf jede wirklich abzielt.

Meine Fragen vorhersagen

Üb die harten Fragen, bevor sie gestellt werden

Trainier mit einem Live-Copiloten und geh dann vorbereitet rein. Ein $29 Session Pass bringt dich durch das Vorstellungsgespräch, ohne Abo und ohne Bindung.

GhostPilot holen