Frontend-Entwickler:in

Fähigkeit, eine Entscheidung unter Unsicherheit zu strukturieren: Identifikation der Bedingungen (Browser-Support, Team-Skill, bestehende Codebase), expliziter Abwägungen, Konsultation der betroffenen Personen (Design, Backend, PM), nachträgliche Validierung mit Daten (Bundle-Size, Lighthouse, Fehlerquote). Bonus: die:der Kandidat:in erwähnt, im Verlauf die Meinung geändert oder die Entscheidung dokumentiert zu haben. Wer rückblickend eine offensichtliche Entscheidung beschreibt, hat selten ernsthaft abgewogen.

Strukturierte Debug-Methode: Reproduktion im Browser (DevTools, Performance-Tab, Network-Tab), Identifikation der betroffenen Geräte oder Browser, durch Experiment validierte Hypothesen. Ehrlichkeit zur Dauer (ein echter Production-Frontend-Bug ist selten in unter 30 Min. erledigt, vor allem bei Browser-Inkompatibilitäten). Bonus: die:der Kandidat:in nennt die Grundursache und den systemischen Fix, nicht nur den Hotfix. Antworten wie „Ich habe einen Workaround mit CSS gebaut“ ohne Diagnose deuten auf schwache Investigationsfähigkeit.

Technische Demut und Lernfähigkeit. Bonus: die:der Kandidat:in benennt, was sie:er heute von Anfang an anders machen würde (etwa Komposition statt Vererbung, Hooks-Extraktion, klarere Props-Verträge). Wer noch nie eigene Komponenten wirklich refactorn musste, hat entweder nichts in echte Produktion versendet oder das Produkt nie über längere Zeit weiterentwickelt.

Fähigkeit, eine technische Schwäche aufzuzeigen, ohne zu blockieren: sachlicher Kommentar im PR (hier ist das Risiko für Nutzer:innen mit Tastatur oder Screenreader, hier mein Lösungsvorschlag), Lösungsangebot, Eskalation an Tech Lead, falls der PR trotz Kommentar gemergt wird. Wer es laufen lässt, weil das Profil senior ist, oder wer Accessibility als nice-to-have behandelt, zeigt mangelnden technischen Mut und Lücken im Frontend-Verständnis.

Klärung des Bedarfs vor der Timeline-Verhandlung (eventuell lassen sich die kritischen Filter-Dimensionen in einer Woche liefern, der Rest in V2). Optionen anbieten: MVP in einer Woche plus V2 in zwei Wochen, expliziter Scope-Cut, kompromissfähige UI-Variante mit weniger Edge Cases. Antworten wie „Ich schaffe das in einer Woche, wenn ich am Wochenende arbeite“ sind ein Warnsignal (mangelnde Selbstführung).

Zuerst Diagnose: nicht alles gleichzeitig reparieren wollen. Priorisierung nach Risiko und Wirkung (typisch: zuerst TypeScript in neuen Komponenten erzwingen und kritische Bestandskomponenten typisieren, dann die 8-12 meistgenutzten Komponenten konsolidieren, dann ein leichtgewichtiges Test-Setup für die kritischen Flows). Abstimmung mit Team und Tech Lead vor jeder Maßnahme. Wer sich direkt in einen vollständigen Rewrite stürzt oder sofort ein Design-System nach Material UI ausruft, zeigt mangelnden Pragmatismus.

Klärung vor dem Vorschlag (erwartete Zeilenanzahl, Datenquelle, Server- vs. Client-Sortierung, Accessibility-Anforderungen, Wiederverwendung an wie vielen Stellen). Kohärente Architektur: Komposition vs. Konfigurations-Props, klare Slot- oder Render-Prop-API, Virtualisierung ab welcher Zeilenmenge, Tastatur-Navigation, ARIA-Rollen für Tabellen. Bonus: Anerkennung der Unsicherheitszonen (Ich würde einen POC mit React-Aria oder TanStack Table machen, bevor ich entscheide, was wir selbst bauen). Wer ohne Klärung sofort in den Code springt, zeigt eine Design-Schwäche.

Strukturierte Methode: (1) Reproduktion auf echtem Gerät oder über Browserstack, nicht nur im Desktop-DevTools-Emulator, (2) Profiling mit Safari Web Inspector über USB-Debugging, (3) Hypothesen ordnen (Memory Leak in einer Listener-Anbindung, exzessive Re-Renders, schwere Animationen, Layout-Thrashing, große Bilder ohne Lazy-Loading), (4) Metriken vergleichen (CPU, Memory, Long Tasks, FPS). Wer sofort auf „wird wohl Safari sein“ springt, ohne zu investigieren, hat einen Bias und unterschätzt iOS-spezifische Eigenheiten (z. B. WebKit-Speicherverwaltung).

