Whiteboard interviews are a test of obedience, not intelligence
Whiteboard and LeetCode-style coding interviews are criticized as selecting for people who rehearse puzzle patterns and tolerate stressful hoops, rather than those who best match real-world engineering work. Commenters counter that some form of live coding is still needed to filter out candidates who “talk the talk” but can’t program, yet agree that many processes are too hard, too divorced from day-to-day tasks, and biased toward those with time to grind. Alternatives raised include shorter, more realistic exercises, probationary or contract-to-hire arrangements, and interview formats that let candidates use their normal tools and demonstrate how they actually solve problems.
What whiteboard / coding interviews actually test
- Many see basic whiteboard problems (e.g., FizzBuzz-level) as necessary to verify someone can actually code; some interviewers report candidates with strong talk but unable to write simple loops.
- Others argue modern processes (LeetCode-style, “2 hards in 45 minutes”) mostly measure prior grinding and pattern recognition rather than real-world problem solving or day‑to‑day skills.
- Several distinguish between very simple screens (“has seen a computer before”) and algorithmic puzzles that rarely appear in normal work.
Obedience vs competence
- Some agree with the article’s framing that high‑ceremony, puzzle‑heavy interviews primarily select for people willing to jump through hoops and follow established rituals.
- Others reject the “obedience” framing as dramatic: they see the goal as risk management and standardization, not subservience.
- There’s a recurring theme that big companies want a small group of idea‑generators and a large group of implementers; whiteboard tests help staff the latter.
Interview reliability, bias, and structure
- Unstructured “just talk about your experience” interviews are criticized as low‑signal and highly biased toward charm and rapport.
- Structured technical questions, ideally the same for all candidates, are defended as fairer and easier to justify to management/HR.
- Some interviewers note rampant exaggeration, plagiarism of take‑homes, and bootcamp‑produced “portfolio” projects, which pushes them toward standardized live coding.
Alternatives: probation, contract‑to‑hire, take‑homes
- Many advocate probationary periods, apprenticeships, or contract‑to‑hire as “try before you buy,” but:
- Candidates bear higher risk (quitting a stable job, healthcare concerns, gaps if fired early).
- Companies gain far more from cheap trials than individual candidates do.
- Take‑home tasks are divisive:
- Critics cite unpaid labor, time asymmetry, and irrelevance to the job.
- Supporters see them as more realistic and less anxiety‑inducing than live coding, if time‑boxed and modest.
Practical interview design suggestions
- Allow coding in a familiar IDE with internet access, not on a whiteboard.
- Use small, realistic tasks (simple data transforms, text game, API design) and then discuss refactoring, trade‑offs, and architecture.
- Consider offering candidates a choice of assessment style (coding exercise vs experience‑based discussion) to avoid pigeonholing and to help those with limited past opportunities.