Was wird im Vorstellungsgespräch als Fullstack-Entwickler am häufigsten gefragt?

Ein Feature von vorn bis hinten, Validierung, Anmeldung, Caching, API-Design, Performance über die Schichten, Datei-Uploads, Releases und die Wahl des Stacks, für Lead-Rollen die Form des Teams und Entscheidungen zwischen Bauen und Kaufen.

Gibt es eine Coding-Runde?

Meist eine App als Aufgabe für zu Hause oder eine Live-Aufgabe mit einem kleinen Frontend und einer API. Halte sie einfach und erklär deine Abwägungen schriftlich.

Werde ich im Frontend und im Backend geprüft?

Ja, aber nicht gleich tief. Sag, zu welcher Seite du neigst, und zeig, dass du auf der anderen ausliefern kannst.

Welchen Stack sollte ich im Interview nutzen?

Den, den du am besten kennst, außer der Job nennt einen. Eine saubere, gut getestete App in einem vertrauten Stack schlägt eine halb fertige in ihrem.

Wie bereite ich mich in einer Woche vor?

Sag die zwei ausgearbeiteten Antworten laut, bau ein kleines Feature von vorn bis hinten mit Anmeldung und Datenbank, deploye es und bereite je eine Geschichte vor: über einen Bug über die Schichten, ein Release und eine Abwägung.

Interviewfragen für Fullstack-Entwickler, mit ausgearbeiteten Antworten

Fünfzehn Fragen, die in Vorstellungsgesprächen für Fullstack-Entwickler immer wieder kommen, vom ersten Fullstack-Job bis zum Lead, Engineering Manager und Head of Engineering. Zu jeder: worauf der Interviewer achtet, eine kurze Antwort, die ausführliche Antwort in einfachen Worten, eine schwache Antwort, die du vermeiden solltest, und eine typische Nachfrage.

Das cvscored-TeamVeröffentlicht 05.11.2026 · Aktualisiert 05.11.2026

Inhalt

So nutzt du diese Fragen
Was ein Fullstack-Entwickler können muss
Ein Feature von vorn bis hinten
Zwischen den Schichten
Releases und Entscheidungen
Fragen für Lead, Engineering Manager und Head of Engineering
Dein Lebenslauf für diese Fragen
Das Wichtigste
Häufige Fragen
Mehr zu diesem Beruf

So nutzt du diese Fragen

Fang mit der kurzen Antwort an, laut. Such dir dann zwei oder drei Punkte aus der ausführlichen Antwort aus und ergänze ein Feature, das du über die Schichten gebaut hast: was der Nutzer getan hat, was der Server getan hat, was die Datenbank gespeichert hat und was unterwegs schiefging. Fullstack-Interviewer ändern gern eine Schicht und fragen, was mit den anderen passiert; sei darauf gefasst.

Was ein Fullstack-Entwickler können muss

Der Browser: ein Framework wie React, Angular oder Vue.js, dazu HTML und CSS gut genug, um einen Screen auszuliefern.
Der Server: ein Backend wie Node.js, Java mit Spring, Python mit Django oder PHP mit Laravel.
Eine Sprache, wo es hilft: TypeScript auf beiden Seiten, mit Typen, die API und Screen teilen.
Daten: SQL und PostgreSQL oder MongoDB in JavaScript-Stacks, samt sicherer Änderungen am Schema.
Zwischen den Schichten: REST-APIs oder GraphQL, Anmeldung und Caching.
Ausliefern: Git, Docker, CI/CD und eine Cloud wie AWS.

Ein Feature von vorn bis hinten

Führ mich durch den Bau eines Buttons „Für später merken“ in einem Onlineshop, von der Datenbank bis zum Screen.

Worauf sie achten: dass du das ganze Feature siehst, jede Schicht und wie sie zusammenhängen.

Kurze Antwort: „Eine Tabelle verknüpft Nutzer mit gemerkten Produkten. Zwei API-Endpunkte speichern und entfernen einen Eintrag, einer listet sie auf. Der Button ändert sich sofort beim Drücken und springt zurück, wenn die Anfrage fehlschlägt. Ich schreibe Tests auf beiden Seiten, gebe es hinter einem Feature Flag frei und messe, wie viele Leute es nutzen.“

