Interview-Framework

Root Cause AnalysisIssue Tree + 5 Whys

Fragen zu Umsetzung, Analyse und Fehlersuche

Wann du darauf zurückgreifst

Jedes „Metrik X ist gefallen oder gesprungen“, Incident-Review, oder „warum ist der Funnel kaputt“.

2.661 Fragen dieser Art, verteilt auf 1.400 der 1.887 Unternehmen in unserer Interview-Datenbank.

Was ist Ursachenanalyse im Interview?

Die Ursachenanalyse beantwortet "Metrik X hat sich bewegt, warum?", indem sie die Suche strukturiert statt zu raten. Du benennst das Problem präzise, segmentierst, baust einen MECE-Baum, dessen Äste sich nicht überlappen, fragst entlang jedes lebenden Astes fünfmal warum und benennst dann eine prüfbare Hypothese samt dem Test, der sie bestätigen würde. Das Framework existiert, um dich davon abzuhalten, im ersten Satz zu raten.

Root Cause Analysis im Video erklärt

Drei Minuten: dieselbe schwache Antwort, umgeschrieben in eine starke, plus die Zahlen aus unserer Fragensammlung dazu, wer sie wirklich gestellt bekommt.

Die Ursachenanalyse beantwortet "Metrik X hat sich bewegt, warum?", indem sie die Suche strukturiert statt zu raten. Neunundsiebzig Prozent der Unternehmen in unserer Datenbank stellen eine root-cause-Frage. Ausgezählt über 100.000+ echte Interviewfragen aus 1.800+ Unternehmen, nach Fragetyp. Gemessen, nicht geschätzt. Quelle: die JobMentis-Interviewfragen-Datenbank.

Die Schritte von Root Cause Analysis

Jeder Schritt ist ein Zug, und die Reihenfolge ist der Punkt. Schritte zu überspringen lässt eine Antwort unstrukturiert wirken, selbst wenn der Inhalt gut ist.

  1. 1

    Das Problem präzise benennen

    Was hat sich verändert, wann, um wie viel, bei wem?

  2. 2

    Segmentieren

    Intern gegen extern, Region, Plattform, Nutzerkohorte, Funnel-Schritt.

  3. 3

    Einen MECE-Baum bauen

    Die Äste der obersten Ebene müssen sich gegenseitig ausschließen und zusammen alles abdecken.

  4. 4

    Fünfmal warum je lebendem Ast

    Grabe, bis du bei einer prüfbaren Hypothese ankommst.

  5. 5

    Priorisieren und testen

    Wähle die Hypothese mit der größten Wirkung und schlage den Test vor, der sie bestätigt.

Eine schwache Root Cause Analysis-Antwort, umgeschrieben

Das Akronym steht in jedem Interview-Blog. Der bewertete Vergleich nicht: Das ist der Teil, den du zweimal lesen solltest.

Frage

“Die Öffnungsrate von Benachrichtigungen ist im Wochenvergleich um 8 % gefallen. Finde den Fehler.”

Schwache Antwort

Vielleicht ist der Text der Benachrichtigungen abgenutzt, oder die Leute sind übersättigt. Ich würde den Text ändern und schauen, ob die Öffnungsrate wieder steigt. Wir könnten sie auch zu einer besseren Uhrzeit senden.

Starke Antwort

Zuerst präzise benennen: Öffnungsrate, nicht Versand, 8 % relativer Rückgang im Wochenvergleich, ab genau wann und bei wem. Dann segmentieren, bevor ich vermute: intern gegen extern, iOS gegen Android, nach Sprache, nach Benachrichtigungstyp, nach Kohortenalter. Nehmen wir an, es zeigt sich nur auf Android, ab Dienstag. Jetzt ein MECE-Baum mit drei Ästen: weniger Benachrichtigungen zugestellt, dieselben Benachrichtigungen seltener geöffnet, oder die Messung hat sich geändert. Fünfmal warum entlang "zugestellt": Kam am Dienstag ein App-Release, hat es den FCM-Kanal geändert, war dieser Kanal standardmäßig stumm? Das ist eine prüfbare Hypothese. Der Test ist ein Vergleich der Zustellbestätigungen vor und nach dem Release auf Android, was sie innerhalb einer Stunde bestätigt oder kippt.

