Interviewfragen für Frontend-Entwickler, mit ausgearbeiteten Antworten

So nutzt du diese Fragen

Sag zuerst die kurze Antwort laut: Das ist deine erste halbe Minute. Such dir dann zwei oder drei Punkte aus der ausführlichen Antwort aus und ergänze einen Screen, den du selbst gebaut hast: was langsam oder kaputt war, was du gemessen hast, was du geändert hast. Interviewer hören auf Messungen und auf den Nutzer, nicht auf eine Liste von Bibliotheken.

Was ein Frontend-Entwickler können muss

• Die Sprache: JavaScriptIn 54 % der Anzeigen für Frontend-Entwickler gefragt (Stand 05.11.2026).Die Sprache des Browsers: Closures, Promises, die Event Loop und einen Stack Trace in Ruhe lesen. in der Tiefe und TypeScriptIn 48 % der Anzeigen für Frontend-Entwickler gefragt (Stand 05.11.2026).Typen für Props, API-Antworten und State, damit Fehler im Editor auffallen, bevor Nutzer sie sehen. für alles, was mehr als eine Person ändert.
• Die Seite: semantisches HTML und CSSIn 59 % der Anzeigen für Frontend-Entwickler gefragt (Stand 05.11.2026).Semantisches HTML, Flexbox und Grid, responsive Layouts und CSS, das ein Team auch nächstes Jahr noch ändern kann., Flexbox und Grid und Layouts, die vom kleinen Handy bis zum breiten Bildschirm funktionieren.
• Ein Framework: ReactIn 37 % der Anzeigen für Frontend-Entwickler gefragt (Stand 05.11.2026).Komponenten, Hooks, State und Effekte; wissen, warum eine Komponente rendert und wie man zu häufiges Rendern verhindert., AngularIn 41 % der Anzeigen für Frontend-Entwickler gefragt (Stand 05.11.2026).Verbreitet bei Banken, Versicherungen und großen Firmen: Module, Services, RxJS-Streams und eine strenge Struktur. oder Vue.jsIn 24 % der Anzeigen für Frontend-Entwickler gefragt (Stand 05.11.2026).Ein leichteres Framework, beliebt bei Agenturen und kleineren Produktteams; Komponenten und reaktiver State., und warum es rendert, was es rendert.
• Daten: REST-APIsIn 33 % der Anzeigen für Frontend-Entwickler gefragt (Stand 05.11.2026).APIs gut aufrufen: Lade- und Fehlerzustände, Wiederholungen, Caching und das Format der Antwort mit dem Backend abstimmen. aufrufen, Lade- und Fehlerzustände und das Cachen dessen, was der Nutzer schon gesehen hat.
• Qualität: Komponententests (Unit-TestsIn 11 % der Anzeigen für Frontend-Entwickler gefragt (Stand 05.11.2026).Komponenten danach testen, was Nutzer sehen und tun, nicht nach ihrem Innenleben.), ein paar End-to-End-Tests (TestautomatisierungIn 5 % der Anzeigen für Frontend-Entwickler gefragt (Stand 05.11.2026).End-to-End-Tests im echten Browser für die wenigen Abläufe, die nie kaputtgehen dürfen, etwa den Checkout.), Barrierefreiheit und Ladezeit.
• Zusammenarbeit: Designs in FigmaEine Design-Datei lesen: Abstände, Tokens, Zustände und Varianten, und erkennen, was das Design vergessen hat. lesen, Reviews in GitIn 35 % der Anzeigen für Frontend-Entwickler gefragt (Stand 05.11.2026).Kleine Branches, klare Commits und Reviews; einen Merge-Konflikt lösen, ohne Arbeit zu verlieren. und Vorschauen jeder Änderung über CI/CDIn 25 % der Anzeigen für Frontend-Entwickler gefragt (Stand 05.11.2026).Jede Änderung wird automatisch gebaut, getestet und als Vorschau bereitgestellt, damit ein Release langweilig ist..

Der Browser und die Ladezeit

Was passiert im Browser zwischen dem Eintippen einer Adresse und dem Anzeigen der Seite?

