Hacker News Reader

Comment by miguelpais | Hacker News Reader

Exactly. The comment I replied to was asking for something less trivial, while this is probably all you have to do to identify the candidates who can't code.

The FizzBuzz problem is at least one order of magnitude easier than this, and still is able to rule out a great part of the candidates (by time limits, according to CodingHorror, not exactly by not being able to code it). The good thing with this test is that you can actually get a glimpse of the ability of the candidate to come up with an efficient solution and identify its complexity.

View on HN

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.

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.

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 ?

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.

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.

When I first sat down to write FizzBuzz for kicks I spent a few minutes trying to think of an elegant or clever solution before writing the obvious answer. I think I would be similarly on guard in an interview situation. I'd say 1 to 10 minutes is easily acceptable accounting for over thinking.

Now if they are actually struggling for 10 minutes, that's another matter.

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.

Weird example, but fine, we can reduce the number of modulo operations if that is the one with the 'cost', but that's not very realistic given that we're printing stuff to stdout, but if we take your premise as true and we optimize for the cost of the modulo operator you would get silly solutions like this:

  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");
	}
  }

Forgive the lack of comments and the hardcoded number of strings.

No modulo operations.

By asking the question that way you'd get solutions that you're not really looking for.

The short version

  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 ); }
  }

You're missing the needed printf("\n"); at the end of the loop.

Elegant solution, but fails to meet the problem specification.

Hehe, compact.

Or you could just ask "Do you know what a lookup table is", and "Can you write 15 entries into an array and cycle through them" ;)

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.

I'm guessing a lot of these people end up working by doing a lot of copy & paste and a trial & error approach to coding.

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.

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

Reply on news.ycombinator.com