Can you beat 99% of programmers? Try the FizzBuzz challenge - <AUTHOR> http://www.trybloc.com/courses/fizz-buzz

<comment><USER2> Suppose FizzBuzz were a perfect proxy for programming ability. Some programmers are FizzBuzz-capable, and the rest are FizzBuzz-failures. Members of both groups interview for jobs. A FB-capable programmer goes on three interviews, gets an offer, and works at his job for a couple of years. A FB- failure goes on three interviews, gets no offers (or if he gets an offer, gets fired shortly after), and goes on three more interviews the next week.

The FB-capable average 1.3 interviews/year. The FB-failures average 150 interviews/year. (All numbers are total fabrications, of course.) There don't have to be a lot of FB-failures for them to represent 99% of interview candidates.

</comment><comment><USER3> You may laugh at the utter simplicity of this test, but I administer this several times a week when I interview candidates.

I am still dismayed at how few programmers can solve this given 30 min (15 for the correct solution, plus 15 for optimizations across instructions and code brevity). It filters out the weak for sure.

<comment><USER4> I always thought that was some kind of urban myth that programmers made up to make themselves look better.

<comment><USER5> Unfortunately it is really not, I have a friend who is just transitioning from junior to senior level and he is kind of coming to the realization that the majority of developers are really that bad. I usually look at elitist statements with a bit of septicemic because generally it is an average person trying to make themselves feel better, but in the case of the development world, it really is that bad. It is the reason that we have the 10x'ers.

For example a good developer should be able to solve this problem even if he has never used the technologies involved. It is that simple of a problem. I have never developed in Ruby in my life, 10 minutes on Google gave me all the Ruby API's I needed to complete the challenge. You see a good developer sees the solution and then figures out the API to do what they need it to do. Mastery of the technology is not what makes a good developer, seeing the solutions is where the value of a developer should be measured.

</comment></comment></comment><comment><USER6> How is it possible that 99% of programmers fail this? What _qualifies_ as a programmer? (Where is that statistic even from...) Does that mean someone with a CS degree? Are the failures stemming from not knowing the general concept, or is it just lack of familiarity with any language (I suppose both are quite horrifying)

<comment><USER7> The actual quote this is based on roughly said 99% of applicants, which is hardly the same as 99% of programmers.

[http://www.codinghorror.com/blog/2007/02/why-cant- programmer...](http://www.codinghorror.com/blog/2007/02/why-cant-programmers- program.html)

My own opinion is that if the ratio is this bad by the time they get to the interview, you may not be pre-screening well enough.

</comment></comment><comment><USER8> I do not know Ruby, but I wanted to see what happened when I clicked next. Without writing any code I clicked "Grade it!" This provided me with the unit test output. I looked at it for a moment and then guessed at a solution that might work using copy and paste and based on the comment in the code. Here it is:

puts ["1", "2", "fizz", "4", "buzz", "fizz", "7", "8", "fizz", "buzz", "11", "fizz", "13", "14", "fizzbuzz", "16", "17", "fizz", "19", "buzz", "fizz", "22", "23", "fizz", "buzz", "26", "fizz", "28", "29", "fizzbuzz", "31", "32", "fizz", "34", "buzz", "fizz", "37", "38", "fizz", "buzz", "41", "fizz", "43", "44", "fizzbuzz", "46", "47", "fizz", "49", "buzz", "fizz", "52", "53", "fizz", "buzz", "56", "fizz", "58", "59", "fizzbuzz", "61", "62", "fizz", "64", "buzz", "fizz", "67", "68", "fizz", "buzz", "71", "fizz", "73", "74", "fizzbuzz", "76", "77", "fizz", "79", "buzz", "fizz", "82", "83", "fizz", "buzz", "86", "fizz", "88", "89", "fizzbuzz", "91", "92", "fizz", "94", "buzz", "fizz", "97", "98", "fizz", "buzz"]

I passed.

<comment><USER9> I too don't know Ruby and passed. My approach:

1\. Google to see if Ruby has a for loop. It does. "for i in 1..100" looks like a good start.

2\. Google for a switch or case statement. Don't like what I see. Google for an if/else. Looks good. Guess "if i%15 == 0 ... elsif ... end".

3\. Google to make sure the mod operator is indeed %.

Done.

<comment><USER10> That "for i in 1..100" loop would get you dinged at lots of Ruby shops, since it's not idiomatic. "100.times { }" is the idiom.

<comment><USER11> 100.times is also wrong (unless you i+1 in your block all the time)

Cleaner, I think is "1.upto(100){ ... }"

<comment><USER12> I like (1..100).each {} better :)