Die ausführliche Antwort in sechs Schritten:

Erst fragen. Können Gäste Artikel merken oder nur angemeldete Nutzer? Was passiert mit der Liste eines Gasts, wenn er sich anmeldet? Gibt es eine Grenze? Diese Antworten prägen jede Schicht.
Die Daten. Eine Tabelle mit Nutzer, Produkt und Datum des Merkens, mit einem eindeutigen Paar aus Nutzer und Produkt, damit zweimaliges Merken nichts bewirkt. Ein Index auf den Nutzer für die Liste.
Die API. Speichern und Entfernen lassen sich gefahrlos wiederholen; die Liste ist paginiert. Jede Anfrage prüft, dass die Liste dem angemeldeten Nutzer gehört.
Der Screen. Der Button ändert sich sofort (ein Optimistic Update) und springt zurück, wenn der Server ablehnt. Er hat eine klare Beschriftung für Screenreader und funktioniert mit der Tastatur.
Tests. Ein Servertest für die Eindeutigkeitsregel und die Prüfung des Besitzers, ein Komponententest für den Button und ein End-to-End-Test: merken, neu laden, noch gemerkt.
Freigeben und lernen. Hinter einem Feature Flag ausliefern (ein Schalter, der das Feature für einen Teil der Nutzer einschaltet), Fehler beobachten, dann für alle einschalten und die Nutzung messen.

Schwache Antwort: „Ich speichere die gemerkten Artikel im Local Storage.“ Auf einem anderen Gerät sind sie weg, und die Firma kann sie nicht sehen.

Nachfrage: „Ein gemerktes Produkt wird aus dem Shop gelöscht. Was zeigt die Liste?“ Den Eintrag behalten, als nicht mehr verfügbar anzeigen und den Nutzer ihn entfernen lassen; nie die ganze Seite kaputtmachen.

Wo validierst du ein Formular: im Browser, auf dem Server oder an beiden Stellen?

Worauf sie achten: dass du weißt, welche Prüfungen den Nutzer schützen und welche das System.

Kurze Antwort: „An beiden, aus verschiedenen Gründen. Prüfungen im Browser helfen dem Nutzer: schnelle Hinweise neben dem Feld. Prüfungen auf dem Server schützen das System, denn jeder kann eine Anfrage ohne Browser schicken. Wo ich kann, nutzen beide dieselben Regeln, einmal definiert.“

Die ausführliche Antwort: Dem Server allein kann man vertrauen, also wird jede Regel dort geprüft: Typen, Längen, erlaubte Werte und Regeln, die die Datenbank brauchen, etwa eine E-Mail-Adresse, die schon vergeben ist. Der Browser wiederholt die einfachen Regeln für die Geschwindigkeit und zeigt die Fehler des Servers neben dem richtigen Feld. Mit TypeScript auf beiden Seiten kann ein gemeinsames Schema beide steuern. Fehlermeldungen sagen in einfachen Worten, wie man das Problem behebt, und behalten, was der Nutzer eingetippt hat.

Schwache Antwort: „Das Formular prüft es, also muss die API es nicht.“ Nachfrage: „Der Server lehnt eine gültig aussehende Adresse ab, die der Browser erlaubt hat. Was sieht der Nutzer?“ Die Meldung des Servers, neben dem Feld, und der Rest des Formulars bleibt erhalten.

Wie funktioniert die Anmeldung von vorn bis hinten in einer App, die du gebaut hast: Sessions mit Cookies oder Tokens?

Worauf sie achten: Authentifizierung über Browser und Server hinweg, und ihre Risiken.

Kurze Antwort: „Für eine Web-App auf einer Domain nehme ich lieber eine Server-Session in einem Cookie, das das Skript nicht lesen kann, markiert als Secure und SameSite. Tokens passen zu mobilen Apps und zu APIs, die andere Dienste nutzen. So oder so werden Passwörter mit einem langsamen Algorithmus gehasht, oder ich nutze einen erprobten Anbieter für die Anmeldung.“