Worauf sie achten: dass du die Schritte des Browsers kennst und deshalb sagen kannst, welcher langsam ist.

Kurze Antwort: „Der Browser findet den Server, lädt das HTML und beginnt, die Seite aufzubauen. Er holt das CSS und die Skripte, die das HTML nennt, berechnet das Layout und malt die Pixel. Skripte können diese Arbeit blockieren, deshalb halte ich die erste Ansicht klein und lade den Rest später.“

Die ausführliche Antwort: Zuerst wird die Adresse aufgelöst (DNS) und eine sichere Verbindung geöffnet. Das HTML kommt an und wird von oben nach unten in einen Baum von Elementen gelesen, das DOM. CSS wird in Regeln übersetzt; der Browser braucht es, bevor er malen kann, es ist also render-blocking. Ein Skript ohne async oder defer hält das Lesen an, bis es gelaufen ist. Dann berechnet der Browser Größe und Position jeder Box (Layout) und malt sie. Spätere Änderungen wiederholen einige dieser Schritte; eine geänderte Größe zwingt den Browser zu einem neuen Layout, was in einer langen Liste teuer ist. Gut rendern heißt: weniger schicken, und früher.

Schwache Antwort: „Der Server schickt die Seite, und React zeigt sie an.“ Nachfrage: „Welchen dieser Schritte bremst ein großes Skript?“ Das Herunterladen, Lesen und Ausführen: Der Main Thread ist beschäftigt, also kann die Seite nicht auf den Nutzer reagieren.

Eine Produktseite lädt auf Handys langsam. Wie findest du heraus, warum, und wie behebst du es?

Worauf sie achten: dass du misst, bevor du etwas änderst, und die üblichen Ursachen kennst.

Kurze Antwort: „Ich messe auf einem Mittelklasse-Handy und in einem langsamen Netz, nicht auf meinem Laptop. Ich schaue auf die Core Web Vitals: wann der Hauptinhalt erscheint, wie schnell die Seite auf ein Tippen reagiert und ob Dinge herumspringen. Dann behebe ich die größte Ursache zuerst und messe noch einmal.“

Die ausführliche Antwort in sechs Schritten:

1. Echte Nutzer messen. Felddaten aus echten Besuchen zeigen die Wahrheit; ein Labortest auf einem schnellen Laptop versteckt das Problem. Die Core Web Vitals sind die drei Messgrößen von Google: Largest Contentful Paint (wann der Hauptinhalt erscheint), Interaction to Next Paint (wie schnell die Seite reagiert) und Cumulative Layout Shift (wie sehr sich Dinge verschieben).
2. Das größte Element finden. Meist das Hero-Bild oder die Hauptüberschrift. Liefere dieses Bild in der richtigen Größe und einem modernen Format aus und sag dem Browser, dass er es früh holen soll.
3. Das Skript kürzen. Schau, was jede Seite herunterlädt. Teile das Bundle, damit jede Seite nur ihren eigenen Code lädt, entferne ungenutzte Bibliotheken und lade Chat-Widgets und Tracker erst, wenn die Seite benutzbar ist.
4. Den Main Thread entlasten. Lange Tasks über fünfzig Millisekunden lassen Tippen träge wirken. Teile sie auf oder verlege schwere Arbeit vom Main Thread weg.
5. Die Sprünge stoppen. Gib Bildern und Werbung einen festen Platz, bevor sie laden, damit sich der Inhalt nicht unter dem Daumen des Lesers verschiebt.
6. Schnell bleiben. Nimm ein Performance-Budget in CI/CDIn 25 % der Anzeigen für Frontend-Entwickler gefragt (Stand 05.11.2026).Jede Änderung wird automatisch gebaut, getestet und als Vorschau bereitgestellt, damit ein Release langweilig ist. auf, damit eine Änderung, die das Bundle deutlich vergrößert, ihre Prüfung vor dem Release nicht besteht.

Schwache Antwort: „Ich würde einen Lade-Spinner einbauen.“ Ein Spinner versteckt die Langsamkeit; er beseitigt sie nicht.

