Failure Stories und Postmortems

Lernziele

Nach dieser Lektion kannst du die Frage „Erzähl von einem Fehler, den du gemacht hast” in 60–90 Sekunden beantworten — ehrlich, konstruktiv und ohne Selbstsabotage. Du weißt, wie du Platform-spezifische Failures auswählst, was Interviewende wirklich hören wollen, und wie du Postmortem-Learnings mit konkreten Plattform-Verbesserungen verbindest.

Das Problem: die Frage ist eine Falle

„Tell me about a failure” klingt harmlos. Ist es nicht. Der Interviewer testet drei Dinge gleichzeitig: Selbstreflexion (erkennst du deinen Anteil?), Reife (wird jemand beschuldigt oder analysiert?), und Lernfähigkeit (hat sich danach etwas geändert?).

Die häufigsten Fehlantworten:

• Der Humblebrag: „Ich habe zu viel Verantwortung übernommen und das Projekt fast allein durchgezogen.” — Der Interviewer wartet auf einen Fehler, nicht auf ein Lob.
• Der External Blame: „Das Team hat nicht geliefert, deshalb ist die Migration gescheitert.” — Auch wenn es stimmt: Was war dein Beitrag zum Scheitern?
• Der Mini-Fehler: „Ich habe einmal ein Tippfehler im YAML gemacht.” — Zu klein, wirkt wie Ausweichen.
• Der Horror ohne Learning: 15 Minuten Incident-Story, aber kein Satz zu „was ist danach anders.”

Gute Failure Stories sind nicht peinlich — sie sind die glaubwürdigsten Stories im ganzen Interview. Gerade bei Senior- und Staff-Rollen für Platform Engineering will man Leute, die schon etwas kaputt gemacht haben und daraus Systeme gebaut haben, die es schwerer machen, dasselbe nochmal passiert.

Was eine starke Failure Story enthält

Nutze STAR — aber mit angepassten Gewichten:

Situation (15–20 Sekunden): Kontext, Teamgröße, was auf dem Spiel stand. „Wir haben ein neues Cluster-Provisioning-Rollout für 20 Teams gemacht” reicht.

Task (10 Sekunden): Deine Verantwortung. Nicht „das Team sollte deployen”, sondern „ich war verantwortlich für den Rollout-Plan und die Kommunikation.”

Action (30–40 Sekunden): Was schiefging — und was du getan hast, als du es merktest. Hier gehört der Fehler hin: falsche Annahme, übersprungenes Review, zu aggressiver Rollout. Dann: Incident-Management, Kommunikation, Fix.

Result (20 Sekunden): Impact (ehrlich, mit Zahlen wenn möglich) und was sich systemisch geändert hat. Der zweite Teil ist entscheidend: Canary-Rollout eingeführt, Policy-Check in CI, Postmortem mit Action Items, die wirklich umgesetzt wurden.

Die Formel, die Interviewende im Kopf haben: Ownership + Analyse + Systemisches Learning.

Gute vs. schlechte Failure-Themen für Platform Engineers

Stark:

• Rollout ohne Canary, der drei Teams für zwei Stunden blockiert hat
• Falsche RBAC-Policy, die Deployments in Produktion gestoppt hat
• Migration, bei der du eine Abhängigkeit übersehen hast
• Roadmap-Versprechen, das du nicht halten konntest — und wie du damit umgegangen bist
• Observability-Lücke, die einen Incident verlängert hat

Schwach:

• „Ich habe Kubernetes nicht gekannt” — zeigt nur Lernkurve, nicht Reife
• Reine Anwenderfehler anderer Teams ohne deinen Anteil
• Ethik- oder HR-Skandale — im Tech-Interview unangebracht
• Erfundene Stories — erfahrene Interviewer hören den fehlenden Detailreichtum

Wenn du wenig Produktionserfahrung hast: Nimm ein ernsthaftes Lab- oder Projektversagen — ehrlich, mit Learning. Keine erfundene War Story.

Blameless — aber nicht verantwortungslos

Postmortem-Kultur bei Platform Teams folgt dem Prinzip: blame the system, not the person — im Interview gilt das nicht als Freifahrtschein. Du sollst schon deinen Anteil benennen. „Ich habe den Rollout ohne Staging-Test freigegeben” ist stärker als „der Prozess war unklar.”

Im Postmortem danach geht es um Systemverbesserungen:

• Guardrail in der Pipeline, der den Fehler verhindert hätte
• Runbook-Update
• Automatisierter Check statt menschlicher Erinnerung
• Kommunikationsprozess für betroffene Teams

