Skip to main content

Bug Analysis and Root-Cause Interviews

Prerequisites: You should already have completed Cross-Domain Interview Scenarios. Leads to: After this, you'll be ready for Test Strategy and "How Would You Test X" Interviews.

"Users report the app is slow sometimes — how would you investigate?" is a symptom with dozens of possible causes, and the question isn't asking you to guess correctly — it's asking whether you can narrow a wide space systematically. This module applies Database Defect Investigation's and Performance Defect Investigation's own investigative discipline directly to that live reasoning moment.

Why This Matters​

A candidate who guesses at a cause immediately. Given the prompt "users report checkout is slow sometimes," a candidate answers immediately: "that's probably the database — I'd add an index." The guess might even be right, but nothing in the answer shows how they got there — no clarifying question, no narrowing of the wide space between "slow sometimes" and "the database specifically."

A candidate who narrows systematically before committing to a hypothesis. A different candidate, given the identical prompt, asks first: "is it slow for everyone, or specific users? Has anything changed recently — a deploy, a traffic increase? Is 'sometimes' correlated with time of day or load?" Learning it correlates with peak traffic hours, they reason aloud: "that points toward a resource-contention issue rather than a single bad query — I'd want to check whether it's database connection pool exhaustion, a slow external dependency under load, or the application server itself running out of capacity, and I'd correlate response-time data against a resource-utilization timeline to distinguish between them."

Both candidates might eventually reach the same correct cause. Only one of them demonstrated a systematic process that would work on a genuinely unfamiliar symptom, not just this specific one.

Reasoning From Symptom to Cause, Systematically​

Ask narrowing questions before proposing a cause: "for everyone or some users," "since when," "did anything change recently" — these questions, reused directly from Database Defect Investigation's own systematic approach, turn a vague symptom into a narrower, more tractable problem before you ever guess at a specific cause.

Reason through layers, not a single guess: Performance Defect Investigation's own discipline — correlating a symptom against a resource-utilization timeline rather than guessing at a single component — is exactly the structured reasoning an interviewer wants to see, even in a conversational, non-technical-tool context.

State your hypothesis, then say how you'd confirm or rule it out: "I'd suspect X, and I'd confirm that by checking Y" is a complete, evaluable answer; "I'd suspect X" alone leaves the interviewer with no way to assess whether your reasoning was sound or lucky.

What the Interviewer Is Really Evaluating​

  • Narrowing before guessing: does the candidate ask clarifying questions, or jump straight to a specific cause
  • Systematic, layered reasoning: does the candidate consider multiple possible causes and a way to distinguish between them, or commit to one guess
  • A stated path to confirmation: does the candidate explain how they'd verify their hypothesis, not just state it

Common Mistakes​

Mistake 1: Proposing a specific cause immediately, without any narrowing question. This module's opening scenario's entire gap traces to exactly this — a plausible guess with no demonstrated process behind it.

Mistake 2: Naming only one possible cause instead of reasoning through several and how you'd distinguish between them. A single-cause guess doesn't demonstrate systematic thinking, even when it happens to be correct.

Mistake 3: Stating a hypothesis without explaining how you'd confirm or rule it out. An unconfirmed hypothesis is indistinguishable from a lucky guess to an interviewer evaluating your reasoning.

Best Practices​

Practice 1: Always ask narrowing questions before proposing a specific cause. This is the single practice that turns "the app is slow sometimes" from an impossible guessing game into a tractable investigation.

Practice 2: Reason through multiple possible causes at different layers before committing to one. This demonstrates the same systematic discipline Database and Performance Defect Investigation already teach, applied conversationally.

Practice 3: State how you'd confirm or rule out your hypothesis, not just what you suspect. This makes your reasoning process evaluable, not just your final guess.

From the Field

A candidate given the prompt "customers report occasionally seeing someone else's account data" immediately asked: "is this happening after a specific action, like navigating quickly between pages, or does it seem random?" Learning it correlated with fast navigation, they reasoned aloud toward a caching or session-handling issue rather than a data-layer defect — a systematic narrowing that led directly to the actual cause (a shared cache key not properly scoped per user) in an interview the candidate had no prior knowledge of the real system's architecture for.

Senior QA Insight

A newer candidate treats a root-cause question as a trivia question with one correct answer to find. A senior candidate treats it as a demonstration of process — the specific final cause matters far less than whether the interviewer watched a systematic narrowing happen, because that process is what transfers to a real, unfamiliar system on the job.

Mini Challenge​

Scenario: You're told, "some users report their shopping cart occasionally empties itself." Nothing else is specified.

Your task: Write the first three narrowing questions you'd ask before proposing any specific cause.

Key Takeaways​

  • Ask narrowing questions before proposing a specific cause — this turns a vague symptom into a tractable investigation.
  • Reason through multiple possible causes at different layers, not a single guess.
  • State how you'd confirm or rule out your hypothesis, making your reasoning process evaluable.
  • The specific final cause matters less than whether your process was systematic and would transfer to an unfamiliar system.

What You Just Learned​

  • Why asking narrowing questions before proposing a cause is the foundation of a strong root-cause interview answer
  • How to reason through multiple possible causes at different layers, reusing Database and Performance Defect Investigation's own discipline
  • Why stating a path to confirmation makes your hypothesis evaluable, not just your final guess
  • How a systematic process, demonstrated live, transfers more credibility than a single correct-sounding guess

Next: Test Strategy and "How Would You Test X" Interviews

Glossary​

No new terms are introduced in this module — every concept used above is defined in its linked source module.

Quick Revision​

Remember these five points:

✓ Ask narrowing questions before proposing any specific cause.

✓ Reason through multiple possible causes at different layers, not a single guess.

✓ State how you'd confirm or rule out your hypothesis, not just what you suspect.

✓ The specific final cause matters less than whether your process was systematic.

✓ A demonstrated process transfers to unfamiliar systems — a lucky guess doesn't.