Nachfrage: „Das Marketing baut drei Tracking-Skripte ein. Was tust du?“ Ihre Kosten messen, sie laden, nachdem die Seite interaktiv ist, und mit dem Marketing ein Budget vereinbaren, damit die Kosten sichtbar sind.

Server-Side Rendering, statische Seiten oder Rendering im Browser: Wie entscheidest du?

Worauf sie achten: dass du das Rendering zur Seite passend wählst, nicht nach Mode.

Kurze Antwort: „Seiten, die Suchmaschinen finden sollen und schnell erscheinen müssen, etwa Produktseiten, werden auf dem Server gerendert oder vorab als statische Seiten gebaut. Screens hinter einem Login, etwa ein Dashboard, können im Browser rendern. Viele Apps mischen beides.“

Die ausführliche Antwort: Client-Side Rendering schickt eine fast leere Seite und baut sie mit JavaScript auf; einfach zu hosten, aber die erste Ansicht wartet auf das Skript, und Suchmaschinen sehen weniger. Server-Side Rendering baut das HTML für jede Anfrage, sodass der Inhalt sofort erscheint und SEOSeiten, die Suchmaschinen lesen können: Server-Rendering, Titel, Links und schnelles Laden. leichter ist, braucht aber einen Server und Hydration, bei der der Browser das JavaScript an das HTML des Servers anhängt. Static Generation baut Seiten vorab: am schnellsten von allen, für Inhalte, die sich selten ändern. Frameworks wie Next.js lassen jede Seite selbst wählen.

Schwache Antwort: „Immer Server-Side Rendering, weil es schneller ist.“ Nachfrage: „Die serverseitig gerenderte Seite erscheint schnell, aber die Buttons tun zwei Sekunden lang nichts. Warum?“ Die Hydration ist noch nicht fertig; schick weniger JavaScript oder mach die wichtigen Teile zuerst interaktiv.

Was ist die Event Loop, und warum friert ein langer Task die Seite ein?

Worauf sie achten: dass du verstehst, wie JavaScript im Browser läuft.

Kurze Antwort: „JavaScript läuft in der Seite auf einem einzigen Main Thread, ein Task nach dem anderen. Die Event Loop nimmt den nächsten Task aus einer Warteschlange, wenn der aktuelle fertig ist. Läuft ein Task lange, warten Klicks, Tippen und Malen, und die Seite friert ein.“

Die ausführliche Antwort: Timer, Antworten aus dem Netz und Nutzerereignisse legen jeweils einen Task in eine Warteschlange. Promises laufen in einer eigenen, schnelleren Warteschlange, die nach jedem Task geleert wird. Der Browser malt zwischen den Tasks, also blockiert eine Schleife über zehntausend Einträge den Bildschirm, bis sie endet. Lösungen: weniger Arbeit, die Arbeit in kleinere Stücke teilen, die dem Browser Luft lassen, lange Listen nur zeigen, wenn sie ins Bild scrollen, oder schwere Arbeit in einen Web Worker verlegen, der auf einem eigenen Thread läuft.

Schwache Antwort: „JavaScript ist asynchron, also blockiert es nie.“ Nachfrage: „Läuft eine async-Funktion auf einem anderen Thread?“ Nein. Sie läuft auf demselben Thread; sie pausiert nur, während sie wartet.

Layout und Barrierefreiheit

Wie baust du ein Seitenlayout, das auf einem kleinen Handy und einem breiten Bildschirm funktioniert?

Worauf sie achten: responsives Design, das geplant ist, nicht geflickt.

Kurze Antwort: „Ich fange mit dem kleinen Bildschirm an und füge Platz und Spalten hinzu, wenn der Bildschirm wächst. Flexbox ordnet Elemente in einer Zeile oder Spalte an; Grid platziert sie in Zeilen und Spalten zugleich. Ich nutze Größen, die sich anpassen, statt fester Pixel, und teste mit echten Inhalten.“

