Hacker News Reader

Comment by afr0ck | Hacker News Reader

I am doing PhD in CS. I solved and designed algorithms to solve very tricky and hard concurrency problems (mostly in the Linux kernel). I ported the Linux kernel to a research CPU architecture. I wrote complex system software to deal with memory models, heterogeneity and cross-ISA migration, modfying glibc, llvm, linux.ld and tens of other system software. I worked on KVM, kernel network stack, networked filesystems and implemented distributed systems levraging all of them. However, I have no single idea what is FizzBuzz, and if someone asks me to do it an interview, I would fail miserably. I also only code in C and lots of LeetCode type of questions are a nightmare for me.

View on HN

> I have no single idea what is FizzBuzz, and if someone asks me to do it an interview, I would fail miserably.

If you know what you are doing even in the slightest, you won't fail.

No one will put you next to the whiteboard and say "do FizzBuzz", expecting you to know exactly what it is and what to do. They will say "write a function that takes in a positive integer as an argument, and then counts from 0 up to that integer. Every time a count is divisible by 3, print out 'Fizz'. Every time a count is divisible by 5, print 'Buzz'. If a count is divisible by both 3 and 5, print 'FizzBuzz'".

I cannot imagine someone who wrote all the complex things you did, but is not able to write a toy counter function like that.

To be honest, that's the first time ever in my life to read the description of FizzBuzz, which is ridiculous. But I was just answering the parent and providing a data point that proves the correctness of his statement.

But in general, I find LeetCode style interviewing very boring and dry. Like all of those "Given a string, find a substring that satisfies bla bla condition", or "given a matrix as csv input, read it then calculate some BS and find the best estimation for some other BS, etc".

When I was very young and naive, that might be fine, but at this point in my life, I just get super super bored and annoyed by such questions.

Instead, I prefer contextual questions. Like if you're hiring for a low-level network programmer, let me do some socket stuff in C or Go, implement a backoff mechanism in a given code template, discuss some TCP/IP congestion stuff, discuss some code, add a small feature, put a bunch of system calls and watch how I care about performance (blocking vs non-blocking, epoll vs select, shared-memory vs message-passing, context switching, etc) and how I handle errors, and also observe my workflow, how I check the documentation, the man pages, debugging, etc.

I think this is a much more reliable and less frustrating way of interviewing and I believe it attracts very highly skilled and motivated people.

FizzBuzz isn't leetcode. It's a filter for bare minimum programming and reasoning skills. It's purposely simple to avoid tripping people up with a seemingly hard problem that depends on insight you might miss while under the pressure of an interview. If you're so innumerate you can't check for integer divisibility you might not be a good fit for some programming tasks.

I've seen candidates fumble when given the problem of adding a node to the end of a linked list. Everybody is pampered now with swiss army knife languages that do everything for you that they don't know how anything basic works. Many of the HN crowd will sneer at the idea of this sort of low level coding but it is still important in many domains.

> Everybody is pampered now with swiss army knife languages

Wow. Who's sneering again?

> Many of the HN crowd will sneer at the idea of this sort of low level coding but it is still important in many domains

Yeah, we do. Because developer-cum-interviewers for companies writing marketing-optimized CRUD apps use these as filters (or to make them feel superior, take your pick), and sneer at people who can't bark out the proper magic incantation for reversing a linked list on demand.

And let's be honest. Unless you're in an exceptionally specific field with exceptionally restricted resources, using the "swiss army libraries" will create more performant code than a human can. Because those "pampered languages" have been optimized to ridiculous degrees.

If the job description is for an embedded programmer you should be prepared to work in that field.

> Because those "pampered languages" have been optimized to ridiculous degrees.

Haha, and then there are stories about python finally getting rid of the GIL - soon, probably, hopefully!

And that's only my favorite language.

There's no way in hell you would fail a FizzBuzz test if you have done the things you say you have done.

At the FAANG companies I’m familiar with, the coding portion is sort of a standard bar that everyone must pass, from new grads to 30-year veterans. The more senior you get, the less they matter.

If you were being hired into a specialist role such as for low-level networking, there would absolutely be a more detailed “Systems” interview where you would discuss in depth the topics you mentioned, usually in the context of a more open-ended “architectural” problem.

Interviewee performance on these “Systems” interviews hold a lot more weight at senior levels, not just for hire/no hire decisions, but in fact the level of your offer.

> However, I have no single idea what is FizzBuzz, and if someone asks me to do it an interview, I would fail miserably.

I'd suggest actually looking up what fizz buzz is before making that claim.

https://en.wikipedia.org/wiki/Fizz_buzz

I like it as an interview question because it gives insight into the candidate's thought process. I'm not as concerned that the resulting code works. My approach is to explain fizz buzz, hand the candidate a computer, ensure they have the tools they're comfortable with, and tell them to use whatever resources they need. Copy and pasting code from the Wiki page wouldn't be the worst that I've seen (and would be 100% acceptable to me if the candidate can explain what the code does). Write it in BF for all I care, as long as you can explain what it does and (ideally) run it.

