Properties of good coding interview questions?

Question

A lot of coder interviews involve asking a brainteaser-ish / cleverness-inspired algorithmic puzzle. I can see how this can help measure intelligence, quick-thinking, and an ability to communicate. And, frankly, I love brainteasers. But maybe you want to hire someone for skills besides quick-thinking and cleverness -- such as an ability to work well with other coders, a knack for very maintainable framework designs, or a good intuition for how end-users think.

So: when choosing an interview question to ask, what makes the question more likely to reveal a great employee vs a mediocre one?

Answer 1

You may want to check out these older SO questions, since various forms of this question have already been asked:

Best interview question

Worst interview question

Worst interviewee answer

Answer 2

These three questions really boil down to the same thing: do you, and your team, like the candidate?

So it makes sense to extend the final round of interviews to include a junior dev, a team leader, and if possible a representative of the user community.

And then go for lunch. Seriously!

Answer 3

At my company, we try to ask questions that:

• Have multiple solutions
• Don't reveal all the details, giving the interviewee a chance to ask questions and make sure they understand the problem

These kind of questions show how well the person can communicate with their peers, which is valued very highly at my company.

I despise brain teasers in technical interviews.

Answer 4

We use a simple pen & pencil coding question as a quick test to see if the interviewee matches up to the skills they claim on their resume.

At first I was concerned that the questions was insulting easy for a senior level dev ... but after seeing a surprising number of candidates either flunk it totally, or take far too long, it has proved its value. We could have discovered that they didn't cut it through other questions, but this is just the fastest approach.

It is also interesting watching people's approach to the problem, which tells you a lot about how they approach coding. The best simply scribble down the answer about as fast as they can write; others spend a lot of time thinking without even trying to draw out any diagrams or anything to help.

Answer 5

I really hate to just paste a link but its tempting. Below is my all time favorite programming article. I won't even paraphrase the 5 points here because that wouldn't do them enough justice:
Steve Yegge's - The Five Essential Interview Questions

However, those questions will really guage the ability of the programmer. If they are flexible, and have at least a rough understanding of everything that a programmer should grasp. It seems what you're looking for is how well can they work well with others? That I am in no place to wonder. I'm as curious as you are!

Answer 6

It's good to start off with a couple of softballs

We usually start off with a couple of simple baby questions.

For SQL or C, for example, we might ask them to explain

select count(*) from foo where x = null or x <> null;

or

x = 0; if (x = 1) then y = 2;

good warmup for a real question

Candidates naturally might be a bit nervous, and giving them an easy question or two gives them a chance to find their groove without worrying about the answer.

shows how the candidate thinks about a problem

Ask them to narrate their stream of conciousness as they work through the problem. They might get the wrong answer, but you will have some idea if it was a minor glitch or a total breakdown of their thinking. Doing this on a simple question prepares them for discussing a harder algorithm question.

let's them know we're not interested in "trick" questions

We're interested in what you know, and what you can do in a real setting.

shows the candidate has some minimal competence in the language or technology.

If a C++ or C# programming candidate doesn't know the difference between "i=1" and "i==1", you can save yourself a lot of time and cut the rest of the interview short.