29

During interviews, I usually open with Fizz-Buzz. Our recruiter has apparently caught onto this and has told every candidate to research this question.

This has lead to several people memorizing any of the zillion one-liners for the solution. The problem - they almost never get the one-liner right. If you spend 15 minutes redoing your one-liner Fizz-Buzz answer, then I know you're probably not the right person for the job.

The issue is some people that memorized the one-liner did ok during the job interview, but the one-liner doesn't compile/run, so I fail them.

I've tried hinting that the best solution is the easy one that you can explain to me, but most of the candidates don't seem to listen. I've said

Please make sure you can explain this to me when you're done. This isn't a trick question, and if you use a language features that I'm not super familiar with, I'm going to type your program in and run it. If it doesn't run then I can't give you any credit for this answer. A simple solution that works is better than a 'clever' solution that doesn't.

This hasn't seemed to help, and I don't want to just come out and say. "Everyone who passed this question used if statements and modulus." Has anyone found a good way to avoid getting 'clever' solutions?

The issue: Very few people are getting past Fizz-Buzz. I think part of the problem is people trying to stand out as the clever candidate. Some of the Fizz-Buzz failures ended up demonstrating a good command of SQL and basic programming concepts like inheritance. They may have passed Fizz-Buzz had they just done it the simple way. For better or worse Fizz-Buzz is a litmus test question for me, and if you fail it, we won't hire you.

EDIT If you spend 20 minutes on Fizz-Buzz, you're not going to move forward. If you spend 5 writing a one-liner, I don't know if it works until I try to run it. Because some of the candidates do better after this question, I'm hesitant to cut the interview short like I would have for a flat-out failure.

EDIT 2 Several commenters have asked if I run each copy of Fizz-Buzz including the for/if/modulus one. If the control flow is obviously right, I don't run it.

The problem with one-liners its never been intuitively obvious what the one-liner was supposed to do. For example, one person decided to write the LINQ version of Fizz-Buzz (for a Java dev position mind you) and proceeded to ramble about how LINQ creates a set and then selects out of it. I've never had a one-liner candidate explain clearly what each command did.

The type of answer I'm looking for is

This is the for (or while) loop that will go from 1 to 100. Next, I calculate the remainders of x/3 and x/5 and store the answer here. Then I do if/else if to determine what if anything I should print.

The reason I still use Fizz-Buzz heavily despite the above issues

  1. Even with this question being extremely popular a good minority of our candidates spend upwards of 20 minutes (occasionally the entire interview) on this question and get it wrong. If you can't create this very simple program in 5-10 minutes, I don't want to hire you.

  2. Every simple question has a one-liner, and I've learned from experience that even simple-sounding problems can be very tricky. I don't want to make up my own as I could inadvertently create a very difficult problem that would take more than 5 minutes to solve.

  3. Using a one-liner tells me about you. Using a one-liner from a language other than the one in the job description tells me A LOT about you. My question has to do with people who may have been couched the wrong way.

  4. It wouldn't be that hard to memorize the for/if/if else version and Fizz-Buzz is a VERY popular question. I've tried saying pretend I'm the stupidest developer you've ever meet. You need to be able to explain the answer to me - The candidate started talking about how cool Perl regex's are (for a Java dev position).

closed as unclear what you're asking by gnat, Lumberjack, scaaahu, Jay, JakeGould Jun 30 '18 at 22:46

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat. – Masked Man Jun 30 '18 at 3:58
  • Pls clarify your question. 1. Do you make candidates dry run the code or write unit tests? 2. Have you made your mind up that a whiteboard Fizz-Buzz must be part of the interview or are you open to other options, such as Fizz-Buzz at a REPL or IDE, or a bank of other beginner exercises? – Qsigma Jun 30 '18 at 6:35
  • "Very few people are getting past Fizz-Buzz. I think part of the problem is people trying to stand out as the clever candidate. " I'd say that's a good thing; clever is the enemy of maintainability. – Andy Jun 30 '18 at 18:19
  • @Andy "Clever is the enemy of maintainability" - this is one of the reasons Fizz-Buzz is one of my go-to's for interviews. I hate seeing one-liners in code. – sevensevens Jun 30 '18 at 19:11
  • I think this question is quite clear: the OP wants to have his cake and eat it too. The correct answer is he can't, and he's going to have to decide how much to keep and how much to eat. – jmoreno Jul 1 '18 at 19:25

