Tech hiring leans hard on competitive-programming-style puzzles, LeetCode grinds, timed algorithm challenges, whiteboard brainteasers, on the assumption that the people who ace them make the best engineers. One of Google's most respected directors, Peter Norvig, observed the opposite: among people good enough to get hired, being a competition winner correlated negatively with doing the job well.
Key Takeaways
- Google's Peter Norvig observed that winning programming contests correlated negatively with on-the-job performance, among Google hires (Norvig's observation).
- His explanation: contest winners are trained to crank solutions out fast, while the job rewards being reflective and careful (Norvig).
- Important caveat: this is within an already-elite pool (people who passed Google's bar), so it's not a knock on problem-solving itself (analysis).
- Optimize hiring for how people build real software, not how fast they solve puzzles.
What Norvig Observed
Peter Norvig, a director of research at Google and co-author of the standard AI textbook, said plainly that being a top competitive programmer was a negative signal for job performance at Google. His reasoning: competition trains you to produce a solution as fast as possible, and the job rewards the opposite temperament, going slowly, being reflective, and making sure the thing is actually right (Norvig's observation). The habits that win contests, speed over caution, clever over clear, can work against you in a codebase other people have to maintain.
To be precise, this is an observation rather than a controlled study with a published coefficient, and it comes with a big caveat, below. But it comes from someone with a great deal of hiring data and a strong reputation for rigor, and it lines up with what many engineering leaders see.
The Important Caveat
Read this carefully, because it's easy to over-claim. Norvig's observation is about people who already cleared Google's very high bar, the top sliver of programmers. Within that already-elite group, contest skill correlated negatively with job performance (analysis of the claim). That does not mean competitive programming makes you a worse engineer in general, or that problem-solving ability doesn't matter, it obviously does. The honest reading is narrower and more useful: once you've established someone can code, their contest ranking tells you little about how well they'll do the actual job, and optimizing for it can select for the wrong temperament.
Why the Skills Diverge
Competitive programming and professional software engineering reward different things. Contests reward solving a well-specified problem alone, fast, with throwaway code that runs once. The job is mostly the reverse: figuring out what the poorly-specified problem even is, writing code other people will read and change for years, collaborating, and being careful because mistakes reach production. A person optimized for the first can be actively miscalibrated for the second, prone to over-clever, hard-to-maintain solutions produced quickly (assessing competitive programmers for industry).
| Competitive programming | Professional engineering |
|---|---|
| Well-specified problems | Ambiguous, evolving problems |
| Solo, timed, fast | Collaborative, sustained |
| Throwaway code | Code maintained for years |
| Clever wins | Clear wins |
A Concrete Version
A team hires the candidate who crushed the timed algorithm rounds. On the job, they write dense, clever, one-pass solutions that work and that nobody else can safely modify, they optimize for the wrong thing, because that's what got rewarded for years. Meanwhile the candidate who was merely solid on the puzzles but asked great clarifying questions and wrote boring, readable code turns out to be the stronger hire. Norvig's point, in miniature: the puzzle score pointed the wrong way.
What to Screen For Instead
The lesson lines up with the Google hiring research that found brainteasers useless: stop over-indexing on puzzle speed and measure the actual job. Give candidates realistic problems in a realistic setting, and watch how they handle ambiguity, how readable their code is, how they collaborate and communicate. That's the heart of a structured, work-sample-based process, and it's what our vetting is built around, evaluating how people build real software, not how fast they solve contest puzzles. See available engineers.
Frequently Asked Questions
Does competitive programming predict job performance?
Google's Peter Norvig observed a negative correlation among Google hires: contest winners tended to do worse on the job, because contests reward fast solutions while the work rewards being careful and reflective.
Does that mean competitive programmers are bad engineers?
No. The observation is within an already-elite pool that cleared Google's bar, so it's about a narrow group, not a general knock. Strong problem-solving matters; contest ranking just doesn't predict job success well.
Why do the two skills diverge?
Contests reward solving well-specified problems alone and fast with throwaway code. The job rewards figuring out ambiguous problems, writing maintainable code others will change, and collaborating carefully over time.
What should we screen for instead?
How people build real software: handling ambiguity, writing readable code, collaborating, and communicating. Use realistic work samples scored on a rubric rather than timed algorithm puzzles.
The Bottom Line
Puzzle speed and building good software are different skills, and Google's Peter Norvig observed that among strong candidates, contest wins can even point the wrong way. Once someone can clearly code, their LeetCode ranking says little about how well they'll do the job. Screen for how people handle real, ambiguous, collaborative work, and you'll hire for the temperament that actually ships.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