Die ausführliche Antwort: Bei einer Session hält der Server fest, wer angemeldet ist, und der Browser hat nur eine ID in einem HttpOnly-Cookie, sodass ein in die Seite eingeschleustes Skript sie nicht stehlen kann; Schutz vor gefälschten Anfragen von anderen Seiten (CSRF) bieten die SameSite-Einstellung und ein Token in Formularen. Tokens wie JWTs tragen die Identität des Nutzers selbst; sie lassen sich leicht über Server verteilen, aber schwer widerrufen, bevor sie ablaufen. Dazu kommen Rate Limits bei der Anmeldung, ein sicherer Ablauf zum Zurücksetzen und eine Zwei-Faktor-Anmeldung für Admin-Konten. Behandle die Anmeldung als Feature mit eigenen Tests.

Schwache Antwort: „Ich lege das Token im Local Storage ab.“ Jedes Skript auf der Seite kann es lesen. Nachfrage: „Der Nutzer ändert sein Passwort. Was passiert mit seinen anderen Sessions?“ Alle beenden, außer vielleicht der aktuellen.

Zwischen den Schichten

Ein Nutzer ändert sein Profil, sieht nach dem Neuladen aber immer noch den alten Namen. Wo suchst du?

Worauf sie achten: dass du jeden Ort kennst, an dem eine Kopie der Daten liegen kann, von der Datenbank bis zum Screen.

Kurze Antwort: „Ich folge den Daten von der Datenbank nach außen. Ist der neue Name gespeichert? Gibt die API ihn zurück oder eine Kopie aus dem Cache? Cacht ein CDN oder der Browser die Antwort? Hält das Frontend eine alte Kopie im State oder im Query-Cache? Ich prüfe jede Schicht, bis ich die alte Kopie finde.“

Die ausführliche Antwort: Caches gibt es auf jeder Schicht: Die Read Replica der Datenbank kann einen Moment hinterherhinken; der Server cacht vielleicht im Speicher oder in einem gemeinsamen Store; ein CDN, also Server nah am Nutzer, die Kopien halten, cacht vielleicht versehentlich API-Antworten; der Browser folgt den Cache-Headern; die Datenbibliothek des Frontends hält Ergebnisse vor. Die Lösung liegt in der richtigen Schicht: no-store-Header für persönliche Daten schicken, den Cache-Eintrag auf dem Server löschen, wenn sich das Profil ändert, die eigenen Daten des Nutzers aus der Hauptdatenbank lesen und den Cache des Frontends nach der Änderung neu laden oder aktualisieren.

Schwache Antwort: „Der Nutzer soll den Browser-Cache leeren.“ Nachfrage: „Es passiert nur bei manchen Nutzern.“ Schau, was sich unterscheidet: eine CDN-Region, eine Replica oder ein zweiter offener Tab mit altem State.

Wie entwirfst du die API zwischen deinem eigenen Frontend und Backend: REST, GraphQL oder etwas anderes?

Worauf sie achten: dass du nach den Screens und dem Team des Produkts wählst und die Kosten jeder Option kennst.

Kurze Antwort: „Für die meisten Produkte REST: einfach, cachebar und von allen verstanden. GraphQL hilft, wenn viele verschiedene Screens verschiedene Ausschnitte derselben Daten brauchen oder mehrere Clients eine API nutzen. Sind Frontend und Backend eine einzige TypeScript-Codebasis, sind typisierte Aufrufe mit gemeinsamen Typen oft am einfachsten.“

Die ausführliche Antwort: Bei REST-APIs hat jede Ressource eine Adresse, und HTTP-Caching funktioniert sofort; Screens brauchen manchmal mehrere Aufrufe oder bekommen zu viel. GraphQL lässt jeden Screen in einer Anfrage genau das abfragen, was er braucht, aber Caching ist schwerer, und eine unbedachte Abfrage kann die Datenbank stark belasten, deshalb braucht es Grenzen für Tiefe und Kosten einer Abfrage. Ein Backend for Frontend, eine dünne API, zugeschnitten auf eine App, ist eine weitere Antwort. Welcher Stil auch immer: Teile die Typen, beschreibe die API an einem Ort und versioniere sie, wenn externe Clients sie nutzen.

