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.
How do they expect to do their jobs ?
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.
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.
I agree it's a good starting point, but surely it's still just getting rid of the ridiculously bad programmers rather than anything else.
main()
{
int i;
int ncounters = 2;
int counters[2] ;
int presets[2] = { 5, 3};
int n; // number of counters that tripped
int j;
char * strings[2] = { "fizz", "buzz" };
// first time, copy presets to counters
for (j=0;j<ncounters;j++) {
counters[j] = presets[j];
}
for (i=1;i<=100;i++) {
n = 0; // reset number of counters that have zeroed
for (j=0;j<ncounters;j++) {
counters[j] = counters[j] - 1;
// output relevant string when counter trips
if (counters[j] == 0) {
// separate strings by dashes if more than one counter trips
if (n != 0) {
printf("-");
}
n++;
counters[j] = presets[j];
printf("%s",strings[j]);
}
}
// no counter tripped, just output the number
if (n == 0) {
printf("%d",i);
}
printf("\n");
}
}
No modulo operations.
By asking the question that way you'd get solutions that you're not really looking for.
int c3 = 1;
int c5 = 1;
for ( int i = 1; i <= 100; i++, c3++, c5++ ){
if ( c3 == 3 ){ printf( "FIZZ" ); c3 = 0; }
if ( c5 == 5 ){ printf( "BUZZ" ); c5 = 0; }
if ( c3 && c5 ){ printf( "%d", i ); }
}Elegant solution, but fails to meet the problem specification.
Now if they are actually struggling for 10 minutes, that's another matter.
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.
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.