Hacker News Reader

Comment by RiderOfGiraffes | Hacker News Reader

The whole point is to use a task so trivial that even moderate amounts of stress won't prevent your fingers from taking over. That's why people who criticize "FizzBuzz" as not testing the true requirements for a job are simply wrong. All you want is some real code that produces a correct answer.

My programmers wrote FizzBuzz in under 60 seconds. If you can't write FizzBuzz in 15 minutes in an interview then you are either unable to program, or any level of stress will prevent you from doing your job. Either way, you couldn't work for me. I don't routinely stress my programmers, but stress is a matter of observable fact.

View on HN

Yeah, I think it's a good test for that reason. I personally would probably do badly on a complicated programming test--- I tend to program best when not in a room with other people, not being put on the spot, allowed to think while walking around outside and then return to a burst of coding, etc. But I could write a few lines of obvious code in pretty much any situation; there's a pretty big difference between peak performance and absolute minimal competence.

It's hard to make analogies to other fields, but it feels sort of like a writing job not asking you to write an insightful philosophy essay on the spot (legitimately difficult), but just asking you to write a paragraph of grammatical English (anyone even remotely fit for the job should be able to do it).

I don't think it's just stress. Few programmers actually write correct code on a whiteboard / pen and paper so expecting them to accurately program outside of their preferred environment can be vary hard for some people. It's something like asking an author to spell out an essay, plenty of people can do it but it's a separate skill from being a good writer.

PS: Try composing your response by saying one letter out loud at a time without typing it before you type it.

I've had employers ask me to bring my own laptop and have me write my code on it in front of them. That reduces the "whiteboard effect" tremendously.

I'd fail: I don't own a laptop.

That would be a good solution for me, too. For example: It's years ago since I used Visual C on Windows, but I use C++Builder daily. I can whip up a good looking, surprise-free, standards-adhering, well behaved GUI in minutes and flesh it out to a fully functional application without hesitation in the hours after. If you'd put me behind Visual C I'd probably be looking for minutes to find the Dialog Editor (errr.... is that Windows Forms nowadays? Hmmm, I should give .Net a look someday).

it's not that different. good programmers sketch the algorithm or data model or architecture on paper first----or however they figure out what they're doing before sitting in front of a computer.

writing a program by hand is not cruel and unusual, it's quite realistic. it's like a musician site reading, not an author writing an essay by spelling letters. (site reading is a skill that comes with being a musician. i can site read music that i would have had to learn to play in the past. i always prefer to read challenging music, but i can play comparatively easy music with little problem.)

"it's like a musician site reading,"

I presume you meant sight reading. Threw me for a couple of seconds.

Agreed, except that FizzBuzz is more on the level of "play me the G major scale" than sight reading.

Yes. But it doesn't have to be 100% correct. It just has to be plausible.

You don't ask an author to to write a perfect essay off the cuff. But certainly any author worth having could generate a brief outline for a story (or whatever type of writing you want them to do)

Your comment about generating my response by saying one letter at a time before typing it made me stop and think - thank you for the insight. However, I still don't think it's a sufficient response.

I agree completely that writing code on a whiteboard is utterly alien to some people, and is so completely divorced from their usual way of working that it's unlikely to give a true picture of how they will code in the real job.

But we're not asking for an insight into how they will code in the real job. We're asking if they can write something like, say, FizzBuzz. More, we're not even asking them to be syntactically flawless and optimally efficient. We're asking if there's any chance that they'll produce working code at all.

I agree that there is to some extent just a disagreement about where to draw the line, and how detailed/accurate the solution has to be, but my experience is broadly in line with the worst claims - 95% of people who approach me for a job in programming can't write code at all.

For the remainder I'll ask how they usually write code, and then collorate with them on something more complex to see how they work.

"But we're not asking for an insight into how they will code in the real job. We're asking if they can write something like, say, FizzBuzz. More, we're not even asking them to be syntactically flawless and optimally efficient. We're asking if there's any chance that they'll produce working code at all."

In practice, few people are asking questions that are as easy as FizzBuzz. I've been through a lot of programming interviews, and I have yet to encounter a problem of that simplicity as an interview exercise. Instead, most companies seem far more interested in laying down the gauntlet, so that they can convince everyone (including themselves) that they only hire "the best".

It sounds like you're trying to keep your programming interviews sane, and that's great. But the problems happen when the other 98% of programmers convince themselves that whiteboarding exercises can be used to successfully discriminate the best of the best from the merely good. One needs only look at the other comments on this page to see that there's a huge and disjoint set of skills that define "competency" to different people.

Given that most people would be answering this in some form of imperative language, I'd say that any solution which includes "for", some "if"s or a "switch", and a few judiciously placed modulus operations would be sufficient. Actually, if I were giving the test, I'd probably ask for pseudocode anyway.

I agree that whiteboard programming can be alien, but certainly a programmer needs to be able to communicate an algorithm in some way other than pure code.

I would think an interviewer should accept someone saying "I'm having trouble on the board, but what I want to do is loop through the numbers, and for each number, mod it with 15, 3 and 5 and then print FizzBizz, Fizz or Bizz." Or, have them draw a diagram, whatever.

Of course, this would need to be supplemented with a coding sample or anything that shows that the person can code when they are in a comfortable environment.

Few programmers actually write correct code on a whiteboard...

But your code doesn't have to be correct. Not as you first write it down, anyway.

The advantage of writing the stupid and broken version of FizzBuzz first is that it gives you ample scope to demonstrate your ability to critique your own bad ideas out loud, write tests and conduct them out loud, eschew premature optimization, analyze the performance of something that's way too slow, and invent alternative approaches only after you've produced the stupidest thing that can possibly work. Not to mention your ability to stand in front of a whiteboard and talk while staying on task and not wasting time, which is a core skill in engineering, even if what you're doing on that whiteboard in real life is rarely actually writing code.

I'm sympathetic to the problem. What with increasing reliance on IDE assistance (and I'm guilty of this) I can easily imaging feeling overwhelmed with just a sheet of white in front of me.

I've tried to do thing mostly verbally, testing their underlying understanding of CS concepts, and hoping this is a decent proxy for development ability.

If you design the questions carefully, the way the applicant answers tells as much as the fact that it's right or wrong.

For example, in a C tech interview I'd ask what you need to if you want to pass variables into a function, and have the function change those values for you. There are a range of correct answers from "put an ampersand in front of the variable" to "call by reference rather than call by value", and these shows different levels of understanding.

I also liked to ask about what the difference between single quotes and double quotes were. A simple correct answer is "one's a character, the other is a string", but somebody who really gets C would tell me that one will lead to the generation of an integer value, while the other results in a pointer.

So it's not just right/wrong, it's shades in between. With some careful design, you can ask questions that tell a lot about how well somebody understand programming.

But occasionally I'd bump into somebody who just couldn't get any of my questions at all, and I'd feel really bad as I tried to think of something simple enough that they wouldn't feel completely awful.

Social stress is different from deadlines. How you conduct the interview is important in this respect, but still FizzBuzz is the correct approach. It would help though if the interviewer made it clear that it's supposed to be a warming-up test, and there is no catch to be looked for.

Wow, so it's been so long since I've had a 'programming' test I had to go look up the FizzBuzz test. A first year compsci student should be able to whip up a solution in minutes. I can't believe that people try for programming jobs and fail FizzBuzz.

Reply on news.ycombinator.com