Schwache Antwort: „GraphQL, weil es neuer ist.“ Nachfrage: „Ein Listen-Screen macht fünfzig API-Aufrufe.“ Einen Endpunkt ergänzen, der die Liste mit allem liefert, was der Screen braucht, oder die Aufrufe bündeln.

Eine Seite ist langsam. Wie findest du heraus, ob der Browser, das Netzwerk, die API oder die Datenbank schuld ist?

Worauf sie achten: Performance über die ganze Anfrage, Schicht für Schicht gemessen.

Kurze Antwort: „Ich teile die Zeit auf. Der Netzwerk-Tab des Browsers zeigt, wie lange der API-Aufruf dauert und wie lange die Seite bis zur Anzeige braucht. Ist der Aufruf langsam, zeigen die Logs und Traces des Servers die Zeit im Code und die Zeit in der Datenbank. Dann behebe ich die Schicht, die die meiste Zeit braucht.“

Die ausführliche Antwort in fünf Schritten:

So nachstellen, wie der Nutzer es erlebt. Ein Handy im Mobilfunknetz, mit echten Daten; ein Entwickler-Laptop mit leerer Datenbank versteckt die meisten Probleme.
Browser oder Server? Antwortet die API schnell, aber die Seite ist langsam, liegt die Ursache im Browser: zu viel JavaScript, ein großes Bild oder eine lange Liste, die auf einmal gerendert wird.
Netzwerk. Viele Aufrufe nacheinander, große Antworten oder keine Kompression; Aufrufe zusammenfassen und nur schicken, was der Screen zeigt.
Server. Ein Trace mit Request-ID zeigt jeden Schritt. Oft ist eine Datenbankabfrage langsam, oder dieselbe Abfrage läuft einmal pro Zeile einer Liste (das N+1-Problem).
Datenbank und zurück. Den Abfrageplan lesen, den Index ergänzen oder die Abfrage umschreiben, dann die ganze Seite noch einmal messen, denn jetzt ist die nächstlangsamste Schicht das Ziel.

Schwache Antwort: „Ich würde überall Caching einbauen.“ Das versteckt die Ursache und bringt veraltete Daten.

Nachfrage: „Es ist nur bei Kunden mit vielen Bestellungen langsam.“ Etwas wächst mit den Daten: ein fehlender Index, eine Abfrage pro Bestellung oder eine Liste ohne Paginierung.

Wie behandelst du einen Datei-Upload, etwa ein Profilbild, von vorn bis hinten?

Worauf sie achten: Grenzen, Sicherheit und Speicherung über Browser, Server und Cloud.

Kurze Antwort: „Der Browser prüft Typ und Größe und zeigt eine Vorschau. Der Server stellt eine kurzlebige signierte Adresse aus, sodass der Browser direkt in den Dateispeicher hochlädt, nicht über meinen Server. Der Server prüft die Datei dann, erzeugt die Größen, die die App braucht, und speichert nur den Schlüssel der Datei in der Datenbank.“

Die ausführliche Antwort: Cloud-Speicher wie S3 bei AWS bietet signierte Upload-Adressen, die nach Minuten ablaufen und eine Datei eines festgelegten Typs und einer festgelegten Größe erlauben. Trau nie dem Dateinamen oder dem Typ, den der Browser meldet; prüfe den Inhalt. Entferne versteckte Daten wie den Aufnahmeort des Fotos, erzeuge kleinere Kopien für Listen und liefere Bilder über ein CDN aus. Persönliche Fotos sind personenbezogene Daten nach der DSGVO (EU) und ähnlichen Gesetzen, also lösch sie, wenn das Konto gelöscht wird.

Schwache Antwort: „Ich speichere das Bild als Text in der Datenbank.“ Nachfrage: „Nutzer laden Fotos von neuen Handys in einem Format hoch, das der Browser nicht anzeigen kann.“ Auf dem Server in ein Format umwandeln, das jeder Browser liest.

Wie würdest du einen Live-Zähler für Benachrichtigungen einbauen, der sich ohne Neuladen der Seite aktualisiert?

Worauf sie achten: die Optionen für Echtzeit-Updates und ihre Kosten auf beiden Seiten.

