Ask some smart business analysts with no coding experience to solve FizzBuzz in Excel. All should be able to do it.
Instead of asserting this fact, put the hypothesis to the test. Ask some smart business analysts and see how many of them can solve fizz-buzz. You're much more likely to win over the audience if you have some data.
Really though, I think this post is needlessly controversial. The whole text could have been, "It makes sense to hire people with no programming experience who can solve fizz-buzz." I don't know how many people fall into that category. I'm not sure how good they'd be or how long they'd take to get up to speed, but that's fine. It's something I can think about and engage with.
The rest of the post is just arguing over definitions. If by "coding" you only mean "turning pseudocode into code", then yes a lot of things people call coding aren't coding. Likewise if by "think analytically" you mean "is able to solve fizz-buzz," then of course companies want programmers who can "think analytically."
No matter what definitions you use, the hiring practices are the same. Fizz-buzz still acts as a negative filter. People who can't solve it aren't hired. People who can solve it may or may not be hired depending on how other things go.
I think that FizzBuzz is just filtering out incompetent applicants who shouldn't be trying for programming jobs to begin with. Joel on Software described this phenomenon back in 2005. [1] His key takeaway is that 99%+ of people applying for developer jobs may be unqualified for pretty much any coding job, but they keep applying anyway.
He describes how he and other companies get 200 applicants for most job postings, of which only one may actually be "good enough." I've seen numbers like that myself when on the hiring end. So everyone thinks they're hiring the top 0.5%, even though the same 199 losers are spamming their resumes to every job posting.
Well, a simple way to filter out that 199 is to apply FizzBuzz or equivalent.
So everyone thinks they're hiring the top 0.5%, even though the same 199 losers are spamming their resumes to every job posting.
Yeah, when you think about it, this whole "we only hire the top 0.5%" condescension really amounts to a basic statistical reasoning fallacy.
To construct an alternate hypothesis: the "real" threshold for ranked competence[1] at "elite" companies might, just might, be more like "the top 5%". But we can safely assume that 95% of the available talent pool in this category will be employed (and not actively seeking), compared with say 70% in the bottom, or "sub-elite" category, at any given time.[2]
So for example in a "town" of 1000 putative developers, with skill levels ranging from god-like to "good enough" to mediocre to utterly bogus and self-deluding, let's say 50 (or 5%) of these are truly "elite", and 950 are "non-elite".
Further, of the elite category, 47.5 will be employed (and not actively looking), and only 2.5 will be in the job market -- versus, out of the 950 non-elite developers, we might have 665 (or 70%) employed, versus 285 (or 30%) on the market and actively looking.
Given this over-simplified (but arguably "less wrong") hypothesis, and assuming that a given opening draws applicants whose fitness ranking is evenly distributed across the pool of in-the-market candidates, it's easy to see that for any given opening, we'll have a ratio of 2.5:285 for elite:non-elite developers -- or a paltry 0.869%(!) of the candidate pool (2.5/287.5) will appear to be from the "elite" category.
That is, for every 1 "elite" resume in your inbox, you'll be seeing 114 "non-elite" resumes. And since tech geeks are, by and large, an insecure, envious lot, they like to brag and fudge a bit -- so that 114 easily becomes 199 in their minds (or the 1 a 0.6, whichever).
Which gives you the infamous "we only hire the top 0.5%" urban legend right there. Even though they're all really just angling over the... top 5% (ranked over the general pool of putative developers).
And since hot-shots like Joel Spolsky, not to mention nearly all of the investment bank / hedge fund types, and well, probably half or more of everyone in the monthly "Who's hiring?" thread just keeps repeating it, and repeating it, and repeating it... well, shucks, it must be true.
[1] As such a thing as generic competence exists can be objectively measured, etc, etc, but that's a separate issue.
[2] Which corresponds -- conservatively, for the purposes of this argument -- to another widely espoused, but never quantitatively substantiated belief out in startupland: that "all" of the good developers are "always" employed and "almost never" on the job market longer than 2 days.
Who cares the about what FizzBuzz REALLY is? Can't we all just agree that it's a programming test because anybody who calls them self a programmer should possess these painfully simple analytic skills. If you can translate pseudocode to code, but can't write pseudocode for FizzBuzz, you're a translator not a programmer.
I've been doing FizzBuzz and a few other code-related tests for the last few years. It was an odd shock when I realized that was the /only/ part of the interview process that had any value to me whatsoever. I mean it. I have seen people display radically different personality traits between the interview and work on Monday. The guy who was almost too nervous to speak in the interview won't stop talking peoples' ears off. The guy who really sold himself well is very shy and quiet now that he has to show up every day. I wouldn't believe if it I hadn't seen it. Not to mention language lawyers, etc. But coding tests have predictive value. YMMV of course.
I'm also surprised how many people get it wrong. I see a lot of this (pseudocode):
for (i = 0; i < 21; i++) {
if (i % 3 == 0) {
print "fizz";
} else if (i % 5 == 0) {
print "buzz";
} else if (i % 3 == 0 && i % 5 == 0) {
print "fizzbuzz";
}
}
Yeah, see, one of those branches is never going to be reached.
Consider yourself fortunate, I've screened candidates who didn't get past the "for" keyword because they couldn't construct a loop in a language of their own choosing, even after I reminded them that perfect syntax is not necessary.
I've had a surprising number of candidates who did not know about the existence of the modulo operator. Not just "I completely forgot about it", but more like "what's the % sign mean?".
> "Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”
Aside from explicitly stating "Hey, encapsulate IF/ELIF/ELSE statements in a FOR loop", FizzBuzz doesn't seem too analytical--am I wrong?
I've been interviewing a bit recently and not a single candidate has actually managed to complete it successfully (I use a slightly simpler variation with different numbers and strings). They have all been juniour but all claimed at least a few years of programming experience (counting university/school). Thinking I was going nuts, I tried it out on my colleagues including one whose total programming experience was trying to learn Python a few months ago, and they finished 100% correctly in under a minute.
I don't ask for correct syntax, an actual programming language, fret over the 100 being included or not etc. Heck I even ask them what the output would be for the "code" they just wrote and they usually get that wrong too! For a for loop and 3 arms of conditionals.
I suspect it is a standin for experience. You can get pretty far copying and pasting sample code you find on the net, maybe altering a number or two. (Or the far more telling commenting blocks of code out.) These days you can have something that appears to work by using project creators and tinkering, but not actually doing a reasonable amount of what could be considered older school programming.
It seems trivial, but yes, to some degree, it requires a little analytical thinking to get over the hurdle of deciding what to print and when. It's shocking just how many "programmers" can't figure it out, even with a little prompting.
I see a frightening number of people buying into the disturbing assertions made in TFA:
- that analytical thinking isn't necessary for programming.
- that translating pseudocode is a sufficient test of programming skill.
- that Excel isn't equivalent to a programming environment, or somehow doesn't count as programming.
- that FizzBuzz requires higher-order thinking. It's not like you're asking someone to implement lists as lambdas. Or the this website's namesake (the Y Combinator.)
I don't think engineers should ever spend their time asking Fizzbuzz. Engineers' time is valuable. And blocking off an hour for a phone screen can interrupt the day. If a preliminary code sample filtering step is used then engineers can jump straight into the meaty interview questions.
The vast majority of people who don't know programming basics like loops and conditionals won't make it to the phone screen stage. Someone might look up the solution to the programming quiz but they'll immediately fail the first interview question. And this can be partially mitigated by rotating puzzles or even changing numbers in the puzzles.
The code sample filtering step should have both a sufficiently tricky puzzle and a bank of at least 20 common corner cases. Just run the test cases automatically. The vast majority of candidates will be eliminated without wasting any engineers' time.
IMO phone screen (if it really is a "screen" and not a full "interview") should be fifteen minutes or less. I usually ask a few very specifically CS101 type questions to see if they remember any of it, and if they don't, they don't come in for an interview.
I've got to disagree here. The whole point of FizzBuzz is that it's a straight-forward analytical problem that you should be able to do easily if you understand the fundamentals.
I think some part of this issue has to be that computer science does not fully equate to coding, and the balance of coding to theory curriculum varies significantly. If you're hiring recent grads then it might make sense to give a little leeway, to help them along and see if you see some spark of analytic ability. Maybe interview nerves are an issue.
If your candidate can't do fizzbuzz but is claiming to be an experienced programmer in the required language, the situation should raise a red flag.
It's not coding, in the strictest sense that it has no computer science or is solely syntactic, but it works at weeding out people who can't build anything. At least this level of analytical thinking is necessary for any programming task, and therefore Fizzbuzz serves its purpose.
How many people have actually been asked Fizzbuzz in an interview? I recently interviewed at several places, before deciding I'd rather try my hand at independent consulting. At least two were companies with (apparently) superb engineering teams. But no one asked me this question, or any preliminary coding question at all. I was asked to code, but only after the companies had paid money to fly me out, put me up in a hotel, and have their team spend a day talking with me. I would be delighted to be asked this question, because I'd take it as a sign that the company values its time and is discriminating in its hiring.
FizzBuzz isn't a coding test, I agree. It's an interview prep test. If a candidate can't take 15 minutes to read up on common interview questions and prepare a simple answer, then they shouldn't be hired.
Higher order thinking is pretty much required to make any working program of minimal complexity. aka. be a programmer.
If you have to hand a programmer pseudo code in order to write a program, you'd be better off hiring competent programmers to write you a compiler and then you can get rid of the programmers who can't think and code it yourself in your fancy new higher order language.
This is definitely the relevant point when it comes to hiring programmers. FizzBuzz is already so close to pseudocode that if you had to write it more clearly, it wouldn't take any more time to just write the code yourself. A programmer who can only work at that level is not a benefit to your team.
You really want people who will improve your team's output by an amount greater than the value of the extra time it takes to communicate with them.
FizzBuzz can be an effective filter to very quickly get rid of the lowest level of applicants and start having a real discussion with the ones who are left.
There is analysis and there is coding. I've met and worked with people who had both skills (awesome) and only one of the two (less awesome). If you're limited in the number of people you can hire (startup) then you want both skills in the same person. I think any business analyst would agree with that.
Starting from pseudocode is a big leg up. In most situations the programmer won't have pseudocode unless he/she writes it. Users don't describe what they want clearly and unambiguously most of the time -- that's the other big skill programmers need. The first skill is being able to write FizzBuzz or something equally trivial in a couple of minutes.
If a so-called programmer or coder can't write FizzBuzz from pseudocode then presumably they won't be able to write it from a prose description, which means they are going to be close to useless solving any real problem.
seeing this makes me cry. I can code this is at least three languages (java, php, python) and I can't even get an interview for a junior dev position. I got bored the other day and tried to write it recursively because why not, right?
[+] [-] AngryParsley|13 years ago|reply
Instead of asserting this fact, put the hypothesis to the test. Ask some smart business analysts and see how many of them can solve fizz-buzz. You're much more likely to win over the audience if you have some data.
Really though, I think this post is needlessly controversial. The whole text could have been, "It makes sense to hire people with no programming experience who can solve fizz-buzz." I don't know how many people fall into that category. I'm not sure how good they'd be or how long they'd take to get up to speed, but that's fine. It's something I can think about and engage with.
The rest of the post is just arguing over definitions. If by "coding" you only mean "turning pseudocode into code", then yes a lot of things people call coding aren't coding. Likewise if by "think analytically" you mean "is able to solve fizz-buzz," then of course companies want programmers who can "think analytically."
No matter what definitions you use, the hiring practices are the same. Fizz-buzz still acts as a negative filter. People who can't solve it aren't hired. People who can solve it may or may not be hired depending on how other things go.
[+] [-] SomeCallMeTim|13 years ago|reply
He describes how he and other companies get 200 applicants for most job postings, of which only one may actually be "good enough." I've seen numbers like that myself when on the hiring end. So everyone thinks they're hiring the top 0.5%, even though the same 199 losers are spamming their resumes to every job posting.
Well, a simple way to filter out that 199 is to apply FizzBuzz or equivalent.
[1] http://www.joelonsoftware.com/items/2005/01/27.html
[+] [-] halbermensch|13 years ago|reply
Yeah, when you think about it, this whole "we only hire the top 0.5%" condescension really amounts to a basic statistical reasoning fallacy.
To construct an alternate hypothesis: the "real" threshold for ranked competence[1] at "elite" companies might, just might, be more like "the top 5%". But we can safely assume that 95% of the available talent pool in this category will be employed (and not actively seeking), compared with say 70% in the bottom, or "sub-elite" category, at any given time.[2]
So for example in a "town" of 1000 putative developers, with skill levels ranging from god-like to "good enough" to mediocre to utterly bogus and self-deluding, let's say 50 (or 5%) of these are truly "elite", and 950 are "non-elite".
Further, of the elite category, 47.5 will be employed (and not actively looking), and only 2.5 will be in the job market -- versus, out of the 950 non-elite developers, we might have 665 (or 70%) employed, versus 285 (or 30%) on the market and actively looking.
Given this over-simplified (but arguably "less wrong") hypothesis, and assuming that a given opening draws applicants whose fitness ranking is evenly distributed across the pool of in-the-market candidates, it's easy to see that for any given opening, we'll have a ratio of 2.5:285 for elite:non-elite developers -- or a paltry 0.869%(!) of the candidate pool (2.5/287.5) will appear to be from the "elite" category.
That is, for every 1 "elite" resume in your inbox, you'll be seeing 114 "non-elite" resumes. And since tech geeks are, by and large, an insecure, envious lot, they like to brag and fudge a bit -- so that 114 easily becomes 199 in their minds (or the 1 a 0.6, whichever).
Which gives you the infamous "we only hire the top 0.5%" urban legend right there. Even though they're all really just angling over the... top 5% (ranked over the general pool of putative developers).
And since hot-shots like Joel Spolsky, not to mention nearly all of the investment bank / hedge fund types, and well, probably half or more of everyone in the monthly "Who's hiring?" thread just keeps repeating it, and repeating it, and repeating it... well, shucks, it must be true.
[1] As such a thing as generic competence exists can be objectively measured, etc, etc, but that's a separate issue.
[2] Which corresponds -- conservatively, for the purposes of this argument -- to another widely espoused, but never quantitatively substantiated belief out in startupland: that "all" of the good developers are "always" employed and "almost never" on the job market longer than 2 days.
[+] [-] lopatin|13 years ago|reply
[+] [-] jlgreco|13 years ago|reply
[+] [-] techdmn|13 years ago|reply
I'm also surprised how many people get it wrong. I see a lot of this (pseudocode):
Yeah, see, one of those branches is never going to be reached.[+] [-] potatolicious|13 years ago|reply
I've had a surprising number of candidates who did not know about the existence of the modulo operator. Not just "I completely forgot about it", but more like "what's the % sign mean?".
[+] [-] danielamitay|13 years ago|reply
Aside from explicitly stating "Hey, encapsulate IF/ELIF/ELSE statements in a FOR loop", FizzBuzz doesn't seem too analytical--am I wrong?
[+] [-] rogerbinns|13 years ago|reply
I don't ask for correct syntax, an actual programming language, fret over the 100 being included or not etc. Heck I even ask them what the output would be for the "code" they just wrote and they usually get that wrong too! For a for loop and 3 arms of conditionals.
I suspect it is a standin for experience. You can get pretty far copying and pasting sample code you find on the net, maybe altering a number or two. (Or the far more telling commenting blocks of code out.) These days you can have something that appears to work by using project creators and tinkering, but not actually doing a reasonable amount of what could be considered older school programming.
[+] [-] greyfade|13 years ago|reply
[+] [-] tehwebguy|13 years ago|reply
There's no abstraction, it's literally instructing the programmer exactly what to do.
[+] [-] tkahn6|13 years ago|reply
[+] [-] smosher|13 years ago|reply
- that analytical thinking isn't necessary for programming.
- that translating pseudocode is a sufficient test of programming skill.
- that Excel isn't equivalent to a programming environment, or somehow doesn't count as programming.
- that FizzBuzz requires higher-order thinking. It's not like you're asking someone to implement lists as lambdas. Or the this website's namesake (the Y Combinator.)
Each one of these items is a big fat WTF.
[+] [-] spaghetti|13 years ago|reply
The vast majority of people who don't know programming basics like loops and conditionals won't make it to the phone screen stage. Someone might look up the solution to the programming quiz but they'll immediately fail the first interview question. And this can be partially mitigated by rotating puzzles or even changing numbers in the puzzles.
The code sample filtering step should have both a sufficiently tricky puzzle and a bank of at least 20 common corner cases. Just run the test cases automatically. The vast majority of candidates will be eliminated without wasting any engineers' time.
[+] [-] swivelmaster|13 years ago|reply
[+] [-] alexlande|13 years ago|reply
[+] [-] antiterra|13 years ago|reply
If your candidate can't do fizzbuzz but is claiming to be an experienced programmer in the required language, the situation should raise a red flag.
[+] [-] michael_fine|13 years ago|reply
[+] [-] danielharan|13 years ago|reply
Bahaha. I want to see you try. And weep.
[+] [-] pjungwir|13 years ago|reply
[+] [-] tjr226|13 years ago|reply
[+] [-] btilly|13 years ago|reply
[+] [-] gregjor|13 years ago|reply
[+] [-] gregjor|13 years ago|reply
http://www.geekschool.org/programming/fizzbuzz/
FizzBuzz in lots of languages, including LOLCode.
[+] [-] fleitz|13 years ago|reply
If you have to hand a programmer pseudo code in order to write a program, you'd be better off hiring competent programmers to write you a compiler and then you can get rid of the programmers who can't think and code it yourself in your fancy new higher order language.
[+] [-] mpdaugherty|13 years ago|reply
You really want people who will improve your team's output by an amount greater than the value of the extra time it takes to communicate with them.
FizzBuzz can be an effective filter to very quickly get rid of the lowest level of applicants and start having a real discussion with the ones who are left.
[+] [-] recursive|13 years ago|reply
[+] [-] ChuckMcM|13 years ago|reply
[+] [-] kuahyeow|13 years ago|reply
[+] [-] gregjor|13 years ago|reply
If a so-called programmer or coder can't write FizzBuzz from pseudocode then presumably they won't be able to write it from a prose description, which means they are going to be close to useless solving any real problem.
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] wheelerwj|13 years ago|reply
[+] [-] icefox|13 years ago|reply
[+] [-] kapilkale|13 years ago|reply