10 Answers 10

63

The solution is the same one used by teachers when they need to avoid cheating off the previous term's exams: randomize the test.

Invent a similar problem (or better, a family of problems, so it can be subtly different for each candidate) and watch them think.

  • 7
    ...for example, the FozzBazz test, where you replace multiples of 4 with "fozz", multiples of 6 with "bazz" and multiples of 24 with "fozzbazz". Good way to stop the rote memorization and regurgitation in its tracks. – HopelessN00b Jun 29 '18 at 20:43
  • 18
    @HopelessN00b What about 12? – user1717828 Jun 29 '18 at 23:00
  • 6
    @user1717828 I guess part of the test would be to see whether candidates note this. – Paŭlo Ebermann Jun 30 '18 at 8:52
  • 2
    @HopelessN00b Nice on, because any even barely qualified software developer will have no problem, but anyone who "researched" the original problem will change the numbers and produce code that doesn't work. – gnasher729 Jun 30 '18 at 13:23
  • 1
    @HopelessN00b This is pretty great -- I'd even go so far as to not change the name of the test, but mix up the requirements from "standard" FizzBuzz. Frankly anyone who is memorizing a one-liner in order to pass a job interview is not someone who I want to hire, personally. – jkf Jun 30 '18 at 21:45
37

I'm a bit confused here. Any recruiter who tells people about this test is a complete failure at their job. Someone needing this advice and "researches" this "problem" may just about scrape through the first hurdle but doesn't have the slightest chance to ever get hired; this is just wasting everyone's time. This test is about the difficulty of counting to ten while standing one leg.

Just take a different question. That would be the meta-fizzbuzz test for interviewers: If you can't find a test that you can use instead of fizzbuzz in five minutes then you shouldn't interview people.

PS. If I interviewed people to clean windows on a highrise building, I might ask them to count to ten while standing on one leg, even though this is discriminatory to those with ear infections, vertigo, physical disabilities or general balance problems.

  • 2
    Very important that this question points out that the recruiter is giving away the questions (could also be on website like glassdoor) – jcmack Jun 29 '18 at 19:44
  • 7
    This test is about the difficulty of counting to ten while standing one leg That characterization seems unduly discriminatory to those with ear infections, vertigo, physical disabilities or general balance problems. It's actually about as difficult as counting to 100, and replacing your multiples of 3 with "fizz", your multiples of 5 with "buzz", and multiples of 15 with "fizzbuzz". Of course, a fizzbuzz test shouldn't take as long as counting to 100, though. – HopelessN00b Jun 29 '18 at 20:38
  • 8
    @HopelessN00b if the job is for cleaning windows on a highrise building, I'd see discriminating against people with general balance problems as a very good thing. – user29357 Jun 29 '18 at 23:37
  • 9
    @HopelessN00b you've obviously misunderstood. Job is working at heights → discriminate against physical disabilities which would make it dangerous. Job is working with code → discriminate against people who can't work with code. gnasher729 is comparing the two situations, by using an analogy. – user29357 Jun 30 '18 at 2:36
  • 18
    @DawoodibnKareem Yeah, and you’d have no one else to blame when they smear soda on every 3rd window, bees on every 5th window, and angry, sticky bees on every 15th window. – HopelessN00b Jun 30 '18 at 2:44
24

As everyone has said already, you should consider changing up your opening question.

But whatever you choose, and you may have already realized this:

There are no good questions, only good follow ups.

Whatever question you choose will be trivial enough that basically anyone could google / get a friend to help / encountered its basic structure already. But what is not trivial is follow up questions.

Can you expand your answer to Woof on multiples of 7?
What are the advantages of your solution?
What are the disadvantages? What different considerations are there if this becomes an enterprise solution dispensing millions of lines of results every second?

The answers to questions like these will tell you much more about the dev than any initial contrived problem statement you could formulate.


Don't discourage one liners. Ask follow up questions that make one liners untenable.

Seniors and Juniors alike can churn out a one line solution to classic FizzBuzz, but only the best can take an ever changing requirement landscape and always, continuously, easily adapt their code.

20

