16 ms·

In that case I completely agree that trivial problems would weed out the candidates that can't program, however who says you can't give something harder than Fi

In that case I completely agree that trivial problems would weed out the candidates that can't program, however who says you can't give something harder than FizzBuzz? Also, FizzBuzz is now so common on the web that a simple search would produce numerous solutions for those that can't program, allowing them to get through to an interview. Assuming this is your yard-stick.

mootothemax 16y ago
I always thought that you should use different words to prevent easy googling? The test remains the same, but with, say, BaaLamb or CowTip.
miguelpais 16y ago
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.
- GreenNight 16y ago
  >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.
ig1 16y ago
I'm the inventor of the fizzbuzz problem and I kept using the question for a long time after it became popular and I didn't see a single candidate (out of maybe ~100) who'd just memorized the answer. I'm guessing the kind of people who can't program are generally the kind that don't do indepth background research/prep prior to interviews.
- jacquesm 16y ago
  That's just really sad, that there are people that would be interviewing for a coding position and it turns out they can't even do that in under a minute or so. How do they expect to do their jobs ?
  - starkfist 16y ago
    I got fizzbuzzed in an interview before I knew what fizzbuzz was. It took about a minute for me to think "what? you want me to do what? Why? ... Ok?" So I would say 1-10 minutes is acceptable.
    - jacquesm 16y ago
      I'd have a problem with being interviewed like that because the question is so simple I'd think they're pulling a joke or something. First thing I'd ask is where is the camera :) I can see how for a junior coding position this might be an appropriate question, say people fresh out of school, and then 1 to 10 minutes might be acceptable. But 4 modulo statements (or 3, if you think about the problem a bit longer) and a loop ? 10 minutes ? That's pretty slow. I understand there is a lot more to programming than coding up a simple solution like this but as problems come it is really a very simple one and if someone would take 10 minutes to put this together I'd be a bit worried about throughput, and probably about experience as well.
      - RiderOfGiraffes 16y ago
        With regards FizzBuzz, my follow-up goes a bit like this: Now suppose the modulo test is really expensive. Suppose we're doing something complicated with large records on disk and we want to do this is that's true, something else if the other is true, etc, etc, just as in FizzBuzz. How would you restructure your code so it's still obvious to a maintainer what it's doing, but so that it avoids doing more modulo operations than necessary. You see, all these trivial exercises can be used as starting points for deeper conversations about aspects of coding.

mootothemax 16y ago

I always thought that you should use different words to prevent easy googling? The test remains the same, but with, say, BaaLamb or CowTip.

miguelpais 16y ago

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.

GreenNight 16y ago
>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.

ig1 16y ago

I'm the inventor of the fizzbuzz problem and I kept using the question for a long time after it became popular and I didn't see a single candidate (out of maybe ~100) who'd just memorized the answer. I'm guessing the kind of people who can't program are generally the kind that don't do indepth background research/prep prior to interviews.

jacquesm 16y ago
That's just really sad, that there are people that would be interviewing for a coding position and it turns out they can't even do that in under a minute or so. How do they expect to do their jobs ?
- starkfist 16y ago
  I got fizzbuzzed in an interview before I knew what fizzbuzz was. It took about a minute for me to think "what? you want me to do what? Why? ... Ok?" So I would say 1-10 minutes is acceptable.
  - jacquesm 16y ago
    I'd have a problem with being interviewed like that because the question is so simple I'd think they're pulling a joke or something. First thing I'd ask is where is the camera :) I can see how for a junior coding position this might be an appropriate question, say people fresh out of school, and then 1 to 10 minutes might be acceptable. But 4 modulo statements (or 3, if you think about the problem a bit longer) and a loop ? 10 minutes ? That's pretty slow. I understand there is a lot more to programming than coding up a simple solution like this but as problems come it is really a very simple one and if someone would take 10 minutes to put this together I'd be a bit worried about throughput, and probably about experience as well.
    - RiderOfGiraffes 16y ago
      With regards FizzBuzz, my follow-up goes a bit like this: Now suppose the modulo test is really expensive. Suppose we're doing something complicated with large records on disk and we want to do this is that's true, something else if the other is true, etc, etc, just as in FizzBuzz. How would you restructure your code so it's still obvious to a maintainer what it's doing, but so that it avoids doing more modulo operations than necessary. You see, all these trivial exercises can be used as starting points for deeper conversations about aspects of coding.