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?
closed as not constructive by Caleb, Mark Trapp Sep 16 '11 at 15:44
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.
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.
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.
|show 2 more comments|
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:
|show 2 more comments|