Ask HN: Why is FizzBuzz more important than actual experience?

I personally suck at "whiteboard" coding too. I'd prefer they leave me in an empty room with a text editor and no internet connection for 10 minutes. But part of the exercise is discussing the problem and or showing your interpersonal skills.

Hopefully you'll find a different employer who interviews in a way better suited to you.

Having a simple challenge (ideally less than an hour) seems appropriate under those circumstances. Ideally you use the simple challenge as a replacement for hours of stressful whiteboarding.

Sounds like you've got a professional network that you can use to get you a new job instead of going through the front door with everybody else.

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?

FizzBuzz is not a puzzle. It's a very straightforward question, there's nothing tricky about it.

Your references are nice, but in many cases there's no easy way to verify that you wrote that code.

> You’re going to see three types of people in your interviews. At one end of the scale, there are the unwashed masses, lacking even the most basic skills for this job. They are easy to ferret out and eliminate, often just by asking two or three quick questions. At the other extreme you’ve got your brilliant superstars who write lisp compilers for fun, in a weekend, in Assembler for the Nintendo DS. And in the middle, you have a large number of “maybes” who seem like they might just be able to contribute something. The trick is telling the difference between the superstars and the maybes, because the secret is that you don’t want to hire any of the maybes. Ever.

That one essay seems to have spawned a major fear in the industry of hiring someone who you might have previously taken a chance on. In an attempt to prevent what Joel warned us about all those years ago, the interview ritual has increased in complexity. We've since been advised that the coding homework and the whiteboard implementation of FizzBuzz are mandatory, and they've swept the industry.

Everyday HTML/CSS has problems that are more difficult than FizzBuzz. It's not a gotcha question, it's mostly there to see if you have actually written any code or if you are submitting a false resume.

Side story: I have witnessed someone with absolutely no coding experience get hired. He not only lasted, he was considered pretty good. His secret: he used Fiverr and some other services to outsource his work. I have to complement the guy. In the end, he completed his tasks and added business value. He wasn't looking for a career, he was just looking for a job that paid well so he could buy a car and move across country. In the end, no one was hurt and both parties got what they wanted.

EDIT: I'm assuming they literally asked about FizzBuzz. It is literally the apocryphal interview question and just beginning filter to see if the rest of the interview is going to be a waste of both of our time. I would assume that if you hadn't come across FizzBuzz that you have never coded before and/or it that you did no preparation for an interview. It isn't all about the difficulty, but FizzBuzz is almost as ubiquitous as "Hello, world."

EDIT Whiteboard Challenge: That said, I loathe whiteboard challenges during interviews. In the past, I've been asked how would I design a Mars Rover and control it from Earth so that it could complete its mission. I didn't know much about AI or computer vision at the time. However, it was for a mid/Senior level full stack position. I had no idea if this were an actual coding question or if he simply wanted to see how I approach problems. I went on about how I would first upload the most precise map data that we have on Mars for the days journey. Then I would make sure the navigational system was accurate by using onboard cameras. The cameras would be looking at certain topological features and how far away they were. If there were a major sand storm that changed the environment, we'd have a problem Houston. I went on about how the Rover would only be given instructions to move as far as can be seen from the original position since the camera feed was not live, but had a delay due to the speed of light. Next, it'd have sensors to know to go into clamshell or whatever mode if it detects a major sandstorm to protect the fragile instruments onboard. He still said he wanted more, so I totally bullshitted something about whether Mars was in its perihelion or not, I'd make sure the Rover only moved during the day etc.

After about 15 minutes of this, he said he was looking for the Rover to be implemented as a RESTful API and Houston would represent the client. I looked at him quizzically, said that was the worst interview question I've ever heard, and I think we're done here. When I got home, I did some googling and found that he ripped this as an interview question: http://stackoverflow.com/questions/185740/would-you-architec...

