How to Answer Root Cause Questions
Root cause analysis questions test something specific: can you systematically investigate a problem under time pressure without wasting questions?
Asked at Meta • 
Asked at Uber Asked at Meta • 
Asked at Coinbase • The framework below provides a decision tree that not only leads you to the right answer but also demonstrates the analytical instincts interviewers at top tech companies are screening for.
What interviewers are looking for
Nowadays, RCA questions are usually follow-ups. You have 10 to 15 minutes, and the interviewer is not scoring you on whether you find the right answer. They are scoring:
- A systematic approach. Every question you ask should change what you look at next. Asking questions at random signals that you are going through a checklist, not reasoning.
- Prioritization instincts. Where you start matters as much as where you end up. Interviewers notice immediately when a candidate goes straight to the most interesting hypothesis rather than the most likely one.
- Thoroughness under constraint. You will not have time to investigate everything. The skill is knowing what to rule out quickly and what to explore in depth.
- Macro awareness at the senior level. A solid investigation starts with internal causes before expanding to external ones if nothing surfaces. Senior+ candidates run both tracks in parallel, since some external factors are immediately falsifiable and can save significant investigation time.
The framework
Follow this five-step process:
- Define the problem
- State your hypothesis space
- Triage with shape-of-drop questions
- Investigate inside the bucket
- Determine the resolution path
Step 1: Define the problem
Before you form a single hypothesis, you need a precise, shared definition of what is actually being measured.
Two things to nail down:
Define the metric. Is the drop in volume, rate, or quality? Each points to a different investigation. A drop in volume (fewer users completing checkout) is a different problem from a drop in rate (the same users completing at a lower percentage) even if both show up as "cart conversion declined."
Define the feature and its measurement boundaries. Get the interviewer to confirm exactly what is and is not included in the metric. This sounds pedantic but it is analytically critical.
"Before I start investigating, I want to make sure I understand the metric precisely. When we say cart conversion rate dropped, what is the denominator: cart creation or cart view? And does the metric include instant checkout flows, or only the standard cart path?"
Why does this matter? If the denominator is cart creation and your product recently launched an agentic feature that automatically creates carts on users' behalf while they review options, the denominator explodes while completions stay flat. The rate tanks. Nothing is broken. You would spend 15 minutes investigating a ghost.
Watch out for: Jumping to hypotheses before you know what is being measured. Interviewers will let you do this and watch you run in the wrong direction. Getting the definition right is not a bureaucratic warm-up; it’s the first filter.
When the question involves conflicting metrics
Sometimes the question is not a single metric drop but two metrics moving in unexpected directions at the same time. These require a different opening move.
When you encounter a conflicting metrics question, your job in Step 1 is to explicitly name the tension. What was the assumed relationship between these metrics, and what does it mean that the relationship has broken?
"Notification engagement is up week over week, but time on site is flat or declining. The assumed relationship here was that higher notification engagement would drive more session time. The tension is that users are clicking through but not staying. Before I investigate causes, I want to name what kind of break this is: are users finding what they expected and leaving satisfied, or finding something disappointing and leaving early? That distinction changes everything I look for."
This is a real pattern. Meta's analytical rounds consistently end with a conflicting-metric follow-up in exactly this shape: one engagement signal up, one retention signal flat or down. Candidates who name the tension before investigating demonstrate the kind of systems thinking that separates a strong answer from a forgettable one.
Step 2: State your hypothesis space
Before you ask a single data question, briefly name the full set of buckets you will investigate. This takes 30 seconds and accomplishes two things: it signals that you are thinking exhaustively, and it gives the interviewer a map of where you are going.
The hypothesis space has two parallel tracks: internal and external.
Internal track
These are causes within your product and organization:
- Product or UX change. A feature release, redesign, or experiment altered user behavior in an unanticipated way.
- Cohort effect. New users acquired from a different channel or campaign behave differently from the existing base, pulling down aggregate metrics.
- Quality or model regression. The product's output degraded, and users are noticing. For AI products, this includes prompt drift and model version changes.
- Infrastructure or latency issue. Response times increased or reliability dropped, causing users to abandon before they get value.
- Measurement artifact. The metric itself changed, not the underlying experience. A different usage type is being averaged in, or the definition is shifted.
External track
These are causes outside your product and organization:
- Competitive and market shifts. A competitor launched something significant, a platform your product depends on changed, or a broader behavioral trend shifted in your category.
- Seasonality and cyclical patterns. The drop follows a known calendar pattern or recurring usage cycle.
- Macro and out-of-control events. A government policy change, regulatory action, macroeconomic shift, or force-majeure event constrained access or demand.
Why two tracks?
The internal track covers every way your product and organization can affect a metric: what you built, who you acquired, how well the product works, how reliably it runs, and how accurately you measure it.
The external track covers every way the world outside your product can move the same metric: what competitors do, what the calendar does, and what governments and economies do.
Step 3: Triage with shape-of-drop questions
Do not jump directly into bucket-specific questions; investigate one hypothesis at a time, with no way to quickly rule things out. The right move is to ask a small number of high-leverage questions that can eliminate multiple buckets at once.
These questions are about the shape of the drop, not its cause. Shape tells you where to look. Think of this step as orienting before investigating.
Question 1: Is there any obvious external event that coincides with the timing of the drop?
This question takes ten seconds and can save your entire investigation. Seasonality, in particular, is the fastest external bucket to falsify: a single historical overlay either confirms or eliminates it.
Question 2: Was the drop sudden or gradual?
Question 3: Is the drop broad-based or concentrated in a specific segment?
Question 4: Did anything change on our end around the time the drop started?
After these four questions, you should be able to say: "Based on this, the most likely bucket is X and possibly Y. I will start with X because [reason], and I want to run a quick check on [external bucket] in parallel since it is fast to eliminate." That statement, delivered clearly, is what demonstrates good PM instincts.
Step 4: Investigate inside the bucket
You are now inside a specific bucket. Your goal is to confirm the root cause with targeted questions, each of which narrows the space further. Each question below shows what a yes implies and what a no implies, because both directions are informative.
If two or three consecutive answers within a bucket do not fit the expected pattern, step back. Say: "This evidence is not consistent with what I would expect from a product change. I am going to revisit my triage and look at infrastructure or cohort effect instead." Stepping back when the data contradicts your hypothesis is a green flag. Do not double down on a bucket that is not fitting.
Bucket A: Product or UX change
You arrive here when: sudden drop, broad-based, internal change confirmed.
The power-user vs. new-user split is one of the highest-signal questions in this bucket. It tells you whether you are dealing with a universal friction problem or a workflow regression that only surfaces with depth of use, and that distinction determines whether the fix is a rollback or a targeted adjustment.
Bucket B: Cohort effect
You arrive here when: a gradual drop, or a concentration in recently acquired users.
Bucket C: Quality or model regression
You arrive here when: gradual drop, broad-based, no obvious internal change event.
Bucket D: Infrastructure or latency issue
You arrive here when there is a sudden drop, concentrated in a specific segment (geography, device, time window).
Bucket E: Measurement artifact
You arrive here when: aggregate metric dropped, but a core user segment appears unaffected, or a pipeline or definition change occurred recently.
Measurement artifact is the most underweighted bucket in interview settings. Most candidates never ask, "Could this be a measurement problem?" and miss an entire class of root causes. On AI products especially, this matters: when agentic or API usage is introduced at scale, automated sessions, which are short by design, get averaged into engagement metrics built for interactive human users. The metric appears to be declining. What is actually happening is that a different kind of usage is being counted inside the same number. Calling this out explicitly signals that you have thought about how AI changes the measurement problem, not just the product.
A candidate at Cursor was asked: "We've seen a lot of usage, but PRs are going down or not making it to production. How would you think about that?"
High usage with declining downstream completion is a textbook measurement artifact i.e. the headline metric looks healthy while the real signal is buried.
Bucket F: Competitive and market shifts
You arrive here when the drop coincides with a known competitor action, a platform your product depends on changes, or a broader behavioral trend shifted in your category.
The last question in this table is one of the most senior signals in the entire framework. Knowing whether your competitors are seeing the same trend requires market awareness beyond your own dashboards: analyst reports, app store rankings, public earnings calls, and social listening. Candidates who can demonstrate fluency with this kind of external data in an interview demonstrate that they think like a GM, not just a feature owner.
Bucket G: Seasonality and cyclical patterns
You arrive here when the drop follows a known calendar pattern or when the timing aligns with a recurring usage cycle.
Seasonality is the fastest external bucket to falsify. A single historical data overlay can either confirm or rule it out in seconds. This is why it is worth checking early (even before going deep on internal buckets) when the timing of the drop makes it plausible.
Bucket H: Macro and out-of-control events
You arrive here when: no internal or competitive explanation fits, or a known large-scale external event coincides with the drop.
Bucket H is the only bucket in this framework where the root cause is genuinely outside your control. That does not mean the conversation ends. A strong candidate identifies the external cause and immediately signals awareness that mitigation remains the PM's responsibility: protecting retention in affected regions, accelerating the contingency roadmap, adjusting pricing to economic conditions, or repositioning the product. Interviewers at the senior level often use this as a natural pivot into a product strategy follow-up. Being ready for that transition is part of the answer.
Step 5: Determine the resolution path
Naming the root cause is not the end of the answer. Interviewers (especially when RCA is a follow-up) will ask, or simply wait for, what you'd actually do next. This step signals that you think like a PM who owns outcomes.
The resolution path has two parts.
First, determine whether the root cause requires action at all. Not every metric drop signals a problem worth fixing. If the root cause is a measurement artifact (automated sessions inflating your denominator), the fix is a metrics architecture change, not a product change. If the drop maps cleanly to a known seasonal pattern, the right call may be to document it, monitor it, and move on. Naming this distinction explicitly tells the interviewer you're not reflexively jumping to fixes.
Second, if action is warranted, name the tradeoff and who owns it. For causes within your own product (e.g., a feature regression, a UX change with unintended effects, a quality drop) briefly assess whether the tradeoff is worth it. If a new feature caused the drop, ask: was this an expected side effect? Is the upside still worth the cost? That's the decision-making judgment interviewers are probing for.
For causes that belong to another team (i.e. a change owned by a different PM, an infrastructure issue, a model update) name the escalation path. Saying "I'd flag this to the PM who owns that surface" is a legitimate and realistic answer. It signals cross-functional awareness, not avoidance.
Interviewer pivots
Two things can happen when you are deep in Step 4 that catch candidates off guard.
The pivot. The interviewer introduces new information that redirects you to an entirely different bucket. "Let's say the analytics team just told you this drop is concentrated in Southeast Asia." This is not a curveball; it’s the interviewer extending the exercise with new evidence. The right response is to treat it as a data point, step back to Step 3, and re-triage with the new constraint. Candidates who panic here were treating the investigation as a performance rather than a live reasoning exercise.
The rabbit hole. The interviewer keeps saying yes and lets you go deeper into an increasingly specific root cause without introducing new constraints. No new information arrives; they just keep confirming. This is the interviewer stress-testing how far your domain knowledge goes within that bucket. Many candidates do not realize the exercise has been extended.
The meta-lesson: the interview is not over when you name a bucket. It is over when the interviewer signals it is. Stay in investigation mode until you get an explicit closing cue.
Common pitfalls
Skipping metric definition. Getting the measurement bounds wrong early means your entire investigation is built on a misunderstood premise. A candidate who asks "what is the denominator?" before forming hypotheses looks more rigorous, not more pedantic.
Ignoring the external track entirely. Candidates who only investigate internal causes and treat competitors or seasonality as afterthoughts miss an entire class of root causes. At senior level, this is a meaningful signal that the candidate thinks like a feature owner rather than a GM.
Raising external factors without being able to investigate them. The opposite problem: candidates who lead with competitors before checking internal causes look like they are avoiding the hard analytical work. The right move is to check the fast-falsifiable external buckets (seasonality, especially) early and hold off on the harder-to-verify ones (competitive shifts, macro) until internal causes have been explored.
Asking questions without acting on the answers. Every answer should visibly change where you go next. If a yes and a no would lead you to the same next question, you are reciting a checklist, not building a decision tree. Interviewers notice this immediately.
Ignoring the measurement artifact bucket. Most candidates never ask whether the metric itself could be the problem. On AI products, especially, this is increasingly the correct answer. Calling it out signals that you understand how AI changes the measurement problem, not just the product.
Anchoring on the first bucket that fits. The first plausible hypothesis is not always the right one. Two or three consecutive nos inside a bucket is your signal to step back and re-triage. Candidates who cannot exit a bucket gracefully appear to be guessing rather than reasoning.