Hacker News new | comments | show | ask | jobs | submit login
For the Love of God, Ask FizzBuzz (brianbrunner.com)
43 points by bbrunner 1487 days ago | hide | past | web | 84 comments | favorite



When I try to see if a person knows how to "think", I start with fizzbuzz and then ask them to do it again without if or case statements. The first time a person is asked something like that you see if they're a thinker or if they just go "that can't be done." That question does a good job dividing people into a group that in 5 years time will ether have 5 years of experience or 1 year of experience repeated 5 times.


I love the five years experience vs. one year of experience repeated five times idea


Same, I've added that to my 'remember this' list of phrases/quotes/terminology.


Wow, so simple, and yet it leads to all kinds of discussions of space complexity, what counts as branching, etc.


Do you mean FizzBuzz specifically, because then you may just see how well they do on pop-quizzing?


For an entry-level position? Sure. For a senior-level position? Don't waste my time. I disagree that the Github repo, resume, etc are useless. You can glean a ton of information about me from those data points that can tell you whether I can code or not. You want to know whether I can think or do basic programming skills? Ask me about my repo. Ask me about projects I've done. If I actually wrote that code, I'd be more than happy to go into detail about the work I've done.

Like someone else said, we wax poetic about DRY all the time, yet you're asking me to take time out of my day to repeat things I already know when that data has already been provided for you. Sigh.

You should be able to have an idea of whether I'm a suitable candidate or not before you even call me, and you should know whether I can code or not before you even bring me into your office.

Entry level position? FizzBuzz all day long. It's the only way you'll find out.

Mid- to Senior-level position? There are better ways to figure out my competency level.

My two cents.


I don't believe the article said that the repo, resume, etc. are useless, it's just that you need to establish a baseline of "can this person code"?

Having done hundreds of interviews, I'm sorry to say that even seemingly "senior-level" people (people with years of programming "experience" on their resume) have shown an inability to do basic coding from scratch. It seems there's a subset of developers who cobble stuff together and code-and-fix to make things work. This is ironically less of a problem with entry-level people.

Yes, if you have a public repo of code, I'll ask you about it, but I want to see you live code something, both to see the code you write and your thinking process about solving the problem. If you feel that's a waste of your time (and if you're truly senior-level, it really won't take very long at all), that's fine, but I will continue to do it.


> even seemingly "senior-level" people (people with years of programming "experience" on their resume) have shown an inability to do basic coding from scratch.

I wouldn't have believed you a few months ago (and your statement is still stronger than my experience), but I've finally seen people who are so maintenance-bound, that even though they're good at _that_, they've never managed to learn the language (the corners, idioms, and semantics) they've been maintaining. It's probably a sign of heroism that they picked up enough to do so on the fly, but, you wouldn't hire them to write new code.


If a developer is too good to do FizzBuzz for me, then probably he's too good to work for me, and should do us both a favor and go away. I imagine that each time he needs to do something, he'll be asking himself whether it's beneath him or not.

As a leader, a senior developer needs to be capable and willing to do anything that gets done underneath his area of responsibility if that's the key thing that needs to be done right now and everybody else is busy doing the thing that they need to be doing. If they're not willing to do whatever it takes, then they're not the kind of senior leader I need.

The larger the organization, though, the more room there is for people who are too good to do various kinds of work. But smaller teams, where the highest productivity is, need flexible people.


Generally I agree, but I've asked FizzBuzz to mid-to-senior level folks who just can't get it. There are plenty of less qualified programmers who got into entry level positions and have held onto jobs long enough that they are now considered mid or senior level.

FizzBuzz provides a great level setter for folks who lack a clearly searchable, well-known code repository.

One half-joking suggestion to anyone using your GitHub repo as a resume: make yourself a FizzBuzz project. You can include basic one so the box can be checked, but as a hiring manager, it'd be fun to see novel and humorous solutions to it that show cases your particular background (e.g. front-end developer? Show me the CSS3 solution.)


FWIW, I disagree; having seen a candidate interview for a senior position at my last company who couldn't code in an interview at all, I think it's worth three minutes on a basic question to make sure they really do have some ability. I don't believe you can have "10-15 years C++" on your CV and not be able to code something basic.

I don't agree about DRY; the whole point is that the data has not been adequately provided until you see it. You do see people with apparently great CVs who are unable to demonstrate the skills in person.


Agreed, but I was unpleasantly surprised when the first senior applicant couldn't solve FizzBuzz. And the one after. And another one. Since then FizzBuzz like basic tasks are part of every interview we conduct, not just for entry level positions. The only difference is the degree of simplicity.


IMHO, you are looking at it the wrong way, that is the candidate's way.

From the employer's point of view, it's all about determining the most effective way of finding out if you're a fit or not. In my personal experience and confirmed by the research I've done, asking basic coding and simple problem solving is the most effective way to eliminate applicants on which you don't need or want to waste your time. Most common "exception" is if one is interviewing what he considers a superstar, but then we are not actually talking about an interview, but rather a sales pitch.

I find that Brian has put it perfectly in the last paragraph: "A solid answer to FizzBuzz is like a firm handshake when meeting your new boss or like opening the door for your date. It’s an introduction that sets a minimum bar and guarantees that neither the interviewer nor the candidate is wasting the other’s time."

And then you ask for Github, resume, whatever-you-find-relevant.


Agreed. If the interviewers are not competent enough to detect those who would fail FizzBuzz through other means (like a simple, respectful conversation about any technical topic) then I would not want to work with them either.


I have been doing a lot of phone screens for our company lately. We ask a FizzBuzz like question in our first phone screen.

So far, only 30% of applicants manage to go pass this point.

It's actually quite hard to believe. Guys who claim to have multiple apps under their belt simply cannot write code. I often question them on what they did in their past and what was their actual contribution to their team. The two most common scenarios are either the so-called technical manager who got promoted there become of lack of coding abilities or the self-taught programmer who was hired by the technical manager. By self-taught, I mean someone who can write HTML and copy/paste JavaScript code from somewhere.


When hiring "Experienced C Programmers", I would just show them a the short version of strcpy() out of K&R, but with variable names change from 'src' and 'dst' to 'x' and 'y'.

Just to read it and say what it did. This eliminated the vast majority of the applicants:

void strcpy(char x, char y) { while(x++ = y++); }


Markdown ate the asterisks in the code snippet. Important to realize that if you're not terribly familiar with C.


    void strcpy(char *x, char *y) { while(*x++ = *y++); }
In this example, why does the loop terminate? Is it because the null terminator counted as a false?


Exactly, since C strings are just pointers to raw memory you usually assume that either the user passes the length explicitly to you or that they're \0-terminated.


I had no idea that's how strcpy is implemented. Buffer overflow exploits and the like aside (ah the good old days) that is really elegant!


I assume the caller has the responsibility to ensure that x is actually large enough to contain y.


You are probably right (and this is one of the reasons why as a language C and C++ can really blow up in your face).


They have to ensure that the strings are \0 terminated, so why not? C is definitely pre-condition-or-else.


that's why there are alternatives such as strncat.


This is not how strcpy is implemented. It is typically done in assembly.


Really? I just did a "apt-get source libc6" and in strings/eglibc-2.17/string/strcpy.c I found:

    /* Copy SRC to DEST.  */
    char *
    strcpy (dest, src)
         char *dest;
         const char *src;
    {
      char c;
      char *__unbounded s = (char *__unbounded) CHECK_BOUNDS_LOW (src);
      const ptrdiff_t off = CHECK_BOUNDS_LOW (dest) - s - 1;
      size_t n;

      do
        {
          c = *s++;
          s[off] = c;
        }
      while (c != '\0');

      n = s - src;
      (void) CHECK_BOUNDS_HIGH (src + n);
      (void) CHECK_BOUNDS_HIGH (dest + n);

      return dest;
    }


That is the fallback implementation in case a platform does not have an optimized version available. Try `sysdeps/x86_64/strcpy.S` to see an optimized version.


Oooh, shiny. I'm not very familiar with how this is all tied together, thanks for the pointer. I was a bit thrown by the apparent lack of ifdefs and such in the c definition, but I see the asm-version starts out with:

    #ifndef USE_AS_STPCPY
    # define STRCPY strcpy
    #endif
So I guess there is some logic set up in the configure-stage before building.