Die ausführliche Antwort: Mobile First hält die Grundstile einfach. Breakpoints, die Breiten, an denen sich das Layout ändert, folgen dem Inhalt, nicht beliebten Handygrößen. Grid passt für den Seitenrahmen und Kartenlisten; Flexbox für eine Toolbar oder eine Reihe von Buttons. Bilder bekommen mehrere Größen, damit ein Handy kein Desktop-Bild herunterlädt. Container Queries lassen eine Komponente sich an den Platz anpassen, den sie bekommt, nicht an den ganzen Bildschirm. Teste lange Wörter, große Schrifteinstellungen und Handys im Querformat.

Schwache Antwort: „Ich nutze ein CSS-Framework, dann ist es responsiv.“ Nachfrage: „Ein langer deutscher Produktname zerschießt dein Kartenlayout. Was tust du?“ Wörter umbrechen lassen, die Karte wachsen lassen und mit den längsten echten Namen testen, nicht mit dem Beispieltext aus dem Design.

Wie würdest du ein eigenes Dropdown bauen, das alle nutzen können?

Worauf sie achten: Barrierefreiheit in der Praxis: Tastatur, Screenreader und Fokus.

Kurze Antwort: „Zuerst prüfe ich, ob das native select-Element reicht, denn es ist von sich aus barrierefrei. Wenn nicht, folge ich dem veröffentlichten Muster für eine Listbox: Die Liste öffnet sich und lässt sich mit der Tastatur bedienen, der Fokus ist sichtbar und springt beim Schließen zum Button zurück, und ein Screenreader hört den Namen, den Zustand und die gewählte Option.“

Die ausführliche Antwort in fünf Schritten:

1. Nimm einen echten Button zum Öffnen, damit Enter und Leertaste funktionieren und er mit Tab erreichbar ist.
2. Name und Zustand. Der Button sagt, was er auswählt und ob die Liste offen ist, mit ARIA-Attributen (Beschriftungen, die der Browser an Screenreader weitergibt) nur dort, wo HTML kein eigenes Element dafür hat.
3. Tastatur. Pfeiltasten bewegen durch die Optionen, Enter wählt, Escape schließt; ein getippter Buchstabe springt zu einer Option.
4. Fokus. Der Fokus wandert beim Öffnen in die Liste und beim Schließen zurück zum Button, und er ist immer sichtbar.
5. Testen. Nur mit der Tastatur, mit einem Screenreader und mit einer automatischen Prüfung; dann Kontrast und Größe der Touch-Ziele korrigieren.

Schwache Antwort: „Ich setze ein aria-label, dann ist es barrierefrei.“ Ein Label allein macht eine Liste nicht mit der Tastatur bedienbar.

Nachfrage: „Warum ist das mehr als gute Praxis?“ Die WCAG, die Richtlinien für barrierefreie Webinhalte, sind der Standard, auf den die meisten Gesetze verweisen; in der EU macht der European Accessibility Act (EU) sie für viele Shops und Dienste zur gesetzlichen Pflicht, in Deutschland umgesetzt durch das Barrierefreiheitsstärkungsgesetz (BFSG), und US-Firmen drohen Klagen.

State, Daten und Komponenten

Wo sollte der State in einer React-App liegen?

Worauf sie achten: dass du State nah an dem Ort hältst, wo er gebraucht wird, und Serverdaten von Bildschirm-State unterscheidest.

Kurze Antwort: „So nah wie möglich an der Komponente, die ihn nutzt. Brauchen ihn zwei Geschwister, hebe ich ihn zu ihrem Elternteil an. Daten vom Server kommen in einen Cache für Datenabfragen, nicht in einen globalen Store. Ein globaler Store ist für das Wenige, das wirklich geteilt wird, etwa den angemeldeten Nutzer.“

Die ausführliche Antwort: State in ReactIn 37 % der Anzeigen für Frontend-Entwickler gefragt (Stand 05.11.2026).Komponenten, Hooks, State und Effekte; wissen, warum eine Komponente rendert und wie man zu häufiges Rendern verhindert. sind Daten, die bei einer Änderung den Bildschirm ändern. Es gibt verschiedene Arten: was in ein Formular getippt wird, ob ein Menü offen ist, was der Server geschickt hat, was in der Adresszeile steht. Die Adresszeile ist oft der beste Ort für Filter und Tabs, damit ein Link dieselbe Ansicht öffnet. Serverdaten haben eigene Probleme, etwa Caching, erneutes Laden und veraltete Ergebnisse, die Bibliotheken wie TanStack Query lösen. Context reicht Werte ohne Props nach unten weiter, aber jede lesende Komponente rendert neu, wenn er sich ändert; er passt also für Werte, die sich selten ändern.

