Frontend-Entwickler Interviewfragen & Antworten

Beispielantwort

Das Design-Team lieferte Mockups für eine Datentabelle mit unendlichem Scrollen, Echtzeit-Sortierung, direkter Bearbeitung und animierten Zeilenübergängen, das alles für einen Datensatz mit über 100.000 Zeilen. Ich erstellte einen Prototyp und stellte fest, dass DOM-Rendering mit Animation bei so vielen Zeilen die Performance auf Mittelklasse-Geräten unter 10 FPS drückte. Statt einfach zu sagen, das sei unmöglich, entwickelte ich zwei Alternativen: eine mit virtuellem Rendering (react-window), die flüssiges Scrollen beibehielt, aber die Animationen vereinfachte, und eine weitere mit Paginierung, die alle visuellen Effekte erhielt. Ich präsentierte beide dem Designer mit den entsprechenden Performance-Metriken. Wir entschieden uns für den virtualisierten Ansatz mit vereinfachten Zeilenübergängen. Der Designer schätzte es, den Kompromiss visuell zu sehen, anstatt ein abstraktes Nein zu hören. Die endgültige Implementierung verarbeitete 100.000 Zeilen mit 60 FPS bei vollständiger Kernfunktionalität.

Beispielantwort

Die Startseite unseres Online-Shops hatte einen Largest Contentful Paint von 4,2 Sekunden, und unsere Conversion-Daten zeigten, dass für jede zusätzliche Sekunde Ladezeit der Kaufabschluss um 7 % zurückging. Ich identifizierte drei Flaschenhälse: ein 2 MB großes Hero-Bild, 800 KB synchrones JavaScript und eine render-blockierende CSS-Datei mit ungenutzten Stylesheets. Ich konvertierte das Hero-Bild in WebP mit responsivem srcset, teilte das JavaScript-Bundle mithilfe von Dynamic Imports auf (was die initiale Ladezeit um 65 % reduzierte) und lagerte kritisches CSS inline aus, während der Rest asynchron geladen wurde. Der LCP sank auf 1,1 Sekunden. Im darauffolgenden Monat stieg die Conversion-Rate um 9 % und die Absprungrate sank um 15 %. Der gesamte Entwicklungsaufwand betrug 4 Tage. Es war eines der Projekte mit dem höchsten ROI, an denen ich je gearbeitet habe.

Beispielantwort

Ich habe eine gemeinsame React-Komponentenbibliothek für ein Unternehmen mit 4 Produktteams aufgebaut, die jeweils ihre eigenen Buttons, Modals und Formulare implementierten. Ich begann mit einem Audit der vorhandenen Komponenten über alle Produkte hinweg. Wir hatten 12 verschiedene Button-Varianten. Ich konsolidierte sie zu 4 (primär, sekundär, Ghost, Danger) mit einheitlicher Größe und Abständen. Ich verwendete TypeScript für strenge Prop-Typisierung, Storybook für Dokumentation und visuelle Tests sowie Chromatic für visuelle Regressionstests. Die Bibliothek wurde mit semantischer Versionierung verwaltet und in einer privaten npm-Registry veröffentlicht. Die schwierigere Aufgabe war die Einführung. Ich hielt wöchentliche Sprechstunden ab, erstellte für jedes Produkt einen Migrationsleitfaden und reichte Pull Requests ein, um den Teams zu zeigen, wie sie ihre eigenen Komponenten ersetzen konnten. Nach 4 Monaten verwendeten alle Teams die gemeinsame Bibliothek, die Design-Konsistenz verbesserte sich sichtbar und die Entwicklungszeit für neue Funktionen sank, weil Entwickler aufhörten, bereits vorhandene Komponenten neu zu bauen.

Beispielantwort

