Live data from Hacker News

Fizzbuzz, Interviews, And Overthinking

dave.fayr.am

51–60 of 115 posts

Re: Fizzbuzz, Interviews, And Overthinking

#51
post #30

Earlier quoted context omitted.

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 com…

I'd like to understand more that second point. How is Maybe not morally equivalent to a conditional? If my ifs were in a separate function that would also work, no?

Re: Fizzbuzz, Interviews, And Overthinking

#52
post #15

We're five years into this, and here's yet another weekly column from a person who has just heard about it and is champing at the bit to prove both he can write FizzBuzz and all the other implementations are not as good as his. It will be a miracle if this thread doesn't turn into a chain of "even better" solutions, like all the other threads that came before it. In this week's installment, the variation where it is…

I would prefer to force candidates to implement FizzBuzz in a language invented solely for purposes of that interview (and which will never be used again). This places all candidates on the same level. It's probably a good thing I don't interview people for programming positions...

You have so little time in an interview to learn so much you can't afford to lose the time to both learn whether they can do FizzBuzz (or whatever other problem) and whether they can manipulate some language of interest, when you could be learning both

The purpose of an interview isn't to be abstractly "fair", it's to find the best candidates for the job. You choose what "best" is (which is to say, please don't put words in my mouth about "only interviewing for the exact skillset" or whatever... you choose what is best, whatever that is). My preferred approach is to give the problem, then let the candidate write in whatever language they choose. If they flail in their putatively favorite language with which they've putatively been working for 4 years... well... I've certainly learned some very important things in those few moments.

Re: Fizzbuzz, Interviews, And Overthinking

#53
post #13

Earlier quoted context omitted.

I honestly don't understand why that's crazy. Empty string evaluates as falsey, so the "or" picks the 10, which is obviously equal to 10. Or am I missing something?

It just seems like a bad choice. The empty string being falsey is... very arbitrary to me. It seems like it's strictly a perl legacy thing that should be (but cannot be) reconsidered. About as far as I am willing to go is nil punning.

> The empty string being falsey is... very arbitrary to me.

It's extremely useful in a lot of contexts. The basic logic is that an empty string is an empty container, and empty containers are false, so you can test for them more easily.

Re: Fizzbuzz, Interviews, And Overthinking

#54
post #43

Earlier quoted context omitted.

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."

It's a different kind of pressure though.

Re: Fizzbuzz, Interviews, And Overthinking

#55
"When you really boil it down to its implementation, FizzBuzz is something of an irritating program. I’m not sure how much the author of the problem really thought about FizzBuzz, but it turns out it’s difficult to express well with the tools available to most imperative programming languages..."

Nonsense.. you call a simple loop with a couple conditions difficult?

Re: Fizzbuzz, Interviews, And Overthinking

#56

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.

To be fair though, reversing a string is not the kind of thing a lot of people deal with - there's usually a library function. Now they should be able to puzzle it out, but if it takes them a moment I'd be generous because I at least put it into the box of "that sounds easy, but oh wait a minute it's slightly different from my usual dev pattern".

To put it another way - when I code it's rarely different from writing to me; code is simply an expression of thought. But when you ask me to do something that seems a bit artificial (reverse a string) it's like asking me to write a haiku - I can do it, but give me a moment while I count out my syllables.

Re: Fizzbuzz, Interviews, And Overthinking

#57
post #43

Earlier quoted context omitted.

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."

It's a different kind of pressure though.

Explain. If you can't produce a god damned string reversal function in 10 minutes, why would I believe you can produce a bug fix to your own, complex code in a few hours? That's what interviewers are considering: the interview is a proxy to see if you can come close to the requirements of the job.

Re: Fizzbuzz, Interviews, And Overthinking

#58
The Ruby example that you recommending hiring because of, is overkill. Here is a better Ruby example:

    (1..100).each do |i|
      o = ""
      o.concat("Fizz") if i % 3 == 0  
      o.concat("Buzz") if i % 5 == 0  
      o.concat("Bazz") if i % 7 == 0  
      o.concat(i.to_s) if o.empty?  
      puts o
    end

Re: Fizzbuzz, Interviews, And Overthinking

#59
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'…

Just for fun, another variant - separating logic from data and trying to be pretty stock python.

    cases = [(3, "Fizz"), (5, "Buzz"), (7, "Bazz")]

    for i in range(110):
        pr = ''.join([v[1] * (i % v[0] == 0) for v in cases])
        print pr or i

Re: Fizzbuzz, Interviews, And Overthinking

#60
post #51

Earlier quoted context omitted.

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 com…

I'd like to understand more that second point. How is Maybe not morally equivalent to a conditional? If my ifs were in a separate function that would also work, no?

> How is Maybe not morally equivalent to a conditional?

Maybe is a way to represent conditionals that is amenable to higher order patterns. if-then-else conditionals are simply that, whereas Maybe is amenable to Monad, Monoid, and Applicative functor laws. So when we pull out mconcat or or mappend, we're actually talking about a higher order pattern.

As I mentioned in the article, we could take that same fizzbuzz code and modify it in many ways under the monoid rules. For example, a different harness in the main function could use Map String Integer and completely change the behavior with the same fizzbuzz function.

Post reply on HN