I've found that pairing with interviewees on real(ish) problems usually helps to detect useful traits (I am not advocating pair-programing here FYI; rather working with them in front of a machine during the interview). Your mileage may vary.

Some of the things I look for are (in no particular order):

1. Knowing where to look for help when stuck

2. Systematically looking up the man pages/docs/API when stuck as opposed to making multiple wild guesses

3. Indenting code and saving files with proper names (you would be surprised how many people don't intend code even when it spills over 15-20 lines)

4. Instinctive eye for usability - for e.g. parsing command line arguments when appropriate rather than doing it blindly (`if sys.argv[n]: foo elif sys.argv[n-1]: bar`)

5. Inclination to iterate, even during an interview. Many people are happy to produce a working answer and leave it at that. Some iterate and tidy up without being asked to.

This gets said a lot, by many people, but: by checking their open-source / publically available work.

If someone's managed to complete a significant task, and the code looks readable and reasonable, they're probably fair decent programmers. Even better if they've got code Out There in multiple languages; that shows a broad base of both knowledge and experience, in my opinion.

That's half the answer, I'm afraid. Anybody with a bunch of time on their hands can churn out quality code. The other half -- self discipline to ``duct-tape your way through'' when in crunch mode -- is not covered by reading sources.

Now that I think of it, another angle comes to my mind: once you're done with the crunch mode, you need to get back to the duct-taped mess and mop it up. If working in an organization, it's mostly communication problem -- you need to explain to your boss why you absolutely must rewrite what works now. Not only taking time, but also risking introducing new bugs.

You'd be surprised.

For the least few years the place I'm currently working has used a remote development exercise as the first filter for applicants - send a simple programming task that should only take an hour or two and look at the results that come back.

50% of applications get rejected based on a quick skim of the code submitted - not for subtle reasons either, with the most common problem being solution complexity that is wildly disproportionate to the complexity of the problem (especially when the notes on the task explicitly warn against this).

And the other question is: how do you sustain and nourish this curiosity and gaining of knowledge in regular project work cycles in typical IT departments under already more-than-pressing deadlines?

Often there are very real issues, however sad and true, why there are so many hacks and "duct type programming" and more often than not, programmers and immediate superiors do not have the luxury of being able to deal with them and instead have to "suck it up".

Once you are in "crunch mode" in a death march project curiosity, elegance and sanity are the first casualties right after all of your free time.

And apart from that, we as humans are not exactly outstandingly great at betting on the "later benefit" instead of immediate gratification.