Try putting two spaces at the beginning of the line.

  void strcpy(char *x, char *y) { while(*x++ = *y++); }


For most markdown flavors, a forward slash before the character (\) should do the trick. [Re-Edit] Finally saw the help and HN isn't typical markdown. 2 spaces for pre tags only.


It's not markdown. https://news.ycombinator.com/formatdoc There are really only two things you can format on HN: italics (with asterisks) and literal lines (with two leading spaces).


I'm not an experienced C programmer but I assume there's missing some '*' somewhere?


I suspect the same people who complain about being asked fizzbuzz are the same people who complain about getting their ID checked when they buy alcohol.

I can implement fizzbuzz in < 30 seconds in half a dozen languages (in vim, maybe < 60 seconds on paper/whiteboard). I don't really take offense to being asked to blow 30 seconds; I understand where the interviewer is coming from the same way I understand where a cashier asking for my ID is coming from.


I think a lot of people who complain don't realize that a decent amount of people do fail FizzBuzz. If they are as smart as they think they are, then they would definitely appreciate not having people on their team who cannot complete FizzBuzz!

I have asked this question before and a lot of people don't know the mod operator and so they struggle and eventually it occurs to them to divide and check the remainder. This usually leads to kinda sloppy looking code, but, I find it to be very revealing about their problem solving abilities. Some people just give up. Some people ask for help. Some people get angry or flustered. All of these scenarios are extremely revealing and help you to understand the candidate's approach to problems.

When the candidate already knows FizzBuzz then the results are usually less interesting - but sometimes they may solve it is some really unusual way which is cool to see.


You said it was cool to see unusual FizzBuzz solutions, so I just coded this up in the last 10 minutes. So... FizzBuzz without any modulo or division operations!

    #include <stdio.h>
    int f0(unsigned int x) { return x? (x&(1<<31)? f1(x<<1) : f0(x<<1)) : 1; }
    int f1(unsigned int x) { return x? (x&(1<<31)? f3(x<<1) : f2(x<<1)) : 0; }
    int f2(unsigned int x) { return x? (x&(1<<31)? f0(x<<1) : f4(x<<1)) : 0; }
    int f3(unsigned int x) { return x? (x&(1<<31)? f2(x<<1) : f1(x<<1)) : 0; }
    int f4(unsigned int x) { return x? (x&(1<<31)? f4(x<<1) : f3(x<<1)) : 0; }

    int t0(unsigned int x) { return x? (x&(1<<31)? t1(x<<1) : t0(x<<1)) : 1; }
    int t1(unsigned int x) { return x? (x&(1<<31)? t0(x<<1) : t2(x<<1)) : 0; }
    int t2(unsigned int x) { return x? (x&(1<<31)? t2(x<<1) : t1(x<<1)) : 0; }

    void main() {
        unsigned int i;
        for(i=1; i <= 100; i++) {
            if(t0(i)) printf("Fizz");
            if(f0(i)) printf("Buzz");
            if(!(t0(i)|f0(i))) printf("%u",i);
            printf("\n");
        }
    }


fantastic! I would be rightfully impressed and amused!


I always suspected that anyone who fails fizzbuzz does it because they are unfamiliar with divisibility mathematics. I am always amazed at CS students who have no grasp on relatively simple math.

I remember trying to explain binary addition to people in a circuits class when we were implementing ripple-carry adders. I was explaining how binary addition is the exact same as decimal addition except you carry at 2 rather than 10. The guy I was explaining it to asked "What is carrying?". He hadn't done addition by hand in so long he had entirely forgotten. And this is a guy who can code up a functional, decent looking PHP based website in a matter of minutes. I suppose it's even more believable that people would forget long division, remainders, and modulus.


When I interviewed for a coding job about 15 years ago I was asked to talk the interviewer through some code. Nothing very exciting, just a very basic loop.

It turned out that 3/4 of the people applying for the job _could not code at all_. They weren't just bad coders - they had never coded anything in their lives.

It's _those_ people that FizzBuzz catches out.


I find that to be exactly true. The really surprising thing is that a college degree or experience at a big company doesn't necessarily tell you what you can learn from just walking through some very basic code.


