Frontend Developer Vorstellungsgespräch: Fragen & Antworten (mit Musterantworten)

Musterantwort

Ich setze konsequent auf einen Mobile-First-Ansatz und arbeite mit flexiblen Layouts über Flexbox und CSS Grid. Mit Media Queries passe ich Abstände, Schriftgrößen und Anordnung an verschiedene Bildschirmbreiten an. Vor dem Release teste ich auf echten Geräten und in mehreren Browsern, nicht nur im Emulator. So vermeide ich böse Überraschungen bei den Nutzern.

Musterantwort

Zuerst messe ich mit Tools wie Lighthouse oder den Browser-DevTools, wo die Engpässe wirklich liegen. Häufige Ursachen sind zu große Bilder, blockierendes JavaScript oder unnötige Re-Renders. Ich optimiere dann gezielt, etwa durch Lazy Loading, Code Splitting und das Komprimieren von Assets. Wichtig ist mir, anhand von Zahlen zu optimieren und nicht nach Gefühl.

Musterantwort

Mit Designern kläre ich früh Details zu Verhalten, Zuständen und Edge Cases, die im Mockup oft fehlen. Mit dem Backend stimme ich mich über die genaue Form der API-Schnittstellen ab, bevor ich mit der Integration beginne. Ich stelle lieber eine Frage zu viel als eine zu wenig, um spätes Nacharbeiten zu vermeiden. Eine gemeinsame Sprache und klare Absprachen sparen am Ende viel Zeit.

Musterantwort

Ich nutze semantisches HTML, sinnvolle Alt-Texte und achte auf ausreichende Farbkontraste. Wo nötig, ergänze ich ARIA-Attribute, um Screenreadern den Kontext zu vermitteln. Ich teste die Bedienbarkeit per Tastatur und mit einem Screenreader, um Hürden früh zu erkennen. Barrierefreiheit ist für mich kein Add-on, sondern Teil guter Qualität.

Musterantwort

Ich verfolge die Release Notes von Frameworks wie React und lese ausgewählte Newsletter und Blogs der Community. Neue Ansätze probiere ich zuerst in kleinen Experimenten aus, bevor ich sie in Produktivprojekte einbringe. Im Team teile ich Erkenntnisse aktiv, etwa in kurzen internen Sessions. So bleibe ich aktuell, ohne jedem kurzlebigen Trend zu folgen.

var ist funktionsgebunden und wird gehoistet, was zu schwer nachvollziehbaren Fehlern führen kann. let und const sind blockgebunden; const verhindert zusätzlich eine erneute Zuweisung der Variablen, wobei der Inhalt von Objekten dennoch veränderbar bleibt.

Jedes Element besteht aus Content, Padding, Border und Margin, die zusammen die tatsächliche Größe bestimmen. Mit box-sizing: border-box werden Padding und Border in die angegebene Breite einbezogen, was das Layout deutlich vorhersehbarer macht.

Der Virtual DOM ist eine speicherinterne Abbildung des echten DOM, die Frameworks wie React nutzen. Bei Änderungen wird zuerst der virtuelle Baum aktualisiert, mit dem vorherigen Zustand verglichen und nur der minimale Unterschied effizient in das reale DOM übertragen.

Beim Bubbling läuft ein ausgelöstes Event vom Zielelement nach oben durch alle Elternelemente bis zum Wurzelknoten. Das ermöglicht Event Delegation, bei der man einen Listener am Elternelement registriert, statt viele einzelne Listener zu setzen.

Synchroner Code wird Zeile für Zeile abgearbeitet und blockiert dabei den Hauptthread. Asynchroner Code über Promises oder async/await erlaubt es, langlaufende Aufgaben wie Netzwerkaufrufe im Hintergrund auszuführen, sodass die Oberfläche reaktionsfähig bleibt.

Kurz vor einem Release stellten wir fest, dass ein Layout in einem älteren Browser zerbrach. Ich habe das Problem auf eine nicht unterstützte CSS-Eigenschaft eingegrenzt und einen Fallback eingebaut. Anschließend habe ich die betroffenen Seiten gezielt in diesem Browser getestet. Das Release konnte ohne weitere Verschiebung erfolgen.

Ein Designer wünschte eine aufwendige Animation, die auf schwächeren Geräten ruckelte. Ich habe das Problem transparent erklärt und eine performantere Alternative vorgeschlagen, die optisch sehr ähnlich wirkte. Gemeinsam haben wir einen Kompromiss gefunden, der gut aussah und flüssig lief. Der Designer war mit dem Ergebnis zufrieden.

Ich übernahm ein Frontend ohne Tests und mit unklarer Struktur. Ich habe zunächst die wichtigsten Abläufe dokumentiert und vor jeder Änderung kleine Tests ergänzt, um Regressionen zu vermeiden. Schrittweise habe ich kritische Teile refaktorisiert, ohne den laufenden Betrieb zu stören. Nach einigen Wochen war die Basis deutlich stabiler.

Mitten in einem Sprint änderte der Kunde die gewünschte Nutzerführung grundlegend. Ich habe die Auswirkungen auf den bestehenden Code bewertet und gemeinsam mit dem Product Owner neu priorisiert. Wir haben den Umbau in machbare Schritte zerlegt und die wichtigsten zuerst umgesetzt. Die neue Variante kam beim Kunden sehr gut an.