If at all possible, I would recommend not using that recruiter - they are actively undermining your process (because it makes them more money).
Don't work with recruiters that do this, it will only cost you in the long run.
If that's not possible, pursuing other answers may be your best option but they all strike me as work-arounds to the real problem.

  • It’s not making them more money if it causes their offers to NOT get hired. – WGroleau Jun 29 '18 at 23:44
  • 5
    +1 It seems like the real issue is the recruiter only producing low quality candidates. Find yourself a better recruiter. – Wes Toleman Jun 30 '18 at 5:42
12

Every few years, I apply for a job just for the interview practice... my last one (last year, mid level Java dev position) they asked me to implement fizzbuzz, and I did a whole "long way", clear easy to follow and maintain version. The developer in the interview committee immediately asked why I wasn't writing more concise code, and I explained that we are no longer using 8 bit CPUs with 16k of RAM and squeezing every last clock cycle out of code wasn't really needed, if it was they wouldn't be using Java, and it is better to write easily maintainable code that is clear and easy to understand than to write convoluted masterpieces that save 3 clock cycles per run of the program.

So use the one liner as a filter. When you ask, don't just ask "Do fizzbuzz". Instead ask them to write a maintainable-by-Judy-from-accounting-who-knows-VBA version of fizzbuzz, or use some other slight indication that the important bit isn't writing impressive code, but writing code that others will be easily able to understand and modify/fix/maintain later. And if they give you a one liner, that may indicate they aren't quite the person you want....

Or, if you want to hire the guy that CAN understand and maintain a filled with one liners super convoluted code base, give them a one liner implementation, ask 'em to unravel it, and make it so that Judy can maintain it, and then reimplement it as a one liner again.

And as other answers have said, cut business relationship with the recruiter.

  • Since this an interview, I wouldn't give any indication what code I expect. I would expect any decent software developer to ask a few questions to make the spec 100% clear, followed by a few minutes of typing until slightly more than 12 perfectly readable lines of code are produced that solve the problem correctly except for some possible typos. – gnasher729 Jun 30 '18 at 19:39
  • @gnasher729 exactly. Which is why you can use the presentation of a one liner as a filter :) – ivanivan Jun 30 '18 at 20:06
  • This is a great answer. The interviewer should be looking for people who write maintainable code, not people who write cryptic one-liners. – Dan Pichelman Jul 2 '18 at 13:54
8

Fizz buzz is such a standard weed out question, a decent candidate should already be prepared to answer it without being coached or needing to memorize answers, and so determining if candidates are obviously memorizing clever answers to it is I feel part of the test.

However, I do not recommend in cutting the interview short. Even if the candidate doesn't seem likely to be a good one, there is merit in treating them respectfully and giving them the full time you've allocated. Word of mouth gets around, and you want to attract good candidates. You won't do that if people interviewing with you have a bad experience and talk about it to other developers.

And if you continue the interview and find that they seem a decent developer, and possibly just made a poor judgement in over preparing, you could follow up with questions about their feelings on the value of code readability versus trying to be clever, and ask them their thoughts on optimizing their answer to fizz buzz, maximizing for simplicity and readability, rather than trying to cram it into one line.

  • "However, I do not recommend in cutting the interview short" - This was originally the entire point of FizzBuzz; to reduce time wasted in interviews that were pointless. If arguing not to do that, I'd suggest making it clearer that the original intention of FizzBuzz (as a cheap filter) isn't something you'd recommend. – Bilkokuya Jul 2 '18 at 9:41
  • I don't feel cutting an interview short when you know the person isn't a fit is disrespectful. I don't end it immediately and scream "YOU FAILED", I switch to a soft-ball question or two and wrap it up 10-15 minutes later. – sevensevens Jul 16 '18 at 18:05
  • I suppose it's probably possible to do it respectfully, but I've also been on the receiving end of it being done very rudely, and it's very easy to come off the same as screaming "YOU FAILED" at them. – Kai Jul 16 '18 at 18:26
5

You have fallen victim to Goodhart's Law but consider: just as candidates have memorised an answer to your question, you have also memorised an interview question that that guy Spolsky wrote about once. So this is not entirely the candidate's or the recruiter's fault. Interviewing these days has fallen into everyone playing a role of who has read the trendy blogs and Cracking The Coding Interview and similar, which means it's not a test of technical skill but one of being part of the in-culture.