Wir erhielten Fehlerberichte, dass unsere Formularvalidierung auf Safari iOS nicht funktionierte. Das Problem: Wir verwendeten die reportValidity()-Methode der Constraint Validation API, die Safari zwar unterstützte, aber anders handhabte. Sie zeigte den Fehler-Tooltip an, verhinderte aber auf iOS keine Formularabsendung. Ich fand heraus, dass der Tooltip durch ein WebKit-Rendering-Problem hinter der virtuellen Tastatur erschien. Meine Lösung bestand aus drei Teilen: Ich ersetzte die nativen Validierungs-Tooltips durch benutzerdefinierte Inline-Fehlermeldungen (was ohnehin die bessere UX war), fügte eine JavaScript-Validierungsschicht als Fallback hinzu und integrierte BrowserStack-Cross-Browser-Tests in unsere CI-Pipeline, um Safari-spezifische Probleme frühzeitig zu erkennen. Außerdem erstellte ich eine Checkliste für kompatibilitätsbezogene Tests, die Safari iOS, Chrome Android, Firefox und Edge abdeckte. Mit der Lösung wurden auf einen Schlag über 40 offene Safari-Fehlerberichte behoben.

Beispielantwort

Das virtuelle DOM ist eine schlanke JavaScript-Darstellung des echten DOM. Wenn sich der Zustand ändert, erstellt React einen neuen virtuellen DOM-Baum und vergleicht ihn mit dem vorherigen. Dieser Vorgang heißt Reconciliation. React verwendet einen heuristischen O(n)-Algorithmus: Er vergleicht Bäume Ebene für Ebene, geht davon aus, dass Elemente unterschiedlicher Typen unterschiedliche Teilbäume erzeugen (und reißt diese vollständig ab), und verwendet Key-Props, um festzustellen, welche Kindelemente in einer Liste geändert, verschoben oder entfernt wurden. Wenn der Vergleich einen Unterschied findet, bündelt React die minimale Menge an tatsächlichen DOM-Operationen. Das ist schneller als direktes Manipulieren des echten DOM, weil DOM-Operationen teuer sind (sie lösen Layout-Neuberechnungen, Paint und Compositing aus), während der Vergleich von JavaScript-Objekten günstig ist. Die wichtigste praktische Konsequenz: Verwenden Sie immer stabile, eindeutige Keys für Listenelemente (keine Array-Indizes), vermeiden Sie das Erstellen neuer Objekt- oder Funktionsreferenzen beim Rendern (sie umgehen Memoization) und setzen Sie React.memo, useMemo und useCallback ein, wenn Profiling unnötige Re-Renders zeigt.

Beispielantwort

Flexbox ist eindimensional. Es verwaltet das Layout entweder in einer Zeile oder in einer Spalte. Grid ist zweidimensional. Es verwaltet Zeilen und Spalten gleichzeitig. Ich verwende Flexbox für das Layout auf Komponentenebene: Elemente in einer Navbar ausrichten, Buttons in einer Symbolleiste anordnen, Inhalte vertikal und horizontal zentrieren. Flexbox eignet sich besonders dann, wenn die Inhaltsgröße das Layout bestimmen soll. Ich verwende Grid für das Layout auf Seitenebene: die Gesamtseitenstruktur definieren, komplexe Card-Grids erstellen, Dashboard-Layouts mit mehreren Bereichen aufbauen. Grid ist dann stark, wenn das Layout die Platzierung des Inhalts vorgeben soll. In der Praxis kombiniere ich beides: Grid für das Makro-Layout (Header, Sidebar, Hauptinhalt, Footer) und Flexbox für das Mikro-Layout innerhalb jeder Grid-Zelle. Der häufigste Fehler ist, Grid für eine einfache Reihe von Elementen zu verwenden oder Flexbox-Hacks (negative Margins, Pseudo-Elemente) einzusetzen, wo Grid eleganter wäre.

Beispielantwort

