FizzBuzz Still Works

If you get "close enough" on paper and pencil under the pressure of an interview, that's great. You can walk through debugging it if you want to see more, but I wouldn't hold even basic logic errors against someone.

I certainly admit that when coding on my own I usually get all kinds of stuff wrong that I fix as I write tests and iterate.

If the number is not multiple of 3 or 5, you must output the number. That's what is he doing.

He prints output at the end of each iteration, setting it to empty string at the beginning.

In each loop, he initializes the output variable to an empty string. If the current integer is not a multiple, he replaces the empty string with the integer. If it is a multiple, he doesn't know which one it is, or if it's a multiple of both, so he appends the text to the existing string variable. At the end of the loop, the string is output.

Since the `output = i` line is the only assignment that occurs when that condition (not a multiple of either) is met, it makes sense to just reassign the variable rather than append to it. It might be less flexible, sure, but flexibility isn't required here.

  "" << 0x41 # => "A"

Admittedly, having a variable that contains either an integer or a string is atrocious programming style, but some people do actually like languages that allow that, so it is par for the course in the given situation.

No. Though output << i.to_s will produce the same result, his code is correct. And yours isn't if you do output << i

1. If not a multiple of 3 or 5 or 15, output = i.

2. If a multiple of 3, output << fizz.

3. If a multiple of 5, output << buzz

4. If a multiple of 15, "fizzbuzz". Already covered in 2 and 3 owing to <<

Apparently people mess up fizzbuzz even when they know it:)

But if you take a second and think about it, how the hell could these same people who fail fizzbuzz write production code in previous companies? Are you really saying that you believe that fizzbuzz is more complicated/difficult than their previous work?

As someone who's run lab experiments and who's seen a bunch of surprising results, trust me when I say that shocking results usually mean that you're running a test that you don't understand.

In this case, you're probably testing for a host of things that have nothing to do with day-to-day engineer performance.

I dunno. I just think it's strange that they even get to the interview stage.

If that's true, it's still a good screening test. You either have heard of it but could code it even if you hadn't, so you pass, or you haven't heard of it and couldn't code it even if you had, so you fail.

    def multiple_of_3(number):
       number % 3 == 0
    end

    def multiple_of_3(number):
       number % 7 == 0
    end

