Talk about that stuff. People sometimes spend extra time polishing a code challenge than they do in their day-to-day. People can lie to you in code just like they can in conversation.
Sure, you know that their ability to do it is there, but you still don't know that they will and you still don't know that if they didn't they could learn. You can get that information from having the right conversation.
What testing tools do you use? What's your approach to testing? What pitfalls have you run into with testing?
What projects have the best and worst documentation that you've used. How does this affect the work you do? How do you make your code usable to others?
What's your opinion about input and output of functions? Separation of concerns, etc?
Or the best question of all: What books about programming have you read and liked and why?
You can't stare at somebody's code and know if you'll like working with them. More importantly, weedout challenges are a solution for the wrong problem. If you're worried about wasting your time bringing in the wrong people to interview, maybe focus on getting better indicators on the kinds of people that you (want to) bring in.
