[soseng]

To change it up a little bit, has anyone here been asked simple debugging questions? I've interviewed at numerous places and I've never been asked the question why a certain piece of code is breaking or how to fix it. The questions could be designed to be self-contained and just complex enough to get a feel for how the candidate thinks. My consulting job usually takes me to places where a project is in trouble or failing. It would seem that quickly understanding broken foreign code would be a huge asset. The closest question I've been asked is: "Here's a Singleton implementation in Java. What can go wrong?"

[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.