Are there any Phone Interview equivalents to FizzBuzz?

Question

I think FizzBuzz is a fine question to ask in an in-person interview with a whiteboard or pen and paper handy to determine whether or not a particular candidate is of bare-minimum competence. However, it does not work as well on phone interviews because any typing you hear could just as easily be the candidate's Googling for the answer (not to mention the fact that reading code over the phone is less than savory).

Are there any phone-interview questions that are equivalent to FizzBuzz in the sense that an incompetent programmer will not be able to answer it correctly and a programmer of at least minimal competence will?

Given a choice, in my particular case I am curious about .NET-centric solutions, but since I was not able to find a duplicate to this question based on a cursory search, I would not mind at all if this question became the canonical source for platform-agnostic phone fizzbuzz questions.

Answer 1

Personally, I think FizzBuzz is the perfect question for a phone interview question. Basically anyone you would ever want to hire should be able to answer this over the phone in under a minute, off the cuff. 15 seconds to think about it is the absolute maximum pause before they should be able to spout off the answer off the cuff. They can do it in pseudocode, in fact, they should do it in pseudocode, because it demonstrates that they can commuinicate effectively.

I know sometimes people are nervous and screw up, but the FizzBuzz question is about as difficult to answer as "Explain what you like about the .Net Framework" type questions. If they screwed up one of those they certainly would not get hired regardless of any nervousness pity.

FizzBuzz is the type of question you should be able to answer faster than you can google, so I would not worry about cheating. Hopefully there are more difficult questions down the line to weed out those who slipped through anyway, since FizzBuzz is only a preliminary filter.

It is effective though. Check out the baffling number of programmers who posted incorrect solutions in response to the Coding Horror post about FizzBuzz imediately after making fun of how easy it was. Maybe I am mistaken, but I have trouble picturing someone who cannot describe a loop, 3 "if"'s, and an "else" being particularly successful at solving complex business problems productively or successfully.

Answer 2

Got this one from this answer to another question, and it worked like a charm for a phoner I was involved in today:

"If you had to verify the input of an e-mail address field, how would you go about it?"

Answer 3

I agree. I have been an interviewee and interviewer at many occasions and my experience tells me asking them to write standard code on the phone is cheating-prone.

After trial and error I have actually concluded that open ended algorithmic questions work very well on the phone. An example is to ask them to build a phone book. Then begin evaluation. If they ask questions, ask them to explain the reason they ask, tell them to evaluate their design choices , give them feedback, and the ask them to explain their iterations. I find that while I don't learn much about their actual familiarity with a particular language, I can tell if they are smart and have fundamentals down solid.

Answer 4

I agree with ironcode that FizzBuzz can be done over the phone, if you're willing to deal in pseudocode. If you're worried about the interviewee merely reading a question off a web page, just propose a change in the requirements and see how they handle it. Just ask, "Instead of all integers, what if we wanted it to print out only Fibonacci numbers?", and if they get totally flustered, you'll know.

Another route is to talk through the high level design of something, asking them questions about what data structures they would choose. I used to follow a script that went like this:

1. "We want to implement the Observable pattern. How would you store the Observers?"
   • In my experience almost everyone starts with an array.
2. "How would you implement addObserver, removeObserver, notifyObservers?"
   • They usually say add to array, remove from array, and loop through array.
3. "We want to guarantee that even if addObserver is called multiple times, the object will only be notified once. Would you change anything?"
   • A bad candidate will get confused, and maybe propose some bizarre changes to notifyObservers.
   • A decent candidate will add a check to addObserver. (You can quiz them to see if they think removeObserver needs to change also.)
   • A better candidate may also consider changing the data structure to a set.
4. "Let's say in our application we know that we will be frequently adding and removing observers. Would you change anything?"
   • If they are still using an array, this push a decent candidate to consider a set.

On the surface it may seem like I'm encouraging people to use more sets instead of arrays, but really the point is that the whole problem is just a framework for having a conversation about choosing a data structure. It isn't about getting a right answer so much as seeing if the candidate will revisit their earlier choices, or if they dig in and never look back. In the rare case that they happen to start with a set, you can change the questions to make an array a better choice (e.g., "We want notifyObservers to be as fast as possible. Would you change anything?").

I also think there is some value in framing it in terms of implementing the Observer/Observable pattern, because you're asking the interviewee to work on a more abstract level. Really terrible candidates might not understand how you can do this without the Java class Library's Observable abstract class, or might spout a bunch of gibberish about "using design patterns" in a way that implies they don't know how to write code at all.

Answer 5

"What's two to the eighth power?"

That was our first question after "hello." We found that flubbing this question was 98% correlated with negative outcomes later in the interview. We wouldn't hang up immediately if the interviewee hemmed and hawed, of course, but if they got it wrong or took too long to answer it was a strong indicator the interview wasn't going to go well.

It's a simple way to screen within ten seconds of answering the phone.