I've heard from multiple sources that people fail fizzbuzz. I now read multiple posts here saying the same. As a hobbyist programmer with a few free lance projects under my belt who never worked in "the industry" I find it simply fascinating. My first reaction is that maybe your interview is very stressing or maybe you ask the applicants to write the code on paper and fail them for any typo. I just can't believe anybody, anybody who ever programmed anything failed such tests in reasonable environment. I mean if I couldn't write fizz-buzz I would never get any code to work. I mean I imagine myself failing to implement a dictionary in C having limited time and being under pressure without a bug somewhere but fizz-buzz ? really ? :)


These are people who have never (will never?) write any actual working code. Through a combination of lying on their resume/bullshitting interviews/hiding away during the actual job they've managed to get by. They are a small percentage of all "Programmers", but a large percentage of people looking for jobs (because they are more likely to be unemployed, more likely to fail an interview, and their best way to get a job is to try as many interviews as they can get).

I'd never be insulted by Fizzbuzz questions, it takes maybe a minute to solve and you can move from there to more interesting questions very easily. If Fizzbuzz is the closest thing to a time waste during the interview process, you're in pretty good shape.


I've wondered the same. And the answer is a delusional, "I'll figure it out when I get there."


If there is one thing around hiring programmers that I wish had more discussion, it's the notion from the interviewer's goal of "trying to understand how one thinks about a problem." Frankly, I don't think we're very good at it. And for good reason -- it's really hard.

My personal experience has been that most of us in the industry aren't well equipped to make that determination reliably among each other. The most successful interviewees I've ever seen are those with excellent pattern recognition and recall. Only a few of those are decent programmers (not even excellent.) But they're all very talented in describing ways of thinking.

In spite of information at hand, I rarely see those in hiring roles ever go away from "does this person think about this the way I do?" It is a very subjective task, so I don't fault those in these positions for following that process. But I think there's a perception in "understanding how a person thinks about a problem" that is flawed.


And starting out in programming, for the love of code, learn how to do these. They set your brain in motion. And ProjectEuler.net


Project Euler, while great, is more about neat math tricks than actual programming.


It's about solving logical problems and expressing those solutions using code. Definitely useful.


Never said that it isn't useful.


What about TopCoder?


I've never participated much but people say that if you get some practice there, algorithm heavy interviews go a lot smoother.


Agreed that there's an intense math flavor, but the "right" way to do lower level PE problems mathematically can be more fun to play with programming ideas.

Problem 1 is basically a fizz buzz and its funny to try alternative algorithms.

So, yeah, brute force its pretty obviously a for loop with a subtotal, two mod tests connected by an or, you get the idea. And that is the first way to do it in a new language.

