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?
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.
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.
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: