Discouraging "one-liner" answers for coding questions [closed]

Question

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).

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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!"

Answer 9

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.

Answer 10

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?