Now, I know that Microsoft Robotics Studio uses REST and, although I am well past whiteboard challenges, if anyone asks me to do one, I will politely tell them that its unrealistic and never the way I would first approach a problem since I never write code freehand. I frequently draw diagrams, concepts, actions, etc. on a whiteboard. I would be more than happy to actually sit down in front of a terminal, load up an editor and write code that I can get an ...

On the flip side I can sort of understand. I actually interviewed today. They had from what I saw 5 people interviewing today. 30 minutes a candidate, with 6 employees screening. Imagine how much source code they would have to review. In addition correlating that to a specific candidate.

Interviewing is an art. I think we're still ironing out the best way. The first person a director had marked the heck out of my resume and highlighted it. He knew what he wanted to ask, yet he let me lead the conversation.

When I lead interviews I asked basic syntax questions. Then what data structures you would use. Then the bulk was whatever was bothering me. I would treat the candidate like a co-worker. Come to them for a sanity check, am I insane is there a better way. I'll denote this only works if they're comfortable with you, they need to feel like your team mate. People hated me because id go over time limits....

I have been searching for the past four months. I get home I hit hacker rank or study. To say the girlfriend is unhappy is an understatement.

So these coding tests, are not fun. A lot of people have trouble with them. But you can work on them. After one phone screen, the interviewer asked are you done. I said hang on a sec. I reviewed my code and added exception handling, and fixed several syntax errors. That mindfulness helped alot.

Today I got to the ux ui director. They asked to see a prior project. Then engaged me about my design decisions. I essentially got a free consultation and it was amazing.

I'm long winded sorry :/. I'll close with this. I do dance improv, poetry slams, and open mics. I have to practice for each. It took ages to memorize a poem, and choreograph it. The interview is your audition. You have to know their script. Know their lines. Your going for the lead role, and you have got to know how to mesh with your partner. Bust your ass, it sucks but get the role and enjoy yourself.

For example, you could explain a problem involving database lock contention and ask the candidate how they would handle structure, indexes and queries to maximise throughput and avoid deadlocks.

Or you could give them an example schema and get them to "spot all the errors" without explaining that an error is anything that isn't in 3NF or higher.

One is going to give you a good understanding of the candidate's knowledge of the subject, the other is going to give you a noisy true/false signal.

It's easy, for me at least, to freeze up at any time in that process and stop being able to do anything at all, even if in a normal work setting it wouldn't be a problem. It seems rather ridiculous, or at least frustrating, that the job hinges on that process.

Skill lists are almost meaningless. You wouldn't believe how many people claim to know C++ but start writing Java syntax on the board when you ask them to code something.

Basically, the problem isn't you, it's other people. It doesn't matter how good your open source portfolio is; the only 100% reliable way to judge someone's coding ability is to put them on the spot. There are too many "embellishers" in the world.

Ideally, as a candidate, you'd go and work at a company for a short period, and once you can evaluate what it's actually like there and they have a chance to evaluate your work, then you would have a followup interview to determine whether to go ahead (and if so negotiate terms) or call it off. But that doesn't work well in our economy or with the way our companies are structured. So we're stuck with speed-dating.

Due to limited interview time, they throw puzzles at you and try to throw you off guard to see how you react to an unusual situation, and whether you can handle it. How you handle a crisis or bizarro unexpected situation is more important than knowing what you can do under normal circumstances or how you are normally. Not a pleasant answer, but one way of looking at the why.

But companies insisting on quizzes instead of looking at free software projects you have is complete bullshit. It means they are not interested in your coding skill but instead are looking for something else.

It could be that they want to see you under stress and think that they can deduce some valuable information from that. Like if you lose your cool it means you are unstable. If you don't talk through the interviewers while solving the puzzle it means you are not a "communicative" person.

Or it could be that they have no idea if the test they are handing out is working or not. They need to calibrate it by running it through a hundred candidates so they can see what the mean and median scores to even know if someones test result is good or bad.

Just to be clear, I think everyone should be able to pseudo code FizzBuzz or strlen() in an interview because it is very simple and every engineer should be able to solve it in 10 minutes. But the tests I've been subjected to have been much more contrived. Like long multi-choice questionnaires or take-home coding projects that took many hours to complete.

