Bug squash: An underrated interview question

Perceived Benefits of Bug-Squash Interviews

• Seen as much closer to real work than LeetCode / algorithm puzzles or pure whiteboarding.
• Highlights core skills: reading unfamiliar code, forming/debugging hypotheses, using tooling, and reasoning from failing tests to fixes.
• Often feels more engaging and “fun” to some candidates, especially those with production experience.
• Reported as a strong “weed‑out” / minimum‑bar test, similar to FizzBuzz: if someone can’t debug a small, well‑scoped bug, that’s a strong negative signal.
• Allows observation of editor/tool fluency, test‑driven thinking, and communication of a debugging process.

Stress, Fairness, and Candidate Diversity

• Many note that interviews are inherently stressful; some say bug‑squash is still less stressful than LeetCode, others say it’s stressful in a different way.
• Concern that this format selects for people who already have multiple offers or are practiced at interviewing, and against those under financial pressure, with anxiety, or disabilities.
• Debate over whether hiring should intentionally select for “working well under interview stress” vs minimizing artificial stress to better approximate day‑to‑day performance.
• Some argue LeetCode disproportionately hurts older engineers (less time to grind) and people with obligations; others dispute that age effect.

Implementation Details: Environment, Language, Time

• Setup costs are a recurring complaint: cloning repos, dependency hell, IDE config, slow laptops can eat much of the interview.
• Proposals: pre‑packaged environments, cloud dev environments, or online sandboxes vs “bring your own tools.”
• Screen‑sharing raises privacy concerns; some prefer constrained windows or remote environments over exposing a full personal desktop.
• Disagreement on language choice:
  • One view: let candidates use any familiar language to measure debugging, not syntax.
  • Another: using the company’s main language is a valid and useful filter, especially where language‑specific performance or tooling matters.

Signal Quality and What’s Actually Measured

• Supporters say it gives “remarkably high signal” on practical competence and debugging approach (hypothesis → test → refine), even if the bug isn’t fully fixed.
• Critics see high randomness: bug difficulty varies, code style mismatches can confuse, and you may learn only “can they fix this one bug.”
• Concern that candidates can over‑ or under‑estimate their performance; some think clear self‑assessment is good, others worry it can tank confidence mid‑loop.
• Some skepticism that “cheating is indistinguishable from skill”; others argue you can still detect shallow understanding via probing questions.

Alternatives and Variants

• Variants mentioned:
  • Code review of a bad PR.
  • “Tell me about a bug you solved” walkthrough (with debate over recall/memory issues).
  • Write tests for a small function and infer edge cases.
  • Mini work‑sample tasks (small feature, perf issue, or prod‑like incident).
• Several emphasize that debugging exercises should be one component among multiple structured, level‑appropriate questions, not the sole gate.