Ich kategorisiere den Zustand nach seiner Art und wähle entsprechende Werkzeuge. Lokaler UI-Zustand (Formulareingaben, Toggle-Zustände, Modal-Sichtbarkeit): useState oder useReducer. Ich halte ihn in der Komponente, die ihn besitzt, und hebe ihn nur bei echtem Bedarf an. Server-Zustand (Daten von APIs): React Query oder SWR. Diese verwalten Caching, Refetching, optimistische Updates und Lade- sowie Fehlerzustände weit besser als manuelle Redux-Muster. Server-Daten lege ich nie in den globalen Zustand. Globaler Client-Zustand (Theme, Auth, Nutzerpräferenzen): React Context für selten aktualisierte Daten (Theme, Locale) oder Zustand für Daten, die sich häufig ändern und ein selektives Abonnement erfordern, um Re-Renders zu vermeiden. URL-Zustand (Filter, Paginierung, Such-Parameter): useSearchParams von React Router. Der Zustand lebt in der URL und ermöglicht Bookmarks und das Teilen von Links. Das Anti-Pattern, das ich vermeide: alles in einem einzigen globalen Store zu speichern. Das erzeugt Kopplung, erschwert das Testen und führt meist dazu, dass Komponenten neu rendern, wenn sich ein nicht verwandter Zustand ändert. Jede Zustandskategorie hat das richtige Werkzeug. Die Kunst liegt darin, das richtige zu wählen.

Beispielantwort

Eine Closure ist eine Funktion, die auch nach der Ausführung der äußeren Funktion noch Zugriff auf Variablen ihres äußeren Geltungsbereichs hat. Die innere Funktion schließt über die referenzierten Variablen ein. Ein praktisches Beispiel: eine Debounce-Funktion. Wenn Sie debounce(fn, delay) schreiben, hat die zurückgegebene Funktion Zugriff auf die Variable timer, die im Geltungsbereich von debounce definiert ist. Jedes Mal, wenn die zurückgegebene Funktion aufgerufen wird, löscht sie den vorherigen Timer und setzt einen neuen. Die Variable timer bleibt über alle Aufrufe hinweg erhalten, weil die Closure sie hält. Sie wird nicht vom Garbage Collector erfasst, solange die zurückgegebene Funktion existiert. Ein weiteres reales Anwendungsbeispiel: Reacts useState-Hook. Wenn Sie setCount(count + 1) aufrufen, stammt der Wert von count aus der Closure, die beim Rendern der Komponente erstellt wurde. Deshalb sind veraltete Closures ein häufiger React-Fehler: Wenn Sie count innerhalb eines useEffect verwenden, ohne es im Dependency-Array anzugeben, schließt der Effekt über den Initialwert ein und sieht nie spätere Änderungen.

Beispielantwort

Zunächst würde ich mein Verständnis sowohl der Design-Anforderung als auch der API-Einschränkung überprüfen. Manchmal ist das, was wie eine Einschränkung aussieht, eigentlich ein anderer Endpunkt oder Parameter, den ich noch nicht gefunden habe. Ich würde die API-Dokumentation prüfen und mit dem Backend-Entwickler sprechen. Wenn die Einschränkung real ist, würde ich drei Optionen abwägen. Erstens: Kann das Frontend die benötigten Daten aus vorhandenen API-Antworten ableiten? Manchmal löst eine clientseitige Berechnung oder Umwandlung das Problem ohne Backend-Änderungen. Zweitens: Ist eine Backend-Änderung im Zeitrahmen machbar? Wenn es sich um eine einfache Ergänzung handelt, würde ich es mit dem Backend-Team besprechen und prüfen, ob wir es koordinieren können. Drittens: Können wir das Design anpassen, um mit den verfügbaren Daten zu arbeiten, ohne die Nutzererfahrung zu beeinträchtigen? Ich würde die Einschränkung und die Alternativen dem Designer und dem Product Manager mit meiner Empfehlung vorstellen. Was ich nicht tun würde: die Einschränkung mit mehreren API-Aufrufen, clientseitigen Joins oder Caching-Tricks umgehen, die Wartungsschulden erzeugen. Wenn die richtige Lösung eine Backend-Änderung ist, gehört es zu meiner Aufgabe, dafür einzutreten.

Beispielantwort