If interviewers insist on me doing such tests I now refer them to my github profile instead. If they don't accept that as substitute for taking the test then the job probably wasn't for me anyway.

I know this is not PC, but coding is not a craft where once you reach a certain level, the rest is polish and experience. Good programming requires a certain virtuosity that not all programmers have (not implying this is genetic, please don't assume I am). People who lack this may produce ok code 90% of the time, but will invariably reach a point where the problem is too hard for them, and they come up with a bad solution.

This applies to working at a big tech company, where all sorts of interesting problems crop up. At an ordinary company or startup, I accept that this might not be so important and maybe these companies are copying the tech company's interviewing style for no good reason. Again, this may not be PC, but people at big tech companies get paid more (even given the location) so I think it's fair to assume their skillset is rarer.

When I interview candidates, I try to mix hard challenges with general coding, design and communications skills. My problems don't usually have a trick that you need to see, and sometimes, like fizzbuzz, they intentionally don't have a clean solution. But my problems are algorithmic in nature. You can see there are some interesting data structures lurking in the background even if they aren't directly applicable.

My reasoning in using these questions is that if a person can't solve a difficult, messy, but well defined problem, then when they encounter such a problem they will be stuck. I know there is a kind of dogma on HN that says that complex problems tend to be a result of programmers not doing the straightforward thing, but my experience is that 10% of the time the straightforward solutions don't work and you need something complex. That is, the flipside of "don't write clever code" is "be clever enough to write the code that is needed". If this sounds arrogant, please bear in mind that it's not usually considered arrogant to say that social skills are important and vary across individuals, so why should coding ability be different?

[1] - (see this for proof - https://hn.algolia.com/?query=fizzbuzz&sort=byPopularity&pre...)

Then there's the internal referral. These candidates are pretty rare. The first month you're hired you're likely to suggest anyone you can right then. After that if you're proposing them, you have a vested interest in them being hired.

Then there's the agency candidate. This person has been groomed by the referral agency to answer your questions. Once when I was hiring, we were asking candidates how to build a priority queue (a queue, where higher priority items were processed first, equal priority items in order). We interviewed 50 candidates, and 47 of them answered quickly and confidently that they'd use XML with XPath to find the next item. o.O

There's the open-source committer. I could spend a few hours reviewing your code, but that's time that I could be interviewing someone else, or actually getting work done. But then I need to make sure you didn't plagiarize it from somewhere. It's too easy to run a search and replace on a git history and slam the whole thing up on GitHub. I mean, I guess that shows technical chops, but poor ethics.

There's the long coding challenge. I wouldn't trust that. I've had coworkers actually ask me to do the coding challenge for them, because they didn't have the knowledge. I assumed they ended up getting someone else to do it for them.

Last is the credit-taker. This was me when I was young (we all have a past). I would over-state my involvement in the project, but because I did have a sizable role in the project and I was insatiably curious, I was aware of how the product worked and why design decisions were made. So I was able to answer any question asked by the interviewer. But was I actually able to build what I claimed?

On-the-spot coding challenges suck, but I don't see a better option out there.

The first few questions are weeder questions. I won't stop an interview if they blank on one, because I'll allow for nerves or a general brain fart. But if they blank on say, the first three really easy basic questions, the interview is over. It doesn't happen often, because those people are likely to get weeded out by the phone screen, but it's happened a few times. And it might not be 100% reliable, but it's good enough for my purposes.

What happens is in some cases people take it too far.

The point of FizzBuzz is a sanity check.

It's like asking a dental surgeon "How many teeth do humans have?".

If they hesitate before answering you don't want them performing surgery on you.

But I guess sometimes people bump the difficulty up step by step until it loses that ability.

As in, a really simple dumb question like FizzBuzz is more valuable because if they fail to do it that's a strong signal that you can depend on.

Sometimes people get greedy and make it more difficult so it loses its value.