Hacker News Reader

Comment by _Codemonkeyism | Hacker News Reader

1. Interesting.

2. I still wonder why around 30% of people with programming experience who have applied to a job when I was recruiting couldn't solve FizzBuzz[1] or string reverse. All of them either University MSc or years of programming experience.

The article hints at using the wrong teaching methods.

[1] Given the written instructions: '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”.'

View on HN

How do you ask people to "solve FizzBuzz" and how do you know they've solved it?

I'm asking because if you do a whiteboard test then it's easy enough to get things wrong on both sides of the interview. Humans are just not as accurate as compilers, not even for the simplest of things.

Besides that there's always nerves, misunderstandings, cultural differences etc. In one place I interviewed they asked me to write a factorial method in Java. I assumed they wanted a recursive method, because, factorial, right? Classic recursive example. So I gave them a recursive factorial in Whiteboard Java™. I turned around from the whiteboard to see the interviewers staring at me, their mouths hanging open. And not in a good way. It turns out all they wanted was to see if I could write a simple loop. Instead of marvelling at my amazing recursion powers, they got the impression I was needlessly flashy and probably had my head up my arse. Also, seeing them staring I completely panicked and I totally screwed the iterative version: the loop went up instead of down, I was adding where I should be multiplying... a shambles.

So they didn't hire me.

Shit happens in interviews and it's not because "Johnny can't program". It's because "Johnny can't pass a programmign interview" (or at least many of them).

I usually do them online with an editor like etherpad.

I tell people they can use the language I hire (Ruby,JS,Java) but I'm fine with other languages or pseudo code.

I tell people I don't care about semicolons or braces, I don't hire them for being a compiler.

Factorial I also use sometimes. Recursive is fine with me if it works, I've seen many people to go the recursive way - hey it's factorial - and then screw up. I sometimes ask people to do an iterative solution, or I ask if the recursion went flawless to write it as tail recursion.

Compilers don't just catch syntax errors though - they also show up logic errors, that may be too subtle to see on a whiteboard. That's true even with very simple programs.

You can definitely step through your program by hand and follow the logic etc, and you should totally be able to do that, but most programmers will not be in the habit of doing this. And neither should they, because it's slow, tedious and error-prone to hand-simulate your algorithms, or even just your for-loops. Not to mention recursive, or larger stuff.

I guess what I'm saying is that programmers are used to "lean on the compiler" and you don't have that on a whiteboard exercise, so it's a bit artificial.