Ich würde technischen Fachjargon vollständig vermeiden und eine Analogie verwenden: 'Das ist, als würde man bitten, einer Wand eine Tür hinzuzufügen. Die Tür selbst ist einfach, aber das bedeutet, Elektroleitungen zu verlegen und möglicherweise tragende Wände anzupassen.' Dann würde ich konkrete Zeitangaben machen: 'Der Button selbst ist 30 Minuten Arbeit. Aber die Daten, die er benötigt, sind noch nicht im System vorhanden, und die Entwicklung der nötigen Datenverarbeitung dauert etwa 2 Wochen.' Ich würde auch Optionen vorstellen: 'Wir könnten nächste Woche eine einfachere Version liefern, die vorhandene Daten nutzt, oder in 3 Wochen die vollständige Version, die Sie sich vorstellen. Was bevorzugen Sie?' Der Schlüssel ist, ehrlich über die Komplexität zu sein, ohne dem Stakeholder das Gefühl zu geben, eine dumme Frage gestellt zu haben. Er muss nicht verstehen, warum es komplex ist. Er muss den Zeitrahmen und seine Optionen verstehen.

Beispielantwort

Ich würde nach fünf Kriterien bewerten, nicht nach Hype. Erstens: Team-Bereitschaft. Wie viel Einarbeitungszeit erfordert das neue Framework? Wenn das Team React kennt und wir Svelte in Betracht ziehen, sind das 4 bis 6 Wochen reduzierter Produktivität. Ist der Zeitplan flexibel genug? Zweitens: Ökosystem-Reife. Gibt es Bibliotheken für Routing, State-Management, Formularverarbeitung und Tests? Finden wir Antworten auf Stack Overflow? Drittens: Einstellbarkeit. Finden wir Entwickler, die dieses Framework kennen? React hat einen deutlich größeren Talentpool als Solid oder Qwik. Viertens: Performance. Löst das neue Framework ein echtes Performance-Problem, das wir haben? Wenn unsere React-App schnell genug ist, ist der Wechsel zugunsten von Benchmarks vorzeitige Optimierung. Fünftens: Langlebigkeit. Wird es von einer stabilen Organisation oder Community unterstützt? Wie ist die Commit-Häufigkeit, die Anzahl der Mitwirkenden und der Unternehmenseinsatz? Ich würde eine repräsentative Funktion sowohl im aktuellen als auch im vorgeschlagenen Framework prototypisieren, die tatsächliche Entwicklungsgeschwindigkeit und Performance messen und den Vergleich dem Team vorstellen. Die Entscheidung sollte datengestützt sein, nicht trendgestützt.

Beispielantwort

Ich würde es proaktiv ansprechen, anstatt zu warten, bis es zum Problem wird. Ich würde eine kurze Liste spezifischer Barrierefreiheitsprobleme zusammenstellen, die ich in den Mockups sehe: fehlende Fokus-Zustände, unzureichender Farbkontrast, Symbole ohne Textbeschriftung, Formularfelder ohne sichtbare Labels. Dann würde ich es konstruktiv mit dem Designer besprechen: 'Ich habe einige Barrierefreiheitslücken bemerkt, die wir vor der Entwicklung beheben sollten. Hier sind die konkreten Punkte.' Ich würde Lösungen vorschlagen, keine reinen Problemlisten: 'Dieser Button braucht einen Fokusring. So könnte er aussehen. Dieser Text hat ein Kontrastverhältnis von 3,2:1, benötigt aber 4,5:1. Zwei Töne dunkler würde das beheben.' Wenn der Designer aus Zeitgründen Einwände erhebt, würde ich das rechtliche und geschäftliche Risiko erläutern: Klagen wegen mangelnder Barrierefreiheit nehmen zu, und Barrierefreiheit nachträglich einzubauen kostet 3 bis 5 Mal mehr als von Anfang an. Ich würde außerdem automatisierte Barrierefreiheitsprüfungen (axe-core in CI) einrichten, um Regressionen zu verhindern.