Backend-Entwickler:in

Bewusste Entscheidungen statt Default-Übernahme: explizite Versionierungsstrategie (URL, Header, kein Versioning mit Gründen), Auth-Modell passend zum Kontext (Session, JWT, OAuth, mTLS), konsistentes Fehlerformat über alle Endpoints. Bonus: die:der Kandidat:in nennt Entscheidungen, die sie:er heute anders treffen würde. Wer ohne Reflexion REST mit JSON Web Token nennt, hat selten ernsthaft abgewogen.

Strukturierte Debug-Methode: Reproduktion, Logs, Metriken, durch Experiment validierte Hypothesen. Ehrlichkeit zur Dauer (ein echter Production-Incident ist selten in unter 30 Min. geschlossen). Bonus: die:der Kandidat:in nennt die Grundursache und den systemischen Fix (Post-mortem, Runbook, neuer Alarm), nicht nur den Hotfix. Antworten wie „Ich habe den Service neu gestartet“ ohne Diagnose deuten auf schwache Diagnosefähigkeit.

Schrittweises Vorgehen: Online-Migration mit Doppelschreiben oder Backfill, expliziter Rollback-Plan, Validierung auf Konsistenz vor dem Cut-over. Bonus: die:der Kandidat:in nennt einen Fall, in dem die Migration länger gedauert hat als geplant, und was sie:er daraus gelernt hat. Wer eine Big-Bang-Migration ohne Rollback beschreibt, zeigt Risikoblindheit.

Strukturierte Methode: (1) Rollback-Option offenhalten, (2) Log-Level auf den betroffenen Endpoints temporär erhöhen, (3) mit Metriken korrelieren (Latenz, Payload-Größe, Quelle), (4) Pattern identifizieren (Tageszeit, Request-Typ, bestimmte:r Nutzer:in oder Tenant). Wer sofort auf „wird wohl die DB sein“ springt, ohne zu untersuchen, hat einen Bias. Bonus: explizite Erwähnung, parallel ein Post-mortem-Dokument zu starten.

Klärung des fachlichen Bedarfs vor der Diskussion über die Lösung (oft lässt sich der Use Case mit aggregierten Daten oder einem Index lösen). Optionen anbieten: passender Index, Materialized View, asynchroner Job mit Cache, Datenmodell-Anpassung. Antworten wie „Ich baue das schon, wenn die DB langsam wird, optimieren wir später“ deuten auf mangelnde Voraussicht.

Zuerst Diagnose: nicht alles gleichzeitig reparieren wollen. Priorisierung nach Risiko und Wirkung (typisch: zuerst Monitoring und Alarme für Sichtbarkeit, dann Tests für die zwei oder drei kritischsten Geschäftsregeln, dann Deployment-Automatisierung, Datenbank-Refactor zuletzt). Abstimmung mit Team und Tech Lead vor jeder Maßnahme. Wer sich direkt in eine Microservices-Migration stürzt, zeigt mangelnden Pragmatismus.

Klärung vor dem Vorschlag (erwartetes Volumen, Latenzanforderung, Retry-Verhalten, Sicherheits-Modell). Kohärente Architektur: asynchrone Queue, idempotente Lieferung mit Event-ID, Retry mit exponentiellem Backoff, Dead-Letter-Queue, signierte Payload (HMAC oder ähnliches), Endpoint-Verifikation. Bonus: explizite Behandlung von langsamen oder ausgefallenen Empfängern (Circuit Breaker, Throttling pro Empfänger). Wer ohne Klärung sofort in den Code springt, zeigt eine Design-Schwäche.

Erkennen, dass eine naive UPDATE-Operation pro Request nicht skaliert: Lock-Contention, Connection-Limits, WAL-Druck. Lösungsraum: In-Memory-Counter mit periodischem Flush, Sharded Counter, Redis-Inkrement mit Persistenz-Strategie, Event-Stream mit nachgelagerter Aggregation. Bonus: Diskussion der Konsistenzgarantien (eventually consistent vs. strikt) und Failover-Verhalten. Wer einfach eine Postgres-Tabelle nimmt, hat Last und Konsistenz nicht durchdacht.

Strukturierte Methode: (1) Korrelation mit externen Faktoren (Verkehrsanstieg, Datenwachstum, Drittsystem-Latenz), (2) Slow-Query-Logs und DB-Statistiken prüfen (Tabellengröße, Indexnutzung, Vacuum-Status bei Postgres), (3) Trace einer langsamen Anfrage von Edge bis DB, (4) Hypothesen ordnen (Index-Bloat, Cache-Miss-Rate gestiegen, Connection-Pool ausgelastet). Bonus: erkennen, dass langsamer Anstieg meist auf Datenwachstum oder Index-Degradation hindeutet, nicht auf einen plötzlichen Fehler.

Solides Verständnis der Anomalien (Dirty Read, Non-repeatable Read, Phantom Read, Write Skew). Read Committed als pragmatischer Default in Postgres, Repeatable Read für konsistente Berichte, Serializable für selten genutzte, aber kritische Pfade (Buchhaltung, Inventar). Bonus: Erwähnung der Performance-Kosten von Serializable und der Strategie mit SELECT FOR UPDATE als Mittelweg. Wer die Levels nicht trennen kann, baut in Produktion Race Conditions ein.

Klare Trennung von Logs (strukturiert, mit Trace-ID), Metriken (RED- oder USE-Methode: Rate, Errors, Duration; oder Utilization, Saturation, Errors) und verteiltem Tracing. Konkrete Tool-Wahl mit Begründung (Prometheus plus Grafana, OpenTelemetry, Datadog, Sentry). Alarme nur auf actionable Signale, nicht auf jede Anomalie. Bonus: explizite SLOs mit Error Budget. Wer pauschal „alles loggen“ sagt, zeigt fehlende Erfahrung mit hochlastigen Services.

Klare Liste: Injection (SQL, OS, Template), Auth- und Session-Schwächen, Authorization-Bypass auf Tenant-Ebene, unsicheres Secret-Handling (Plaintext im Repo, in Logs, in Tracing), unsicheres Deserialisieren, SSRF aus Backend-Calls, Open-Redirect. Konkrete Maßnahmen: parametrisierte Queries, Secret-Manager, Output-Encoding, Authorization-Checks auf jeder Request, Logging ohne sensible Daten. Bonus: OWASP-Top-10-Bezug mit konkreter Anwendung im eigenen Stack.

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 (anderes Datenmodell, andere API-Form). 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 Backend-Team ist das ein hartes K.o.-Signal.

Aktive Mentorenhaltung: Pair-Programming auf kritischen Pfaden, pädagogische Reviews mit Begründung (nicht nur „ok, merge“), dokumentierte Architektur-Entscheidungen (ADR), Weitergabe guter Praktiken (Idempotenz, Backoff, sichere Deploys). Wer „Ich helfe, wenn ich gefragt werde“ sagt, ohne mehr Konkretes, zeigt eine passive Haltung. Im KMU mit kleinem Backend-Team ist die Fähigkeit zur Weitergabe entscheidend für die Nachhaltigkeit des Teams.

Partnerschaftliche Haltung: konstruktives Challenging auf Basis von Machbarkeit, Komplexität oder operativen Folgen, Alternativvorschläge. Bonus: die:der Kandidat:in nennt einen Fall, in dem sie:er den ursprünglichen Vorschlag nach Austausch akzeptiert hat (keine systematische Opposition). Wer Frontend, SRE oder DBA mit „verstehen Backend nicht“ beschreibt, zeigt Schwäche im übergreifenden Teamspiel.