To be honest, I didn't believe in the FizzBuzz situation when I read it. I didn't believe that it was possible to exist such a group of programmers who couldn't do a simple code like that.
Assuming such a group doesn't exist, I'm all for harder problems, harder than the one presented.
But assuming the group exists, and assuming, as I did, that the problem presented tries to weed out its members, I just though something that "hard" wasn't needed.
But of course, the point of an interview is to identify the good, not the bad, so harder problems would do just fine as well in ruling out the bad.
But the whole point of the article was a user's doubt in being able to pass a FizzBuzz kind of problem. For that, something harder than the problem presented may probably not be embarrassing at all to fail at.
>But of course, the point of an interview is to identify the good, not the bad, so harder problems would do just fine as well in ruling out the bad.
Yes, and no. Hard problems, being hard, mean that you don't expect all the good programmers to pass them, but to see how they think around them. And some people are able to talk the talk without walking the walk.
It's better to have an easy problem and a hard one. The easy one weeds awfully bad people, the hard one helps you find the good among the rest.
Assuming such a group doesn't exist, I'm all for harder problems, harder than the one presented.
But assuming the group exists, and assuming, as I did, that the problem presented tries to weed out its members, I just though something that "hard" wasn't needed.
But of course, the point of an interview is to identify the good, not the bad, so harder problems would do just fine as well in ruling out the bad.
But the whole point of the article was a user's doubt in being able to pass a FizzBuzz kind of problem. For that, something harder than the problem presented may probably not be embarrassing at all to fail at.