Fullstack-Entwickler:in

Fähigkeit, eine Entscheidung unter Unsicherheit zu strukturieren: Identifikation der Bedingungen, expliziter Abwägungen, Konsultation der betroffenen Personen, nachträgliche Validierung mit Daten. Bonus: die:der Kandidat:in erwähnt, im Verlauf die Meinung geändert oder die Entscheidung für die Zukunft dokumentiert zu haben. Wer rückblickend eine offensichtliche Entscheidung beschreibt, hat selten ernsthaft abgewogen.

Strukturierte Debug-Methode: Reproduktion, Logs, Instrumentierung, durch Experiment validierte Hypothesen. Ehrlichkeit zur Dauer (ein echter Production-Bug ist selten in unter 30 Min. erledigt). Bonus: die:der Kandidat:in nennt die Grundursache und den systemischen Fix, nicht nur den Hotfix. Antworten wie „Ich habe den Service neu gestartet“ 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. Wer noch nie eigenen Code wirklich refactorn musste, lügt oder hat Code nie über längere Zeit in Produktion gehalten.

Fähigkeit, eine technische Schwäche aufzuzeigen, ohne zu blockieren: sachlicher Kommentar im PR (hier ist das Risiko, 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, zeigt mangelnden technischen Mut.

Klärung des Bedarfs vor der Timeline-Verhandlung (eventuell lässt sich das Feature in zwei Phasen liefern oder vereinfachen). Optionen anbieten: MVP in einer Woche plus V2 in zwei Wochen, expliziter Scope-Cut, zusätzliche Ressourcen. 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 Monitoring zum Sehen, dann Tests in kritischen Zonen, dann Deployment-Automatisierung). Abstimmung mit Team und Tech Lead vor jeder Maßnahme. Wer sich direkt in eine vollständige Neuentwicklung stürzt, zeigt mangelnden Pragmatismus.

Klärung vor dem Vorschlag (erwartetes Volumen, Latenzanforderungen, unterstützte Geräte, Persistenz ungelesener Benachrichtigungen). Kohärente Architektur: Push (WebSocket oder Server-Sent Events) vs. Pull (Polling), Persistenz (Notification-DB), Idempotenz, E-Mail-Fallback. Bonus: Anerkennung der Unsicherheitszonen (Ich würde einen POC machen, bevor ich mich zwischen WebSocket und SSE festlege). Wer ohne Klärung sofort in den Code springt, zeigt eine Design-Schwäche.

Strukturierte Methode: (1) Log-Level auf den betroffenen Endpoints temporär erhöhen, (2) mit Metriken korrelieren (Latenz, Payload-Größe, Quelle), (3) Pattern identifizieren (Tageszeit, Request-Typ, bestimmte:r Nutzer:in), (4) Hypothesen ordnen (DB-Timeout, Race Condition, Speicher). Wer sofort auf „wird wohl die DB sein“ springt, ohne zu investigieren, hat einen Bias.

Vor dem Optimieren messen: DevTools, Lighthouse, Server-Profiler. Bottleneck identifizieren (Rendering, DB-Queries, Payload, CDN). Nach Aufwand mal Wirkung priorisieren. Antworten wie „Ich baue Caching ein“ ohne Diagnose deuten auf vorzeitige Optimierung. Bonus: erkennen, dass 8 Sekunden in Produktion meist auf ein systemisches Problem hinweisen (N+1-Queries, riesige Payload), nicht auf eine lokale Optimierung.

Verständnis der Test-Pyramide (viele Unit-Tests, weniger Integrations-Tests, wenige E2E). Unterscheidung zwischen Coverage und Nutzen (90 % Coverage auf trivialem Code zählt weniger als 60 % auf kritischer Geschäftslogik). Bonus: die:der Kandidat:in nennt einen Fall, in dem ein Test eine reale Regression verhindert hat. Wer einfach „100 % Coverage“ ohne Differenzierung antwortet, zeigt schwaches Urteilsvermögen.

DB-Transaktion: Atomarität und Isolation werden von der DB gemanagt (ACID), begrenzt auf die Transaktionsdauer. Application-Lock: Koordination zwischen Prozessen oder Instanzen über Redis, ZooKeeper oder ähnliches; nützlich, wenn die Koordination über eine einzelne DB hinausgeht (Microservices, Task-Queue). Deadlock-Risiko bei beiden. Wer die beiden Mechanismen nicht trennen kann, baut in Produktion Race Conditions ein.

Schrittweises Vorgehen: (1) kritische Komponenten und wiederkehrende Patterns kartieren, (2) zuerst Hooks 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 Zustand im KMU, Redux ab größerem Volumen). Wer sofort alles auf React Server Components 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. 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 Tech-Team ist das ein hartes K.o.-Signal.

Aktive Mentorenhaltung: Pair-Programming, pädagogische Reviews (nicht nur ok merge), Dokumentation von Entscheidungen, Weitergabe guter Praktiken. Wer sagt „Ich helfe, wenn ich gefragt werde“, ohne mehr Konkretes, zeigt eine passive Haltung. Im KMU mit kleinem Tech-Team ist die Fähigkeit zur Weitergabe entscheidend für die Nachhaltigkeit des Teams.

Partnerschaftliche Haltung: konstruktives Hinterfragen auf Basis von Machbarkeit oder Komplexität, Alternativvorschläge. Bonus: die:der Kandidat:in nennt einen Fall, in dem sie:er das ursprüngliche Briefing nach Austausch akzeptiert hat (keine systematische Opposition). Wer PMs oder Designer:innen als „verstehen die Technik nicht“ beschreibt, zeigt Schwäche im Teamspiel.