So you wanna try recursion? I feel fuzzy at this time but something like you call recurse(1000) and it calls recurse(999) and so on until it hits 0 and stops. Now from memory my weird design was the return was returning the (the returned subtotal from calling recurse(x-1)) + x when x is a mult of 3 and not a mult of 5 + x when x is a mult of 5 and not a mult of 3 + x when x is a mult of 15 (15 is 3 and 5 at the same time)) Yeah or something like that. (edited what the heck was I thinking? I'll leave this as unedited, but thats not right. This is a good fizz buzz example of give them the question, a wrong answer, and ask them to debug it.)

Another one to demonstrate your ability at screwing around with arrays is simply make an array size 1000 all zeroed out and a for loop to run thru all indexes of that array (now try not to fall off either edge) and if the array index is a mult of 3 or a mult of 5 then set that array value to the array index. Finally add together all the values of the array.

Hmm so you've got a minor parallel processing cluster on hand and everyone runs some language you're unfamiliar with and has access to a shared NFS dir so all 100 of your hosts run the worlds dumbest program that checks to see if 1000 files exist, if not, it picks a psuedo-random number between 0 and 1000, checks to see if its already been calculated, if not, it decides if that number is a mult of 3 or 5 and if it is, then a filename "random-number" appears using dd if=/dev/urandom of="random-number" and you copy 1K blocks equal to the number of blocks in the random number (so file 14.crazy is zero bytes long but 15.crazy is precisely 15K in length) then given 100 workers randomly selecting a random number less than 1000 you have to run way more than 10 rounds but eventually all the shell scripts simultaneously terminate on all the worker nodes because ls | wc -l returned 1000 aka all 1000 results have been calculated. Then you run cat * > result and du -k result to see how many K are used which is the sum of all the mults of 3 and 5 between 0 and 1000... I did this to torture test a small cluster and its NFS server and its network and disk IO a long while back. I remember it took more rounds than you'd guess to test all 1000 digits and of course if varies, unless your psuedo-random number generator is screwed up. Or you could intentionally use a screwed up RNG to see if its any good. Also I did my run using M not K although a motivated lunatic would use G, I suppose, to really torture a NAS. Isn't this a diabolically insane and funny way to solve the problem?

On a simpler level, or a differently crazy level, you can do all your math in octal, just because. It won't really change anything but it looks entertaining. And why not write your own octal-dec conversion routine, to print out the result, just because?

The point is not to do it the fastest or most obvious way but to screw around with odd ideas, not the same old boring fizzbuzz.

Graphical is hilarious instead of using a boring old array. So what happens if you use a PNG graphics image to store your table of multiples? So 15 is 15 black pixels? This is an interesting way to test your ability to squirt out and in pixels. Also does your PNG library interface like 1e6x1 graphics images and how scalable is it when you access the same graphics image 1e3 times does it scale?

There is a tiny problem that someone who thinks this is hilarious might use hilarious designs in production code.


> guarantees that neither the interviewer nor the candidate is wasting the other’s time

Yeah, it guarantees that only the interviewer is wasting the candidate's time. If you're hiring off the street I could possibly see some value in FizzBuzz, even though it's going to turn off any actual A player you happen to interview, but if I sent in a portfolio/past project/etc and you FizzBuzz me, I'm walking out. If you distrust a candidate that badly I can't imagine how micromanaged your employees must be.

FizzBuzz both saves you time by filtering out incompetent people, and saves actual competent people time by demonstrating that you're not willing to do what it takes to attract great hires. There's no shortcut to real interviews.


The target audience of FizzBuzz (i.e., those who fail it badly) are indistinguishable from you otherwise, and they outnumber you. They also do send in portfolios and past projects, simply they lie about who did the actual coding in those projects.

The exception is when a company is approaching you directly - then it would be insulting. However, if an outside recruiter approaches you, and then hands over to the company... again, you need FizzBuzz or such, because some recruiters are cheaters and will even help hopeless candidates fake their portfolios.

Wasting people time hurts - but accidentally hiring someone who'd fail FizzBuzz hurts orders of magnitude more.


Would you also walk out on your first day if your new boss asked you to do something you considered simple or boring?

If so it sounds like FizzBuzz may still serve as a valuable filter!


I FizzBuzz all new developers I hire. Frankly, if you aren't prepared to spend the 5 (at most) minutes it takes to put FizzBuzz down in a language you say that you are an expert in, I'm ok with you walking.

Being a productive team member requires trust, and FizzBuzz is a really low standard to start at when attempting to gain trust. I'd be openly suspicious that anyone who can't be bothered to run through FizzBuzz in an interview would be the type to complain that whatever task they are working on (that needs to be done) isn't RealProgramming(tm), and is beneath them.


I'm off the market, but if I were asked to do FizzBuzz on a tech intervieew, I would do it, but conditional on the interviewer doing something as idiotic immediately after that. Like write an iterator for a binary tree.

Treating the person on the other side of the table is a fake works both ways. Don't underestimate how actually offensive a FizzBuzz question to a qualified developer is.


Think of it this way: they aren't trying to offend you - they're trying to show you that they're keeping all the other idiots who can't do FizzBuzz from joining the team.

FizzBuzz is a necessary but not sufficient standard for acceptable technical skill.

As a hiring manager, I'm not just amazed by how many people can't do FizzBuzz, but by how many people haven't even heard of it before I ask it.


> I'm not just amazed by how many people can't do FizzBuzz, but by how many people haven't even heard of it before I ask it.

This is very true. I've often thought of pulling it from the list of questions just because of the visibility that it gets - I mean, I do actually feel, to an extent, embarrassed asking it. Surely anyone who spends 30 whole minutes preparing for a job interview can find it on Google.

It still manages to be difficult for some people, though. And, really, that's something that I want to know quickly.


If the interviewers are not competent enough to detect those who would fail FizzBuzz through other means (like a simple, respectful conversation about any technical topic) then I would not want to work with them.


It is an immediate indicator that they're hiring off the street. That might be good---you're very competitive---but it also may mean that hiring is pretty out of touch from dev communities.


well, why don't you flip it around. how would you like it if you were a developer who, as part of his duties, had to interview potential hires and HR keeps sending you people who are unable to even solve FizzBuzz? Or, worse yet if they actually hire people who are unable to handle FizzBuzz and now you have them sucking up all of your time along with bits of your soul?

You don't see any value of FizzBuzz because you are only thinking about it from one limited perspective.


I might turn around and ask you to print out the alphabet. I mean, I don't want to work for someone who can't write.


FizzBuzz-type questions are for the first remotely technical interview, not once your programming credentials have already been established by the people who are interviewing you. You make it sound like the people interviewing you already know anything about you other than what's on your resume.

It filters out a surprising number of people, including those with what appear to be very impressive resumes. I don't know what your definition of "hiring off the street" is, but if it means that the people interviewing you don't know anything about you prior to the interview, then that's pretty much all hiring for any company of any size (i.e., non-startups).


>If you're hiring off the street I could possibly see some value in FizzBuzz, even though it's going to turn off any actual A player you happen to interview

I think this is the use case that they're referring to. If you're getting a job referral from someone you trust, you probably shouldn't do it. It's also not that much time. I've never done any professional coding in my entire life, and I could write fizzbuzz in at least three languages in less than 10 minutes.

Edit: 10 minutes EACH. I'm not that good.


A lot of the people going to an interview will be incompetent. With other people's projects as references. (Or so they say it is in many places, these days.)

If you insist on just working where they have evolved perfect routines to weed out the incompetents before interviewing, you'll miss out on most new places with smart people.


Good article but why the hell that horrible font? If I was not hiring currently, I would not have bothered to try to read it...


Are we looking at different pages? http://imgb.mp/jmI.jpg


Font renders differently on iPad (monospaced) vs Mac Book (your screenshot) for me.


I am on Win 8 Laptop with not much resolution and using Chrome, here the font is even thinner and has aliasing artifacts.


Seems like a perfectly decent monospaced font. Medium grey on light grey is annoying, though.


But monospaced fonts aren't good for reading prose.


http://i.imgur.com/0ygryEl.png

FF24/Mint 15 looks fine to me (bit small maybe).


Yeah, fizzbuzz is a filter guys. Yes, you can read their code repos and do in depth interviews, but you shouldn't waste your time until they can do something as simple as fizzbuzz. You will be truly surprised how many just don't pass that filter and are literally wasting your time.

To reiterate: necessary, but not sufficient.


"A good resume with a long list of well-known companies and a degree from a top-tier engineering school doesn’t guarantee anything." I'm sorry but a year+ at those companies proves you've provided at least something of worth to them. The real crux of the argument is can they solve the kinds of problems your company faces.

I would certainly hope that the barrier to entry for every job I applied for wasn't something so standardized (and quite frankly, useless). I would eventually point to a github repo with it done already. We wax poetic about DRY yet you're gonna ask me to repeat myself? Seems pretty hypocritical to me.


You'd be surprised.

Degrees don't count for much in terms of experience. I've seen people with electrical engineering degrees (from good universities) ask which way the strips are connected on a breadboard. Many, many people go through university and get a good chunk of theory in their minds without any practice.

As for companies - if someone is leaving a well known company, you should ask why. Almost always there is a good reason for it, like moving to warmer climes, family commitments and so on. However, there should always be a fizzbuzz check to make sure the person wasn't let go because they were inept.

As an aside, a long list should also give warning signs if it's in a short period. If I'm hiring a 20-something and they've been through 5 companies I'd be wary. They may be a top notch programmer, but do I want to hire someone who will most likely jump ship in a year or two? Probably not.


You're missing the point. What you are not realizing is how many people actually fail fizzbuzz.

If it seems so simple and useless to you because it's easy, then you are not one of the people who will ever be weeded out by a fizzbuzz style question.

Put it this way... Would you want to work with somebody who was unable to handle fizzbuzz?


I definitely would not want to work with them and yet I have. My problem isn't the failure rate, its the repeated asking of a question I should be able to prove via a public repo. The repo should be more than adequate, I would hope. If it isn't, we would have much bigger problems of trust.


> I'm sorry but a year+ at those companies proves you've provided at least something of worth to them. Not sure about that. I think there are lots of "well known companies" where a good bluffer can relabel themselves and bounce around enough that nobody realizes they haven't got anything to offer.

>We wax poetic about DRY yet you're gonna ask me to repeat myself? Some people can wax poetic pretty effectively without being effective at implementation. I've written a 1 line fizzbuzz python generator in less than 2 minutes. If one is too arrogant/uncompromising to take the two minutes to satisfy this (if asked), or unable to turn it into something interesting ("This is done with generators. I might never do it this way in practice, but the question you asked me was so mind-numbingly boring I had to do it this way to entertain myself"), then one probably won't work that well on an effective team.


I forget that in most "well known companies" they are much larger in size and people can easily hide behind others in such a place. That's where my ignorance comes in. I've been only part of smaller shops where if you aren't producing, you absolutely do not last.

Yet I easily forgot the person with a masters degree that could not pass, was hired anyway, and subsequently fired 3 days later for not improving an iota. I think my frustration is that people like this exist, forcing companies to give the same test to weed them out with no way to skip the question if you can faithfully prove you're not that person.


I am still skeptical for the effectiveness of FizzBuzz. I wonder if there are actual science experimental result to support this hypothesis where asking FizzBuzz as a filter would actually be effective. I wonder what is the percentage of those candidates who failed this filter are actually the worst kind of candidates, and if those who passed this filter would turns out not be a good fit. I see no correlation between passing FizzBuzz and being a good fit, productive engineer. Most of the proponent of FizzBuzz seems to assume that engineering skills could be accurately form a pyramid, where there are some questions where you need to understand before tackling other higher level questions, and that people who don't understand the "basics" will not be able to grasp or excel in the skills in higher levels. May I ask how many interviews here have taken CS courses and may I ask how many of you find FizzBuzz is relevant to any of the courses you have taken? Do you need to know FizzBuzz in order to tackle the vast problem spaces of Computer Science? Do you need to know FizzBuzz by heart to have experienced working in a large projects with thousands of people? Do you need to know FizzBuzz to implement a binary tree? Do you need to excel in FizzBuzz to code up a language parser?

To me, it is absurd that people believe in FizzBuzz because I see this mindless ritual of asking FizzBuzz question can be best described as Cargo Cult Science as coined by Richard Feynman (http://neurotheory.columbia.edu/~ken/cargo_cult.html), where in this context of hiring, recruiters are hoping that by asking FizzBuzz he will definitely filter out all incompetent programmers/engineers so he won't have to waste time finding out if the candidates are actually suitable for the position and the team.

If FizzBuzz is the ultimate filter for the position he is applying for, or if it should be considered universal, then why wouldn't university teaches them to memorize all possible variations of them in their introductory programming classes? Also wouldn't you think people who are not good programmers would cheat his/her way out by simply memorize the solution? Then aren't you still wasting time asking FizzBuzz questions?


I don't really understand; why not ask an actual substantial question in a phone interview? Poor candidates who would fail fizzbuzz would fail that too; good candidates would be expected to pass such a question anyway.

Either way, you're wasting an hour of eng time at most.


Totally agree on asking FizzBuzz type questions first! I have understood a lot about the person just by asking simple questions. Most people fall into the trap of answering it in a very complicated way to advoid many if else if conditions for no reason! :P :)


[deleted]


To me fizzbuzz eliminates certain types of candidates who have absolutely no reasoning skills. You would be surprised at how many people are out there who have learned how to regurgitate lessons from school but seemingly have no clue how to solve any real work.

These people do manage to get themselves hired based on their academic degree and they wind up contributing absolutely nothing, while consuming time from the developers around them until eventually they are dismissed.

You don't want one of these guys on your team. Simple fizzbuzz exercises will usually uncover them unless they have managed to memorize it previously.


Deleted my post because my mobile screwed it up before I was finished. All good points. FizzBuzz is so simple that it can be regurgitated too or lifted from a Google search on your phone as you're talking with the interviewer. That so many can fail with so many examples is terribly troubling.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: