Hmm, I don't think I can put it down to a guideline. It's sort of an intuitive feel I get from them during an interview or working with them the first time. Some people just have the programmer mentality and it exudes from them. Others just come off as wet fish. I guess if I had to make it into something concrete then I would say it's how comfortable they feel/act when you ask them to back up their reasoning or motivation for doing something. I'd also add in there the willingness to go learn about something on their own to solve a problem before just simply asking for help. The good diamonds in the rough often tell you all about what they learned and tried along the way to solving a problem and then ask for guidance once they get stuck. I like those types since they show initiative and the ability/willingness to learn. They also aren't easily intimidated and accept challenges even when they might be getting in over their heads. Of course there are some who just take every challenge and drown, but I usually know them ahead of time and are standing by with the life jacket and some words of wisdom when the time comes.

As for the trying to account for user errors and odd cases, I changed my style of teaching to make these things less of an issue. I try to get them to think more simply about a problem and make it so they can't possibly have a situation that causes a user to make an improper choice/action. I used to be a defense type programmer with lots of error handling until I was shown that most errors can be avoided by simply reducing the complexity of the code/feature so it can't error in the first place (except for things like hardware failures of course). It's another one of those things I can't simply put into words here, but I do spend a lot of time teaching these things to my more experienced students. It makes me proud when they show me how they avoided a pitfall just by changing how the users/interfaces/systems interact with it.