[Full disclosure: I'm in the habit of hand-simming my stuff especially in the last year where I've been developing a grammar induction algorithm, so I'm not worried that I'll have to stand on a whiteboard and not know how to step through a loop, but I still think it's not very useful to make people do that).

Factorial recursion solution is flashy? It's supposed to be high school level stuff.

They were expecting an iterative solution, so giving them a recursive one came across as a bit snotty. As it should.

What language did you do your high-school level stuff in? I assume it wasn't Java, because in Java there are no good reasons to use recursion (it provides iterative primitives, unlike say Haskell, Prolog, Lisp etc) and there are good reasons not to (its compiler doesn't (or didn't) do tail-call optimisation).

Not to mention, any language without pattern matching is a bit shit for teaching recursion anyway: you tend to miss the point because of all the bookkeeping.

Pascal and lisp-like language that was created for teaching purposes in our school. Still, recursion was among the first procedural programming topics, right after procedures themselves, if I remember correctly.

Pascal and lisp-like? What school was that, or rather -when was that?

Recursion is generally considered hard by most programmers, hence why my interviewers thought I was showing off. You can google a bit and see that people do indeed have trouble getting their heads around it.

[0] has quite interesting discussion about the FizzBuzz exercise.

It feels a little like a window to the programmers mind. Some of them are disturbed by the simple repetition and come up with obfuscated or infective solutions etc.

[0] http://c2.com/cgi/wiki?FizzBuzzTest

>2. I still wonder why around 30% of people with programming experience who have applied to a job when I was recruiting couldn't solve FizzBuzz[1] or string reverse. All of them either University MSc or years of programming experience.

take a world 100m running champion and ask him to run the 30m with making 360 deg rotation left on each 3rd step and rotation 360 deg right on each 5th step... That would be such a fun, like a drunken duck...

It's perspective. By the end of interviewing 6 or 7 people, YOU know those questions and all the paths to answers cold. You not only know the questions and answers, you know all the ways thinking about those problems is connected to other problems. So, WHO could possibly not know that? Possibly you, before you put together your list of interview tech questions.

.. but these two always come up as suggestions. So much so that anyone googling "what questions to expect during a programming interview" ought to be able to come up with canned answers to them.

A priori you might expect to find that there were lots of candidates who could do string reversal and fizzbuzz but nothing else. This doesn't seem to be the case.

That's right. Mostly they test whether people have taken the time to prep for an interview. That has some value, but maybe not the value the interviewers intended.

I like the kinds of interviews where you assign a coding problem before the interview and review the code, or where debugging is part of the tech interview.

So you think given the instructions in an interview:

'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”.'

people should not be able to write the code? Just by hearing the answer 6 to 7 times ("By the end of interviewing 6 or 7 people") someone knows the answer?

"Possibly you, before you put together your list of interview tech questions."

No actually given the instructions I could write the code in one go. So I'm mystified as why someone applying to a developer position could not do this in your opinion.

The problem is that Fizzbuzz and string reversing are a kind of trick questions. Either you have already done them or not. Good people will fail at trick questions very easily in interviews. Since they don't represent real work and aren't statistically significant, why are we using them? They are merely adding random noise in the interview process.

How is Fizzbuzz a trick question?

To someone who can't do it, it is a trick question.

The "trick" is the first hump - a goat.

argumentum ad hominem (edit: was never asked to do Fizzbuzz)

Not at all.

Even a simple programming question can stump someone not trained in it. I've seen people who (supposedly) have computer science degrees fail on FizzBuzz.

In the end, it makes some sense to "talk shop" about programming issues. If they can't follow, it's probably not a good idea to hire them.

From this thread you'll find people that will reject someone with 10 years of experience because of failing Fizzbuzz in the conditions of an interview. It's not always used to talk shop. What I say is that there are things that are probably more statistically significant that questions with gotchas.

So? I've interviewed people with graduate Computer Science degrees who couldn't program a for {...} loop. Blew my mind, but it happened enough times that it doesn't surprise me any more.

Going to echo this sentiment: I think the only way FizzBuzz is a trick question is if you aren't familiar with the modulus operator, in which case I think it fair to say you haven't spent much time programming.

That being said, I'm assuming the failure mode we're discussing is 'flailing at the whiteboard and would never make any progress given infinite time' and not 'wrote an off-by-one error that a unit test would catch.'

Even if you've never heard of the modulus operator, it's still easy, eg in Python:

  fizz = 3
  buzz = 5
  both = 15

  for i in range(1, 101):
      if i == both:
          print "FizzBuzz"
          both += 15
          fizz += 3
          buzz += 5
      elif i == fizz:
          print "Fizz"
          fizz += 3
      elif i == buzz:
          print "Buzz"
          buzz += 5
      else:
          print i

If you can't write your own modulo function if don't understand the fundamentals of integer/floating point operations. Or are unaware of ceil and floor functions.

Fizzbuzz trick: you have to make a special case for modulo 15, you can't reuse the 3 and 5 cases.

string reversing in place trick: stopping at the middle else it's an identity function.

Any time you spend with Fizzbuzz, you could spend it on more complete quizzes, discussing past experiences, taking references etc.

And if the candidate trips up, this gives you an opportunity to walk through a virtual compile-debug-test cycle.

When I asked these kinds of questions I would execute the program in my head, and tell the candidate things like "your reverse() methods moves some stuff around, but the end result appears the same as before". Or "this fails with ArrayIndexOutOfBounds on line X". Typically it only took a few minutes to find the bug and fix it, and I learned about how the candidate solves problems.

I find it unlikely that good people will fail to do string reversing if they haven't seen it before.

I find it much more likely that the fizzbuzz failers are the students who wanted to copy my programming projects in undergrad.

> I find it unlikely that good people will fail to do string reversing if they haven't seen it before.

I've seen this for people that were hired and proved excellent.

Everyone can do Fizzbuzz or reverse a string on the job. Much less can do it correctly the first time, on a whiteboard, in a job interview. When you hire a carpenter, you don't ask him to hit a nail with a plastic hammer while you watch.

Certainly you can learn Fizzbuzz and string reversing, meaning that you could be a false positive in the interview. Assuming that you are interviewing experienced devs and you use the test as a kicking-off point for discussing any errors rather than as an opportunity for calling the candidate an idiot, you are unlikely to hit false negatives.

Even in these circumstances I've had a decent proportion of candidates never able to even begin to outline some code, let alone get far enough in to enounter "tricks" or "pitfalls". These are candidates I'm comfortable assuming have not learned to code.

That blows my mind. I believe you it's more like what are people learning with these degrees?

I code for fun mostly and I feel like even my 'basic' level knowledge should be able to outline code for a simple problem like fizzbuzz or string reversal.

Go read up on the origins of FizzBuzz. It was intended to filter out the non-coders, despite what their resume might say. That was Spolksy's problem: BS in CS, resume otherwise looks good, get them in for a tech interview and they simply bomb.

Mind still blown? Yeah, well, it happens more than you think. Varying definitions for "SDET" are out there, but I think most would agree that an SDET should be able to code. I've had SDETs with Microsoft on their resume that couldn't even match curly braces, let alone write something that would compile and work.

So I use FizzBuzz or an equivalent. I tell the candidate up front that it should take them single digit minutes. I offer points for creativity if they find it too simple. And once in a while a candidate with ten years experience shows up who can't do it. Glad we didn't start with that red/black tree implementation, then.

late reply.. but damn thats crazy. Admittedly I'd get lost on the red/black tree but a basic loop and modulus is pretty much like CS101...

It is crazy, and thankfully not all that common. But I've observed it often enough to never trust a resume. Granted, far more often with SDETs[0] than "regular" devs, but I've seen a few of the latter that would struggle with or outright fail FizzBuzz. The craziest part, though, is that most worked someplace else previously. Did they outright lie about previous roles? I wouldn't believe they lied, but I'm certain they blatantly exaggerated.

[0] Why more common with SDETs? My theory is that SDET is easier to fake, and if your SDET "development" consists of var foo=FindUIElement("bar");foo.click(), then FizzBuzz could give you trouble.

So I work right now supporting a recruiting team with technology project management/data analysis and I can definitely agree with never trusting a resume. I've learned most of the time people don't actually know they're exaggerating, they tend to be unaware of how limited their skill set is.

"Even in these circumstances I've had a decent proportion of candidates never able to even begin to outline some code"

Same here.

Well in this case I would be surprised if any other programming question wouldn't reveal them.

When presented with a trivial programming task in an interview, I'm partly questioning whether there's something deeper I'm missing or if it's a basic challenge like "did you ever write any code yourself?". That's why some might perceive it as a trick question.

In my experience if a tech hiring person is playing with "trick" questions during an interview you should very quickly start wondering if this would be a place you really need to work.

Maybe, but I wouldn't be surprised if it's not up to them what the questions are.

Yes this happens, some developers overthink things and think meta then meta then meta. This makes it especially tricky to do surveys ("what does the question really mean?") with developers from my experience.

When this happens to me, people in the interview tell me something like "This is easy, are there strings attached I can't see?"

It's because some interviews try to have you solve hard problems, expecting you to have a solution ready in 5 minutes, whereas in the real world you'd consult literature for that.

Whatever happened to, "he seem to be able to code, let's try it for a couple weeks"?

Happened to me twice where everything was fine and then after having been interviewed by 5 or more people, one of them has a bad feeling, and you're not given a chance to prove yourself in a probationary period. Situations like that made me wonder if freelancing is a better path.

Never had cause to reverse a string but have needed to reverse an array. Never had cause to do something like fizzbuzz but have needed modular operator (actually both in the same function) but if I had never had reason to validate barcodes of differing lengths and validate the check-bit, I would probably fail on fizzbuzz too. In fact I probably would fail today if asked, who has time to remember something that useless, and that easy to look up?

Fizzbuzz or string reverse aren't something to remember. They are small logic puzzles that programmers should be able to easily figure out in an interview, even if they have never heard of them. Unless, perhaps, the candidate gets so stressed that they lock up and fail to think straight, which is of course totally plausible.

I agree, but wouldn't call string reverse a logic puzzle, only if all programming is logic puzzles.

I would like to learn and understand how you think you would fail on FizzBuzz if you get these instructions [1]:

[1] if stuck on modulo I usually suggest to assume there is a function divisible

For me? Anxiety largely. And probably over engineering the problem trying to demonstrate skill beyond fizzbuzz.

I have a terrible memory and struggle to be confident, I would probably just not manage to write anything under interview conditions. When I first learned about fizzbuzz I did it and wondered what all the fuss was about, it's not a complicated logic puzzle, just that I'm used to writing code while connected to the Internet, my brain simply doesn't try to remember things I know I can look up in 1 second.

So you are incapable of writing any program you haven't seen before or have seen but didn't decide is important enough to memorize?

How can you expect to be a professional software developer if you can't get some specs, then develop a solution?

I disagree. What's tricky about a naive solution for FizzBuzz? The only argument I could think of is "well it uses modulo which isn't all that standard". Not knowing modulo (or "how do I check if a number can be divided by another number") is a very bad sign (imo)...the rest is printing stuff, branching, a loop, methods/functions and getting a program to run (+maybe TDD). Those are all rather fundamental building blocks.

Usually modulo is not a problem, if stuck I suggest candidates assume there is a function divisible that returns true or false.

What.

If someone perceives "FizzBuzz" to be a "trick" question, he's exactly the kind of person FizzBuzz question should weed out as fast as possible.

Not sure how FizzBuzz is a 'trick question'. Given these instructions at an interview:

It spells out in words what needs to be written in code.

String reverse is: Write a method/function that returns the reverse of it's argument. Would be interested to learn how these are trick questions.

Not everyone has the entire unicode spec in their head.

I usually go with ascii.

If the solution is fine, I ask were they see problems. Some mention UTF-8/16. I'm happy if someone tells me this is tricky and there is a working solution in library X or they would google for a solution that works with UTF-8/16.

If you're a programmer, you can write FizzBuzz. Whenever I do a first technical screen, I always start with FizzBuzz - explicitly telling the interviewee it's just to warm them in before we get to the real stuff. No trick there.

https://news.ycombinator.com/item?id=11497607

>The problem is that Fizzbuzz and string reversing are a kind of trick questions.

They are the exact opposite. They are practical, very simple, introductory questions. Fizzbuzz is literally "do you know what a loop and a conditional are?".

String reversal at least involves a backwards loop, which isn't that hard, but you don't use often in practice. I'd guess there are 10x as many for-of loops as for i = 0...loops in our codebase, and 10x as many for i = 0...loops as backwards loops in our code base. I think Swift may be removing C-style for loops, even (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo...). Of course you can still express it using a while-loop, but this reflects the frequency of certain types of code.

On the one hand, I'm tempted to say everyone should be able to do that, on the other hand, they do feel like a type of programming that isn't super common in a lot of applications. FizzBuzz is probably a bit better in that regard.

Not necessarily a backwards loop, it can be done just fine with a simple recursion too. If a candidate can't do either, well, this is a task explicitly to weed out those candidates.

Seriously? The sum total of my undergrad programming experience was a Fortran/Matlab course and I was able to write a FizzBuzz implementation when I first heard about it. As an outsider, the idea of a professional programmer not being able to write a FizzBuzz implementation sounds as ridiculous as a pharmacist who couldn't tell you what sudafed was for or a mechanic who couldn't replace an oil filter.

If you've not done something similar to fizzbuzz, then you're not a programmer.

Programming is all about abstraction. And fizzbuzz is an abstraction of a huge range of programming work.

Namely:

go through this data

pull out bits, based on these conditions

then do something with it

Some version of that underlies the vast majority of programming work.

Reply on news.ycombinator.com