Schwache Antwort: „Ich packe alles in Redux.“ Nachfrage: „Zwei Tabs zeigen dieselbe Liste, und in einem wird sie bearbeitet. Wie bleiben sie im Gleichschritt?“ Beide lesen dieselbe gecachte Abfrage, und die Bearbeitung aktualisiert sie oder lädt sie neu.

Eine Komponente rendert zu oft neu, und das Tippen fühlt sich träge an. Wie behebst du das?

Worauf sie achten: dass du die Ursache mit Werkzeugen findest und weißt, was React rendern lässt.

Kurze Antwort: „Ich zeichne es im Profiler auf, um zu sehen, welche Komponenten rendern und warum. Meist liegt der State zu weit oben, oder bei jedem Rendern wird ein neues Objekt oder eine neue Funktion erzeugt und weitergereicht. Ich verlege den State nach unten oder halte diese Werte stabil und greife erst dann zu memo.“

Die ausführliche Antwort: Eine Komponente rendert neu, wenn sich ihr State ändert, wenn ihr Elternteil neu rendert oder wenn sich ein Context ändert, den sie liest. Ein Re-Render ist nicht immer ein Problem; er wird eines, wenn ein teurer Baum bei jedem Tastendruck rendert. Lösungen, in dieser Reihenfolge: den Tipp-State in der eigenen Komponente des Eingabefelds halten; einen großen Context aufteilen; lange Listen nur die Zeilen auf dem Bildschirm rendern lassen; dann das teure Kind memoisieren, damit es Renders überspringt, wenn seine Props gleich sind.

Schwache Antwort: „Ich packe jede Komponente in memo.“ Das macht Arbeit und versteckt die Ursache. Nachfrage: „Memo hat nicht geholfen. Warum?“ Eine Prop ist jedes Mal ein neues Objekt, also schlägt der Vergleich immer fehl.

Wie lädst du Daten für einen Screen, mit Ladezustand, Fehlern und langsamem Netz?

Worauf sie achten: dass du jeden Zustand des Screens entwirfst, nicht nur den Gutfall.

Kurze Antwort: „Jeder Screen, der Daten lädt, hat vier Zustände: lädt, leer, Fehler und geladen. Ich entwerfe alle vier mit dem Designer, zeige ein Skeleton statt eines springenden Spinners, lasse den Nutzer einen Fehler erneut versuchen und breche eine Anfrage ab, die der Nutzer nicht mehr braucht.“

Die ausführliche Antwort: Stimm das Format der Antwort mit dem Backend ab und typisiere es in TypeScriptIn 48 % der Anzeigen für Frontend-Entwickler gefragt (Stand 05.11.2026).Typen für Props, API-Antworten und State, damit Fehler im Editor auffallen, bevor Nutzer sie sehen.. Cache, was geladen wurde, damit das Zurückgehen sofort geht. Entprelle ein Suchfeld (Debounce), damit es nicht für jeden Buchstaben eine Anfrage schickt, und ignoriere eine alte Antwort, die nach einer neueren ankommt. Bei langsamem oder wackligem Netz zeig, was du schon hast, und sag klar, was fehlgeschlagen ist. Manche Teams nutzen GraphQLVom Server genau die Felder holen, die ein Screen braucht; bei manchen Produktfirmen statt REST im Einsatz., damit jeder Screen genau die Felder anfragt, die er zeigt.

Schwache Antwort: „Ich hole die Daten in einem Effect und setze den State.“ Nachfrage: „Der Nutzer tippt schnell, und die Ergebnisse flackern zwischen alt und neu. Warum?“ Die Antworten kommen in falscher Reihenfolge an; brich die alte Anfrage ab oder ignoriere ihre Antwort.

