Hacker News Reader

Comment by jacquesm | Hacker News Reader

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.

View on HN

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.

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.

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

Hehe, compact.

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

Elegant solution, but fails to meet the problem specification.

Reply on news.ycombinator.com