Interview framework

Root Cause AnalysisIssue Tree + 5 Whys

Execution / analytical / debugging questions

When to reach for it

Any 'metric X dropped / spiked', incident review, or 'why is the funnel broken'.

2,672 questions of this shape, across 1,411 of the 1,964 companies in our interview bank.

What is root cause analysis in an interview?

Root cause analysis answers "metric X moved, why?" by structuring the search instead of guessing. You state the problem precisely, segment it, build a MECE issue tree whose branches do not overlap, ask five whys down each live branch, then name one testable hypothesis and the test that would confirm it. The framework exists to stop you guessing in the first sentence.

Watch the Root Cause Analysis breakdown

Three minutes: the same weak answer rewritten into a strong one, and the corpus numbers behind who actually gets asked this.

Root cause analysis answers "metric X moved, why?" by structuring the search instead of guessing. Seventy-nine percent of the companies in our bank ask a root-cause-shaped question. Counted across 98,000+ real interview questions from 1,800+ companies, by question type. Measured, not surveyed. Source: the JobMentis interview corpus. Chapters: 0:00 A real Root Cause Analysis interview question 0:22 Who actually gets asked this 0:47 Root Cause Analysis: the method 1:31 A weak answer 1:53 The same answer, rewritten 2:58 What flattens a root-cause answer 3:12 Where this actually gets asked 3:24 Get the full guide

The Root Cause Analysis steps

Each step is one move, and the order is the point. Skipping ahead is what makes an answer feel unstructured even when the content is good.

1
State the problem precisely
What changed, when, by how much, for whom?
2
Segment
Internal vs external, geo, platform, user cohort, funnel step.
3
Build a MECE issue tree
Top-level branches must be mutually exclusive and collectively exhaustive.
4
Ask 5 Whys down each live branch
Drill until you hit a testable hypothesis.
5
Prioritize and test
Pick the highest-impact hypothesis; propose the test to confirm it.

A weak Root Cause Analysis answer, rewritten

The acronym is on every interview blog. The graded contrast is not, so this is the part worth reading twice.

Question

“Notifications open-rate dropped 8% week-over-week. Debug it.”

Weak answer

It could be that the notification copy got stale, or maybe people are getting notification fatigue. I would try changing the copy and see if the open rate goes back up. We could also send them at a better time of day.

Strong answer

State it precisely first: open rate, not sends, down 8% relative week-over-week, starting exactly when, and for whom. Then segment before hypothesizing: internal versus external, iOS versus Android, by locale, by notification type, by cohort age. Say it comes back Android-only, starting Tuesday. Now a MECE tree with three branches: fewer notifications delivered, the same notifications opened less, or the measurement changed. Five whys down "delivered": did an app release ship Tuesday, did it change the FCM channel, was that channel silent by default? That is a testable hypothesis. The test is to compare delivery receipts before and after the release on Android, which confirms or kills it within an hour.

Why the strong version wins: The strong answer segments before it hypothesizes, keeps branches mutually exclusive so a user cannot sit in two at once, and ends with one concrete test that can run today. The weak answer guesses a cause in its first sentence and proposes a fix for it, which is precisely what the framework exists to prevent.

What flattens a Root Cause Analysis answer

The moves that turn a good framework into a forgettable answer.

Guessing the cause before segmenting.
Overlapping branches (e.g., 'iOS users' vs 'paid users' - users can be both).
No concrete test at the end.

Who actually gets asked Root Cause Analysis questions

Counted across every question in our interview bank, not estimated. Root Cause Analysis-shaped questions are not spread evenly, and these are the roles and industries whose loops lean on them hardest.

Roles

Industries

Practice Root Cause Analysis out loud, not in your head

Try it on this prompt

“Notifications open-rate dropped 8% week-over-week. Debug it.”

Reading a framework builds false confidence. The voice simulator asks a Root Cause Analysis-shaped question, listens to the whole answer, and scores the structure, the signal and the length, so you find out where your story drifts before an interviewer does.

Start a mock interview

Companies that ask Root Cause Analysis questions

These companies ask Root Cause Analysis-shaped questions in their loop. Each bank holds the real questions and the rubric we grade against.

Root Cause Analysis: frequently asked questions

What are the steps of root cause analysis in an interview?

State the problem precisely (what changed, when, by how much, for whom), segment it (platform, geo, cohort, funnel step), build a MECE issue tree, ask five whys down each live branch until you reach a testable hypothesis, then prioritize one hypothesis and propose the test that confirms it.

What does MECE mean?

MECE stands for mutually exclusive, collectively exhaustive. Every branch of your tree must be separate from the others, and together they must cover every possibility. "iOS users" and "paid users" is not MECE, because one person can be both, and overlapping branches make the analysis impossible to close out.

What is the most common root cause analysis mistake?

Guessing the cause before segmenting. Once you have named a suspect in the first sentence, the rest of the answer becomes a search for evidence that supports it. The other two are overlapping branches, and finishing with no concrete test.

Which roles get asked root-cause questions?

In our interview bank, software engineers face the most root-cause and debugging-shaped questions, followed by product managers and then sales. It is a consulting technique by origin, but any role expected to explain why a number moved will meet it.

The other six frameworks

Root Cause Analysis is one of seven. If the question you are preparing for does not have this shape, one of these does.