[suresk]

I tend to think debugging is a pretty useful indicator of how well someone will do - the best developers I've known were really good at debugging, and I've seen very few people be good at debugging and bad at programming - so I usually try to incorporate a debugging question or two into my interviews.

I like to ask debugging type questions in sort of a role-play format. Usually I'll start with a symptom that an end-user might see and then allow the candidate to ask me for any additional information (as either the end user or a system admin giving them log files and other things) to help them narrow down what the problem might be.

It is a little tricky to make it possible for them to make progress without knowing anything about the hypothetical code base, but I like it because I think troubleshooting problems is a decent indicator of someone's skill and knowledge: Do they have a good approach to narrowing down where the problem is? Do they know what kind of information to ask for (for Java devs, I like to ask questions that lead them towards asking for thread dumps or heap dumps), which shows mastery of a language/platform? Do they ask good questions in general?

I've also seen people use printed stack traces and ask the candidate walk through what the stack trace is telling them and what the possible root causes might be - this is more useful when you want to test someone's knowledge of a specific framework.

Handing someone an application in a broken state and watching them work through the process of debugging it would seem like it would be interesting, but I've never had the time to prepare this for an interview.