The solution
In February 2013, 37signals published "Why we don't hire programmers based on puzzles and tricks" on its company blog, and the post hit Hacker News the same day. The discussion opened with the failures of trivia-driven hiring: a Microsoft interviewee had prepped from How Would You Move Mount Fuji? and was asked to write C's strcmp() from memory, Amazon interviews leaned on Big-O recitation and "count all the stars in the universe," and interviewers often just searched for "programming interview questions" without asking what the answers proved.
37signals' counter-move was to reject the genre outright: no hiring based on puzzles and tricks. Commenters described the alternative as "trying them out for size" — putting candidates in front of actual work rather than synthetic brainteasers. Practitioners pushed the same direction with concrete mechanisms: ITA Software found in-person quizzing far less useful than reading code someone had written offline, and one hiring manager built interviews around a day of pairing that asked three questions — can they do the job, do they fit the team, and can they adapt when the game changes?
The two screens test different things. Trivia and brainteasers are coachable — a whole lore of expected questions and prep books exists — and they select for recall and composure under artificial pressure. Commenters noted that insight-style thinkers can fail an hour of procedural questioning yet do well over a longer real task, and a candidate mid-panic-attack could fail FizzBuzz while remaining a fine programmer. Observed work answers the question trivia cannot: how the person reads an unfamiliar codebase, spots mistakes, writes code, and works with strangers.
What it achieved
Drop the puzzle gauntlet: try candidates out for size and let real work, not recall, decide hires
Why it worked
Puzzle screens are coachable: a lore of expected questions and prep books lets candidates rehearse, so the test measures preparation and memory, not job ability.
Trying candidates out for size observes the actual job — reading a real codebase, spotting mistakes, writing code and collaborating — evidence no brainteaser can produce.
Artificial pressure distorts results: insight-style and anxious candidates can fail one-hour puzzles yet perform well on real work over a longer span.
The public stance signals what the company values and opened a 442-comment debate that pressure-tested the idea in public.
What can be applied
When a hiring screen measures preparation more than the job does, change the evidence: try candidates out on real work and let performance decide
Aftermath
The essay drew 648 points and 442 comments on Hacker News, making 37signals the anti-puzzle side's reference point. Defenders said hard brainteasers reveal problem solving under pressure; opponents countered with a day of pairing, FizzBuzz as a cheap negative filter, and ITA's practice of reading offline code. The trial approach was called good but impractical for less-known employers that still need puzzles as a talent magnet. No measured hiring outcome appears in the discussion; the effect was normative — "trying them out for size" became the main alternative to trivia interviews.
FOLLOW THE EVIDENCE
The sources
- Why we don't hire programmers based on puzzles and tricks | Hacker News news.ycombinator.com