Bug squash: An underrated interview question
Many engineers argue that “bug squash” interviews—where candidates debug a failing test or small codebase—are a more realistic and informative alternative to algorithmic whiteboard or LeetCode-style questions. Supporters say these exercises better reflect everyday work, reveal how people navigate unfamiliar code and tools, and are harder to fake, while critics highlight issues of stress, environment setup, language bias, and the risk of turning debugging into yet another gotcha. Underneath the specific format, commenters focus on broader hiring goals: balancing fairness to juniors and seniors, avoiding over‑indexing on interview performance under pressure, and designing processes that actually identify good long‑term teammates rather than just strong test takers.
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.