At one job a few candidates stood out. I was running late as usual, so I popped in, realized I'd forgotten my notebook in my car, and went back to grab it. By the time I returned the candidate had literally run out of the office. One candidate wanted to impress us with his bash skills and got completely flummoxed trying to figure out how to implement the modulo operation in bash. What really stood out about the candidate we hired was that they reviewed the code and then ran it to verify the correct behavior before handing the computer back to me. They were the only candidate to do that.

I really hope you (or someone else in your interview loop) asks another question besides FizzBuzz.

I'm not quite sure where you got the impression that fizz buzz is the only interview question that got asked. I'm fairly process oriented so I find a lot of value in observing how someone works. But at some point it's just not worth it to proceed further.

I like fizz buzz because it's both a good low pass filter and a good jumping off point for further discussion. If you can't read the Wiki entry and wrap your head around fizz buzz, you're probably not a good fit. If you can then there's the opportunity to ask all sorts of questions (e.g. why did you choose this language, how would you test this, what would you do differently) and maybe even move on to a more complex program.

For the one candidate who struggled with bash, we started offering input around the ten minute mark. Stuff like "is there something else you could use instead of the modulo operator", leading questions to encourage them to check the man page (or google it), inquiring maybe a different language would be a better fit. That this person could wrap their head around fizz buzz was only a minor detail. That they were fixated on making a specific implementation work was a big miss. At this job specifically the tech stack was fairly diverse so there was a lot of value in being able to suss out the right tools for the job and less value in being able to bang out a more complex algorithm in clojurescript or whatever.

However, I have no single idea what is FizzBuzz, and if someone asks me to do it an interview, I would fail miserably.

A fellow commenter here has already addressed this point, but let me reiterate: you wouldn't be told "do FizzBuzz" with the expectation that you already know what FizzBuzz is. The problem definition would be explained, and it is a very trivial problem. That's why it's often used as a low level filter for programming interviews.

At a former employer we used to do just about everything we could to make the process as easy for the candidates as we could. We'd give them a laptop with an IDE running, the skeleton of the test app already in place (eg, main method, and any "plumbing" dictated by the language. We supported using Java and Python) and comments basically saying "flesh in the required logic here." We would give them, IIRC, 5 such "skeletons" and ask them to pick any one (or more) they wanted to implement and gave them approximately 30 minutes. Besides FizzBuzz the other ones were "reverse a string" and other problems of similar difficulty. And yes, you could use any standard library API that you wanted. And frankly, if somebody had said "I know how to do this, but I'd need to download library $FOO" we probably would have arranged to get them library $FOO ('net access on the test machine was disabled, as we really didn't want to test their ability to go find the answer somewhere else and copy & paste).

And despite all that, it was sad to find that very many candidates, even those with documented years of experience and/or advanced degrees, could not manage to complete a very simple programming assignment. Well... I say "sad" but there is another way of looking at this: it could be that FizzBuzz, "reverse a string", etc., just don't have any particular relevance and that this whole exercise is useless. I mean, if you have a person who's been gainfully employed as a developer for 10 years, and they can't do this, what does that tell you? Maybe it's the test that's wrong. Even though intuitively, I think most developers would believe that anybody who can't do this sort of thing doesn't really know how to program.

Anyway, back to the original point directed at the OP: being self-taught isn't really that big a deal, IF you can demonstrate some fundamental level of competency.

I tend to memorize it like this:

  If number modulus 3 is true, print "Fizz"
  If number modulus 5 is true, print "Buzz"
  If number modulus 15 is true, print "FizzBuzz"

My favorite examples are in Python and Lua, but I honestly adore Lua's version as it makes it really clear of what it does.

Here's an implementation of mine for reference:

    local startTime = os.clock()

    for i=1,100 do  
      fizz = (i % 3 == 0) and "fizz" or ""
      buzz = (i % 5 == 0) and "buzz" or ""
      if fizz == "" and buzz == "" then goto continue end
      print(string.format("[%03d]: %s", i, fizz..buzz))
      ::continue::
    end

    local endTime = os.clock()
    print(string.format("Total time %.6f seconds", endTime - startTime))

An issue is that a lot of mediocre people got into decently ranked positions and are now mediocre interviewers, too.

I think FizzBuzz and other easy questions being asked is a symptom of the opposite issue.

The field of interviewees is so mediocre that if you start with a reasonably difficult interview question a lot of them will flounder and will never get it. When I interview I like asking tiered questions. They build on each other conceptually and get harder.

The first one I ask takes good candidates 10-15 minutes at most. I've had some solve it in 2 minutes. You can write a not-too-ugly 1-liner in Python to solve it. Some candidates spend a full interview on that question and never get it. The question isn't a trick question, it requires a basic knowledge of data structures and directly translates to the (mostly simple) code people write every day. If someone solves this question it basically tells me that they're good enough for the second question, not much else.

But man, is it painful to interview someone who can't answer that first question with a harder problem to start with. I don't know if you've ever interviewed someone who just didn't get it, no matter how many hints you drop, but it is an uncomfortable experience.

That is why we have FizzBuzz. Asking a harder question first to a shockingly large number of candidates is a waste of effort. So we all have to FizzBuzz and then (hopefully) answer some real questions.

Reply on news.ycombinator.com