# Systematic Debugging Quiz

## Question 1

What is the first step in systematic debugging?

A) Fix the most likely cause
B) Reproduce the bug consistently
C) Add more logging
D) Ask someone else

<!-- ANSWER: B -->
<!-- EXPLANATION: Without a reliable reproduction, you can't verify that your fix works. Reproducing first ensures you understand the problem and can test hypotheses. -->

## Question 2

You see: `TypeError: Cannot read property 'name' of undefined at Profile.jsx:18`. Where should you look first?

A) Line 18 of Profile.jsx — what is undefined?
B) The file that imports Profile.jsx
C) The backend API only
D) The browser console for more errors

<!-- ANSWER: A -->
<!-- EXPLANATION: The stack trace points to Profile.jsx:18. Something there is undefined when `.name` is accessed. Check what variable or prop is undefined at that line. -->

## Question 3

What does "binary search" mean in debugging?

A) Search for the word "binary" in the code
B) Halve the problem space (input, code, or history) to isolate the cause
C) Use a binary file editor
D) Restart the program repeatedly

<!-- ANSWER: B -->
<!-- EXPLANATION: Binary search in debugging means repeatedly halving — e.g., comment out half the code, test with half the data, or use git bisect to find the introducing commit. -->

## Question 4

Why is "rubber duck" debugging effective?

A) Ducks are good listeners
B) Explaining the problem out loud often reveals the bug before you finish
C) It's faster than using a debugger
D) It only works for simple bugs

<!-- ANSWER: B -->
<!-- EXPLANATION: The act of explaining forces you to articulate assumptions and logic. Often you spot the flaw while formulating the explanation. It works for bugs of any complexity. -->

## Question 5

What's wrong with adding a quick fix that hides the symptom?

A) Nothing — if it works, ship it
B) The root cause may cause other bugs; you also can't verify the fix
C) Quick fixes are always wrong
D) It makes the code harder to read

<!-- ANSWER: B -->
<!-- EXPLANATION: Symptom fixes (e.g., fallbacks) can hide the real bug, which may surface elsewhere. Without a repro, you can't verify the fix. Find and fix the cause when possible. -->

## Question 6

Drag these debugging steps into the correct order:

<!-- VISUAL: quiz-drag-order -->

A) Reproduce → Hypothesize → Test → Conclude → Fix
B) Fix → Test → Hypothesize → Reproduce
C) Hypothesize → Fix → Reproduce → Test
D) Test → Conclude → Reproduce → Hypothesize

<!-- ANSWER: A -->
<!-- EXPLANATION: Reproduce first to understand the problem. Form a hypothesis. Design and run a test. Conclude (confirm or reject). Fix the root cause. The cycle repeats if the hypothesis was wrong. -->

## Question 7

<!-- VISUAL: quiz-drag-order -->

Put these debugging steps in the correct order:

A) Conclude (confirm or reject hypothesis)
B) Reproduce the bug consistently
C) Fix the root cause
D) Hypothesize the cause
E) Test the hypothesis

<!-- ANSWER: B,D,E,A,C -->
<!-- EXPLANATION: First reproduce to understand the problem, then form a hypothesis, design and run a test, conclude based on the result, and finally fix the root cause. The cycle repeats if the hypothesis was wrong. -->

## Question 8

<!-- VISUAL: quiz-drag-order -->

Put these hypothesis-testing steps in the correct flow:

A) Observe the result
B) Form a falsifiable hypothesis
C) Design a test that would disprove it
D) If disproved, form a new hypothesis
E) If confirmed, fix the root cause

<!-- ANSWER: B,C,A,D,E -->
<!-- EXPLANATION: Form a falsifiable hypothesis, design a test that could disprove it, run the test and observe, then either form a new hypothesis if disproved or fix the root cause if confirmed. This scientific approach isolates the cause efficiently. -->