Was fängt TypeScript für dich ab, und was nicht?

Worauf sie achten: dass du Typen als Werkzeug nutzt und weißt, wo sie aufhören.

Kurze Antwort: „Es fängt falsche Props, fehlende Felder und Tippfehler ab, während ich schreibe, und macht große Änderungen sicher. Es prüft nicht, was zur Laufzeit ankommt: Eine API kann trotzdem etwas anderes schicken, deshalb prüfe ich Daten am Rand der App.“

Die ausführliche Antwort: Typen verschwinden beim Build; der Browser führt reines JavaScript aus. Eine Antwort, die als Nutzer typisiert ist, kann also trotzdem eine Fehlerseite sein. Validiere Daten dort, wo sie hereinkommen, zum Beispiel mit einer Schema-Bibliothek, und lass die Typen von dort aus weiterfließen. Schalte den Strict Mode ein, vermeide den Typ any, der die Prüfung abschaltet, und erzeuge Typen aus der Beschreibung der API, wo du kannst, damit Frontend und Backend übereinstimmen.

Schwache Antwort: „Mit TypeScript brauchen wir keine Tests.“ Nachfrage: „Ein Team will eine große JavaScript-App auf TypeScript umstellen. Wie?“ Datei für Datei, strikt für neuen Code, beginnend mit gemeinsam genutztem Code und den API-Aufrufen.

Wie testest du eine Formular-Komponente so, dass die Tests nicht bei jeder Designänderung brechen?

Worauf sie achten: Tests für das Verhalten, das der Nutzer sieht, nicht für das Innere einer Komponente.

Kurze Antwort: „Ich teste, was der Nutzer tut und sieht: in das Feld mit der Beschriftung E-Mail tippen, auf Senden drücken, die Fehlermeldung sehen. Ich finde Elemente über ihre Beschriftung oder Rolle, nicht über einen Klassennamen, damit ein neues Design den Test nicht bricht, ein kaputtes Formular aber schon.“

Die ausführliche Antwort: Die meisten Frontend-Tests sollten Komponententests dieser Art sein; sie laufen schnell und prüfen auch, dass Beschriftungen vorhanden sind, und helfen so der Barrierefreiheit. Eine kleine Zahl von End-to-End-Tests lässt die echte App im Browser laufen, für Abläufe, die nie kaputtgehen dürfen, etwa Registrierung und Zahlung. Visuelle Tests vergleichen Screenshots gemeinsamer Komponenten. Snapshot-Tests des Markups brechen bei jeder Änderung und werden meist ohne Hinsehen freigegeben.

Schwache Antwort: „Ich prüfe, ob der State der Komponente gesetzt ist.“ Nachfrage: „Ein End-to-End-Test schlägt bei einem von zehn Läufen fehl. Was tust du?“ Herausfinden, warum, meist wird eine feste Zeit gewartet statt auf das Element; nie einfach so lange neu starten, bis er durchläuft.

Sicherheit im Browser

Wie schützt du eine Web-App vor Cross-Site Scripting, und wo bewahrst du ein Login-Token auf?

Worauf sie achten: dass du das wichtigste Risiko im Frontend kennst und es nicht selbst erzeugst.

Kurze Antwort: „Cross-Site Scripting, XSS, heißt, dass das Skript eines Angreifers in deiner Seite läuft, meist über Text, den ein Nutzer eingegeben hat. Frameworks escapen Text von sich aus, deshalb füge ich nie rohes HTML von Nutzern ein. Ich ergänze eine Content Security Policy. Ein Login ist in einem Cookie am sichersten, das kein Skript lesen kann, nicht im Local Storage.“

Die ausführliche Antwort: Mit XSS kann der Angreifer als der Nutzer handeln: seine Daten lesen, Anfragen in seinem Namen schicken. Die Gefahrenstellen sind die wenigen Orte, die HTML direkt einfügen, Links, die aus Nutzereingaben gebaut werden, und Skripte von Drittanbietern. Eine Content Security Policy sagt dem Browser, welche Skripte laufen dürfen. Ein HttpOnly-Cookie kann kein Skript lesen, also kann ein XSS es nicht stehlen; mit Cookies braucht das Backend außerdem Schutz gegen gefälschte Anfragen von anderen Seiten (CSRF).