Vor dem Optimieren messen: Lighthouse, WebPageTest, Chrome DevTools Performance-Tab, RUM-Daten falls vorhanden. Bottleneck identifizieren (Render-blocking JS oder CSS, große ungeoptimierte Bilder, kein Code-Splitting, schwere Drittanbieter-Skripte, ungenutztes JavaScript, fehlende Caching-Header). Nach Aufwand mal Wirkung priorisieren: typischerweise zuerst Bildoptimierung und Code-Splitting, dann Drittanbieter-Skripte einschränken, dann Server-Response-Time. Antworten wie „Ich baue Server-Side-Rendering ein“ ohne Diagnose deuten auf vorzeitige Optimierung. Bonus: erkennen, dass LCP-Probleme meist bei Bildern, Web-Fonts oder einem späten Hydrate-Schritt liegen.

Verständnis der Frontend-Test-Pyramide (viele Unit-Tests auf Hooks und Utilities, Komponenten-Tests mit Testing Library auf Verhalten statt Implementation, wenige E2E in Playwright oder Cypress auf den kritischen Flows). Unterscheidung zwischen Coverage und Nutzen (90 % Coverage auf Präsentations-Komponenten zählt weniger als 60 % auf einem Checkout-Flow). Bonus: die:der Kandidat:in nennt einen Fall, in dem ein Test eine reale Regression verhindert hat. Wer Snapshot-Tests als zentrale Strategie nennt oder einfach „100 % Coverage“ ohne Differenzierung antwortet, zeigt schwaches Urteilsvermögen.

useEffect: läuft nach Commit, asynchron zum Browser-Paint, geeignet für Datenabruf, Logging, Subscriptions. useLayoutEffect: läuft synchron nach Commit, vor dem Paint, geeignet für Messungen und imperativen DOM-Zugriff, der Layout-Flicker vermeiden muss. State-getriebenes Rendern bevorzugen, wenn die Information aus Props oder State ableitbar ist (kein Effekt nötig). Wer die drei Mechanismen nicht trennen kann, baut typische Frontend-Anti-Patterns ein: doppelte Renders, Flicker, Race Conditions in Effekten. Vue-äquivalent: watchEffect vs. computed vs. lifecycle hooks.

Schrittweises Vorgehen: (1) kritische Komponenten und wiederkehrende Patterns kartieren, (2) zuerst Hooks oder Composables und Business-Logik extrahieren (großer Hebel, geringes Risiko), (3) große Komponenten entlang fachlicher Grenzen zerlegen, nicht entlang technischer Schemata, (4) State-Manager nur dort einführen, wo Props-Drilling tatsächlich wehtut (Context oder Pinia im KMU, Redux oder Zustand ab größerem Volumen), (5) Styling-Strategie vereinheitlichen ohne Big-Bang-Migration. Wer sofort alles auf React Server Components oder Nuxt 4 umstellen will, zeigt fehlenden Pragmatismus.

Offenheit: Fähigkeit, Code vom persönlichen Ego zu trennen. Bonus: die:der Kandidat:in nennt einen Fall, in dem sie:er durch eine Review tatsächlich umgedacht hat (etwa bei Accessibility-Hinweisen, die zunächst unwichtig erschienen). Wer beschreibt, der:dem Reviewer:in die eigene Logik erklärt zu haben, anstatt zuzuhören, zeigt eine Schwäche in der Coachability; im KMU mit kleinem Frontend-Team ist das ein hartes K.o.-Signal.

Aktive Accessibility-Haltung: semantisches HTML als Standard, Tastatur-Navigation getestet, Fokus-Reihenfolge und sichtbarer Fokus geprüft, ARIA-Rollen nur wo nötig, Kontraste validiert, Screenreader-Test mindestens einmalig pro nicht-trivialer Komponente. Bonus: die:der Kandidat:in nennt ein konkretes Tool (axe, Lighthouse, VoiceOver, NVDA) und einen Fall, in dem ein Accessibility-Audit eine echte Nutzungsverbesserung gebracht hat. Wer Accessibility als Aufgabe am Projektende behandelt oder pauschal an QA delegiert, zeigt eine Lücke, die im KMU teuer wird (Klagen unter BFSG ab Mitte 2025 sind real).

Partnerschaftliche Haltung: konstruktives Hinterfragen auf Basis von Machbarkeit, Performance- oder Accessibility-Risiko, Alternativvorschläge mit Skizze oder Prototyp. Bonus: die:der Kandidat:in nennt einen Fall, in dem sie:er das ursprüngliche Briefing nach Austausch akzeptiert hat (keine systematische Opposition). Wer Designer:innen als „verstehen die Technik nicht“ oder PMs als „reden zu viel“ beschreibt, zeigt Schwäche im Teamspiel, die im KMU mit kleinem Produktteam besonders teuer wird.