Kurze Antwort: „Ich fange mit der einfachsten Option an, die den Bedarf deckt. Polling alle halbe Minute reicht für einen Zähler oft aus. Muss es sofort sein, schicken Server-Sent Events Updates vom Server über eine offene Verbindung; WebSockets sind für Verkehr in beide Richtungen, etwa einen Chat.“

Die ausführliche Antwort: Polling ist einfach und funktioniert überall, aber die meisten Anfragen bringen nichts Neues. Server-Sent Events halten pro Nutzer eine Verbindung offen und passen zu Updates, die nur vom Server kommen. WebSockets erlauben beide Richtungen und brauchen Sorgfalt bei Load Balancern und beim Wiederverbinden. Echtzeit-Verbindungen brauchen einen gemeinsamen Kanal zwischen den Server-Kopien, etwa Redis, damit ein Ereignis auf einem Server die Nutzer erreicht, die mit einem anderen verbunden sind. Auf dem Screen: nach dem Ruhezustand oder einem verlorenen Netz neu verbinden und den aktuellen Zähler holen, wenn die Verbindung zurück ist.

Schwache Antwort: „WebSockets für alles.“ Nachfrage: „Zehntausend Nutzer sind verbunden, und du deployst.“ Alle Verbindungen brechen auf einmal ab; die Clients verbinden sich mit einer zufälligen Verzögerung neu, damit die neuen Server nicht überflutet werden.

Releases und Entscheidungen

Ein Feature braucht eine Änderung im Frontend, eine an der API und eine an der Datenbank. Wie gibst du es frei, ohne dass etwas kaputtgeht?

Worauf sie achten: dass du weißt, dass die Hälften zu verschiedenen Zeitpunkten freigegeben werden, und das einplanst.

Kurze Antwort: „In Schritten, die jeder für sich sicher sind. Zuerst die Änderung an der Datenbank, die der alte Code ignoriert, dann die API, die alte und neue Anfragen unterstützt, dann das Frontend, hinter einem Feature Flag. Alte Teile werden erst entfernt, wenn nichts sie mehr nutzt.“

Die ausführliche Antwort: Nutzer lassen eine alte Version des Frontends stundenlang in einem Tab offen und mobile Apps monatelang, also muss die API beides annehmen. Das ist Expand and Contract: erweitern, indem die neue Spalte oder das neue Feld neben das alte kommt, Leser und Schreiber umstellen, dann zusammenziehen, indem das Alte entfernt wird. Ein Feature Flag lässt dich das Feature schrittweise einschalten und sofort ausschalten, wenn die Fehler steigen. Die CI/CD-Pipeline lässt den End-to-End-Test der wichtigsten Abläufe vor dem Umschalten gegen die neue Version laufen.

Schwache Antwort: „Wir deployen nachts alles zusammen.“ Selbst dann läuft in einem offenen Tab noch das alte Frontend. Nachfrage: „Das Flag ist seit Monaten für alle eingeschaltet.“ Entferne es und den alten Code; alte Flags sind versteckte Komplexität.

Du startest ein neues Produkt mit zwei Entwicklern. Welchen Stack wählst du, und warum?

Worauf sie achten: Urteilsvermögen und Abwägungen, nicht ein Lieblings-Framework.

Kurze Antwort: „Den, den das Team schon gut kennt, als eine einzige deploybare App, einen Monolithen, mit einer relationalen Datenbank und einem verwalteten Hosting. Für ein Webprodukt heißt das oft TypeScript mit React und Node.js oder ein Framework wie Django oder Laravel, das Anmeldung und Admin mitbringt. Wie schnell wir von den Nutzern lernen, zählt am ersten Tag mehr als die Skalierung.“

Die ausführliche Antwort: Liste auf, was das Produkt braucht: Anmeldung, Zahlungen, E-Mail, Admin-Screens, vielleicht eine Suche. Ein Framework mit „Batteries included“ liefert vieles davon gratis; ein leichterer Stack gibt mehr Freiheit und mehr Arbeit. Eine Sprache auf beiden Seiten lässt zwei Leute sich frei im Code bewegen. Wähle langweilige, gut dokumentierte Werkzeuge, für die man leicht Leute findet. Ein Monolith mit klaren Modulen lässt sich später aufteilen, wenn ein Teil es braucht; frühes Aufteilen kostet ein kleines Team den Großteil seiner Zeit. Schreib die Entscheidung mit ihren Gründen auf.