Schwache Antwort: „Um Sicherheit kümmert sich das Backend.“ Nachfrage: „Das Marketing will HTML aus einem Editor in die Seite kopieren. Was tust du?“ Es mit einem gut getesteten Sanitizer bereinigen, der nur sichere Tags behält, und zwar auch auf dem Server.

Fragen für Senior, Staff und Architekten

Wie arbeitest du mit Designern an einem Screen, den das Designsystem nicht abdeckt?

Worauf sie achten: bei Senior-Rollen die Zusammenarbeit mit dem Design als Partner und den Schutz der Einheitlichkeit.

Kurze Antwort: „Ich spreche früh mit dem Designer, bevor gebaut wird. Oft reicht eine bestehende Komponente mit einer neuen Variante. Ist es wirklich neu, entwerfen wir es einmal, für jeden Zustand, und nehmen es ins Designsystem auf, damit das nächste Team es nicht noch einmal baut.“

Die ausführliche Antwort: Ein Designsystem ist der gemeinsame Satz aus Komponenten, Design Tokens (benannte Farben, Abstände und Schriftgrößen) und Regeln, der ein Produkt einheitlich hält. Einzelne Sonderkomponenten driften auseinander: andere Abstände, fehlende Fokuszustände, kein Dark Mode. Frag, welches Problem das neue Design löst; prüfe die FigmaEine Design-Datei lesen: Abstände, Tokens, Zustände und Varianten, und erkennen, was das Design vergessen hat.-Datei auf Zustände, die das Mock-up vergessen hat (leer, Fehler, langer Text, Tastaturfokus); und vereinbart, wem die neue Komponente gehört.

Schwache Antwort: „Ich baue genau das, was das Design zeigt.“ Nachfrage: „Die Deadline ist morgen.“ Jetzt mit bestehenden Bausteinen bauen, die Lücke notieren und die richtige Komponente einplanen.

Wie würdest du ein Designsystem bauen, das mehrere Produktteams nutzen?

Worauf sie achten: bei Lead- und Staff-Rollen das Denken in Plattformen und in den Menschen, die sie übernehmen.

Kurze Antwort: „Ich fange mit den Komponenten an, die die Teams schon untereinander kopieren, baue sie einmal mit Designern, barrierefrei und dokumentiert, und veröffentliche sie als versioniertes Paket. Die Übernahme ist der schwierige Teil, deshalb mache ich die gemeinsame Komponente zur einfachsten Wahl.“

Die ausführliche Antwort: Fang mit den Tokens und den zehn Komponenten an, die jeder Screen nutzt: Buttons, Eingabefelder, Dialoge, Tabellen. Bau sie mit eingebauten Tests auf Barrierefreiheit, dokumentiere jede mit Beispielen und versioniere das Paket, damit Teams aktualisieren, wann sie wollen, mit klaren Hinweisen, was sich geändert hat. Miss die Nutzung über die Produkte hinweg. Gib den Teams einen Weg, Änderungen anzufragen, und ein kleines Kernteam, das schnell antwortet. Ein Designsystem, das niemand nutzt, kostet nur; eines, das alle nutzen, spart Wochen pro Screen.

Schwache Antwort: „Ich würde zuerst eine vollständige Komponentenbibliothek bauen und sie dann starten.“ Nachfrage: „Ein Team sagt, das System bremse es aus.“ Die Komponente finden, die es blockiert, und sie schnell korrigieren oder erweitern, oder das Team sie mit Review im System selbst bauen lassen.

Mehrere Teams arbeiten in einer großen Frontend-App, Builds und Releases sind langsam. Würdest du sie in Micro-Frontends aufteilen?

Worauf sie achten: bei Rollen als Staff Engineer und Frontend-Architekt, ob du eine große Änderung ehrlich abwägst.