My suggested solution is to write an original piece of code yourself implementing a simple function, say 10-20 lines, but with a few flaws, and ask a candidate to debug it. You can easily produce a new one anytime you want and all the recruiter can do is brief candidates to be good at debugging, which is what you want anyway.

3

Very few people are getting past Fizz-Buzz

FizzBuzz to the rescue. Congratulations. It's working.

Remember what Imran Ghory said in his original post:

On occasion you meet a developer who seems like a solid programmer. They know their theory, they know their language. They can have a reasonable conversation about programming. But once it comes down to actually producing code they just don’t seem to be able to do it well. (emphasis mine)

As some English guy once said, "Aye, there's the rub". Some people can talk a good game. But when it comes to producing something that works - and not even something complicated! - they blow it. They fail. They can't do it! Why? Well, to paraphrase Barbie, "Programming is HARD!". And that's the entire purpose behind FizzBuzz - to separate the programmers from the talkers.

I think part of the problem is people trying to stand out as the clever candidate

Who cares? It's not about why they fail - it's about THEY FAIL. Tell me - do you want "The Clever Guy" whose code won't run, or do you want the guy who understands that what you write has to work, even if it's not the coolest solution? Of course, you want the latter. Why the latter? Because (as the short guy almost said to the the man in black), "You are not a great fool". The other guys, those who try to be clever and end up being buffoons, are not who you want, regardless of how good a game they can talk. You want the people who can actually sit down and Make Something Work - and FizzBuzz is proving its worth, even if you don't like the results.

Over the years people (non-developers all) have repeated to me that "the programmer is not the code". And while that's really nice from a touchy-feely Human-y Resource-y code-y-review-y point of view, from the point of view of BOTH the programmer AND those who he works with - it's completely wrong. The programmer is very, very much defined by the code he/she writes. What are artists defined by? Answer - their work! What are authors defined by? Answer - their work! What is a programmer defined by? Answer - THEIR WORK! And WHAT is the end product of a programmer's work? CODE! In terms of their work, THE PROGRAMMER IS THE CODE; THE CODE IS THE PROGRAMMER! Learn it, live it, love it!

The issue is some people that memorized the one-liner did ok during the job interview, but the one-liner doesn't compile/run, so I fail them.

Good for you. You're doing the right thing.

But in my opinion, in this post you're making a fundamental interviewing error. In the face of clear problems - like, not being able to code up a working solution to a very simple programming problem - you're attempting to make excuses for them. There are plenty of cut-and-paste "developers" out there. There are plenty of great-Google-fu "developers" out there. But a so-called "developer" who can't produce a working solution to FizzBuzz, and who can't listen clearly when you tell them to make it work correctly rather than to spit out an incorrectly-memorized one-liner..? As someone almost said, a long time ago in a galaxy far, far away, "These are not the developers you're looking for...".

As the guy with pointy ears said, "Live long and prosper".

EDIT

And to get past the "recruiter is telling candidates about FizzBuzz" thing, you should develop a family of Simple Development Tasks That Any Developer Should Be Able To Write In Two Minutes Or Less. Here's some examples:

  1. Vary FizzBuzz a bit. Classic FizzBuzz prints Fizz for numbers which are evenly divisible by 3 and Buzz for numbers which are evenly divisible by 5. So change it to seven and eleven. Or four and nine. Or reverse it - Fizz on five, Buzz on three.
  2. Change the name and the output. Name it FoosBall, or something like that.
  3. "Print all the even numbers from one to 200".
  4. "Print all the even numbers divisible by 7 between 1 and 357".

Develop other variations on this theme. Remember, you're not giving them anything tricky. You're not telling them to write a SELECT statement that returns the values of the Fibonacci sequence as a series of rows. In my opinion THAT would be over-kill! You're trying to give them a dirt-simple programming task to see if they can do it. To filter out the wannabees you don't have to do anything complicated! That's kind of the whole point of FizzBuzz.

And...make sure you take their phones away. Some "developers" can't code without their phones. I can't imagine why... :-|

