Hacker News Reader

Comment by J-dawg | Hacker News Reader

I'm probably taking the question too literally, but do people really use FizzBuzz as a hiring test?

I only ask because until recently I'd never written a FizzBuzz program. I've seen it mentioned so many times that I thought I'd better give it a try.

Even for a mediocre JavaScript developer like me, it was trivially easy and took about 5 minutes. I would be astonished if it was used for hiring anyone other than the most junior/trainee roles.

I think you're probably using "FizzBuzz" as a euphemism for abstract coding challenges. Could you give some examples of the problems you are being set?

View on HN

I think on a phone screen (which is typically something that is done in order to not waste everyone's time) something like fizzbuzz is fine.

It's very easy to lie about projects and to have some friends back you up - verifying all this takes time.

Simply having something that takes five minutes to be sure you are talking with someone who can actually code is worth it from a phone screening point of view.

I have only once asked this question in an actual interview. I had a "senior architect" in who told me he had led all kinds of projects but something just seemed off with him - he was very very good at steering the conversation away from the technical details of what he had actually done and instead talked in lots of generalities. The guy was supremely confident and likeable.

Sure enough, he couldn't actually code for shit. When I later asked how he got past the phone screen, it turned out that he managed to intimidate the (junior) engineer giving the screen enough (by implying it was beneath the architect to even answer such a question) that he managed to get a "pass" even though he didn't actually do the task we asked.

Some people are REALLY good at bullshitting.

> It's very easy to lie about projects and to have some friends back you up - verifying all this takes time.

If I were presented with a candidate (already somehwhat vetted) who claimed authorship of an open source project, I would definitely take a look at it, and then ask them detailed questions about it in the interview. If they hadn't actually written it, I don't think they could fool me for very long.

Out of curiosity, I tried literally FizzBuzz on a couple of new grad candidates (my job is software, but we attract a lot of computer engineers). About half were able to do it without help. I no longer use FizzBuzz, but I'll use other very trivial questions to end an interview early if I suspect a resume has been significantly exaggerated.

I work in embedded systems. We mainly write C. We ask candidates to implement strlen() in the phone screen. A surprising number are not able to. It's a very low bar, but still a useful filter.

Wow that is a low bar.

I've also asked similar questions for embedded roles. Lots of candidates can't implement their own strlen function. Most of my coding questions need 3-5 lines of basic C and lots of them struggle even if I give a couple hints.

  > I tried literally FizzBuzz on a couple of new grad candidates
  > About half were able to do it without help

So, one could do it, and one could not?

This is fascinating. How close did the unsuccessful candidates get? Did you give them any hints?

Did you let them run their code to test it, or was it a pure whiteboard exercise?

For the successful ones, what did you ask them next?

It's very common. You can sit there talking yourself blue in the face about a legitimately difficult piece of work, and I can almost guarantee, one or more of the developers they roped into attempting an interview will default to it, or something similar.

Your typical developer has no business interviewing anyone, in my opinion, but there you go.

> a euphemism for abstract coding challenges

Yes. People seem to like to come up with their own "clever" versions.

An example of what the OP is probably talking about (to make a huge assumption here) is an example I've used alot on HN:

> At an interview for a non-senior backend developer job on a CRUD app: "Traverse this binary search tree and provide the Big-O time complexity of your implementation"

OTOH, I haven't done too many interviews being young myself, but If someone claimed to have SQL knowledge, and I were hiring for that role, I would simply draw out two-three tables in a dB and have them do basic-intermediate tasks such as INNER JOIN. Or add an index to a given table.

Reply on news.ycombinator.com