Fizzbuzzed(dominickm.com)
dominickm.com
Fizzbuzzed
http://dominickm.com/?p=514
77 comments
I completely disagree that the question is a bad question. He does not say there is a right answer, only that they are able to make a competent argument about what language they like and why. The point of the question is to see if they have actually put much thought into developing software. Enough thought, in fact, to have an opinion on what they like and why. Furthermore, it tests their ability to verbalize convincing arguments for their opinions with logical evidence for those arguments. These are skills that are needed when working in a development team.
Now if he is saying, "well they said python and I hate python, so they are wrong!" Then, obviously, that is not a good interview tactic. But I didn't find that to be the case from the way it was presented in the article.
Now if he is saying, "well they said python and I hate python, so they are wrong!" Then, obviously, that is not a good interview tactic. But I didn't find that to be the case from the way it was presented in the article.
The problem isn't that there's a wrong answer, it's that it doesn't immediately admit apples-apples comparisons between candidates, it's hard to structure it so it can do that, and even harder (probably requiring several generations of candidates) to tune the apples-apples criteria to find something that actually predicts how candidates will actually perform the job.
Those are the big theoretical problems with questions like that. But the pragmatic problems with it are even worse: they are a lens that focuses and applies subjective biases on the part of interviewers. Developers are terrible psychologists, and subjective interviews are the one time that we demand that software developers perform as psychologists.
The best job interview questions are strictly and (as closely as possible) objectively predictive, and the easiest predictive questions to ask are work-sample questions: "here is a problem we solve routinely in this job, candidate, please solve it yourself."
Those are the big theoretical problems with questions like that. But the pragmatic problems with it are even worse: they are a lens that focuses and applies subjective biases on the part of interviewers. Developers are terrible psychologists, and subjective interviews are the one time that we demand that software developers perform as psychologists.
The best job interview questions are strictly and (as closely as possible) objectively predictive, and the easiest predictive questions to ask are work-sample questions: "here is a problem we solve routinely in this job, candidate, please solve it yourself."
I still completely disagree with you. You are misunderstanding the point of the question, and probably missing the importance of being able to formulate an opinionated argument about development and present it to a team. That is the point of the question.
You should not be apples-apples comparing candidates anyway. Everyone is different, and it is a collection of skills that you need to be a developer.
Candidate A may be a person who isn't as quick with coding, but they can quickly architect a solution in their mind and formulate an opinionated argument about why it is superior.
Candidate B may be an incredible coder, but unable to explain their methodology, or architect a solution that is generic and re-usable.
Both of these candidates can be an asset to the team in different ways. I find a lot of developers, the "JUST LET ME CODE" types, really don't understand the communication skills needed to develop an application with a large group of people. This question helps find people that will be better in that group situation, regardless of how strong their coding skills may be...because coding is only a portion of the job, in the real world.
Edit: I also pointed out in my reply, that an interviewer who takes a subjective bias when assessing the answer to this question is doing it wrong.
You should not be apples-apples comparing candidates anyway. Everyone is different, and it is a collection of skills that you need to be a developer.
Candidate A may be a person who isn't as quick with coding, but they can quickly architect a solution in their mind and formulate an opinionated argument about why it is superior.
Candidate B may be an incredible coder, but unable to explain their methodology, or architect a solution that is generic and re-usable.
Both of these candidates can be an asset to the team in different ways. I find a lot of developers, the "JUST LET ME CODE" types, really don't understand the communication skills needed to develop an application with a large group of people. This question helps find people that will be better in that group situation, regardless of how strong their coding skills may be...because coding is only a portion of the job, in the real world.
Edit: I also pointed out in my reply, that an interviewer who takes a subjective bias when assessing the answer to this question is doing it wrong.
You believe that you shouldn't try to hire based on apples-to-apples comparisons of developers. I not only don't agree with you, but I run a (relative to startups) high-volume recruiting practice premised on that belief. We're not going to agree, and that's fine.
In the 12 years of my career prior to discovering objective, work-sample, standardized, data-driven hiring, I hired exactly the way you're advocating. I sought out questions like the one you're advocating for. My favorite question from that time: "if you had to put together a libyou.a that you take from project to project, what would be in that library?" I found it to be a great way to start a conversation with a candidate to get inside of their head, and also liked the fact that it quickly gave me a signal as to whether the candidate had actually done the kind of work we did in our shop.
As it turns out, the ability to project a signal as to whether a candidate has actually done the kind of work we do in our firm is not actually useful. What's useful is: "if the candidate is put in a reasonable position to try, can they actually perform the tasks the role requires". Surprisingly --- in fact, shockingly --- I've found zero correlation between the capacity to signal ability and the capacity to demonstrate ability. ZERO. Our best performers six months in, as often as not, interview terribly on "signalling" terms, and were hired because work-sample testing overrode those concerns.
In the 12 years of my career prior to discovering objective, work-sample, standardized, data-driven hiring, I hired exactly the way you're advocating. I sought out questions like the one you're advocating for. My favorite question from that time: "if you had to put together a libyou.a that you take from project to project, what would be in that library?" I found it to be a great way to start a conversation with a candidate to get inside of their head, and also liked the fact that it quickly gave me a signal as to whether the candidate had actually done the kind of work we did in our shop.
As it turns out, the ability to project a signal as to whether a candidate has actually done the kind of work we do in our firm is not actually useful. What's useful is: "if the candidate is put in a reasonable position to try, can they actually perform the tasks the role requires". Surprisingly --- in fact, shockingly --- I've found zero correlation between the capacity to signal ability and the capacity to demonstrate ability. ZERO. Our best performers six months in, as often as not, interview terribly on "signalling" terms, and were hired because work-sample testing overrode those concerns.
It is just a nitpick, but opinionated argument about superiority of a solution that person just quickly architected is not a good thing. Opinionated argument about a solution that the person through out and really considered advantages/disadvantages is a good thing.
Opinionated argument about half through unprepared ideas are fun, but waste of time when done during meetings.
Opinionated argument about half through unprepared ideas are fun, but waste of time when done during meetings.
For your type of industry or company perhaps. Not all jobs or companies are the same, and different styles of questions will be more useful depending on those.
A lot of development shops work by picking the best technology for the job. They choose the best plugin, or the best language, or the best component. In those types of shops, this question is exactly as you say - a task they will have to do routinely in the job.
A lot of development shops work by picking the best technology for the job. They choose the best plugin, or the best language, or the best component. In those types of shops, this question is exactly as you say - a task they will have to do routinely in the job.
My type of industry is "consulting software development in every mainstream programming language and on every stack". We could have a very long thread arguing the point, but I'm going to go out on a limb and say that I hire for an unusually representative segment of the software development industry.
I get what you're saying, but I think that's true of every interview question. There are no truly objective questions and people are unique; there is no way to make an apples-to-apples comparison of two different people.
I think work-sample questions are really good, but you're still optimizing for people who can solve problems in the extremely artificial context of a job interview.
I think work-sample questions are really good, but you're still optimizing for people who can solve problems in the extremely artificial context of a job interview.
"in the extremely artificial context of a job interview" is also true of every interview question. So giving it as a criticism of work-sample questions, when comparing those to other types of question, is meaningless.
One nice benefit of work-sample hiring processes is that you can rig them to counteract the inherent hostility of a job interview, in ways that you can't easily apply to person-to-person free-form interviews.
I just went through a process like this as a candidate. I was emailed a problem description and told, "Please send us the code that solves this problem. Do so at your leisure, and please don't spend more than x hours on it." This meant I got to use my own setup, and didn't feel as though I was required to come up with the "perfect" solution.
When you think about it, it's odd that most programmers aren't interviewed this way. As a firm, the most important question I want answered is "Can the candidate do the job?" There are obviously other important considerations, but that's numero uno. And the best way to tell whether the candidate can do the job is to ask them for a small sample to prove it.
I'm 100% certain I've been passed over for positions at other places because the hiring process isn't generally designed to answer that question accurately. It's something I want to keep in mind for when I'm on the other side of the table.
When you think about it, it's odd that most programmers aren't interviewed this way. As a firm, the most important question I want answered is "Can the candidate do the job?" There are obviously other important considerations, but that's numero uno. And the best way to tell whether the candidate can do the job is to ask them for a small sample to prove it.
I'm 100% certain I've been passed over for positions at other places because the hiring process isn't generally designed to answer that question accurately. It's something I want to keep in mind for when I'm on the other side of the table.
The problem is like its asking you what your favorite type of glue is. Favorite hammer. Favorite color. Favorite grade of gasoline. Unless you have some weird emotional attachment to the subject it makes no sense.
I understood it more in the sense that "as long as candidate can answer the question, with a sensible reason, and defend the reason" - even if the interviewer disagrees with the candidate.
Here's some answers that meet your criteria: They answer the question, they give a reason, and you might disagree with it.
"My favorite language is Haskell because it lets me reason about the correctness of my program before I even try running it."
"My favorite language is Python because that's what we used in school."
"All I know is Matlab, and whenever I've needed to program something I've always been able to do it in Matlab, so I never bothered to learn anything else."
"I guess my favorite language is C#. That's what pays the bills. Everything at work has always been written in C# or Visual Basic."
"My favorite language is Java, because that's what I use to write Minecraft mods, but I actually work as a COBOL programmer where I have twenty-five years of experience."
All of these answers are technically "correct", but the interviewer will inevitably judge some of them to be "more correct" than others. It's subconscious and it can't be helped.
Moreover, when you get together with a team for a post-mortem and get asked what you think about the candidate, the answer you give will be culturally conditioned. So I can predict what many teams are likely to say: The Python person is "awfully inexperienced". The Matlab person is "a bit narrow". The C# person is a tool, of course, unless we actually work with the Microsoft stack. The top marks are likely to go to the Haskell or the COBOL person; victory may hinge on the team's prevailing opinion of Minecraft.
Which of these answers is most indicative of potential success as, say, a Rails developer? None of them. There is probably no signal here at all.
"My favorite language is Haskell because it lets me reason about the correctness of my program before I even try running it."
"My favorite language is Python because that's what we used in school."
"All I know is Matlab, and whenever I've needed to program something I've always been able to do it in Matlab, so I never bothered to learn anything else."
"I guess my favorite language is C#. That's what pays the bills. Everything at work has always been written in C# or Visual Basic."
"My favorite language is Java, because that's what I use to write Minecraft mods, but I actually work as a COBOL programmer where I have twenty-five years of experience."
All of these answers are technically "correct", but the interviewer will inevitably judge some of them to be "more correct" than others. It's subconscious and it can't be helped.
Moreover, when you get together with a team for a post-mortem and get asked what you think about the candidate, the answer you give will be culturally conditioned. So I can predict what many teams are likely to say: The Python person is "awfully inexperienced". The Matlab person is "a bit narrow". The C# person is a tool, of course, unless we actually work with the Microsoft stack. The top marks are likely to go to the Haskell or the COBOL person; victory may hinge on the team's prevailing opinion of Minecraft.
Which of these answers is most indicative of potential success as, say, a Rails developer? None of them. There is probably no signal here at all.
Yes, that's what I'm looking for what I ask this question.
There's no wrong answer, but if your resume says you've developed projects in C and in Java but you are not able to articulate any reasons you might pick one over the other, I'm a little suspicious. It doesn't even really have to be languages; I mostly just want to hear you have a well-reasoned opinion on something.
There's no wrong answer, but if your resume says you've developed projects in C and in Java but you are not able to articulate any reasons you might pick one over the other, I'm a little suspicious. It doesn't even really have to be languages; I mostly just want to hear you have a well-reasoned opinion on something.
Most of the time, the factually correct answer to "why did you choose to work with Language X?" is "because when I arrived on the job, the existing software was implemented in X".
Is that a well-reasoned opinion? "I'd like to pay the rent this month" is a good reason. "The company doesn't have the time to reimplement working software on a different platform" is a good reason.
Of course, a well-socialized programmer understands that these answers, while truthful, are insufficient, and will have duly memorized a stock answer like "You pick C when you really need runtime performance and don't mind all the segmentation faults, otherwise you pick Java."
Is that a well-reasoned opinion? "I'd like to pay the rent this month" is a good reason. "The company doesn't have the time to reimplement working software on a different platform" is a good reason.
Of course, a well-socialized programmer understands that these answers, while truthful, are insufficient, and will have duly memorized a stock answer like "You pick C when you really need runtime performance and don't mind all the segmentation faults, otherwise you pick Java."
Sure, that factually correct answer is fine, but you've changed the question to something less insightful. It wouldn't make sense to ask a candidate why they used language X for project Y unless they had a choice the decision. Most people don't. I know that.
If you gave me that "stock answer" I'd ask followups. This isn't a trivia question with a secret "right answer" password.
And hey, it's not the Worlds Greatest Interview Question, but I like it a whole lot better than "explain Quicksort" or "write out pseudocode for calculating a checksum on the whiteboard"
If you gave me that "stock answer" I'd ask followups. This isn't a trivia question with a secret "right answer" password.
And hey, it's not the Worlds Greatest Interview Question, but I like it a whole lot better than "explain Quicksort" or "write out pseudocode for calculating a checksum on the whiteboard"
My issue with that question would be that it favors students who spent a lot of time reading blogs, slashdot/HN/other journal like discussions over those that spend time coding. If you read enough of such opinions pieces, then you should pass this line of questioning reasonably and defend it even if you hardly used the tech in question.
I am saying that as someone who would confidently blable about agile development (it is the thing back then) and architectural designs/patterns without experiencing them on a real project at that age.
Those questions may show whether the candidate has general well roundness, but they are not likely to distinguish those who can do from those who can not do. Someone who focus on solving problems and coding will be able to answer them to some level, but it is very easy for him to answer less well and in less details.
I am saying that as someone who would confidently blable about agile development (it is the thing back then) and architectural designs/patterns without experiencing them on a real project at that age.
Those questions may show whether the candidate has general well roundness, but they are not likely to distinguish those who can do from those who can not do. Someone who focus on solving problems and coding will be able to answer them to some level, but it is very easy for him to answer less well and in less details.
It turns out that I don't care where you got your ability and aptitude, so long as you can actually deploy that ability and aptitude on problems relevant to my business.
That's another problem with subjective interviews: it allows developer interviewers to apply their biases about the genealogy of knowledge to candidates.
That's another problem with subjective interviews: it allows developer interviewers to apply their biases about the genealogy of knowledge to candidates.
I'd argue that having that breadth of knowledge is nearly as valuable as the ability to actually write code, so I don't know that this is such a bad thing. The ability to understand the complexities and tradeoffs across a large range of potential solutions/toolsets/etc is extremely important, otherwise people fall into the "everything's a nail ..." problem.
@jghn There is a difference between asking also those questions to learn about candidates breadth of knowledge on one hand and making it a focus of interview on another. Former is ok, latter will select strong talkers and will have little relationship to actual ability to produce anything.
That's why I said it was nearly as important as the ability to code.
By that I meant that if interviewing a candidate you should be able to say w/ reasonable accuracy if they can a) actually write code (personally I don't usually care if it involves the tech stack I'm using) and b) have a strong breadth of knowledge on different paradigms, tools, languages, etc so that their decision making will be well informed going forward. Note that my lack of caring about tech stacks/languages/etc is because I've found people who are strong at b) are able to pick those things up rapidly, assuming that they actually can code in the general sense.
By that I meant that if interviewing a candidate you should be able to say w/ reasonable accuracy if they can a) actually write code (personally I don't usually care if it involves the tech stack I'm using) and b) have a strong breadth of knowledge on different paradigms, tools, languages, etc so that their decision making will be well informed going forward. Note that my lack of caring about tech stacks/languages/etc is because I've found people who are strong at b) are able to pick those things up rapidly, assuming that they actually can code in the general sense.
>'In no other job capacity do software developer's subjective beliefs and opinions get applied so directly to business outcomes.'
Absolutely.
I think several of the responses to this post are missing the key word here - subjective. Asking subjective questions and qualifying them with subjective criteria like 'reasonable' is necessarily going to allow for the subjective beliefs and opinions of the developer turned 'CEO for an interview' to affect the business.
Absolutely.
I think several of the responses to this post are missing the key word here - subjective. Asking subjective questions and qualifying them with subjective criteria like 'reasonable' is necessarily going to allow for the subjective beliefs and opinions of the developer turned 'CEO for an interview' to affect the business.
I could imagine that those sorts of people, the ones who let interviews go to their head, the ones who feel the need to impose their will on the interviewee and the interview process, are likely to cause problems with the candidate if he/she is hired.
Have you seen people who mesh perfectly well but go to hell in a handbasket when you throw them in an interview? It feels like that is something, however arbitrary and difficult to test, that you'd catch when you interview these people - avoid anyone whose fitment is questionable at all, and that your statement is merely a byproduct of not catching these bad interviewers before you extended them an offer.
Have you seen people who mesh perfectly well but go to hell in a handbasket when you throw them in an interview? It feels like that is something, however arbitrary and difficult to test, that you'd catch when you interview these people - avoid anyone whose fitment is questionable at all, and that your statement is merely a byproduct of not catching these bad interviewers before you extended them an offer.
Yes. 2 of our 3 best hires in the last 18 months were extremely awkward in interviews, so much so that we had to carefully edit out negative feedback that obviously derived from the candidate's discomfort in the interview.
My thesis is that practically all software developers are bad interviewers. I'm not suggesting that there are a couple bad apples that turn into tyrants during interviewers, but rather that the interview process is a vector that pushes software developers into a subtly bad place, in a Stanley Milgram sort of way.
My thesis is that practically all software developers are bad interviewers. I'm not suggesting that there are a couple bad apples that turn into tyrants during interviewers, but rather that the interview process is a vector that pushes software developers into a subtly bad place, in a Stanley Milgram sort of way.
I've been programming for a couple years now, part time. I work in IT troubleshooting proprietary software on customer's machines. I've written several vb.net applications to automate things in the office. (Screen scraping/website automation, log file readers/parsers,, etc...) Lately I've been working in python more for my screen scraping needs and also learning web2py. I've thought about trying to apply for a programming job where I work, or at least maybe see if I can shadow a programmer to see what it's like.
I've always been put off by thinking that I'd just be embarrassed because I'm not good enough and they'd laugh at my code. Nobody in my group at work does any kind of coding or scripting, and all my work is proprietary and I can't really share it on the internet for feedback. I've heard of this fizzbuzz test before, but just now looked up what it is exactly. I can't believe how easy that is, and that people are actually failing at it. Makes me feel like maybe I should apply for some of the developer jobs at our company.
I've always been put off by thinking that I'd just be embarrassed because I'm not good enough and they'd laugh at my code. Nobody in my group at work does any kind of coding or scripting, and all my work is proprietary and I can't really share it on the internet for feedback. I've heard of this fizzbuzz test before, but just now looked up what it is exactly. I can't believe how easy that is, and that people are actually failing at it. Makes me feel like maybe I should apply for some of the developer jobs at our company.
> I'd just be embarrassed because I'm not good enough and they'd laugh at my code.
I don't think one is a good programmer until one believes themself to be a bad programmer.
When I was more green, I used to think "I've got this!", but as I learned more, I began to realize how little I really knew.
I don't think one is a good programmer until one believes themself to be a bad programmer.
When I was more green, I used to think "I've got this!", but as I learned more, I began to realize how little I really knew.
> I've always been put off by thinking that I'd just be embarrassed because I'm not good enough and they'd laugh at my code.
The good news is that you already sound like a programmer. It's been a decade since I first started programming and I'm excited when I don't cringe at code I wrote half a year ago.
The fact that you seem driven and willing to learn should be assets when you are applying.
The good news is that you already sound like a programmer. It's been a decade since I first started programming and I'm excited when I don't cringe at code I wrote half a year ago.
The fact that you seem driven and willing to learn should be assets when you are applying.
Also look up [Dunning-Kruger effect]. You know enough to be worried you don't know enough! Definitely apply for developer positions, or work on external projects, where the details of your work can be discussed with other technical peers – not just its output as evaluated by non-technical people. It's the best way to improve.
To clarify, I don't think "Fizzbuzz" necessarily means "printing out Fizz on multiples of 3, Buzz on multiples of 5, etc." Fizzbuzz generally refers to a simple programming test to make sure candidates can actually write some amount of code.
No, it literally means what you said above, and the majority of applicants literally can't do it. It's shocking and sounds ridiculous, but is true.
I've interviewed people for a junior position recently. I gave the FizzBuzz test, verbatim from Wikipedia. Only about 10% were able to do it on a whiteboard, without help.
I can't write any code effectively on a whiteboard in front of an audience. -> I'm a terrible programmer.
TIL I'm a terrible programmer.
TIL I'm a terrible programmer.
An audience of one. What about on a piece of paper? In front of a computer. How would do in code reviews? You can state your concerns to the interviewer to see if they can accommodate.
I've never seen a whiteboard interview with only one interviewer. The smallest was 2.
Whiteboards are for diagramming things more complicated than lines of code. [e.g. Interactions between several web services or paths of control across entire programs]
I've honestly just accepted that by the standards of many people's interviewing processes I'm a bad programmer. :)
Whiteboards are for diagramming things more complicated than lines of code. [e.g. Interactions between several web services or paths of control across entire programs]
I've honestly just accepted that by the standards of many people's interviewing processes I'm a bad programmer. :)
Yup. Hell, if you think you can do it, but you're put off by a whiteboard, I'll get you a laptop with a development environment on it and leave the room to let you work on the problem.
Interviews are stressful. Keeping the candidate relaxed should be on the interviewer's mind.
Interviews are stressful. Keeping the candidate relaxed should be on the interviewer's mind.
>Pretty much everyone I asked to do Fizzbuzz failed
…I can't help but wonder what that really means? They gave up without producing any work? The program didn’t compile because they were typing random characters into the IDE? They were unfamiliar with the IDE, and couldn’t find the "compile" button? They couldn’t get the program to compile because of missing semicolons? The program didn’t write anything out to the terminal? The program never printed out "Fizz"? They printed out "FizzBuzz" on every line? The program never printed out numbers? The program printed out commas instead of newlines after every number? They went from 1 to 101 instead of 1 to 100?
…I can't help but wonder what that really means? They gave up without producing any work? The program didn’t compile because they were typing random characters into the IDE? They were unfamiliar with the IDE, and couldn’t find the "compile" button? They couldn’t get the program to compile because of missing semicolons? The program didn’t write anything out to the terminal? The program never printed out "Fizz"? They printed out "FizzBuzz" on every line? The program never printed out numbers? The program printed out commas instead of newlines after every number? They went from 1 to 101 instead of 1 to 100?
>I can't help but wonder what that really means?
My guess: it's the unfamiliarity of the mathematical modulus operator that trips most people up. A lot of CRUD developers will never need to use modulus calculations in day-to-day work. Pull some values from a database record, throw it up on a form, then save it back. Use plus+ for totaling dollar amounts. Use multiply* for calculating sales tax. A LOB programmer can do stuff like that for years without modulus% anywhere in his code. Something like credit-card number validation does use modulus calc but programmers can just copypaste[1] someone else's example or just use a library.
However, a lot of these FizzBuzz discussions talk about computer science graduates specifically. A lot of CRUD devs do not have formal comp sci backgrounds so it's somewhat understandable that they're not familiar with modulus. However, I can't think of a reason why a compsci grad wouldn't know it.
[1]http://www.codeproject.com/Tips/515367/Validate-credit-card-...
My guess: it's the unfamiliarity of the mathematical modulus operator that trips most people up. A lot of CRUD developers will never need to use modulus calculations in day-to-day work. Pull some values from a database record, throw it up on a form, then save it back. Use plus+ for totaling dollar amounts. Use multiply* for calculating sales tax. A LOB programmer can do stuff like that for years without modulus% anywhere in his code. Something like credit-card number validation does use modulus calc but programmers can just copypaste[1] someone else's example or just use a library.
However, a lot of these FizzBuzz discussions talk about computer science graduates specifically. A lot of CRUD devs do not have formal comp sci backgrounds so it's somewhat understandable that they're not familiar with modulus. However, I can't think of a reason why a compsci grad wouldn't know it.
[1]http://www.codeproject.com/Tips/515367/Validate-credit-card-...
>My guess: it's the unfamiliarity of the mathematical modulus operator that trips most people up.
This is an interesting hypothesis, can anyone confirm that this is a particular sore spot? I wonder if that would show up as a generational gap? If the younger generations are working with web pages and never used much arithmetic, let alone remainders. But older generations grew up with low level graphics programming and arrays in languages like C and assembly where the modulus comes up all the time. So could we come up with the moral equivalent of FizzBuzz that a much larger percentage of the people who failed FizzBuzz could pass? And then I'd like to see how hard I'd think that test was.
This is an interesting hypothesis, can anyone confirm that this is a particular sore spot? I wonder if that would show up as a generational gap? If the younger generations are working with web pages and never used much arithmetic, let alone remainders. But older generations grew up with low level graphics programming and arrays in languages like C and assembly where the modulus comes up all the time. So could we come up with the moral equivalent of FizzBuzz that a much larger percentage of the people who failed FizzBuzz could pass? And then I'd like to see how hard I'd think that test was.
Even if you're unfamiliar with the modulus operator, it's not that hard to test divisibility.
C and sufficiently similar: x == k*(int)(x/k)
C and sufficiently similar: x == k*(int)(x/k)
I have done a fair share of interviewing and have asked people to do things similar to FizzBuzz in their own favourite language. When they fail, it's not about the details. (I don't mind mistakes, although I do ask and see if the candidate can spot them when given a hint.) It's amazing how many people completely and utterly fail at the task. They can't produce a loop, they can't come up with the necessary if statements, they can't even explain in pseudocode or verbally which steps need to be taken. They don't even know where to start. Sometimes it's because of anxiety or stress, but usually when it's an indication someone has no practical programming experience.
It means they can't succeed in writing the code. It's not a failure to understand how to use the IDE, or a failure to understand how to compile. It's that the applicant cannot actually write even the most basic code. The fact that this is so hard to believe and yet happens so often is what makes FizzBuzz so interesting.
I also wonder this same thing. I was asked to whiteboard fizzbuzz in pseudocode during an interview, and I actually made a slight mistake, I can't remember what it was now, but I think it would have duplicated the "FizzBuzz" lines. Overall, the accuracy of my 5 minute solution had little to no insight into how I would perform as a developer.
Now, if they were given time to actually compile code that ran a fizz buzz program and test it out before submitting it and STILL got it wrong...that might be questionable. But I think we need more information to really see if it was a bad assessment of their abilities or truly "bad" developers.
Now, if they were given time to actually compile code that ran a fizz buzz program and test it out before submitting it and STILL got it wrong...that might be questionable. But I think we need more information to really see if it was a bad assessment of their abilities or truly "bad" developers.
>There is however one last hurdle — a written test in the form of Fizzbuzz.
A "last hurdle"? Shouldn't it be the first hurdle?
I thought the point of using FizzBuzz in its proper context was to be a quick filter to weed out the majority of candidates. That way, you avoid wasting interview time with them.
A "last hurdle"? Shouldn't it be the first hurdle?
I thought the point of using FizzBuzz in its proper context was to be a quick filter to weed out the majority of candidates. That way, you avoid wasting interview time with them.
Everyone starts out thinking that, especially when interviewing juniors. "I'll use FizzBuzz to weed out the 5% who are just outright lying about having programmed ever before in their lives, and after they bang it out in 30 seconds, we can move on to something interesting!"
Ten interviews later, you're just praying that SOMEONE will please just pass the FizzBuzz so you can hire them on the spot and go drink vodka to forget the entire experience. It's really sad.
Ten interviews later, you're just praying that SOMEONE will please just pass the FizzBuzz so you can hire them on the spot and go drink vodka to forget the entire experience. It's really sad.
I don't like making job applicants do work -- even something as simple as fizzbuzz -- if it's unlikely I'm going to hire them. Just seems unfair. Also, if I'm giving someone a test, I'd prefer they work on it in front of me, which means it won't be the first screen. And finally, I don't think struggling on FizzBuzz necessarily means "No Hire."
(I actually don't really give these sort of tests at all anymore. Didn't seem that useful in practice.)
(I actually don't really give these sort of tests at all anymore. Didn't seem that useful in practice.)
> -- if it's unlikely I'm going to hire them.
But how do you get to the "unlikely" determination? Do you want to get a ballpark reading on "unlikely" within the first 10 minutes of the interview or at the very end after investing an hour?
I'm not suggesting that FizzBuzz is the be-all-end-all but for the folks who already do find useful as a low-investment bs filter, it makes the most sense to use it at the beginning of the process and not at the end. Using it as a "last hurdle" makes no sense if you have a stack of resumes to plow through. If you have prior assumptions that 90% of those candidates are not competent at programming, what's the logic in using FizzBuzz as the last step? You want to identify the 10% as quickly as possible before investing too much extended interview time.
But how do you get to the "unlikely" determination? Do you want to get a ballpark reading on "unlikely" within the first 10 minutes of the interview or at the very end after investing an hour?
I'm not suggesting that FizzBuzz is the be-all-end-all but for the folks who already do find useful as a low-investment bs filter, it makes the most sense to use it at the beginning of the process and not at the end. Using it as a "last hurdle" makes no sense if you have a stack of resumes to plow through. If you have prior assumptions that 90% of those candidates are not competent at programming, what's the logic in using FizzBuzz as the last step? You want to identify the 10% as quickly as possible before investing too much extended interview time.
Yup, you're probably right. If you're at the end of the process and on the cusp of hiring someone to write code but you're not sure whether they can write simple code then there's probably something wrong with your process.
"But how do you get to the "unlikely" determination?"
M positions, N > 2*M candidates.
M positions, N > 2*M candidates.
Not necessarily... you can ask for code samples up front, then later in the interview see if the candidate is actually capable of living up to the expectations set by the code samples.
FizzBuzz is just a bozo filter. Sure, it screens out unqualified applicants. But why are you even getting unqualified applicants in the first place? It's because your hiring strategy is fundamentally flawed.
When I go out to look at job postings, that is all that I see. Single, standalone jobs. What I really need to see is an entire career track within the same company, from green rookie all the way up to the highest non-executive position on that track.
If I saw that, I could self-select for the position that is most appropriate to my current skill level. You wouldn't need to use FizzBuzz as my bozo filter. You would have to use a more difficult task, such as prioritizing a list of bugs and feature requests in a hypothetical program, based on perceived severity, resource requirements, and business needs.
But it seems like companies now only ever want developers with 5-10 years of experience in all the techs from the stack that they already use, and there are no promotions except into management. Where do they imagine those people come from? Where do they think those people go after they age out?
Is there some developer nursery out there that takes green rookies, trains them up into competent developers, and then just forces them to leave? Is there a developer nursing home that hires only grizzled, jaded old veterans and pays them all handsomely to do work that never involves any training?
The reason that you need an ever-increasing amount of bozo filters is because your job openings do not match the profile of job-seekers. Unqualified applicants are clogging your system because your posting is the closest thing they can find to their own skills.
Bozo filters treat the symptom. The only cure is to give all those bozos their own jobs to apply for. If your company is large enough to support that many positions, you really should establish complete career tracks, across all levels of experience, and advertise them as a whole to job seekers, so they can tell you what rung of the ladder they think they should be on.
In short, you advertise all the positions that already exist at your company, the number of vacancies, and how those positions are linked by promotion. Anyone applying for multiple positions spanning more than two mutually exclusive skill levels is automatically filtered out as a resume spammer.
When I go out to look at job postings, that is all that I see. Single, standalone jobs. What I really need to see is an entire career track within the same company, from green rookie all the way up to the highest non-executive position on that track.
If I saw that, I could self-select for the position that is most appropriate to my current skill level. You wouldn't need to use FizzBuzz as my bozo filter. You would have to use a more difficult task, such as prioritizing a list of bugs and feature requests in a hypothetical program, based on perceived severity, resource requirements, and business needs.
But it seems like companies now only ever want developers with 5-10 years of experience in all the techs from the stack that they already use, and there are no promotions except into management. Where do they imagine those people come from? Where do they think those people go after they age out?
Is there some developer nursery out there that takes green rookies, trains them up into competent developers, and then just forces them to leave? Is there a developer nursing home that hires only grizzled, jaded old veterans and pays them all handsomely to do work that never involves any training?
The reason that you need an ever-increasing amount of bozo filters is because your job openings do not match the profile of job-seekers. Unqualified applicants are clogging your system because your posting is the closest thing they can find to their own skills.
Bozo filters treat the symptom. The only cure is to give all those bozos their own jobs to apply for. If your company is large enough to support that many positions, you really should establish complete career tracks, across all levels of experience, and advertise them as a whole to job seekers, so they can tell you what rung of the ladder they think they should be on.
In short, you advertise all the positions that already exist at your company, the number of vacancies, and how those positions are linked by promotion. Anyone applying for multiple positions spanning more than two mutually exclusive skill levels is automatically filtered out as a resume spammer.
I've always been a fan of "walk the walk, then talk". Basically, do FizzBuzz first then follow up with questions. Reason being, if you can't do some basic coding than its not even worth the time of having a discussion. You are, after all, hiring for a coding based position.
At my work we use Codility. Every applicant is given a link to a codility test and the decision to proceed to phone screen/etc is made based on their result. There are some exceptions made, i.e. it's not a flat "you need to score at least X" but it resolves the "can you actually write some code" question up front.
Doesn't seem very scalable if you have a lot of applicants (unless you let them do the test at home?).
I think asking for code samples up front is the best way to weed out those who aren't good candidates -- you can tell a lot about someone through their work.
I think asking for code samples up front is the best way to weed out those who aren't good candidates -- you can tell a lot about someone through their work.
A few places I've applied have given me coding challenges to work on from home. None has taken me more than an hour, were relatively simple and fun, and I've never failed to get an interview afterward. I'm not entirely sure what all of that means.
I think this Spolsky article provides some insight into why this might be the case:
http://www.joelonsoftware.com/items/2005/01/27.html
We request solutions to slightly harder problems in response to an initial application. Even though this is done at home, it still filters out a large percentage of applicants.
We then do something at the same level at the start of the interview. This filters out about half of the people who have got as far as an interview.
We then do an SQL test, building slowly from "select * from user" to a multi-table with sorting query. This filters out the other half.
We don't hire often.
Anyway, this is a very long-winded way of agreeing with Joel. I meet good programmers all the time - just rarely in interviews.
Alternatively, offering the going rate is too low an offer...
We then do something at the same level at the start of the interview. This filters out about half of the people who have got as far as an interview.
We then do an SQL test, building slowly from "select * from user" to a multi-table with sorting query. This filters out the other half.
We don't hire often.
Anyway, this is a very long-winded way of agreeing with Joel. I meet good programmers all the time - just rarely in interviews.
Alternatively, offering the going rate is too low an offer...
I struggled with this when I was responsible for hiring at 500px before I moved on. The key is to ask for code samples ahead of time. It doesn't necessarily have to be open source contributions, though that slightly preferred, but I refused to interview someone that didn't have code samples.
I went from 30 interviews per one hire to about 2 or 3. The most common problem being a potential candidate not knowing enough of the internet stack to be truly useful (for example, knowing only rails, but having no real knowledge of how AJAX worked, or load balancers, or databases, or DNS, etc).
I went from 30 interviews per one hire to about 2 or 3. The most common problem being a potential candidate not knowing enough of the internet stack to be truly useful (for example, knowing only rails, but having no real knowledge of how AJAX worked, or load balancers, or databases, or DNS, etc).
How did you handle people with no open source contributions? I'd imagine most non-OSS code would be under an NDA or something.
They just sent me code.
It is up to them to make sure that they are following NDAs. Also, sometimes code isn't open source, and it isn't NDA; like 4th year assignments or small contracts.
It is up to them to make sure that they are following NDAs. Also, sometimes code isn't open source, and it isn't NDA; like 4th year assignments or small contracts.
Makes me feel slightly more confident in my ability as someone who recently finished my CS degree, but I still feel very far behind. I find it very weird that someone even after their freshman year in such a degree program could not understand or comprehend such a simple task. I don't think anyone in my schools department would fail at these tasks after taking the introduction to programming course.
Where are all these students coming from? Perhaps there is some problem with the source. It seems like they aren't being taught to understand, but are instead being taught to copy instructions in some manner.
Where are all these students coming from? Perhaps there is some problem with the source. It seems like they aren't being taught to understand, but are instead being taught to copy instructions in some manner.
"[W]hat is your favorite programming language / platform and why" while a reasonably good open-ended question, students just haven't been exposed for long enough to different languages/platforms to have an opinion, although this question (as almost any other) will certainly have the "hacker in my own time" types talking.
That's why I like it. I add "and what would you change about it if you could?" to identify those candidates who really think about their tools.
FizzBuzz is the programming interview version of asking UK Chancellor George Osborne what 7x8 is[1].
[1]http://www.bbc.com/news/blogs-magazine-monitor-28143553
[1]http://www.bbc.com/news/blogs-magazine-monitor-28143553
In most established tech companies --- those with, say, more than 10 employees --- interviewing is performed by a semi-arbitrary selection of line developers.
If you're managing the hiring process at one of those companies, you should keep in mind that for a typical software developer, being involved in the hiring process is the closest they're going to get to participating in corporate strategy. For the time that they're in the room with a candidate, they are essentially the CEO of the hiring process. The more attention I've paid to hiring processes, the more convinced I am that this goes to people's heads. In no other job capacity do software developer's subjective beliefs and opinions get applied so directly to business outcomes.