Schwache Antwort: „Microservices auf Kubernetes, damit wir skalieren können.“ Nachfrage: „Ein Investor fragt, ob es eine Million Nutzer schafft.“ Erklär, welcher Teil sich zuerst ändern müsste und dass es den Plan gibt; gebaut wird er erst, wenn er gebraucht wird.

Auf dem Server schlägt etwas fehl. Was sieht der Nutzer, und wie findest du später die Ursache?

Worauf sie achten: eine Fehlerbehandlung, die dem Nutzer und dem Entwickler dient, über die Schichten hinweg.

Kurze Antwort: „Der Nutzer sieht eine kurze Meldung in einfachen Worten, die sagt, was er als Nächstes tun kann, und behält, was er eingetippt hat. Der Server gibt einen klaren Fehlercode und eine Referenz zurück, loggt die Details mit einer Request-ID, und dieselbe ID steht im Fehlerbericht des Frontends, sodass ich einem Fehler vom Klick bis zur Datenbank folgen kann.“

Die ausführliche Antwort: Entscheide, welche Fehler der Nutzer beheben kann (ein falsches Feld, eine abgelaufene Session) und welche nicht (ein Bug, ein Ausfall); die ersten bekommen eine genaue Meldung, die zweiten eine Entschuldigung und einen neuen Versuch. Zeig Nutzern nie einen Stack Trace oder eine Meldung der Datenbank; das verwirrt sie und hilft Angreifern. Fang Fehler am Rand jeder Schicht ab: eine Error Boundary auf dem Screen, damit ein kaputtes Widget nicht die ganze Seite leert, ein einziger Error Handler auf dem Server, der Exceptions in dieselbe Form der Antwort übersetzt. Sammle auch die Fehler des Frontends, denn die meisten erreichen die Logs des Servers nie.

Schwache Antwort: „Ich zeige ‚Etwas ist schiefgelaufen‘.“ Nachfrage: „Der Support sagt, Nutzer sehen Fehler, die du nicht findest.“ Nimm die Referenz in die Meldung auf, damit Nutzer sie nennen können, und prüfe die Fehlerberichte des Frontends auf Fehler, die die API nie aufgerufen haben.

Wie deployst du eine Fullstack-App, und was gehört in die Pipeline?

Worauf sie achten: dass du betreiben kannst, was du baust, nicht nur schreiben.

Kurze Antwort: „Jeder Push führt die Prüfungen aus: Typprüfungen, Tests für beide Hälften und einen Build in Docker. Jeder Pull Request bekommt eine Vorschau zum Durchklicken. Ein Merge in main deployt auf Staging, dann in die Produktion, mit den Änderungen an der Datenbank zuerst und einem schnellen Weg zurück.“

Die ausführliche Antwort: Docker baut für jede Umgebung dasselbe Image. Secrets liegen im Secret Store des Hosters. Die statischen Dateien des Frontends gehen an ein CDN; das Backend läuft in mehreren Kopien hinter einem Load Balancer, mit einem Health Check, damit eine kaputte Kopie keinen Verkehr bekommt. Datenbankmigrationen laufen in einem eigenen Schritt vor dem neuen Code. Beobachte nach einem Release einige Minuten lang Fehler und Antwortzeiten; zurück geht es, indem du das vorherige Image deployst. Halte Staging nah an der Produktion, sonst fängt es nicht ab, was in der Produktion kaputtgeht.

Schwache Antwort: „Ich kopiere die Dateien auf den Server.“ Nachfrage: „Eine Migration bricht auf halbem Weg ab.“ Migrationen laufen in einer Transaktion, wo die Datenbank es erlaubt, werden zuerst an einer Kopie der Produktionsdaten getestet, und der alte Code funktioniert weiter, bis sie fertig sind.

Fragen für Lead, Engineering Manager und Head of Engineering

Du bist der einzige Entwickler, der Frontend und Backend kennt. Wie hörst du auf, der Engpass zu sein?

Worauf sie achten: für Senior- und Lead-Rollen, dass du Wissen verteilst, statt es festzuhalten.

Kurze Antwort: „Ich mache mich absichtlich entbehrlich: kurze schriftliche Notizen dazu, wie jeder Teil funktioniert, Pairing mit anderen auf der Seite, die sie weniger kennen, Reviews, die etwas beibringen, und eine Regel, dass zwei Leute jeden Teil freigeben können. Mein Ziel ist, im Urlaub zu sein, ohne dass das Team wartet.“

Die ausführliche Antwort: Finde heraus, wo Arbeit auf dich wartet: Reviews, Releases, Fragen. Schreib die Entscheidungen und die Schritte zum Einrichten auf. Lass einen Entwickler mit Hang zum Frontend eine API-Änderung im Pairing machen und einen mit Hang zum Backend einen Screen. Mach das lokale Setup mit Docker zu einem einzigen Befehl, damit jeder die ganze App starten kann. Teile die Rufbereitschaft. Miss es: wie lange Reviews warten, wie viele Leute jeden Teil im letzten Monat freigegeben haben.

Schwache Antwort: „Ich arbeite einfach länger.“ Nachfrage: „Das Team sagt, dein Code sei am schwersten zu ändern.“ Frag, welche Teile, und schreib sie im Pairing mit den Leuten um, die sie ändern müssen.

Das Team wächst von vier auf fünfzehn Entwickler. Teilst du es in ein Frontend- und ein Backend-Team?

Worauf sie achten: für Lead- und Engineering-Manager-Rollen, wie die Form des Teams das Produkt beeinflusst.

Kurze Antwort: „Ich würde nach Produktbereichen teilen, nicht nach Schichten: Jedes Team verantwortet einen Teil des Produkts, etwa Onboarding oder Abrechnung, vom Screen bis zur Datenbank. Nach Schichten geteilte Teams reichen sich für jedes Feature Arbeit zu, und genau dieses Warten bremst wachsende Firmen.“

Die ausführliche Antwort: Kleine Teams von etwa fünf bis acht Leuten, jedes mit einem klaren Bereich und einem Produktmanager, können ausliefern, ohne andere zu fragen. Innerhalb eines Teams neigen die Leute trotzdem zu Frontend oder Backend; das ist in Ordnung. Manche Arbeit braucht ein gemeinsames Zuhause: das Designsystem, die Anmeldung, die Deploy-Pipeline. Gib diesen Teilen Verantwortliche oder, sobald es genug Teams gibt, ein kleines Plattform-Team. Ordne den Code passend: Module pro Produktbereich mit klaren Grenzen, damit Teams selten den Code der anderen ändern.

Schwache Antwort: „Ein Frontend-Team und ein Backend-Team, weil die Skills so verteilt sind.“ Nachfrage: „Zwei Teams müssen beide den Checkout ändern.“ Eines verantwortet ihn und macht die Reviews; das andere steuert bei, oder die Arbeit wird gemeinsam geplant.

Wie entscheidest du als Head of Engineering in einer kleinen Firma, was ihr selbst baut und was ihr kauft?

Worauf sie achten: für Rollen als Head of Engineering und Solution Architect, dass du Kosten, Risiko und Fokus für das Geschäft abwägst.

Kurze Antwort: „Wir bauen, was das Produkt besonders macht, und kaufen alles andere oder nutzen Open Source: Anmeldung, Zahlungen, E-Mail, Suche, Monitoring. Ich vergleiche die vollen Kosten, einschließlich der Zeit der Entwickler für Bau und Betrieb, mit dem Preis und dem Risiko, von einem Anbieter abhängig zu sein.“

Die ausführliche Antwort: Die Zeit eines kleinen Teams ist das Knappste, was es hat. Anmeldung oder Zahlungen selbst zu bauen heißt, jahrelang für ihre Sicherheit und ihre Ausfälle einzustehen. Kaufen heißt eine monatliche Rechnung, weniger Kontrolle und einen Plan, wie man den Anbieter verlässt, wenn die Preise steigen oder der Dienst eingestellt wird. Prüfe den Datenschutz: wo der Anbieter personenbezogene Daten speichert und ob ein Vertrag das abdeckt. Prüfe die Entscheidungen einmal im Jahr, denn was für fünf Entwickler richtig war, ist für fünfzig vielleicht falsch. Erklär jede Entscheidung den Gründern in Geld und Risiko, nicht in Werkzeugen.

