When it comes to "interview test" questions, the subject of FizzBuzz often comes up. There is also a Coding Horror post about it.
Now, if you bother reading sites such as this, you are probably less likely to be in the demographic of programmers who would find FizzBuzz anything but trivial.
But is it really true that 99% of programmers will struggle with it?
Really?
What is the evidence to back this up?
Some real-life examples would be very helpful in answering this question.
99%? No. A significant percentage? Yes. From my own direct experience of interviewing people I can testify to this one. It might seem insignificant to you but there are a lot of people in the programming field who have more or less faked their way through for years and apply on non-entry level positions and fail this one.
Even if you CAN easily solve it, but you give me huge static about being asked to do such a menial task will count against you. Being on a team means having to sometimes do things you might not enjoy but are necessary. If right off the bat, before we've even started to work together you think it would be best to try and assert your special status of being above doing something I've asked you to do then it will act as a mark against you.
I don't care necessarily how elegant your solution is (although that would be nice) but seeing you take a stab at it on a whiteboard and talking your way through it shows me that you're at least willing to take a stab at it. If you get indignant and say something along the lines of "I'm a problem solver, not a code monkey!" then you will be knocked down a peg.
I have had interviewees just flat out refuse to even begin to attempt it. Just simply refuse. No. Uh uh. Won't do it. I ask one or two more polite questions, thank them for their time and close the interview off.
I say this as a manager and as a developer.
I think that 99% of programmers who apply for a job (and don't get it) may struggle over it. But not 99% of programmers that are productively holding a job.
That's the nature of our modern job-seeking process. Many people who apply are not qualified.
That Coding Horror post also speaks to the way we teach Computer Science nowadays. In the past (particularly at MIT), you were required to learn things like Lisp, which pretty much requires you to grasp concepts like recursion.
Nowadays people are taught Java because it is widely used in industry, and the focus has shifted to syntax rather than deep programming thinking. I don't dislike Java; in fact, I think it's an ideal first programming language. But I have not seen my instructors teach deep programming principles with it.
I hate to say this but
The main reason I've seen programming questions fail to get answered is the fault of the asker rather than the answerer.
I can clearly remember one interview where I was being asked how to create a particular collection search algorithm that would run in constant time (Same number of look ups regardless of how many items in the collection). I fumbled and bumbled on it for 20 minutes before giving up. It was then that this genius doing the interviewing proceeded to demonstrate the answer as being something that operated in nearly constant, but still not constant time. A bit like saying "Give me an answer of zero" and then accepting 0.1.
Short of it is that I've seen too many cases where someone interviewing is asking a question that fails to meet the following criteria:
Seriously (1), I think asking people to write code in the verbal portion of an interview is stupid.
Seriously (2), I think interviewing people without asking them to write code is also stupid.
Seriously (3), You should either give them "homework", ask them to bring in code samples, or give them a laptop and couple of questions and quiet office to work on them. Then leave them alone while they work on them. I usually go with the latter approach as it limits their ability to get outside help (cheat) and I can time box it.
int? result; for (int i = 0; i < int.MaxValue; i++) { T item = (i < array.Length) ? array[i] : someDummyItem; if (item == whatWereLookingFor) result = i; } return result; - constant time :)
Commented
Jul 7, 2011 at 0:31
All you need to do is search on FizzBuzz. There was a huge wave of blog posts on it. Generally speaking the blogger said "I told people to write it in [some language] and here are the kinds of mistakes they made:" and then listed some pitfalls. The fun starts in the comments where people say "ha! that's trivial in [some other language], all you have to write is this:" followed by code. The next comment invariably finds bugs in that first one. Seems like some very good devs don't get it right the first time, in any language. Some of the errors:
When I'm hiring, I ask people to code at the whiteboard for me, nothing anywhere near that complicated (I know, you don't think it's complicated) and many candidates fail utterly. I mean like writing vb-style If, Then, End If but putting braces as well (just to be on the safe side I guess) or writing C# (and asking first, C#?) but having not one semi colon anywhere. Don't start me on logic errors!
I've read the Coding Horror article you mention, and my opinion is that Jeff is right... but when is the last time he got interviewed?
When you are interviewed, you are usually in high stress, and you often have to answer to theoretical questions (no intellisence, no google, no resharper, ... only your memory troubled by stress). That's the same in tests. Stress doesn't help you.
I've noticed that the only way to know if someone is suitable for a position is to work with him for a while... Just take the last 10 persons you hired out of 100 (maybe more), how much was a really good hire???
An employer should hire a problem solver, not a code monkey that know about modulos.
You can't test "for a while all applicants", so interviewing them is required. That's why I focus my questions on that (problem solving) and do past reference check.
My opinion is that the FizzBuzz is dangerous for the company that is looking for developers to substain its growth.
I was recently tasked with interviewing over 50 programmers for a senior position where they would be working mostly with PHP.
I tossed the fizzbuzz problem on the screening exam, mostly to amuse myself and because I wanted ten good questions and had only nine. My intent, at the time was to show people that we can have fun too, even on interview questions.
80% Of the applicants solved the problem, but did not use the modulus operator.
15% of the applicants could not solve the problem.
5% of the applicants solved the problem using the modulus operator.
While my sampling is quite limited (50 applicants from one country), I can tell you that:
95% of them had a BS or higher in a CS curriculum (universities here compete by trying to make CS sound more spectacular).
I was truly amazed. Well, frightened .. but amazed. I did not think I'd come close to reproducing the results, since the problem has become so popular. This shows me that 5% of my applicants might not be super programmers, but at least they read programming related blogs.
x - (x/y)*y?
Commented
Sep 21, 2014 at 21:06
In my last round of hiring I had 3 construction workers with 0, I repeat zero, programming education or experience apply for a software developer position.* So that's the bottom of the barrel. If you assume a normal distribution of skill, then you can see how the average skill level will be quite low and even 'above average' (amongst applicants) will still be relatively bad.
Now, if you're fizzbuzzing only the applicants that had what appeared to be some programming ability, you'll find that you now have:
Additionally, some 'fizzbuzz' questions that I've seen are domain specific. You can progressively develop with a language/framework x for a number of years (hence z years experience with x) and not have come across certain parts of it (library developers not knowing much about UI component development for eg.)
Likewise, lots of developers do maintenance development these days, so their architecture/design skills may be weak in some areas.
Now, I'm not sure if 99% is accurate, but IME it's still pretty high. At least in the 80% range.
* No, we didn't call or even give a second look at these applications.
Yes really. Probably not 99% but still pretty high. I used to interview computer science students for internships and full time hires. I'd interview about 25 students at a college. We were told not to ask the same questions, because the students talked. I quickly learned that it didn't matter, because I would only get 3 or 4 students out of the 25 who could answer my first question. "Write strcmp"
I asked them to write a function to compare two strings. Maybe to use the function to sort words for a dictionary. You would be amazed at the number of students who didn't understand how to compare two words, let alone know how to write the function. And some of these students claimed they got all A's in CSc.
The thing is programming is VERY DIFFICULT. A lot of people like to think they know how to program, but they don't.
Some thoughts:
I wouldn't hold it against someone if their program had some bugs but they clearly had the right idea. Debugging is part of programming.
I think it is sad that so many people are applying for jobs they don't know they can't do. Seems to me like a problem with the economy.
It is really easy to ask people bad questions, where the only "correct" answer is the one the interviewer would give.
This test very nicely covers several things I want to know about a programmer I might hire:
To elaborate on the last point, there are countless solutions to fizz-buzz. Do you go for readability? Speed? Brevity? Do you try to finish writing the program quickly? How a programmer attacks this simple problem is very telling. If a programmer can't pick a solution and see it through to the end, what does that tell you about how this person will perform on a real task?
Unfortunately, many people with impressively looking resumes do seem to lack basic programming skills. I have seen many cases when people who list C and C++ on their resumes could not answer basic questions about pointers.
There are two types of people I would hope that FizzBuzz would help me avoid.
In either case, I don't really care about a perfect implementation. The test that you need to make with people applying for developer jobs is that they can program at all.
That said, I would probably not bother with that particular test for several reasons now. Firstly it's very well known and either of the above groups would be quick to try it. Secondly I would prefer to use Steve Yegge's phone screen questions to screen out non-programmers before we got as far as bringing them in. If someone recognised those questions it would imply they had read Steve Yegge's blog which would suggest to me they were in the top 1% of developers who take their profession seriously and certainly warrant an interview. Likewise if someone had some good rep here or on SO I would be inclined to interview them.
It's hard to believe that developers can't code FizzBuzz until you see the "nine-to-fivers" that copy and paste their work together and conciously try not to write code. I couldn't believe it when I heard one of our senior developers teaching a C# developer, with 3 years "experience", how to use a Dictionary. Interfaces? Design patterns? stdout? YAGNI? My lead had never heard of YAGNI! It's amazing what these people don't know.
I believe it now. I also think there's too many developers just doing enough.
I think part of why it is such a popular question is because there is more then one way of answering it, and depending on which way the candidate chooses to go can give you an insight about how they code. Some great examples can be seen here if you have 10K rep on Stack Overflow.
As to the 99% statistic, check where that number comes from. It is probably biased. If it is based off entry-level programmers interviewing for their first job, then yes I can see that being possible, especially if the majority of their candidates are coming straight out of college. I can actually think of someone who probably would write out a 100 condition if statement as a solution to that problem.
I find the statement that 99% of the programmers are unable to program or to solve a simple coding test highly exaggerated. In the case of the FizzBuzz test, either you have encountered this problem before and can easily solve it with the modulo operator or you have not encountered it before and will struggle with it. It tells the interviewer nothing about your programming skills.
I think the problem with many programmers apparently leaving a bad impression at an interview lie in the nature of technical interviewing methods. Interviewers expect applicants to memorize and instantly reproduce language syntax, details and computational complexity of data structures, hardware architectures, design patterns, etc, etc. The area of computer science/software engineering is vast. It is impossible and insensible to try to memorize everything.
In the real world, the key is to be able to understand the programming/design problem assigned to you and to know where to find information(your IDE, man pages, books, google, etc) how to solve your problem. This is something however that interviewers never test for.
I am still a relatively junior programmer (I have been coding for money for ~2 years and coding in some professional capacity as a side-responsibility for about 2 before that) so use sufficient grains of salt.
I have some experience doing a first screen for coders for a Large Enterprise Project (we kinda knew the project was doomed, but hey, they wanted to pay anyways). As the only programmer at the firm doing the hiring I was given the task of reviewing resumes and screening applicants.
This was for a government project so it perhaps probably didn't attract the most talented applicants, but I did not receive one application from anyone with a github account that actually had code shown, nor anyone who had a portfolio, so I used fizzbuzz (literally the exact problem) as a first pass on anyone who looked like they might be able to program.
I prefaced it with a pseudo-apology stating that I knew it was stupid but that I just wanted to see any working code, and if they wanted they could send another example of equal or greater value or really anything, but that fizzbuzz would suffice.
The result: I didn't get one response that was actually correct, which is mind-blowing considering the volume of answers on the internet. No one even bothered to plagiarize. We had to just go with hiring people who had previously worked on the failed previous iterations of the project.
After the initial shock of the exercise and disappointment about how screwed government software/contracting was, I felt much better about my own skills, so small victories?
Edit: By not correct I don't mean an off-by-one error (i.e. I asked for through 100 not 99) or some other innocent bug that is an easy fix. I mean not functional, either won't run/compile/etc or showed clearly that the problem was just not read and understood, also a significant portion withdrew the application and not one sent some other code instead.
