> I can’t go fairly judge other programmers with FizzBuzz without going through the test myself. I implemented it in Ruby, my go-to language for hammering out quick solutions, and in the spirit of fairness to those I interviewed, I did it with pen and paper on the first day of the interviews (and confirmed it by entering and running it)
Be careful with this kind of test evaluation:
1. The problem isn't new to you - you have already had the problem in your head for days or even years. Whether you admit it or not, you already have a good idea of how to approach the problem.
2. You are not under stress, as the candidate would be.
Emphasis on point #2. You're hiring a programmer not a clutch outside shooter for your basketball team. Unless your code consistently has a lot of fires that need to be put out in short order there's no reason to filter people based on clutch performance.
I have to agree with this one. It sounds absolutely crazy that the average engineer can't write fizzbuzz during an interview.
But if you take a second and think about it, how the hell could these same people who fail fizzbuzz write production code in previous companies? Are you really saying that you believe that fizzbuzz is more complicated/difficult than their previous work?
As someone who's run lab experiments and who's seen a bunch of surprising results, trust me when I say that shocking results usually mean that you're running a test that you don't understand.
In this case, you're probably testing for a host of things that have nothing to do with day-to-day engineer performance.
"how the hell could these same people who fail fizzbuzz write production code in previous companies?"
Maybe they had a lot of supervision, or were someone that could talk a good game to management but didn't deliver, or maybe they just fiddled around with minor stuff in other folks' code.
While experience is obviously a really good thing and a useful thing, if they can't write fizzbuzz you'd have to re-evaluate that experience in the light of new knowledge.
I think you missed my point. I'm saying that fizzbuzz is very, very unlikely to be something you should use for evaluating someone's experience.
What I'm pointing out is a fundamental problem with coding problems.
FizzBuzz is a relatively simple problem to solve, so if fizzbuzz fails as a test for coding ability, then it's fairly likely that all coding problems fail.
There's are probably better metrics (faster, more uniform, etc) that you could use to figure out how good a coder is.
For example, one thing I've noticed is that I'm fairly aware of the skill levels of everyone I've ever worked with. I think it might be interesting to see how peers rate each other (A players can tell A players, and so on)- maybe that would be the metric that's most useful. All I know is that FizzBuzz probably isn't it.
One last thing I need to add: the people who are dramatically more productive coders are not always dramatically more productive because they code faster or better. It's often because they enact/enable processes that amplify the other developers. (e.g. the developer who pushes the company to have a hackathon, or the dev who creates machine images preconfigured for deploying test and dev builds).
This isn't about a metric of how good a coder is though, it's an absolute minimum, it's a bar to pass, it's a lowest-common-denominator filtering mechanism - can you solve a trivial problem in a generous amount of time?
Obviously interviews are stressful but this is FizzBuzz we're talking about. If someone cannot figure it out during a moderately-stressful interview, they quite simply aren't a very good programmer.
FizzBuzz seems to get a lot of people simply because they aren't familiar with the remainder (Modulo) operator.
I have to admit that I myself rarely need to use it. When I first read about FizzBuzz I tried to solve it by division and then comparing the floating point result to a rounded int result (i.e. circular way to get the remainder).
I'd be interested to see how many people pass if you simply remove the remainder operator part of it entirely. My guess is that near 100%.
FizzBuzz is still less "unfair" than a lot of the trick programming questions, riddles, or random CompSci trivia that many companies (Google, Microsoft, etc) do.
This is one of the reasons I would never even apply at a Google. I don't perform well programming wise under that level of pressure and my "random trivia" reserves are low.
It really depends on the type of programming job you are interviewing for, but for all of the jobs I've had I'd expect a candidate to be able to do this with or without using a mod operator. I've asked people similarly simple programming problems; I like the approach. I don't like requiring leaps of intuition or analysis as a filter like this though. So problems should be straightforward. You are checking for fundamental coding and problem solving in an interview like this.
So, when production is down, and clients are calling, and revenue is lost, it's okay to say "I'm too stressed to fix this bug?"
I'm sympathetic to complaints about overly technical interviews (I've bombed a few in my day because of stress and/or ignorance), but as others have pointed out, this is FizzBuzz. I'm generally very bad at interview/algorithm puzzles, but I could even figure this one out pretty quickly.
A better metaphor would be those things happening and your boss saying "solve fizzbuzz in 10 minutes or we'll fire you". (or we'll fire you == not getting the job/failing the interview).
The big difference between the two metaphors is that mine has direct impact on your personal life and negative consequences are gonna be seen as your fault, while yours is a company threat - fixing it will get you seen as a hero, not a disgraced villain.
Interview stress and normal workday stress are completely different beasts, in my experience. Coping with one is not always an indicator of the ability to deal with the other.
How are we supposed to interview candidates at all, if their interview specific stress is so crippling? What sort of things can they answer, if not at least FizzBuzz?
Give them a unique programming problem before hand and ask them to bring their solution to the interview, and then discuss the solution with them.
Unless they "cheat" this should give you a good idea of what they're capable of. The cheating should also show up if they cannot explain it or why they wrote it the way they did.
How far beforehand would you suggest? Would walking into the interview, handing them the problem, and then telling them that you'll come back in 10/15 minutes to "start" the interview be acceptable?
Asking someone to solve a problem in the waiting rooms is considerably different then letting them solve the problem in their chosen environment. Probably not as stressful as durring an interview with people watching however.
As noted in another reply to this question, get them to bring in a project and explain it.
Additionally, they could spend some time with the team they'd be working in, pairing (or whatever) with other members and really demonstrating their abilities.
It's not really that difficult to get away from the whole "technical question at the interview" problem, and I'd wager that in the long-term it'd be better for all concerned.
Eh, maybe. Those are fine interviewing techniques, but I am unconvinced that explaining something technical you've done in the past would really be that different (from a stress-induced difficulty standpoint) than FizzBuzz.
That's the whole point of the article/test - there are loads of folks (apparently) who can talk about it but not produce even this simple example when asked to. You probably don't want them.
Yeah, that was my take-away. Any "talk about what you have done" that gets specific enough should be susceptible to the same stress though; I cannot fathom how that wouldn't be the case.
Which is why I wrote the second part: Drag them in for x days, get them to work with existing staff on existing problems. If you have engaged staff, they will weed out the (clue|use)ful and reject the time-wasters.
Reminds me of a test in my intro computer architecture class, where the prof was making the key while we were taking the test, and partway through was like "This is taking me longer than I thought it would, so you guys can take this home and work on it."
That's probably deliberate: he says himself (and I agree with this approach) that the point is to figure out if someone knows how to program at all. Off by one errors, syntax errors, these are not all that relevant. The failures are the ones who stare at the paper blankly, or have no idea that they need a loop, or some other such hopeless approach.
If you get "close enough" on paper and pencil under the pressure of an interview, that's great. You can walk through debugging it if you want to see more, but I wouldn't hold even basic logic errors against someone.
I certainly admit that when coding on my own I usually get all kinds of stuff wrong that I fix as I write tests and iterate.
Yeah I've used FizzBuzz myself, and under interview conditions it's actually much harder to implement a correct (for edge cases, etc.) solution in a short time. I always took that into account. However I also added the twist that I wanted the candidates to also write the tests for the program in TDD style. I hoped that this would actually help, by asking the interviewee to follow a repeatable pattern of first expressing what they wanted to code to do and then implementing. We also did ping-pong pairing so I could help write a test, or do an implementation if things were going poorly, to see if that would jump start the candidates brain into the problem.
The results were quite frankly a disaster, no better than what Joey found (though I didn't do enough interviews for a statistical sample).
Unfortunately my limited observations have lead me to believe that too many developers (particularly in the enterprise environments) are used to working on legacy codebases that they hack and change until the bug they are fixing goes away. Many rarely implement features much, if at all, and the ones they do are heavily broken.
[Article author here!] Reg is right. The purpose of the FizzBuzz test was to weed out anyone who couldn't program at all and not punish anyone who forgot a semicolon, used = when they should've used == or some similar error. I was completely prepared to discuss the result if someone got close to a working solution.
To my surprise, the candidates' solutions were either bang-on or way off. The guy who asked "Do you think I should use a loop?" had to be cut off at the ten-minute mark, and his paper had only the start of a C-syntax for loop and a lot fo scratched-out lines.
But the specification is to print the number, not the character with the character code corresponding to the number. So unlike your "correction", his code does what it should.
Admittedly, having a variable that contains either an integer or a string is atrocious programming style, but some people do actually like languages that allow that, so it is par for the course in the given situation.
I've never touched Ruby, so I could be misunderstanding, but I think his code is correct.
In each loop, he initializes the output variable to an empty string. If the current integer is not a multiple, he replaces the empty string with the integer. If it is a multiple, he doesn't know which one it is, or if it's a multiple of both, so he appends the text to the existing string variable. At the end of the loop, the string is output.
Since the `output = i` line is the only assignment that occurs when that condition (not a multiple of either) is met, it makes sense to just reassign the variable rather than append to it. It might be less flexible, sure, but flexibility isn't required here.
His solutions works while your does not. I ran them both in irb. This is because "string << integer" does not do what you think it does. It treats the integer as character code.
The line before that is output = "", there will never be any output to overwrite by line output = i. Note that this is output for just one line, not the entire output of the procedure.
Well said. It's equivalent to receiving the exam paper days in advance and bragging how fair or equivalent it is. In fairness to the interviewer, he has the position of the other side and I can't hold it against it him. It's just not the same from the position of the interviewee.
Hacker News as of late has given me quite a bit of hope that I'll be able to actually get a job writing code one day (anyone need an intern? ;) ) between this FizzBuzz thing, and hearing about people who've never heard of multi-dimensional arrays, I'm feeling a little more confident..!
Of the authors three ideas as to the reason for the inability of candidates to pass the test, I can perhaps understand the first two. My younger days involved copying/pasting Actionscript2 code and relying on superstition to get it working. All the while having no idea of how the fundamental constructs (like loops) even worked. What I don't understand is how someone has the confidence to apply to a job/hold down a job when their coding style is cut and paste.
His final point has me scratching my head a bit. Specialist or not, aren't loops and conditional logic kind of the fundamental tools in all languages. What would the discipline be that has you coding in a specialist niche, but not using loops or conditionals?
Perhaps what you're experiencing is the Dunning-Kruger effect: that people who are unskilled frequently rank themselves as more competent than people who actually are skilled.
Hmm.. perhaps. Still it seems a wildly bold to overestimate yourself by such a large amount. We're talking about the absolute basics here. I mean, I look at job postings and come away depressed after realizing I don't recognize half the stuff they want 5+ years experience in. So what does for-loop-not-knowing guy think we he sees the same requirements?
I dunno. I just think it's strange that they even get to the interview stage.
I'm amazed this still works. Like the author i would've thought everyone going for such a job would instantly know what fizzbuzz is and make sure they know it.
Another question i feel works really well in interviews is asking them to show you something they've created, personally or professionally. Its a nice open ended question, gets them talking about something they know and lets you ask many follow up questions about specific parts of the thing they've done which gives you a good feel of what they're capable of.
One of the things I've learned is that almost all introductory blog posts are wasted: The people I'd most like to reach don't read programming blogs, Hacker News, progreasmming.reddit.com, or anything else.
FizzBuzz is famous, but alas it is famous amongst people who could code it without advance knowledge of it.
>> FizzBuzz is famous, but alas it is famous amongst people who could code it without advance knowledge of it.
If that's true, it's still a good screening test. You either have heard of it but could code it even if you hadn't, so you pass, or you haven't heard of it and couldn't code it even if you had, so you fail.
Frankly speaking, would you want such a person working for you if they couldn't loop over a list of numbers and write simple arithmetic without advance preparations?
"i would've thought everyone going for such a job would instantly know what fizzbuzz is and make sure they know it."
The point of FizzBuzz is that it's not something you "know" or need to study. It's such a trivial problem that any developer should be able to write it off the cuff.
The kind of person who has heard of FizzBuzz before is someone who cares about their profession and reads about it. They're unlikely to fail the test in the first place.
For it to become common knowledge it would have to be part of a significant percentage of interview screens across the industry. Evidently that hasn't happened, and I wonder if it ever will.
80% of applicants for an internship at a company I used to work at failed FizzBuzz when I applied it to them (same deal, pencil and paper and a choice of any language they want).
The worst was one perky young woman who wrote her answer in three minutes flat, handed it back and asked, "Did I get it right?" I answered, "No...." and from that point on it became the most awkward interview ever.
The interviews were for all of 15 minutes anyways. I'm not so bent on time efficiency that I felt it necessary to save myself and the applicant twelve minutes by concluding the interview early. Also, I'm human and that's a level of cold that I didn't want to go to.
Could be skilled in an other field, or just an interesting conversation. If the interview's scheduled for a fixed time anyway, might as well make the best of it.
Maybe you should administer the test towards the end of the interview after you've gotten to know the candidate a bit and allowed for time for their nervousness to wear off.
A minimum competency test is reasonable. Better to know such things before the interview stage IMO; its a terrible waste of everyone's time to show up, fail fizzbuzz and leave.
Is it just me or does his "sample" program look needlessly complex ? Does he really need to create all those function definitions ? I'm not super familiar with ruby but those ARE function definitions - right ?
Since when is it good programming practice to have functions for every little thing ? (I'm picturing myself scrolling or jumping around in an editor to figure out what exactly the call does). This is like doing hello world with a function. Or having a function to add two numbers. Yes, sometimes it's necessary for syntactical clarity but in this case it just seems like overkill.
Also why are some people on HN talking about edge cases to FizzBuzz ? There are no edge cases that I know of unless you talk about the number zero - which isn't part of the question.
EDIT: Why the downvotes? I don't see why trying to discuss what's clearly a programming related problem on HN brings you downvotes ? Interesting.
> Also why are some people on HN talking about edge cases to FizzBuzz ? There are no edge cases that I know of unless you talk about the number zero - which isn't part of the question.
I don't know about you, but I sure see it as an edge case.
# This is incorrect due to edge case.
# If divisible by 3, fizz
# If divisible by 5, buzz
# If divisible by 15, fizz buzz
# Else number
1.upto(20) do |i|
if i % 3 == 0
puts "Fizz"
elsif i % 5 == 0
puts "Buzz"
elsif i % 15 == 0
puts "FizzBuzz"
else
puts i
end
end
In my book, that's a pass, but you should have a discussion where you walk through the code and ask the interviewee what happens when i is 15, and hopefully they'll spot the problem, maybe with a little bit of nudging.
But the main point of Fizzbuzz is that some people who call themselves programmers are incapable of producing a loop, some conditionals, and some print statements. Your solution had that, which is why you passed it. The point is to find the people who can't even get that part right.
I see an incorrect algorithm in your solution but I don't really see what would be called an edge case (just to explain: anything divisible by 3 will enter the first conditional and omit the last, hence the algorithm you've used is incorrect). Or maybe we're talking about different things. Could you please explain to me in words what a fizzbuzz edge case would be ?
One of the good things about this is it's easy to change the definition of "multiple_of_3" to reflect changing requirements. For example, suppose we wanted Fizz to be printed with multiples of 7 instead. Easy! Just change:
def multiple_of_3(number):
number % 3 == 0
end
to
def multiple_of_3(number):
number % 7 == 0
end
Now perhaps he sees the advantage: no refactoring necessary.
(* I feel I should say that I am being sarcastic. Anyone who thinks it's ok to have a function called "multiple_of_3" that checks if it is a multiple of 7 should probably be fired immediately.)
My question was: Why would you create a function that does something you could access as a built in language feature ? What is the benefit of using a function as opposed to just evaluating the result of i%3==0 ?
Looking at a function call for "multiple_of_3" I would actually expect it to do more than i%3==0 since that could've been done just right there.
I'm just trying to understand if there are benefits of doing it this way and not directly. So far I've just encountered snarky remarks and no real arguments either way.
I created the convenience functions "multiple_of_3" and "multiple_of_5" for a couple of reasons:
1. To make it clear to the interviewer that I "get" the problem.
2. To prevent myself from making any dumb mistakes. I'm only a half-decent coder, so I've made it a habit of putting such "Mollyguards" (http://en.wiktionary.org/wiki/molly-guard) in my code as a precaution.
3. To show a little Ruby coding style. The convention in Ruby is to favour lots of concise little routines over big-ass ones. See "Eloquent Ruby" for the guideline and Shopify's ActiveMerchant library for an example of such Ruby in actual production code.
> To show a little Ruby coding style. The convention in Ruby is to favour lots of concise little routines over big-ass ones.
Writing small, concise components(classes, methods, functions, modules...) is a generally a good practice in any language. However, moving i % 3 in a separate method is not a good practice. As another commenter pointed out, your names are hardly apt. It would better serve to name them fizz?(multiple_of_3) and buzz?(multiple_of_5). But even then, if all fizz? is doing is i % 3, let it be inline. True that in the future you might need additional processing for fizz?(not for this particular eg; I am talking real world), but re-factor it when you need it. It's not like if you have i%3 inline, it makes it harder to re-factor it into a fizz? method later.
Also, since you are talking ruby conventions, shouldn't your predicates be named multiple_of_3? instead of multiple_of_3?
Yeah, you've gotta immediately refactor that into a multiple_of function that takes an argument x and returns another function that takes an argument y and returns whether it's a multiple of x.
Ah, Currying... (and how Firefox spellcheck recognizes that as a word, but not spellcheck)
*
On another note, I've seen other bizarre blind spots in experienced programmers. One time, when I was learning Ruby, I went to a Ruby "hack night" in SF where a bunch of people there explained that they had been hackers for a while. The group was given a challenge to implement C-style integers (with overflow/loop-around) using Ruby classes.
The session had "mentors" who were professional Ruby programmers (mainly with Rails).
So as I was writing my class, and implementing addition, I figured I would need to input another integer object and add its value. So I needed to know how to expose a member variable, and couldn't find the doc that said how, leading me to ask a mentor.
He was stumped. I was thinking, "WTF? You program Ruby all day but don't know how to write [what I later found was called] an accessor?" I wasn't asking for anything fancy, just the plain ol'
I like the problem of printing the leap years (or deciding if a year is leap). It's the same as FizzBuzz in the core (though a bit more complicated), but presents itself as something real, not like an artificial task. And as a bonus, you can see if the applicant knows the rules for inserting leap years (there are no negative points for not knowing that, only positive if you do).
Isn't this the point where you congratulate the interviewee on the breadth of their off the top of their head Ruby knowledge ... and then ask them to do it by hand?
Surely the latter won't be a surprise; if I answered like that I'd do it with a grin and a "Well, I could do it like this [write out the above], but I suspect you want something more like this [then write an implementation of the method]."
It's true. Of the last four or so candidates we've had, only one managed to do FB and none had heard of it. One of them, once presented with the problem, even said "Why on earth would I want to do that?" to which I replied "Because you want the job?"
With an answer like that I would have assumed you were a jerk. You could have easily answered the question in a positive manner that explained your need to have the candidate complete the task. "Because I said so" is often a valid answer to a child, but not to an adult.
What I'm curious about is why so many seem so beholden to FizzBuzz in the first place to the point they assume everyone already knows what it is. The fact that none of your candidates had heard of FizzBuzz was to your advantage. What's the point of administering a test if everyone had already heard of it and knew the answer?
So, did you hire the one candidate that completed FizzBuzz and did you hire this person because they could?
If a candidate comes in with previous knowledge of FizzBuzz, that would indicate to me they are probably pretty in touch with the industry. That is, they probably read blogs or forums about development and/or interviewing. That would be a good thing, and they would likely get the problem right.
That would be fine with me. If it does get to the point that _everyone_ knows it, then we have to find a new question.
Previous knowledge of FizzBuzz doesn't necessarily indicate competency. They could have easily just read a blog about "The 10 Most Common Programming Interview Tests" and memorized a popular, simple way of creating the code.
To be honest, I seriously doubt the knowledge of FizzBuzz will be a common thing. I was seriously coding for a year or so before I had ever heard of it. When I first saw the question I had what I felt was a responsible block of code that worked. Since then I've tweaked it to be more efficient as my skill level increased. But I've never been asked in an interview to code FizzBuzz or anything like it.
I'm sure someone will drag out the extreme counter-example after I say this, but I am pretty sure nobody ever has ever advocated hiring a person simply because they can do fizz-buzz. Fizz-buzz is just one step in many of a noise filtering process.
I'm not saying they should, I'm just curious about the outcome of this round of interviews.
I've interviewed many a "web designer" that were obviously not qualified on the level they claim. Just asking how to make text flow around an image is a simple gotcha that someone who claims to hand code HTML should know. If you're just a designer then that's fine, but don't say you can hand code HTML and not know what a float is or even have creative solution that doesn't involve a float. I've met many who couldn't come up with a reasonable answer. But it's not an immediate "sorry, you should go now" moment for me when they cannot do so. I also look into how they answer and how they handle being told they were wrong.
Something like FizzBuzz is a useful tool but I see too many give it too much weight without considering other variables involved in giving the test. Each interviewer has their own style but having a heavy hand on one or two aspects of the interview means you may be passing up a good hire.
If I had followed the "rules" that I've seen many advocate then one of the best hires I had ever seen wouldn't have walked through the door and even then he would have been told to walk right back out. Turned out he was an excellent hire that learned quickly and was excited about his work. That young man just recently started his own development company, granted its just him for now but he's got the work and chops to support it. Makes me wonder if I were a FizzBuzz or nothing kind of interviewer how things might have been different. To be honest I have no idea if he could have coded FizzBuzz, I didn't ask.
But I also understand if you are going through dozens or hundreds of resumes then you have to do something. Just don't be the "I don't hire unlucky people" guy that throws away half the resumes when starting. Too many FizzBuzz advocates get dangerously close to that kind of attitude.
Gee, it sure is easy to assume I'm a jerk. From my pithy story, you sure didn't guess the following true elements I omitted:
1. There was a great deal of primping and preening prior to the coding phase of the interview, and it was made clear that the phase of the interview was designed to demonstrate basic coding skills, that it's a fairly standard industry practice, and that these exercises are fairly meaningless and all the rest. There was plenty of warm up.
2. I wasn't running the interview; I lack the authority to do that. I am simply a member of the group the interviewee was interviewing for. I blurted it out because I was shocked by his response, which I felt demonstrated that he felt he was above menial coding exercises. I've never met a good engineer who would scoff at a problem because it was too simple, especially in a context where demonstrating prowess was desired.
3. The candidate, who is a "senior engineer" in his current position, also showed us some of his code after failing this part of the interview, which was a truly disgusting, thousands of lines of copy-paste crap pile. Imagine writing a large interactive site with jQuery, then remove the ability to use selectors and do all that by hand. Then imagine what you're doing also happens to be done for you by your backend if you enable a bit of configuration. That's the level of shockingly incompetent we're talking about.
4. We still offered the candidate the job, because we're fairly desperate, we were worried about losing the position if we didn't hire someone, and he seemed personable--and like he probably wouldn't screw things up worse than they already were on this particular project, which came back from being outsourced in really sorry shape.
5. The candidate refused to take the job, not because of the group, the low pay, the interview process, but because we couldn't get HR to change the job title from "Software Engineer" to "Senior Software Engineer." He actually made this clear to my bosses on the phone, that if they could just add "Senior" to the job title he would take the job, even with no other changes, and refused--angrily--when they couldn't do that.
I can understand why, with one remark taken out of context, you might relate more to the interviewee than the interviewer. But you really should cut people a little slack around here. Most applicants to programming jobs--especially outside technology hubs--are just not very good. This guy wasn't very good and seemed to know it, even though he hadn't seen Fizz Buzz before, and it hasn't stopped him from having a career in programming for decades.
I think you are missing the point of the GP's answer. Instead of nailing in 1 minute the easy question (would it be fizzbuzz or "write me a program that prints 'hello world'" or something of that kind), the candidate is supposed to write the answer quickly and move on.
Being snob about the interview question is not going to help things.
Maybe sometimes we forget, the interview is for BOTH parties. I think it's fair to ask if puzzle like questions are an expectation. It would be simple to answer: "Yes, we know this is a silly puzzle, but it's a fast way for you to show us your real world skill".
> Being snob about the interview question is not going to help things.
Isn't "because you need the job" snob? The interviewer could have very well said "We start with simple problems, and then we expand on it. So let's start with this fizzbuzz problem."
I obviously took the "because you need the job" as a statement of a snob, or in my words a jerk. Despite the reasons for the statement, it would have given me a negative impression of the person. If that person was management then it would give me a negative impression of the workplace. As someone else points out in this thread, an interview goes both ways.
It sounds like you're screening out people who question the status quo and always try to be working on something meaningful. Is that what you want?
In a good programming job, when given a task, it's an excellent response to say, "Why on earth would I want to do that?" (Though maybe not worded quite like that.) That way you get context, refine the requirements, and eliminate unnecessary work. If that behavior is required by the job, then you should expect it in the interview.
It's an important point. If the job involves writing FizzBuzz type code, give them that in the interview. If the job is writing kernels and databases and distributed whatevers, go ahead and hand out some hardcore computer science questions. If the job is fiddling with CSS and filling out TPS reports, be honest with yourself about that, and go ahead and hire some mediocre programmers, because anyone else is just going to get bored anyway.
It's kind of a sore point because when I interviewed for my current job, they grilled me on robust algorithms for keeping data stores synchronized. Cool, I like this stuff. I got hired. Guess what? We don't even use database transactions here. I'm serious, people consider them too complicated. I spend my time in meetings, in the bug tracker, doing code reviews, occasionally coding something less complicated than what I cut my programming teeth on 20 years ago. That's the actual job. FizzBuzz misses the point for jobs like this.
A thought-provoking post. I really like the specific details the author provides about the interview set-up and the results observed among candidates at his company.
Now amazing as it is that there is anyone around who has not already heard of FizzBuzz as a job screen, I actually heard an even more amazing story in August 2012, which I shared here on Hacker News a month ago.
The story, which no one here seemed to believe the first time I related it, but which I fear is very likely true, is that the hiring supervisor who told me this story is the lead programmer for a company that uses Web back-end programming to serve up online, adaptive lessons. He has a position open for a new programmer as the company's business grows. He has advertised in the expected places like Stack Overflow and Joel on Software. During the year 2012, the company has received many resumes. Applicants who have computer science degrees, and especially the many applicants who have master's degrees and who otherwise look all right, are invited to do a phone screen in preparation for an in-person interview. During the phone screen, the applicants log into an application that allows them to type on their own PC to write code that can be seen by the hiring supervisor. The test the hiring supervisor uses is "Write a program using a for loop to print the integers from 1 to 100." Applicants are permitted to use any language they please, and the supervisor said he would even consider correct pseudocode a successful answer. He has not yet had ANY applicant, not even one, submit a flawless working program to do that. Not one. He was eager to interview an applicant who got the test MOSTLY correct, after seeing many applicants fail to do it at all.
I know the company that that hiring supervisor works for. I do not know how much its location or the fact that the software roles in that company are support roles rather than producing the company's main product may influence the desirability of the company. But somehow I think he is not lying when he says that a straightforward implementation, no tricks, of "Write a program using a for loop to print the integers from 1 to 100" is too hard for many CS graduates. That's why everyone hiring today should build a work-sample test into the hiring process.
Even with the 40% hit rate you can reduce it further by asking what could make it perform faster.
"That's great for FizzBuzz to 100, but what if we went to a million? What would you do to make it perform in... I don't know, a quarter of the current execution time?"
Even if they wrote a solution that avoided % or / it is always worth a few minute exploration into how one might optimise code that works today but one day is found to be slower than desired.
If the interviewer were good, they would play it cool and immediately ask the candidate to walk through the code out-loud and give reasons that they did what they did.
Does someone else have a few programming tests on hand aside from FizzBuzz?
Also InterviewStreet ( https://www.interviewstreet.com/ ) has a nice collection of problems of varying degrees of difficulty. Quite handy if you want to "prepare" for an interview.
We deal with maps a lot, and I usually ask this one: assume a matrix. Fill the matrix with numbers, so that the outer 'ring' of numbers has the value 1, one 'ring' more to the center has the value 2, and so on. To visualize this, imagine that this matrix represents a height map, where each number represents a cell in a surface, and the value of the number is the elevation of the area of that cell. The result should be a height map of a pyramid. To make things easier, assume that the number of rows and columns in the matrix is equal, and that that number is uneven.
Followup-questions may go into the direction of what if some of the assumptions are loosened, or what are the performance implications of several possible solutions, or how to do it when iterating in whatever is the most optimal manner performance-wise considering the storage implementation of the matrix (avoiding cache misses or disk seeking etc.).
I've only had a single person ever pass this test, out of 10 or so interviewees.
Another one was where a colleague of mine drew a car on a piece of paper and asked the candidate to explain how he would design a class hierarchy if one were to model a car in OOP. His answer was to have a class 'rectangle' and two classes 'circle' (referring to the box and the two wheels my colleague drew on the paper). Seeing the incredulous looks on our faces, he then proceeded to an unintelligible story of 'has-a' vs 'is-a' as it related to the point in the middle of the circles, and how a 'point' somehow 'was-a' circle except that it had room in the middle. True story.
>We deal with maps a lot, and I usually ask this one: assume a matrix. Fill the matrix with numbers, so that the outer 'ring' of numbers has the value 1, one 'ring' more to the center has the value 2, and so on. To visualize this, imagine that this matrix represents a height map, where each number represents a cell in a surface, and the value of the number is the elevation of the area of that cell. The result should be a height map of a pyramid. To make things easier, assume that the number of rows and columns in the matrix is equal, and that that number is uneven.
This sounded fun, so I thought about it for a couple minutes and came up with the following in JavaScript:
var pyramatrix = function(a) {
a += 1 - (a & 1); // increment a by one if even
var b = [], // pyramid y-axis
c = a-(a>>1), // get the "center" of the pyramid (eg. 7 -> 1234321 -> 4 is the center)
d = function(x) { return Math.abs((x+1)-c) }, // calculate offset from center
e, f, // values for storing current index offset
g = ''; // initialize string for pretty output
for(var i = 0; i < a; i++) {
b[i] = []; // pyramid "x-axis" (current row)
for (var j = 0; j < a; j++) {
e = d(i); // get y offset
f = d(j); // get x offset
b[i][j] = c - (e > f ? e : f); // set current index to center minus larger offset
g += '['+b[i][j]+']'; // add value to pretty output
}
g += '\n'; // add a line break after each row
}
console.log(g); // print pretty output
}
I was pretty satisfied when it worked exactly as intended on the first try!
EDIT: Now that I look at it, you could obviously move e = d(i); outside the second for loop, but for the sake of posterity I'm not going to change the solution from what I first came up with.
That looks like a nice solution to me, some of the Javascript idioms I'm not familiar with, but after looking at it for a while it seems you're using what I'd consider the 'best' method of generating it - looping over each cell and calculating the height based on the distance to the 'top' (or 'center', depending on how you look at it).
Personally I consider the 'naive' version (as in: the first, easy to manually verify version one would bang out as a prototype) to be one where a matrix is pre-allocated and each ring is filled in from the outside inwards (so first assign all 1's, then all 2's, and so on), but funnily enough nobody ever went that route, not even my colleagues who did it.
>Personally I consider the 'naive' version (as in: the first, easy to manually verify version one would bang out as a prototype) to be one where a matrix is pre-allocated and each ring is filled in from the outside inwards (so first assign all 1's, then all 2's, and so on)
I'd consider the 'naive' version (and the first solution that popped to my mind pretty much instantly) to be where you first fill the grid with 1's, then then loop over the next level and add 1 and repeat until you're on the top. So like this for example:
function(a) {
a = a | 1; // add 1 to even numbers
var b = new Array(a),
i, y, x,
s = 0;
// initialize the array
for(y = 0; y < a; y++) {
b[y] = new Array(a);
for(x = 0; x < a; x++) {
b[y][x] = 0;
}
}
// turn it into a pyramid heightmap
for(i = a; i > 0; i--) {
for(y = s; y < i; y++) {
for(x = s; x < i; x++) {
b[y][x]++;
}
}
s++;
}
return b;
}
Though in JavaScript it's a bit more complex than it might otherwise be since you can't just declare a multi-dimensional int array in a single line. Anyway, I discarded this solution about as fast as I came up with it because I knew there'd be more clever ways to go about it, and came up with the offset calculation method a couple minutes after that. And amusingly enough I had to actually test and iterate this 'naive' version a bit before I got it running right, whereas my 'complex' solution worked on the first try. Funny how that goes.
Thanks for the pyramid example, that's a good one. As a calibration point, it took me from 16 minutes past the hour when I read your post to 26 past the hour to complete. And the ten minutes included two interruptions where I had to go to another office. And 3 more minutes to write this post.
I did google "2d array python" when the array initialization I used at first didn't work. (I'm new to python and had not done a 2d array in it yet.)
Works fine, dumps the result in formatted output, and accepts any positive number as an argument to pyramid size, odd or even.
Thank you, that's interesting. That's in the magnitude of time I myself estimated when I started asking this question, but I started wondering over time if my expectation was realistic.
> I've only had a single person ever pass this test, out of 10 or so interviewees.
Did that person get the job? Lots of companies seem to administer those brain-bending tests and then does not use it as the deciding factor when hiring someone.
I've personally been exposed to several quizzies like checking if a number is a prime, walking a directory tree and printing .txt files, implementing a variant of the soundex algorithm, a web server to interact with the twitter api... The worst (or best) was one in which the interviewer asked me to solve a Roman Square problem as a homework. Except instead of a 3x3 square it was a hexagon containing 64 numbers. Aced all the tests, even the Roman Square and the interviewer even told me I was the only one they had interviewed that solved the problem. It was freakishly hard and involved creating a pretty complicated constraint solver.
I still didn't get the job. In fact, the common theme in my professional life, after dozens of interviews, is that if there is a programming test involved then I will not be offered the job, no matter how well I score.
My conclusion is that companies do not use tests to determine whether to hire applicants or not. Interviewers make up their decisions regardless of test results and then use them purely to make their decision seem more objective they in reality are: "Bill scored low on or test, he is not a good candidate..." or "Bill did score well, BUT $blablabla" where $blablabla is some irrational stuff.
This particular one did, yes, but not just because she could solve this problem. I refuse to let my hire/no hire recommendations be boxed into binary thinking or autistically rigid 'if a then b' type of testing. I will try my best to interview in a way that will eliminate or suppress any biases I may have, but will still use judgement when interpreting the results of any tests/questions. Rigid algorithms are too easy to game.
Pre-Screen for us is simply provide working code that 'Finds the the four highest integers in a list of integers'. We accept any language.
The controversial bit, is we ask for Big O of their solution.
There are a lot of candidates who didn't get the CS degree and struggle with this, surprisingly no one has ever said "I don't know Big O".
Generally, working code is enough to at least get you in the door for a face-to-face. Yet this alone filters out more than 50% of the resumes.
def top_four_ints_from(input_list)
working_set = []
input_list.each do |n|
working_set.push(n)
working_set.sort!.shift while working_set.count > 4
end
working_set
end
I'm pretty sure that's O(n). Constant time to insert any one value to the working set, Roughly n sorts performed but since each individual sort covers at most five elements we're still at (5 lg 5) * n -> O(n).
I did a phone interview once for Facebook and my interviewer used binary search of an array of integers. I think it is a good thing to use for a first filter because even if you don't know it from memory it is pretty obvious from first principles, and it involves both looping (or recursion) and branching and it is only 10 lines of code. Also there are a few twists you can apply afterwards:
1. Turn it into bisect: return the index at which the searched value should be inserted to maintain the sorted list.
2. Allow any type of array member and require a comparison function provided that returns the standard -1,0,1.
3. Point out that binary search can be used for membership testing with O(log(n)) comparisons where n is array length. Then ask for a data-structure that can perform membership testing in constant time (answer: hash table.)
EDIT: the actual programming was in a shared buffer (something like etherpad). I was mock-interviewing a friend and I had him do it on paper and that worked alright too.
EDIT2: The hardest part about discussing FizzBuzz is avoiding derailing the discussion into FizzBuzz code golf.
#!/usr/bin/env python
for i in range(1,101):
print [i,"Fizz","Buzz","FizzBuzz"][(0==i%3)+2*(0==i%5)]
That's the beauty of FizzBuzz, you don't really need other tests. It weeds out the dead wood very quickly and when you have 10 resumes to walk through in a week, that's a handy thing. Best to know this early on to avoid wasting your time and the candidate's as well.
Other examples of FizzBuzz-level tests? They aren't exactly tough to come up with. I used to ask for a function that takes a string and returns a boolean indicating whether or not it contains all uppercase letter.
At this point, I'd think the FizzBuzz test is to get people to explain what the FizzBuzz test was. Most programmers I'd want to hire would probably have heard of at least the vague problem,
I do not object to the broad points being made here but I do object to this interpretation. It's beyond awkward for many good valuable programmers, stifling really, to do this kind of unrealistic audition programming for a live audience. You are not just under stress -- you are far, far, far outside of any demonstration of your true value to the employer.
Perhaps the hiring pool really is that bad, you have a giant pile of unqualified applicants, and you really must use this kind of blunt instrument rather than taking the time to talk with candidates and their references and really get to know their work and their reputations. I've never had to do hiring and I don't envy you if you do. But I've also never in my life had to do this kind of test, and I think I'd use it as a filter myself to avoid working for someone who uses it.
[EDIT: I assumed it would be clear that I'm not talking about the coding challenge of FizzBuzz. I'm talking about the experience of audition-style programming. You end up filtering on less important characteristics of applicants who might otherwise be your best candidates, but think you're filtering on FizzBuzz.]
It's a for-loop, some conditionals, and printing. If you can't produce this in a few minutes, you can not program.
The point isn't to make a perfect, working fizzbuzz in the first try, the point is to find out if your applicant can program at all in the first place.
Ridiculously enough, there are people that can't program that would pass a normal interview with flying colours, but who utterly fail at fizzbuzz, which makes it a very valuable tool.
Programming on paper opposite an examiner with a stopwatch is indeed unrealistic. I don't disagree that FizzBuzz is crazy simple as a programming challenge.
I agree as well, which is why it's very important that you don't do that as an interviewer. The important thing is to check if the applicant can write a little bit of code from scratch, not if they can do it on time, in front of a big audience, without errors, with extra stress added on top.
And it sounds like the OP did it in an ok way, and didn't scare away any great programmers, which makes his conclusion pretty valid, that 60% of his applicants simply weren't capable.
Having been on both sides the interview process and going through hundreds of candidates, I agree that a code solving problem is a valuable gauge for the technical acumen of the candidate. In fact the best experiences I have had on both sides of the table have had a well thought out coding element included. The better ones had a more real world requirement and aren't so puzzle like (yes FizzBuzz is pretty simplistic, but it’s still a puzzle).
The biggest issue I see with this approach is the “On Paper” (white board applies as well) code. This is an unrealistic expectation. Unless you’re writing all your code on paper and this is a basic skill for your process, you've already added a factor that may push a normally fine developer out.
If language is unimportant, then process should be as well. Let the developer solve the problem in the best way they can, even if they do ‘Google’ it. You can use the amount of ‘googleing’ as another factor to evaluate.
I have to protest, Fizzbuzz is not a puzzle! There's no trick! The entire algorithm is given by the problem description!
If you allow people to google it, you allow copy-paste-coders to pass the test, and you don't want that.
Solving it requires a loop, some conditionals, and some print statements. If you can't write that from scratch, then you can't program. At all.
Also, writing code or pseudo-code on a whiteboard is something we do pretty often at work, I don't think it's an unrealistic demand that your coworkers should be able to join in on such a discussion.
I see the point. Still you're not testing how the candidate works. No one knows everything about everything. We are looking for the right team member to solve business problems, full stop. Shipped code always wins over the perfect algorithm sketched on the whiteboard.
Think of it more as "testing how they don't work." A computer without google ensures that, however they may work, "google it" is not their only method.
I don't want to hire somebody that can only "ship" with google.
I still see your point. However, how do you solve a problem if you just don't know something? To me, a big factor in this test is, did they finish and does it work? Lets say they understand that Modulo would be the way to go but they are unsure of the syntax. Where would they find the answer? Or do we say, sorry you're out...you must memorize everything?
Being able to look up information on demand is an important skill, but that is not what is being tested by FizzBuzz. Furthermore, if it is a skill that needs to be exercised while attempting FizzBuzz, that is a disqualifier.
'FizzBuzz without Google' doesn't mean the candidate is expected to have memorized everything. Just a very minimal baseline.
You can always test Google-skills separately, if you think it is in doubt.
I do, yes. I figure doing so probably looks better than being able to answer the question (or rather, than just being able to answer the question, since you still answer it of course).
One time I got dinged for using a library to calculate standard deviation (as a part of larger solution) rather than doing the math by hand. I guess I assumed they were more interested in codecraft than in arithmetic and I was wrong.
Ah, that's pretty crappy. I try to avoid that sort of thing by prefacing all library calls / fancy language features with a "I'm going to just use [this thing]. If you want me to go into that, I can". Not so much ask permission as tell them. It's really a pain in the ass to have to be on guard like that though.
Well, assuming it's Haskell (given the lack of semicolon and otherwise valid Haskell syntax):
x is an unused variable in the function "int" you're defining. This function returns the ratio (as a ratio, not a float) 5 / 3 for any argument, and is equivalent to "int = const (5 % 3)", which you would be more likely to see (probably inlined).
Yesterday we got "OOP isn't that great", today we get FizzBuzz... must be that time of the month. We're probably due for a "idea-guys are worthless" here soon.
> All the candidates came to us pre-screened by a recruiting company.
Immediately end business relationships with that recruiting firm and start doing phone interviews yourself. Someone failing FizzBuzz during an in-person interview is also a red-flag on your hiring process.
I recall being sent to a programming interview by a recruiting company. The recruiter coached me on questions the company had asked previous applicants and then debriefed me afterwards to find out what I'd been asked.
This person was definitely not acting in their client's best interests.
Be careful with this kind of test evaluation:
1. The problem isn't new to you - you have already had the problem in your head for days or even years. Whether you admit it or not, you already have a good idea of how to approach the problem.
2. You are not under stress, as the candidate would be.