[Nursie]

"how the hell could these same people who fail fizzbuzz write production code in previous companies?"

Maybe they had a lot of supervision, or were someone that could talk a good game to management but didn't deliver, or maybe they just fiddled around with minor stuff in other folks' code.

While experience is obviously a really good thing and a useful thing, if they can't write fizzbuzz you'd have to re-evaluate that experience in the light of new knowledge.

[ssebro]

I think you missed my point. I'm saying that fizzbuzz is very, very unlikely to be something you should use for evaluating someone's experience.

What I'm pointing out is a fundamental problem with coding problems.

FizzBuzz is a relatively simple problem to solve, so if fizzbuzz fails as a test for coding ability, then it's fairly likely that all coding problems fail.

There's are probably better metrics (faster, more uniform, etc) that you could use to figure out how good a coder is.

For example, one thing I've noticed is that I'm fairly aware of the skill levels of everyone I've ever worked with. I think it might be interesting to see how peers rate each other (A players can tell A players, and so on)- maybe that would be the metric that's most useful. All I know is that FizzBuzz probably isn't it.

One last thing I need to add: the people who are dramatically more productive coders are not always dramatically more productive because they code faster or better. It's often because they enact/enable processes that amplify the other developers. (e.g. the developer who pushes the company to have a hackathon, or the dev who creates machine images preconfigured for deploying test and dev builds).

[Nursie]

This isn't about a metric of how good a coder is though, it's an absolute minimum, it's a bar to pass, it's a lowest-common-denominator filtering mechanism - can you solve a trivial problem in a generous amount of time?