</comment></comment></comment></comment></comment><comment><USER13> Those rules are somewhat different to the ones I learned in HS. My teacher's version mapped buzz to multiples of _seven_ , not three, and also required you to use fizz if there was a five anywhere in the number, and buzz for any number containing a seven. Thus, 17,27,37.. were buzzes, as were 70..79, 170..179, and so on. 57 and 75 were both fizz-buzz by that rule. Numbers with multiple 5s had to use the appropriate number of fizzes, and numbers with multiple 7s had to use the appropriate number of buzzes. Thus, 757 would be "buzz-fizz-buzz".

I've seen the fizz buzz test mentioned a lot lately, and had assumed that it was referring to the somewhat more challenging version I knew. Do people really have that much trouble with this simple version?

<comment><USER14> Your teacher may have modified the problem so students couldn't just copy- paste a solution off the Internet. Sounds like a good teacher.

</comment></comment><comment><USER15> I don't know. I've met a ton of programmers and yes have seen people fail at fizzbuzz. But 99%? that number seems a little high.

Then again, my experience is with students at CMU and developers in Silicon Valley.

The stat still seems kind of far out though...

</comment><comment><USER16> It took me a while to figure out why mine wasn't working because I wrote [1..100], which is a one-element array with a range in it. Too much Haskell, I guess.

To salvage my dignity, here's the Haskell solution:

        main = mapM_ putStrLn $ map fizzbuzz [1..100]
            where fizzbuzz n | n `mod` 15 == 0 = "FizzBuzz"
                             | n `mod` 3  == 0 = "Fizz"
                             | n `mod` 5  == 0 = "Buzz"
                             | otherwise       = show n

</comment><comment><USER17> This might be a little offtopic, but I would advise against leaving `console.log` calls in production code, even when there are checks to prevent calling it when the console object is undefined. Commenting those lines out would do the trick, since minification can remove them.

Also I went to the [calculator challenge](<http://www.trybloc.com/courses/calculator#/1>) and noticed this

        # add(4, 2) => 8
        def add(x, y)
        end

Needless to say the comment should read `=> 6`.

Also, since we are all geeks, here's my Clojure version

        (defn buzziffy [a b x]
    	      (cond (and (zero? (mod x a)) (zero? (mod x b))) "FizzBuzz"
    	            (zero? (mod x a)) "Fizz"
    	            (zero? (mod x b)) "Buzz"
    	            :else x))

        (println (apply str (map #(str (buzziffy 3 5 %) "\n")
    	                      (range 1 100))))

</comment><comment><USER18> I passed with this : class FizzBuzz def self.run for i in (1..100) if((i.modulo(3)==0) && (i.modulo(5)==0)) puts "FizzBuzz" elsif(i.modulo(3)==0) puts "Fizz" elsif (i.modulo(5)==0) puts "Buzz" else puts i end end end end

and got this :

"Nice job, you beat the FizzBuzz test! If you believe in the rumors, you are officially better than 99.5% of programmers."

\--

I'm new to ruby, is there any way to "optimize" that code? \- Edit : I don't know how to format code for HN.

<comment><USER19> <http://news.ycombinator.com/formatdoc>

<comment><USER18> cool, thanks. :)

</comment></comment></comment><comment><USER20> The fun thing about these sorts of tests if in figuring out how to do it a little bit differently. For example, I wanted to see if I could do it with a true one-liner (ie, no semicolons) with piecewise construction (ie, no nested ternaries). Here's my solution.

(Yes, it's ugly. But it works!)

        (1..100).each { |i| puts [i % 3 == 0 ? "Fizz" : nil, i % 5 == 0 ? "Buzz" : nil].join.first || i }

<comment><USER21> 1.upto(100){|n|puts [["Fizz"][n%3],["Buzz"][n%5]].inject{|m,e|m=m.nil? ? e:m+=e||""}||n}

</comment></comment><comment><USER22> My initial solution works in real Ruby, but it didn't work in this demo: <http://imgur.com/YBYwN>

Apparently, assigning the result of a comparison to a literal breaks this demo.

Edit: Also, bonus points if you can elaborate on why you think my second solution really does work correctly, despite the apparent bug. :)

</comment><comment><USER14> Submitted a (locally tested as working) program, got "0 errors found" and an error message. The ironing is delicious.

Output:

       <title>Application Error</title>

Application Error

</comment><comment><USER23> >Can you beat 99% of programmers?

Can we have a title that isn't strongly reminiscent of facebook spam?

</comment><comment><USER24> Some ruby code for those non-rubyists:

      (1..100) do |i|
        if i * 2 == 8 and i + 1 == 5
          puts "foo"
        elsif i + 3 == 9
          puts "bar"
        else
          puts i
        end
      end

Not the solution, but all the syntax you'll need in there.