Kurze Antwort: „Nur, wenn das Problem darin besteht, dass Teams sich gegenseitig die Releases blockieren, und günstigere Lösungen gescheitert sind. Mit Micro-Frontends baut und veröffentlicht jedes Team seinen eigenen Teil der Seite, aber sie kosten Geschwindigkeit, Einheitlichkeit und Tooling. Ich würde zuerst klare Modulgrenzen, schnellere Builds und Zuständigkeitsregeln in einem Repository versuchen.“

Die ausführliche Antwort: Ein Micro-Frontend ist ein Teil des Produkts, etwa der Checkout oder die Kontoeinstellungen, den ein Team allein baut und deployt. Der Gewinn: unabhängige Teams und kleinere Releases. Die Kosten: dieselbe Bibliothek doppelt geladen, verschiedene Versionen gemeinsamer Komponenten, schwierigere End-to-End-Tests und mehr, was das Handy des Nutzers herunterladen muss. Miss zuerst: Build-Zeit, wie oft Teams aufeinander warten, wie oft veröffentlicht wird. Wenn du aufteilst, dann nach Geschäftsbereich, mit gemeinsamem Designsystem und einer Version des Frameworks und einer einzigen Shell für das Routing.

Schwache Antwort: „Ja, Micro-Frontends sind der moderne Weg.“ Nachfrage: „Die Geschäftsleitung will es dieses Jahr erledigt haben.“ Zuerst einen Bereich umziehen, Ladezeit und Release-Dauer messen und danach über den Rest entscheiden.

Wie stellst du eine große App von einem alten auf ein neues Framework um, ohne die Arbeit an Funktionen anzuhalten?

Worauf sie achten: bei Rollen als Lead, Staff Engineer und Frontend-Architekt, ob du eine lange Änderung mit wenig Risiko planen kannst.

Kurze Antwort: „Screen für Screen, nicht in einem großen Rewrite. Alt und Neu laufen nebeneinander; neue Screens werden im neuen Framework gebaut, und alte ziehen um, wenn sie ohnehin geändert werden müssen. Ich verfolge den Fortschritt und setze einen Termin, an dem das alte Framework entfernt wird.“

Die ausführliche Antwort: Ein großer Rewrite hält das Geschäft monatelang an und wird meist zu spät fertig. Der Strangler-Ansatz legt eine dünne Shell um die App, die jede Route an den alten oder den neuen Code schickt. Zieh gemeinsame Teile zuerst um: das Designsystem, die API-Aufrufe, die Anmeldung. Vereinbare mit dem Produktmanager, welche Screens mit geplanter Funktionsarbeit umziehen, damit sich der Umzug selbst bezahlt. Behalte die Ladezeit im Blick, denn zwei Frameworks gleichzeitig bringen Gewicht, und halte die Zeit mit beiden kurz. Ein Team, das von AngularJS auf AngularIn 41 % der Anzeigen für Frontend-Entwickler gefragt (Stand 05.11.2026).Verbreitet bei Banken, Versicherungen und großen Firmen: Module, Services, RxJS-Streams und eine strenge Struktur. oder von einer alten jQuery-App auf ReactIn 37 % der Anzeigen für Frontend-Entwickler gefragt (Stand 05.11.2026).Komponenten, Hooks, State und Effekte; wissen, warum eine Komponente rendert und wie man zu häufiges Rendern verhindert. wechselt, folgt demselben Plan.

Schwache Antwort: „Wir frieren die Funktionen sechs Monate ein und schreiben neu.“ Nachfrage: „Wie überzeugst du den Engineering Manager, es zu finanzieren?“ Zeig, was das Bleiben kostet: Einstellungen, ausbleibende Sicherheitsupdates und wie lange Funktionen heute dauern.

Dein Lebenslauf für diese Fragen

Interviewer fragen nach dem, was in deinem Lebenslauf steht; schreib also die Arbeit hinter diesen Antworten hinein, eine Zeile pro Ergebnis, in den Wörtern der Anzeigen:

Bewerte deinen Lebenslauf dann an einem echten Frontend-Job: Das Ergebnis zeigt, welche dieser Screens und Messungen der Job verlangt und welche dein Lebenslauf noch nicht belegt.