Verbinde in der Interview-Antwort mindestens eine konkrete Änderung. „Wir machen jetzt blameless Postmortems” ist zu vage. „Seitdem erzwingt unsere Provisioning-API einen Staging-Canary für alle Cluster-Updates über 10 Nodes — wir haben den Fehler zweimal simuliert, bevor wir live gingen” ist überzeugend.

Beispiel-Antwort (Gerüst, anpassen!)

Frage: „Erzähl von einem Fehler, den du gemacht hast.”

Antwort: „Beim Rollout von Network Policies als Default habe ich auf alle 40 bestehenden Namespaces ausgeweitet — obwohl nur neue abgesprochen waren. Ich übersprang die Team-Leads, weil ich die Policy für harmlos hielt.

Drei Teams hatten innerhalb von 20 Minuten broken Staging-Deploys. Sofortiger Rollback, Kommunikation in #platform-support, Call mit Betroffenen.

Impact: 45 Minuten Störung, drei Teams, kein Produktions-Impact. Danach: Canary-Rollouts mit Bake-Time, Connectivity-Check in CI vor Policy-Changes, Pflicht-RFC ab 10 Namespaces. Zweiter Rollout — 60 Namespaces — ohne Incident.”

Dauer: etwa 75 Sekunden.

Praxis: drei Failure Stories schreiben und testen

1. Brainstorm (10 min): Notiere fünf Situationen, in denen etwas schiefging — mindestens zwei, bei denen du klar Verantwortung trägst.

2. Drei ausformulieren (25 min): Schreib STAR für die drei stärksten. Jede Story braucht: deinen Fehler in einem Satz, Impact mit Zahl oder Größenordnung, mindestens eine systemische Änderung danach.

3. Schwächen-Check (5 min): Lies jede Story und markiere Humblebrag, External Blame oder fehlendes Learning. Korrigiere.

4. Laut üben (10 min): Trage alle drei vor — ziel 90 Sekunden. Welche fühlt sich am natürlichsten an? Die nimmst du ins Interview.

5. Follow-up vorbereiten (5 min): Für deine Hauptstory: Was würdest du heute anders machen? Was, wenn der Interviewer fragt „Warum bist du nicht gefeuert worden?” (Spoiler: Reife und schnelles Handeln zählen.)

Typische Stolperfallen

Zu lang: Failure Stories sind keine Incident-Postmortems mit 20 Minuten. 90 Sekunden, dann Pause lassen.

Zu klein oder zu groß: Tippfehler ist zu klein. „Ich habe das ganze Unternehmen lahmgelegt” ohne Learning ist zu groß und unglaubwürdig.

Nur Technik, keine Reflexion: Der Interviewer will hören, dass du verstanden hast, warum du den Fehler gemacht hast — Zeitdruck, Annahme, fehlender Prozess.

Learning ohne Umsetzung: „Wir haben darüber geredet” ist schwach. „Wir haben X eingeführt und seitdem Y nicht mehr passiert” ist stark.

Interview-Vorbereitung

Rechne mit Variationen der Kernfrage:

• „Was würdest du anders machen?” — Konkreter Prozess- oder Technik-Change, nicht „ich wäre vorsichtiger.”
• „Wie hast du das dem Team mitgeteilt?” — Zeigt Kommunikationsreife.
• „Was hat dein Manager gesagt?” — Kurz und sachlich; Fokus auf dein Learning, nicht Drama.

Wenn du keine passende Produktionsstory hast: Sag es. „Meine stärkste Failure Story kommt aus einem Projekt mit echtem Betriebsdruck, nicht aus Produktion — ich erkläre trotzdem, was ich gelernt habe.” Ehrlichkeit schlägt Erfindung.

Checkliste

• Ich habe mindestens eine STAR-Failure-Story (60–90 Sekunden), mit eigenem Fehler und systemischem Learning.
• Die Story enthält Impact (Zeit, Teams, Scope) und mindestens eine konkrete Änderung danach.
• Kein Humblebrag, kein reines Team-Bashing.
• Ich habe zwei Backup-Stories für Follow-ups.
• Ich kann in einem Satz sagen, was ein blameless Postmortem vom Interview-Unterscheidet.

Zusammenfassung

„Erzähl von einem Fehler” ist eine Einladung zur Reife-Demonstration, nicht zur Selbstanklage. Starke Antworten benennen deinen Anteil ehrlich, beschreiben Impact und Fix, und enden mit einer systemischen Verbesserung, die den Fehler schwerer wiederholbar macht. Platform Engineers mit guten Failure Stories wirken wie Leute, die Incidents produktiv machen — genau das sucht man in Senior-Rollen. Als Nächstes: Wie du die Plattform-Verbesserungen aus solchen Learnings nicht nur baust, sondern auch von Teams adoptiert bekommst — ohne Zwang.