Live data from Hacker News

Fizzbuzz, Interviews, And Overthinking

dave.fayr.am

41–50 of 115 posts

Re: Fizzbuzz, Interviews, And Overthinking

#41

Forget Fizzbuzz, we get candidates that cannot reverse a string (in their language of choice). A friend of mine just told me he uses the question "What is the hex number that comes after 'F'" as his first "weed-out" technical question. It boggles the mind.

They cannot reverse a string even using the API call? If so are these people who have held down a programming job before?

I assume the question is something along the lines of "Implement a strrev in the language of your choice", not "Use the strrev equivalent in the language of your choice".

Re: Fizzbuzz, Interviews, And Overthinking

#42
post #14

I recently challenged people to codegolf fizzbuzz ( http://swizec.com/blog/fizzbuzz-without-ifs-in-90-char-i-wil... ) The Haskell solution was really cool: [max(show x)(concat[n|(f,n) This is much simpler and it looks easier to extend as well.

I wrote a JS one-liner solution the other day, though JS isn't quite as concise as Haskell:

function fizzbuzz (n) { return new Array(n + 1).join().split(',').map(function (j, i) { return (i % 3 ? '' : ' fizz') + (i % 5 ? '' : ' buzz') || ' ' + i; }).slice(1).join().slice(1); }

185 characters

Edit: If I move from a general solution to only 1-100 and remove spaces and semicolons:

new Array(101).join().split(',').map(function(j, i){return (i%3?'':' fizz')+(i%5?'':' buzz')||' '+i}).slice(1).join().slice(1)

Down to 126, but a lot of that is related to precision with the whitespace and handling a JS quirk with map on undefined values; without the extra joins/split/slices, it goes down to 83 characters (but also doesn't work).

Re: Fizzbuzz, Interviews, And Overthinking

#43

Forget Fizzbuzz, we get candidates that cannot reverse a string (in their language of choice). A friend of mine just told me he uses the question "What is the hex number that comes after 'F'" as his first "weed-out" technical question. It boggles the mind.

Because I tend to get really nervous in interviews and consequently don't interview all that well most of the time, I try to be sensitive to people like me. I prefer to start very simple and sort of gradually increase the pressure until I can find a backing off point.

If you cannot reverse a string under pressure, you are likely unqualified for the job you are applying for. At least in my job, there is often more pressure than "write a string reverse function in any language you like in 10 minutes."

Re: Fizzbuzz, Interviews, And Overthinking

#44

I agree that Fizzbuzz can be a more interesting example of how to write code without repetition. While the author suggests that languages such as Haskell provide a unique advantage, the deciding question seems to be the availability of pre-built abstractions. Consider the following solution in Python: for i in xrange(1,101): print (('' if i%3 else 'Fizz')+('' if i%5 else 'Buzz')) or i or the even more general: mappin…

Breaks the spec: 'Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.'

Actually, this spec is ambiguous, too. For multiples of five, do we print the number AND "Buzz" or just "Buzz" ? Similarly for multiples of 15.

I thought the OP was a joke, BTW. It had to be, doesn't it? If somebody thought of this problem and solution the way the job candidate did, why on earth would one want to hire somebody who loves complexity for its own sake?

To me, the following is the clearest way to express this (in C anyway). I suppose it says a lot about me! lol

#include #define FALSE (0) #define TRUE (!FALSE)

int main(){

  for(int i=1; i 

Re: Fizzbuzz, Interviews, And Overthinking

#46
post #30
post #25

cases = ( (3, 'Fizz'), (5, 'Buzz'), (7, 'Bazz'), (11, 'Boo'), (13, 'Blip'), ) for i in range(1, 101): out = [] for c in cases: if i % c[0] == 0: out.append(c[1]) if out: print ''.join(out) else: print i Edit: not to detract from the post's point, I think it's valid. Monoids are cool and all but simple counting arguments can take you a long, long, long, way when case analysis fails you.

Precisely. The Ruby solution author quotes as ideal and impressive seems way overblown to me. And I don't buy that ,,it would probably be dismissed as “overly complex” by younger programmers'' because it is exactly what I would consider perfect approach... few years ago. Since then I learned the value of simplicity, and abstractions with adequate flexibility. That Ruby code exhibits neither.

Firstly, the ruby code was produced (admittedly from my memory) from someone on the tail end of a 5 hour interview process, of which I was not the first technical interviewer. It is exceptional in that context.

Secondly, I feel like you (and aristus in his/her code snippet above) missed the secondary point of my post. Please consider that monoids and Maybe are capturing a higher level pattern in a way that we can compose. To write a classical for loop and toss in conditionals and whatnot is to descend to exactly the same depths as the Ruby code you say is not "simple".

Basically, you say one is "simple" and the other is not is you picking up on what you're comfortable with in Python. Both are complex in the same way; the Python just makes a marginally better choice in how to represent the rules (as data).

If you'd like to see how I'd take that piece of code and golf it to include that feature, I'm happy to oblige. I originally was going to post that, but cut it because the post was already overlong and the point is to explore the unusual patterns fp is capturing.

Here is my bullshit golfing derivative, though:

    {-# LANGUAGE MonadComprehensions #-}

    module Main where
    import Control.Applicative
    import Data.Monoid
    import Data.Maybe
    import System.Environment

    factors = [(3, "fizz"), (5, "buzz"), (7, "bazz")]

    rules = [\i -> [res | i `rem` fac == 0] | (fac,res)  pure i)

    main = do
      upTo 

Re: Fizzbuzz, Interviews, And Overthinking

#47
post #25

cases = ( (3, 'Fizz'), (5, 'Buzz'), (7, 'Bazz'), (11, 'Boo'), (13, 'Blip'), ) for i in range(1, 101): out = [] for c in cases: if i % c[0] == 0: out.append(c[1]) if out: print ''.join(out) else: print i Edit: not to detract from the post's point, I think it's valid. Monoids are cool and all but simple counting arguments can take you a long, long, long, way when case analysis fails you.

This can be edited down to six lines with a simple trick: a Python string multiplied by True will return itself, and multiplied by False will return the empty string.

  for i in range(110):
      pr = ""
      pr += "Fizz" * (i%3 == 0)
      pr += "Buzz" * (i%5 == 0)
      pr += "Bazz" * (i%7 == 0)
      print (pr if pr else i)
I iterated over range(110) to show that it handles the "FizzBuzzBazz" case correctly.

EDIT: Or we could use lambdas as OP's Ruby code did; this might be more maintainable...

  cases = [
      lambda n: "Fizz" * (n%3 == 0),
      lambda n: "Buzz" * (n%5 == 0),
      lambda n: "Bazz" * (n%7 == 0) ]

  for i in range(110):
      pr = ""
      for case in cases:
          pr += case(i)
      print (pr if pr else i)
That's nine nonblank lines.

Re: Fizzbuzz, Interviews, And Overthinking

#48
post #14

I recently challenged people to codegolf fizzbuzz ( http://swizec.com/blog/fizzbuzz-without-ifs-in-90-char-i-wil... ) The Haskell solution was really cool: [max(show x)(concat[n|(f,n) This is much simpler and it looks easier to extend as well.

In JS:

i=0;while(i++Pardon the global.

Re: Fizzbuzz, Interviews, And Overthinking

#49
post #18

I agree that Fizzbuzz can be a more interesting example of how to write code without repetition. While the author suggests that languages such as Haskell provide a unique advantage, the deciding question seems to be the availability of pre-built abstractions. Consider the following solution in Python: for i in xrange(1,101): print (('' if i%3 else 'Fizz')+('' if i%5 else 'Buzz')) or i or the even more general: mappin…

My "I'm going to hell, but that's okay" C version: #include #include #define when(mod, msg) do { if((i mod) == 0) { fputs(#msg, stdout); *hit = true; } } while(0) #define through ; i Super extensible!

My going to hell version:

https://github.com/rcs/fizzbuzz/blob/master/bitwise.c

Choice excerpts:

  char fmts[] = "FizzBuzz%u";
and

      // Default start is 8
    unsigned int start =
      // Shift down 1 if div5
      (8 >> DIV5(mask))
      // Shift down another 4 if div3 */
      >> ( DIV3(mask) 

Re: Fizzbuzz, Interviews, And Overthinking

#50
post #40

Earlier quoted context omitted.

Thanks! What sort of surprised me as I shopped my copy around and showed people the python-add-one-factor example is that even programmers I consider experts didn't realize how quickly the conditional cascade blows up. It's easy to miss. And I looked around for people to mention this in blog posts, but almost no one does. So I feel like there's a bit of life left in the old fizzbuzz yet.

I think the non-blown cascade is exactly what makes fizzbuzz aggravating. With three noises, the linear solution clearly dominates. With two, the exponential is actually shorter -- but feels unclean.

I've been programming some game servers, and I have the same problem with guaranteed two-player games; I feel dirty hard-coding the logic to assume two players, yet making it general enough for N players makes it absurdly more complex for no gain, which is a net loss.

(And yes, before anyone pops in, these are guaranteed two-player games. Of all the rules of the games in question which have changed over time, that is the one rock-solid constant which will not change in this application.)

Post reply on HN