I'm looking for some advice on interviewing technical candidates. I touched on this briefly in a question I previously asked: template questions in a technical interview and was informed that FizzBuzz questions are designed to weed out candidates you definitely don't want coming near your code. Moving on from that, I'd like to know what FizzBuzz questions work best? In my own experience, the common one I've seen is "Can you write a method to determine if a number is prime or not?". Personally, I find this a little too easy (writing the most efficient one is another story). Are there better FizzBuzz questions that can be used? What ones would you put to a candidate?

  • 1
    For which position do you want to hire someone? Try distilling some very easy questions (solvable in 5 minutes) based on competences you need. – johanvdw Sep 16 '11 at 13:52
  • The FizBuzz and Prime questions are there as simple filter questions that can be easily and quickly applied (potentially over the phone). They in no way indicate technical competency but they can quickly remove a good percentage of people that have no clue. – Martin York Sep 16 '11 at 15:03
  • 1
    As written, this is a highly subjective, "list of X" question that's clearly off topic. You might save it by rephrasing to something like "What makes FizzBuzz a good interview question?" or "What features to good programming interview questions have in common?" – Caleb Sep 16 '11 at 15:16
  • @Caleb, I know that FizzBuzz is a question in itself, but I also see it commonly referred to as a category of questions with the intent of weeding out people you don't want to invest more time with, which is what I'm going with in my question. I thought I was being specific with the inclusion of the word 'technical'. I don't want to use specific keywords like Java/C# etc as the the answers could be implemented in any language. I'll reword, thanks for the heads up. – Desolate Planet Sep 16 '11 at 15:23
  • 1
    @Desolate this really isn't all that constructive: your earlier question is the better way to phrase a question like this. I like Caleb's "What features to good programming interview questions have in common?" rephrase, but a revision like that essentially duplicates your earlier question. At any rate, none of the answers here bothered to answer your actual question, instead answering their own, made up questions, which likely could've been added to your original question. – user8 Sep 16 '11 at 15:46

I would look through this list of 100 questions and tailor it as needed for the specific job requirements of the position. I would suggest trying to hit every area once, especially if you are looking for a well-rounded engineer, but focus on the areas most relevant to the job.

A few examples of the questions it sounds like you are most interested in. Instead of asking "how", explicitly ask them to write a method or routine, either in pseudocode (my preferred method) or the language that they would be using if they were hired.

  • How do you find out if a number is a power of 2? And how do you know if it is an odd number?
  • How do you find the middle item in a linked list?
  • How would you write a function to reverse a string? And can you do that without a temporary string?
  • In an array with integers between 1 and 1,000,000 one value is in the array twice. Write a method to determine which one.
| improve this answer | |
  • 9
    That 100 questions list is craptastic. Abstract class vs interface? Hope you're not interviewing for C++... – DeadMG Sep 16 '11 at 14:20
  • @DeadMG It's not "craptastic" at all. You do need to tailor the questions to your specific environment, though. If I was hiring an engineer for a position that would involve C++ design and development, I would ask about virtual and pure virtual methods, as an example. – Thomas Owens Sep 16 '11 at 14:44

Personally, I wouldn't put any of them to a candidate. I'd sit him down in front of a laptop in a non-threatening setting and have him hack on a project with you to show critical thinking skills and ability to pick up new tools/technologies quickly.

Seriously, they're not children. Logic puzzles rarely do what you hope they do. Asking someone to write an algorithm on the spot is a hard thing to do. At least for me, I like to go mull a problem over coffee and sketch a bit before I sit down and start working on it. A traditional interview setting does not beget easy-flowing thought.

Hell, take him out for a beer and talk to the guy. The most important thing is to get to know someone when they aren't twitchy and nervous, see what kind of person they are, and evaluate their abilities in a non-threatening way.

If my current employer did this, I probably wouldn't have gotten the job. Right now I develop complex and good-working systems requiring abilities well beyond that asked in an interview, as a bonus I get along really well with everyone in the office. Why? Non-traditional interview policies. All of our candidates come in (after a telephone screen) to hack for a day. Better yet, pay them for a day.

| improve this answer | |
  • 1
    Sometimes you don't have the time to do that, but I have to agree that seeing someone working is a great way to evaluate if this person fits in your projects. – wleao Sep 16 '11 at 13:45
  • 6
    Also FizzBuzz questions are designed to weed people out before you invest that much time in someone. – Jon Hopkins Sep 16 '11 at 13:56
  • 1
    @wleao: Do you have time to wait for someone to work out their notice elsewhere, only to find out they know all the algorithms by heart but couldn't actually turn a business requirement into code without a lot of help? – pdr Sep 16 '11 at 13:58
  • 1
    @pdr No, I don't. But the majority of companies follow those standards because they believe that they have. I'd love to change the world: youtube.com/watch?v=jzrUqAtUcpU – wleao Sep 16 '11 at 14:00
  • 1
    @Xorlev - This isn't the only question you'd ask but if you throw three simple problems at them and they drop the ball on more than one of them I'm going to move on to the next person. You have to be realistic about how much time you invest in someone who is showing themselves unable to solve basic problems. – Jon Hopkins Sep 16 '11 at 15:59

You could ask questions that are related to programming paradigms, for instance, a problem that could be solved easily using functional programming. Let's say, design an algorithm to compute a postfix expression. That way you could also see if the candidate knows how to use stacks.

I recommend you reading:

  1. How Would You Move Mount Fuji?
  2. Cracking the Coding Interview, Fourth Edition: 150 Programming Interview Questions and Solutions
  3. Algorithms For Interviews
| improve this answer | |
  • 4
    I don't even know what a postfix expression is without Google. And this is the problem with interview questions like this. – pdr Sep 16 '11 at 13:56
  • I've never read "How would you move mount fuji?", but it looks like a really interesting read. +1 for book recommendation. – Desolate Planet Sep 16 '11 at 14:27
  • 2
    @Desolate Planet: It is an interesting read, and so I encourage you to read it. But keep in mind that even though it is interesting, it does not give particularly good advice on interviewing, and it describes a style of interviewing that hardly anyone uses at Microsoft anymore. The idea that you can determine if someone is going to be a good coder by asking brain teasers was faddish and has largely passed. – Eric Lippert Sep 16 '11 at 15:32
  • 2
    I would name another mountain "Mount Fuji". There. Moved. =) – wleao Sep 16 '11 at 19:10
  • 1
    @wleao: I'll try that. Next time a customer needs software I'll just rename the helpdesk software to whatever they need. =) – Falcon Sep 16 '11 at 19:15

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