Schwache Antwort: „Entwickler können alles bauen, also bauen wir es.“ Nachfrage: „Der Anbieter der Suche verdreifacht seinen Preis.“ Wisse vorher, wie schwer ein Wechsel wäre, halte deine Daten exportierbar und vergleiche die Alternativen, bevor sich der Vertrag verlängert.

Dein Lebenslauf für diese Fragen

Was in deinem Lebenslauf steht, wird zum Vorstellungsgespräch. Schreib zu jedem Thema unten eine Zeile, die beide Hälften der Arbeit nennt und mit einem Ergebnis endet:

Skill	Schwache Zeile	Starke Zeile, mit Beleg
Verantwortung für Features	Neue Features umgesetzt.	Gespeicherte Suchen von der Datenbank bis zu den E-Mail-Benachrichtigungen in 3 Wochen ausgeliefert; 1 von 5 aktiven Nutzern hat eine eingerichtet.
Anmeldung	Authentifizierung umgesetzt.	Eine selbst gebaute Passwortspeicherung durch einen Anbieter für die Anmeldung und eine Zwei-Faktor-Anmeldung für Admins ersetzt; Kontoübernahmen gibt es nicht mehr.
Performance	Die Performance der Anwendung verbessert.	Die langsame Bestellseite auf eine Abfrage pro Zeile zurückgeführt; eine einzige Abfrage und Paginierung brachten sie von 6 s auf unter 1 s.
Releases	Mit CI/CD gearbeitet.	Feature Flags und Vorschau-Deployments eingeführt; Hotfixes nach Releases von wöchentlich auf monatlich gesunken.
Team	Beim Wachstum des Teams geholfen.	Die Notizen zu Setup und Architektur geschrieben und mit jeder neuen Kollegin und jedem neuen Kollegen im Pairing gearbeitet; die Zeit bis zum ersten Release von 3 Wochen auf 3 Tage gesenkt.

Bewerte deinen Lebenslauf dann an einem echten Fullstack-Job: Das Ergebnis zeigt, auf welche Schichten sich der Job stützt und wo dein Lebenslauf nur eine Hälfte des Stacks belegt.

Das Wichtigste

Antworte, indem du der Anfrage folgst: der Klick, die API, die Datenbank und zurück zum Screen.
Validiere immer auf dem Server und im Browser dem Nutzer zuliebe.
Finde eine langsame Seite, indem du die Zeit auf Browser, Netzwerk, Server und Datenbank aufteilst.
Gib Änderungen, die beide Hälften betreffen, in Schritten frei, die jeder für sich sicher sind.
Für Lead- und Manager-Rollen kommen die Form des Teams, das Verteilen von Wissen und Entscheidungen zwischen Bauen und Kaufen dazu.

Häufige Fragen

Was wird im Vorstellungsgespräch als Fullstack-Entwickler am häufigsten gefragt?: Ein Feature von vorn bis hinten, Validierung, Anmeldung, Caching, API-Design, Performance über die Schichten, Datei-Uploads, Releases und die Wahl des Stacks, für Lead-Rollen die Form des Teams und Entscheidungen zwischen Bauen und Kaufen.
Gibt es eine Coding-Runde?: Meist eine App als Aufgabe für zu Hause oder eine Live-Aufgabe mit einem kleinen Frontend und einer API. Halte sie einfach und erklär deine Abwägungen schriftlich.
Werde ich im Frontend und im Backend geprüft?: Ja, aber nicht gleich tief. Sag, zu welcher Seite du neigst, und zeig, dass du auf der anderen ausliefern kannst.
Welchen Stack sollte ich im Interview nutzen?: Den, den du am besten kennst, außer der Job nennt einen. Eine saubere, gut getestete App in einem vertrauten Stack schlägt eine halb fertige in ihrem.
Wie bereite ich mich in einer Woche vor?: Sag die zwei ausgearbeiteten Antworten laut, bau ein kleines Feature von vorn bis hinten mit Anmeldung und Datenbank, deploye es und bereite je eine Geschichte vor: über einen Bug über die Schichten, ein Release und eine Abwägung.