<comment><USER25> Probably should include the modulo operator too (Is it '%' ? I'm not a rubyist)

<comment><USER24> Part of the FizzBuzz test is to find out if the candidate is aware of modulo. :). But yeah it is %.

<comment><USER25> Oh man, I didn't even think of that. Such a basic concept...the mind reels. =(

</comment></comment></comment></comment><comment><USER26> I tried just hitting "Grade it" and got this reply:

> Oops, looks like we found 0 errors in your code. Try again and click "Grade > it!"

So I guess that means I passed?

(After reloading the page it seemed to work better)

</comment><comment><USER27> I am happy I passed, I was worried I suck. What a great day! :)

</comment><comment><USER28> Never really touched ruby before and did it without any help other than checking google for some ruby syntax. I highly doubt 99% of "programmers" can't do this.

<comment><USER14> "Programmer" is a professional job with little to no barrier to entry, often working for people who have no ability to evaluate the quality of your work objectively.

You would be shocked at some of the people out there who call themselves programmers, and even more shocked at how many of these people have supported themselves for years.

</comment></comment><comment><USER29>
      out = [
        ["FizzBuzz", "Fizz", "Fizz", "Fizz", "Fizz"],
        ["Buzz"],
        ["Buzz"]
      ]
      (1..100).each do | ii |
        puts out[ii % 3][ii % 5] || ii
      end

Thanks!

PS: i am assuming this is the fastest you can do in ruby (but I suspect that blocks are expensive alas)

PS2: passing the test is interesting, having a look at the good and/or best answers would be a decent award for having tried in the first time.

</comment><comment><USER30> The challenge is insufficiently specified. What sort of spacing am I supposed to put between the number, fizz/buzz, and the next answer? A space? A colon and a space? Does it matter?

I don't know ruby, so I didn't make a response, but these things should be spelled out.

<comment><USER31> I just spend the last 30 minutes to learn enough Ruby to pass the test. There are many ways to do this to get it to pass. Thank heavens for modulo, however.

<comment><USER32> It's simple without modulo too. Division's just repeated subtraction, so subtract 3 or 5 until you hit 0... if you pass it, it wasn't evenly divisible. Multiple loops instead of one.</comment></comment></comment>


Ask HN: mother of all todo managers in Lisp - <AUTHOR>

I'm pretty sure I saw some link to some company using Lisp to build a todo manager that plans stuff for you so you don't have to. I've managed to lose the link to that site. Did I hallucinate that? <comment><USER2> Presentation: [http://www.slideshare.net/smartrevolution/how-a-clojure- pet-...](http://www.slideshare.net/smartrevolution/how-a-clojure-pet-project- turned-into-a-fullblown-cloudcomputing-webapp)

And the todo manager itself: <https://the-deadline.appspot.com/>

<comment><AUTHOR> That's the one. Thanks a million!</comment></comment>


What software developers should learn from the VW diesel scandal - <AUTHOR> http://technical.ly/philly/2015/11/02/what-software-developers-should-learn-from-the-vw-diesel-scandal/ <comment><USER2> N. Don't write any code that isn't specified by a requirement. In a shop as large as VW, there are requirements.

Investigations are only beginning, but at this point it's plausible that some of the coders involved didn't quite know what the purpose of their code was. VW execs jumped early to try to hang this on "one or two software engineers."

Promote this publicly in the interests of "traceability," which everyone agrees is a good thing. Want it privately in the interests of self- preservation.

If a company wants something built, particularly in a regulated industry, they damn well better declare it.

Which reminds me, it will be interesting to see how the VW code in question relates to their requirements systems.

<comment><USER3> Why do think VW would bother issuing formal requirements?

<comment><USER2> Because it's inconceivable that they could manage software and hardware production without them. They're huge. You can't ad-hoc something that large.

Or are you asking why would VW bother with requirements for the cheating subset? Well, that would be my point then. Don't write software against something a manager mentioned in a meeting or in your cube.

<comment><USER3> If we're talking strictly about an ECU, I'd guess that most of them are a codebase that is a complete disaster. The only management activity around ECU development is likely something to the extent of "6 engineers at 1.12 times our standard engineer cost for 6 months will cost us...".

My guess is all of them just do shit until it works. There are tons of sensors, valves, etc. that need to be managed but it isn't anywhere near as complex as trying to build customer relation system feature #125125. There is literally one user input to the system, that is the throttle position. If the system even appears to work correctly in all states, ship it. As an engineering effort an ECU is quite the accomplishment, as a software development effort its quite boring.

Something like an infotainment system that can have lots of different states presents much more information to the user. It's actually a much more challenging to develop, because you'll have people instantly noticing when you've drawn the UI widget for feature #125125 wrong.</comment></comment></comment></comment>