Warum die starke Version gewinnt: Die starke Antwort segmentiert, bevor sie vermutet, hält die Äste gegenseitig ausschließend, sodass ein Nutzer nicht in zweien gleichzeitig sitzen kann, und endet mit einem konkreten Test, der heute laufen kann. Die schwache rät die Ursache im ersten Satz und schlägt dafür eine Lösung vor, also genau das, was das Framework verhindern soll.

Was eine Root Cause Analysis-Antwort flach macht

Die Züge, die aus einem guten Framework eine vergessliche Antwort machen.

  • Die Ursache raten, bevor segmentiert wurde.

  • Überlappende Äste, etwa „iOS-Nutzer“ gegen „zahlende Nutzer“: man kann beides sein.

  • Am Ende kein konkreter Test.

Wer wirklich Root Cause Analysis-Fragen gestellt bekommt

Über alle Fragen unserer Interview-Datenbank gezählt, nicht geschätzt. Fragen vom Typ Root Cause Analysis verteilen sich nicht gleichmäßig: Das sind die Rollen und Branchen, deren Prozesse sich am stärksten darauf stützen.

Rollen

Branchen

Übe Root Cause Analysis laut, nicht im Kopf

Probiere es an dieser Frage

“Die Öffnungsrate von Benachrichtigungen ist im Wochenvergleich um 8 % gefallen. Finde den Fehler.”

Ein Framework zu lesen erzeugt falsche Sicherheit. Der Sprachsimulator stellt dir eine Frage vom Typ Root Cause Analysis, hört die ganze Antwort an und bewertet Struktur, Signal und Länge, damit du merkst, wo deine Geschichte abdriftet, bevor es jemand im Interview tut.

Simuliertes Interview starten

Unternehmen, die Root Cause Analysis-Fragen stellen

Diese Unternehmen stellen in ihrem Prozess Fragen vom Typ Root Cause Analysis. Jede Datenbank enthält die echten Fragen und die Rubrik, nach der wir bewerten.

Root Cause Analysis: häufige Fragen

Was sind die Schritte der Ursachenanalyse im Interview?

Das Problem präzise benennen (was hat sich verändert, wann, um wie viel, bei wem), segmentieren (Plattform, Region, Kohorte, Funnel-Schritt), einen MECE-Baum bauen, entlang jedes lebenden Astes fünfmal warum fragen, bis eine prüfbare Hypothese steht, und dann eine Hypothese priorisieren und den Test vorschlagen, der sie bestätigt.

Was bedeutet MECE?

MECE steht für mutually exclusive, collectively exhaustive, also gegenseitig ausschließend und gemeinsam vollständig. Jeder Ast deines Baums muss von den anderen getrennt sein, und zusammen müssen sie alle Möglichkeiten abdecken. "iOS-Nutzer" und "zahlende Nutzer" ist nicht MECE, weil eine Person beides sein kann, und überlappende Äste machen die Analyse unabschließbar.

Was ist der häufigste Fehler bei der Ursachenanalyse?

Die Ursache vor dem Segmentieren zu raten. Sobald im ersten Satz ein Verdächtiger benannt ist, wird der Rest der Antwort zur Suche nach Belegen dafür. Die beiden anderen sind überlappende Äste und ein Schluss ohne konkreten Test.

Welchen Rollen werden Ursachenfragen gestellt?

In unserer Interview-Datenbank begegnen Software-Engineers den meisten Fragen zu Ursachenanalyse und Fehlersuche, gefolgt von Product Managern und dann Sales. Die Technik stammt aus der Beratung, aber jede Rolle, die erklären soll, warum sich eine Zahl bewegt hat, wird ihr begegnen.

Die anderen fünf Frameworks

Root Cause Analysis ist eines von sechs. Wenn die Frage, auf die du dich vorbereitest, diese Form nicht hat, deckt eines davon sie ab.