Exactly. I'd guess that about half of the candidates at an entry-level position would fail to distinguish between the diagnosis stage and the remedy stage, lumping them all into one. We see this tendency all the time in these forums. Seeing methodical, step-wise decomposition of the problem, even if the steps differ from my own course, would be the signs to look for. These would tell me that the candidate has the ability and aptitude to at least become a useful debugger, even if the person isn't one already.
I really like what Johnsfine says about the use of theory and the ability to objectively prove or disprove the theory as a way to get to the root of a bug or problem.

BTW, when the OP said "idle approach", I think she meant IDEAL APPROACH.

OK

That's a very open topic. I agree with the statement that it's really about how the person approaches a problem. Not all problems are pure software. I also agree that, in the role of a software person; good coding is helpful. Being able to step back and try experiments to systematically validate parts of a solution is also important.

I would certainly say that this is an example of excellent debugging skills:

http://randomascii.wordpress.com/201...n-my-compiler/

If you have to ask, then you ain't got it.