Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fizzbuzz, Interviews, And Overthinking

dave.fayr.am

Post reply on HN
Print view View original

111–115 of 115 posts

Re: Fizzbuzz, Interviews, And Overthinking

#111

Post by DanBC »

EnderMB wrote: post #88
borplk wrote: post #85

Earlier quoted context omitted.

Are you kidding? reversing a string in your language of choice is far too trivial. If you can't do it you really aren't ready to be working in the industry.

It's not about whether they can do it or not. It's about why knowing a skill that will take even a non-developer ten seconds to Google makes someone incapable of functioning as a developer. More often than not the people that spout that kind of nonsense are twenty-something junior developers that read a bit of HN and have decided that they know better than everyone else about what makes a good programmer. Why would y…

Being able to web-search the answer is good.

Being able to recognise the correct answer in the sea of dross that is search engine results pages is better.

Being able to take the correct answer, and adapt it to what you need, and plugging it into what you already have, is best.

Do you really want to employ people who say they have X years of experience doing something but who cannot do a very simple task in the choice of their language? That's not a stupid trick gimmick question - there's no "gotcha" there. Perhaps we're getting caught up on the specific "reverse a string". Substitute that for something relevant to maintaining and building on a shitty web app.

Re: Fizzbuzz, Interviews, And Overthinking

#112

Post by EnderMB »

adgar2 wrote: post #106
EnderMB wrote: post #104

Earlier quoted context omitted.

Bullshit. The only reason why people ask these things is because big software houses do so, and for some reason they think that their shitty web app needs a Google quality "rockstar developer". The difference between reversing a string and pulling data from a database are, literally, completely different tasks. The killer is that the latter is something that a candidate will do in a job. You're more than welcome to a…

> The difference between reversing a string and pulling data from a database are, literally, completely different tasks. The killer is that the latter is something that a candidate will do in a job. Why can't you do both? Seriously? Pulling data from a database is orders of magnitude harder to get right than reversing a string.

That's not the point. You have a finite amount of time in an interview, so why on earth would you ask a question regarding a meaningless skill that the candidate will use maybe once in their entire time at the company when you can ask something that, you know, might actually tell you if they're a good programmer or not.

Re: Fizzbuzz, Interviews, And Overthinking

#113

Post by koide »

KirinDave wrote: post #110
koide wrote: post #108

Earlier quoted context omitted.

I believe that efforts using trivial examples to show how complexity can be managed via certain abstractions are doomed to fail. And that's a pity, because it makes abstractions harder to explain in a proper context. You need an example where the complexity at least rears its ugly head before the abstraction starts to shine. For many people, especially those not familiar with it at the time of the reading, the simple…

> I believe that efforts using trivial examples to show how complexity can be managed via certain abstractions are doomed to fail. I've received 5 emails and about 10 tweets from people saying, "I think I understand monoids better because your tutorial sat at the right level of abstraction and overhead for me to get." So, I think I succeeded for 15 people. Which I am pretty damn happy about. Because whenever I write…

FWIW, you can count me in. I've understood monoids better thanks to your article.

My comment was not a jab at your article, but a comment on how hard it is to find the proper abstraction level.

And that I fully understand people who'd say it is making things more complex for its own sake, and I'm not sure it necessarily is because they don't want to learn.

Re: Fizzbuzz, Interviews, And Overthinking

#114

Post by ludovicurbain »

KirinDave wrote: post #93
ludovicurbain wrote: post #81

First of all a modulo is ultra expensive, one does not simply modulo 15 when they already modulo 3 and 5. The proper structure is if(3){if(5)}elif(5){}else{},unless anyone has a better proposition. While of course it is possible to define abstractions that handle fizzbuzzing anything for any number, it's clear that the monoid way is a bad overweight bloated approach. Second the example written is code bloat à la java…

This is another example of someone who I think looked at my code examples but didn't read the post. Fair enough, I guess. > While of course it is possible to define abstractions that handle fizzbuzzing anything for any number, it's clear that the monoid way is a bad overweight bloated approach. Why? It is not computationally expensive, and it avoids excess modulo operations. All the dispatching work gets figured out…

Bloated, as in, takes way too much space for what it is.

Additionally, it does _not_ avoid excess mod operations, _and_ the implementation is _broken_ because it won't print fizzbuzz for the 15.

Lastly, using lambda's and whatnot's just because you can is yet another form of inefficiency and completely obfuscates what the machine will do.

I mean to suggest that 1) it should be a much shorter read 2) it's inefficient, and wrong 3) one does not simply lambda everything.

Re: Fizzbuzz, Interviews, And Overthinking

#115

Post by KirinDave »

ludovicurbain wrote: post #114
KirinDave wrote: post #93

Earlier quoted context omitted.

This is another example of someone who I think looked at my code examples but didn't read the post. Fair enough, I guess. > While of course it is possible to define abstractions that handle fizzbuzzing anything for any number, it's clear that the monoid way is a bad overweight bloated approach. Why? It is not computationally expensive, and it avoids excess modulo operations. All the dispatching work gets figured out…

Bloated, as in, takes way too much space for what it is. Additionally, it does _not_ avoid excess mod operations, _and_ the implementation is _broken_ because it won't print fizzbuzz for the 15. Lastly, using lambda's and whatnot's just because you can is yet another form of inefficiency and completely obfuscates what the machine will do. I mean to suggest that 1) it should be a much shorter read 2) it's inefficient,…

> Bloated, as in, takes way too much space for what it is. > Additionally, it does _not_ avoid excess mod operations, _and_ the implementation is _broken_ because it won't print fizzbuzz for the 15.

If we're talking about the Haskell version here (I can't tell?), you're wrong on all counts.

• It is about as short as any reasonable impl I've seen of FizzBuzzBazz. Not long at all.

• And it does print out correctly for 15.

• And it does NOT do excess operations. It does exactly one modulo per factor.

Do you not understand how it works? I detail it pretty closely in the post; please look again.

The second ruby version _is_ long, but does not perform excess operations (unless you're complaining about Ruby's implementation of lambdas, which is out of scope). As I said both in my article and in this discussion; coding during an interview is tricky and that's not a bad effort.

Fianlly, the naive if-chain extensions are deliberately wrong to extend, but my initial research and experience is that most programmers don't realize that until they try it once. But then, they're lifted right from Rosetta Code so they're hardly unrepresentative of what people consider an "unacceptable" version of Fizzbuzz.

Post reply on HN