Whiteboard interviews are a test of obedience, not intelligence

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.