(* I feel I should say that I am being sarcastic. Anyone who thinks it's ok to have a function called "multiple_of_3" that checks if it is a multiple of 7 should probably be fired immediately.)

Looking at a function call for "multiple_of_3" I would actually expect it to do more than i%3==0 since that could've been done just right there.

I'm just trying to understand if there are benefits of doing it this way and not directly. So far I've just encountered snarky remarks and no real arguments either way.

Ah, Currying... (and how Firefox spellcheck recognizes that as a word, but not spellcheck)

* On another note, I've seen other bizarre blind spots in experienced programmers. One time, when I was learning Ruby, I went to a Ruby "hack night" in SF where a bunch of people there explained that they had been hackers for a while. The group was given a challenge to implement C-style integers (with overflow/loop-around) using Ruby classes.

The session had "mentors" who were professional Ruby programmers (mainly with Rails).

So as I was writing my class, and implementing addition, I figured I would need to input another integer object and add its value. So I needed to know how to expose a member variable, and couldn't find the doc that said how, leading me to ask a mentor.

He was stumped. I was thinking, "WTF? You program Ruby all day but don't know how to write [what I later found was called] an accessor?" I wasn't asking for anything fancy, just the plain ol'

    def foo
      @foo
    end

But the main point of Fizzbuzz is that some people who call themselves programmers are incapable of producing a loop, some conditionals, and some print statements. Your solution had that, which is why you passed it. The point is to find the people who can't even get that part right.

Surely the latter won't be a surprise; if I answered like that I'd do it with a grin and a "Well, I could do it like this [write out the above], but I suspect you want something more like this [then write an implementation of the method]."

Being snob about the interview question is not going to help things.

That would be fine with me. If it does get to the point that _everyone_ knows it, then we have to find a new question.

1. There was a great deal of primping and preening prior to the coding phase of the interview, and it was made clear that the phase of the interview was designed to demonstrate basic coding skills, that it's a fairly standard industry practice, and that these exercises are fairly meaningless and all the rest. There was plenty of warm up.

2. I wasn't running the interview; I lack the authority to do that. I am simply a member of the group the interviewee was interviewing for. I blurted it out because I was shocked by his response, which I felt demonstrated that he felt he was above menial coding exercises. I've never met a good engineer who would scoff at a problem because it was too simple, especially in a context where demonstrating prowess was desired.

3. The candidate, who is a "senior engineer" in his current position, also showed us some of his code after failing this part of the interview, which was a truly disgusting, thousands of lines of copy-paste crap pile. Imagine writing a large interactive site with jQuery, then remove the ability to use selectors and do all that by hand. Then imagine what you're doing also happens to be done for you by your backend if you enable a bit of configuration. That's the level of shockingly incompetent we're talking about.

4. We still offered the candidate the job, because we're fairly desperate, we were worried about losing the position if we didn't hire someone, and he seemed personable--and like he probably wouldn't screw things up worse than they already were on this particular project, which came back from being outsourced in really sorry shape.

5. The candidate refused to take the job, not because of the group, the low pay, the interview process, but because we couldn't get HR to change the job title from "Software Engineer" to "Senior Software Engineer." He actually made this clear to my bosses on the phone, that if they could just add "Senior" to the job title he would take the job, even with no other changes, and refused--angrily--when they couldn't do that.

I can understand why, with one remark taken out of context, you might relate more to the interviewee than the interviewer. But you really should cut people a little slack around here. Most applicants to programming jobs--especially outside technology hubs--are just not very good. This guy wasn't very good and seemed to know it, even though he hadn't seen Fizz Buzz before, and it hasn't stopped him from having a career in programming for decades.

  def top_four_ints_from(input_list)                                                    
    working_set = []

    input_list.each do |n|                                                    
      working_set.push(n)
      working_set.sort!.shift while working_set.count > 4
    end                                                 
                                                                                 
    working_set                                                               
  end

This sounded fun, so I thought about it for a couple minutes and came up with the following in JavaScript:

    var pyramatrix = function(a) {
        a += 1 - (a & 1); // increment a by one if even
        var b = [], // pyramid y-axis
          c = a-(a>>1), // get the "center" of the pyramid (eg. 7 -> 1234321 -> 4 is the center)
          d = function(x) { return Math.abs((x+1)-c) }, // calculate offset from center
          e, f, // values for storing current index offset
          g = ''; // initialize string for pretty output
    
        for(var i = 0; i < a; i++) {
          b[i] = []; // pyramid "x-axis" (current row)
          for (var j = 0; j < a; j++) {
            e = d(i); // get y offset
            f = d(j); // get x offset
            b[i][j] = c - (e > f ? e : f); // set current index to center minus larger offset
            g += '['+b[i][j]+']'; // add value to pretty output
          }
          g += '\n'; // add a line break after each row
        }
        console.log(g); // print pretty output
    }

    pyramatrix(7)
    [1][1][1][1][1][1][1]
    [1][2][2][2][2][2][1]
    [1][2][3][3][3][2][1]
    [1][2][3][4][3][2][1]
    [1][2][3][3][3][2][1]
    [1][2][2][2][2][2][1]
    [1][1][1][1][1][1][1]

EDIT: Now that I look at it, you could obviously move e = d(i); outside the second for loop, but for the sake of posterity I'm not going to change the solution from what I first came up with.

I did google "2d array python" when the array initialization I used at first didn't work. (I'm new to python and had not done a 2d array in it yet.)

Works fine, dumps the result in formatted output, and accepts any positive number as an argument to pyramid size, odd or even.

Did that person get the job? Lots of companies seem to administer those brain-bending tests and then does not use it as the deciding factor when hiring someone.

I've personally been exposed to several quizzies like checking if a number is a prime, walking a directory tree and printing .txt files, implementing a variant of the soundex algorithm, a web server to interact with the twitter api... The worst (or best) was one in which the interviewer asked me to solve a Roman Square problem as a homework. Except instead of a 3x3 square it was a hexagon containing 64 numbers. Aced all the tests, even the Roman Square and the interviewer even told me I was the only one they had interviewed that solved the problem. It was freakishly hard and involved creating a pretty complicated constraint solver.

I still didn't get the job. In fact, the common theme in my professional life, after dozens of interviews, is that if there is a programming test involved then I will not be offered the job, no matter how well I score.

My conclusion is that companies do not use tests to determine whether to hire applicants or not. Interviewers make up their decisions regardless of test results and then use them purely to make their decision seem more objective they in reality are: "Bill scored low on or test, he is not a good candidate..." or "Bill did score well, BUT $blablabla" where $blablabla is some irrational stuff.

  #!/usr/bin/env python
  rules = {3:'fizz, 5:'buzz'}
  for n in xrange(1, 101):
    print ''.join(n%x is 0 and rules[x] or '' for x in rules) or n

Well, since we're going there... have some JavaScript again!

  for(var i=0;i++<100;console.log(((i%3?'':'Fizz')+(i%5?'':'Buzz'))||i));

  function(a){a=a|1;var b=[],c=a>>1,d=Math.abs,e=0,f;for(;e<a;e++)for(b[e]=[],f=0;f<a;f++)b[e][f]=1+c-d(d(c-e)>d(c-f)?c-e:c-f);;return b}

  function(a){var b=a.length,c='',d=0,e;for(;d<b;d++){for(e=0;e<b;)c+='['+a[d][e++]+']';c+='\n'}console.log(c)}

void main(){for(int i=1;i<=100;i++)printf(i%3&&i%5?"%d\n":"%szz\n",i%3?(i%5?i:"Bu"):i%5?"Fi":"FizzBu");}

;)