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