To quote Wayne: "Party on, Garth!"

  • 1
    Don't take their phones away. Stay in the room with them. In my opinion, leaving is disrespectful. If you want to save time, cut the interview short if they're not good enough or fast enough. At least, that's my personal opinion, others may disagree. – Stephan Branczyk Jul 1 '18 at 9:01
  • Either way - make sure there's no chance the candidate is Googling for answers. – Bob Jarvis Jul 1 '18 at 16:41
  • +1 This is the only answer that actually emphasises the core point of FizzBuzz; to remove candidates that literally cannot write code; quickly. Anything more than that starts muddying the reason for using it as a test in the first place. – Bilkokuya Jul 2 '18 at 10:23
2

Do it the easy way first.

Then, do it the difficult way.

What are the comparative benefits and drawbacks to both those approaches?

(Thanks to aschepler for suggesting that third question)

That's the answer you're looking for.

Unfortunately, as soon as your recruiter learns of these new questions, you'll be back to square one. There is no way around this.

Let go of your own perfectionism. You can't set up the perfect experiment with the same identical questions every time. Even without the recruiter, there is no guarantee that the candidate who aces all your questions doesn't have a friend who took the interview before him and gave him all your questions.

You'll need multiple questions and rotate/vary them a little.

  • If you're going to ask for two different solutions, then maybe more important than what those solutions actually are is the candidate's response to the next prompt: What are the comparative benefits and drawbacks to your two approaches? – aschepler Jun 30 '18 at 2:19
  • Blaming a recruiter for trying to make his candidates conform to client requirements is like trying to blame a cook for seasoning the dish "just right". I've known A LOT of recruiters over the years. Some were better, some were worse. Some were absolute schlock-monsters who would re-write your resume without even telling you. ("I know about what? Wow - I didn't know I knew that!") Some were guys I'd worked with who thought this was "an easier gig". All of them cared about getting their candidate placed, because THEY WANTED TO GET PAID! Wow! Money actually is a motivator! Whoodathunkit?!? – Bob Jarvis Jul 1 '18 at 0:56
  • @aschepler, Thanks, I've just incorporated your suggestion. – Stephan Branczyk Jul 1 '18 at 8:49
  • @BobJarvis, Point taken. It is true that I was a little harsh against recruiters. I've just removed that part. Thanks for the feedback. – Stephan Branczyk Jul 1 '18 at 9:04
  • @StephanBranczyk - actually I thought your comment about recruiters being perhaps other-than-trustworthy-partners in the recruiting process was completely on-point! Perhaps I went a bit overboard :-( – Bob Jarvis Jul 1 '18 at 16:53
1

If you want the candidates to focus on results, rather than "good code", then you should make it clear that you're not going to look at the code. Hand them a laptop and tell them they're going to save their program as a text file and you're going to run it from the command line without ever looking at it.

If you do look at the code, the inevitable result is that people will optimize for "code that I think will impress the interviewer", rather than code that performs to the specs. In some ways, having an easy question makes this harder. If I'm asked in an interview how to find the first billion primes given such-and-such a running time constraint, then I can show cleverness by various time-saving strategies. If I'm asked to do FizzBuzz, the only way I can show my cleverness is by playing Code Golf.

You can reduce, but not eliminate, this phenomenon by stressing that you just want an answer, and you're not looking for any sort of optimization. It can also help if it's clear to the candidate that this is a preliminary question; there are going to be further questions where they can show mastery, right now you're just asking for competence. Something else you can do is try to focus on readability. Tell the candidate to imagine that a non-programmer is going to read the code, and you want them to be able to see at a glance what the code does.

A question to ask, however, is why this is a concern. Do you think that there are people that would be good hires, but are failing due to this phenomenon?

  • 5
    Playing Code Golf during an interview isn't showing cleverness. – Erik Jun 30 '18 at 12:33
  • 2
    I would argue that producing code that a non programmer can read is mastery. One thing I look for during an interview is someone who writes maintainable code, not someone who feels the need to show how clever they are – tddmonkey Jun 30 '18 at 15:54
  • 2
    If you're handed FizzBuzz, the point is not to show how clever or cool or code-golf-y you are. The point is to prove you can make it work. As OP said, "...if you use a language features that I'm not super familiar with, I'm going to type your program in and run it". So candidates increase their risks by being clever. They decrease their risks by being straightforward - which is a whole lot like "real" programming. At least in my experience, your mileage may vary, tax, title, and options extra. :-) – Bob Jarvis Jul 1 '18 at 1:04

Not the answer you're looking for? Browse other questions tagged or ask your own question.