So prüfst du Codequalität und Engineering‑Gesundheit im Interview

Bei technischen Interviews geht es nicht nur darum, ob du die Aufgabe lösen kannst. Es geht darum, in welchen Zustand du den Code, die Releases und das Team übernehmen würdest.

Dieser Leitfaden zeigt dir praxisnahe Fragen, schnelle Sachen, die du an einem Repo prüfen kannst, und die echten roten Fahnen, auf die du achten solltest.

Was bedeutet „Engineering‑Gesundheit” konkret?

Engineering‑Gesundheit umfasst Codequalität, Testabdeckung und Stabilität, CI/CD‑Pipelines, Incident‑Historie und Postmortems, den Umgang mit technischer Schuld, Ownership und die Entwicklererfahrung (Tooling, Onboarding, Code‑Review‑Prozess).

Wichtig ist, sowohl den aktuellen Zustand als auch die Fähigkeit des Teams zur Verbesserung zu beurteilen. Ein chaotischer Code mit einem klaren Plan und Management‑Support ist oft besser als ein scheinbar stabiler Code ohne Erneuerungsmöglichkeiten.

Konkrete Fragen fürs Interview (und warum sie nützlich sind)

Stell kurze, präzise Fragen, die nach Beispielen verlangen. Floskeln und Marketing‑Antworten sagen dir wenig.

Die folgenden Fragen kannst du in technischen Screens, Gespräch mit dem Manager oder im abschließenden Loop stellen. Zu jeder Frage beschreibe ich kurz, wie eine hilfreiche Antwort klingt und worauf du achten solltest.

• „Wie oft deployed ihr in Produktion? Beschreibt mir den letzten erfolgreichen Deploy.” — Gut: automatisierte, häufige Deploys; Rollback‑Plan. Schlecht: manuelle Deploys durch eine einzelne Person.
• „Nenn mir einen kürzlichen Incident und den Postmortem‑Output.” — Gut: blameless Postmortem, konkrete Maßnahmen und Metriken zu Verbesserungen. Schlecht: keine Postmortems oder Schuldzuweisungen.
• „Wie verwaltet ihr technische Schulden?” — Gut: explizite Tickets, Zeitbudget für Schulden, Priorisierung nach Impact. Schlecht: Schulden werden nur „irgendwann” abgearbeitet.
• „Wie läuft das Onboarding für neue Entwickler?” — Gut: dokumentierter Setup‑Guide, erste Tasks, Mentor/Buddy. Schlecht: „Einfach selbst herausfinden” und Probleme beim Build.
• „Wer trifft Architekturentscheidungen und wie dokumentiert ihr sie?” — Gut: RFCs, Entscheidungsträger, Pro‑/Contra‑Abwägungen. Schlecht: Ad‑hoc‑Entscheidungen ohne Nachvollziehbarkeit.

Schnelle Repo‑Checks vor oder während des Gesprächs

Wenn du Zugriff auf ein öffentliches Repo, Demos oder Architektur‑Dokumente hast, reichen ein paar Heuristiken, um viel zu lernen. Du musst kein Experte für die Codebasis sein.

Kein Zugriff? Bitte um einen Screenshot, ein kurzes Walkthrough oder ein Architekturdiagramm im Interview.

• README und Onboarding‑Dokumente: Sind sie vorhanden und aktuell? Gute Dokumentation ist oft ein Qualitätsindikator.
• Commit‑Historie und PRs: Viele kleine PRs vs. seltene große Merges — kleine PRs sprechen für bessere CI/Review‑Praktiken.
• CI‑Status: ständig fehlschlagende Pipelines oder lange Jobs bedeuten Wartungsaufwand.
• Tests: Sind Tests nahe beim Code? Gibt es Unit‑, Integrations‑Tests und laufen sie automatisch?
• Issue‑Tracker: Sind Tickets klar beschrieben und getaggt (bug, tech debt, infra)? Ein chaotischer Backlog zeigt Priorisierungsprobleme.

Wie du Antworten richtig einordnest

Nicht jedes Problem ist ein Dealbreaker. Verlässlich sind Antworten, die konkrete Beispiele, Namen, Zeiträume und messbare Outcomes nennen. Vage Aussagen mit vielen „irgendwie” oder „meistens” sind weniger vertrauenswürdig.

Beispiel einer guten Formulierung: „Wir deployen täglich. Letzte Woche haben wir einen flakigen Test isoliert und eine CI‑Prüfung hinzugefügt, die Regressionen verhindert.” Eine schwammige Antwort wäre: „Unsere Deploys sind meistens okay.”

Rote Fahnen, bei denen du genauer nachfragen solltest

Einige Warnsignale verdienen besondere Aufmerksamkeit. Sie bedeuten nicht automatisch, dass du absagen solltest, aber du solltest Nachfragen stellen und dir überlegen, wie viel Risiko du akzeptierst.

Wenn verschiedene Interviewpartner unterschiedliche Geschichten über Entscheidungswege erzählen, deutet das auf fehlende Abstimmung oder schlechte Dokumentation hin.

• Keine Postmortems oder Vorwürfe nach Incidents.
• Deploys oder Wartungsaufgaben, die nur eine Person beherrscht (Wissensinseln).
• CI lokal grün, im Main‑Branch aber häufig rot — fragile Tests/pipelines.
• Technische Schulden werden immer wieder verschoben, ohne Budget oder Zeit dafür.
• Neue Kolleginnen brauchen Wochen, bis das Projekt läuft, oder Tests werden aus Bequemlichkeit übersprungen.

Was du Manager und Team separat fragen solltest

Manager und Entwickler sehen Dinge unterschiedlich. Frag Manager nach Prioritäten, Roadmap und Budget für Refactorings. Frag das Team nach Alltag, Code‑Review‑Normen und welchen Schmerzpunkten sie täglich begegnen.

Beispiel: Der Manager sagt „Wir planen 10 % Sprintzeit für Schulden.” Frag das Team, ob das wirklich eingehalten wird und wie das konkret aussieht.

• Manager: „Woran messt ihr Engineering‑Velocity und Qualität?”
• Team: „Zeig mir einen aktuellen PR und worauf Reviewer geachtet haben.”
• Manager: „Wie ist das On‑Call‑Modell und die Eskalationskette?”
• Team: „Was hast du zuletzt refactored und warum?”

Du brauchst nicht von jedem Interview perfekte Antworten. Ziel ist ein stimmiges Gesamtbild: Sind Probleme bekannt und werden sie aktiv angegangen, oder sind sie versteckt und ignoriert?

Wenn du die Rolle willst, aber Sorgen hast, bitte um konkrete Zusagen — Verbesserungsplan, bessere Onboarding‑Docs oder ein Commitment zur CI‑Stabilisierung — und versuche, diese Punkte vor einer Zusage schriftlich bestätigt zu bekommen.