I think the best way is to give them access to a code base, give them 48 hours and have them submit a pull request for a feature. That way you can see that they can learn the codebase and implement the feature in their own time. During the interview, you can discuss their code and the reasoning behind the implementation details.
I once got asked to spin off an ec2 instance from an image provided by the company I applied to, and then answer certain questions about the dataset on that thing. I had to write actual code to obtain the answers. All that had to happen within 24 hours. Then there was an on-site interview where they asked questions about stuff like JVM garbage collector fine-tuning and such. That was the best interview I had, ever.
Still I think that would become obvious pretty quickly. I've actually had people start writing out a textbook algorithm that just solved the wrong problem. And then completely stumbled when trying to explain how the program would arrive at the intended result.
I usually ask questions until the person is out of his comfort zone, and if he is completely clueless on how to proceed at that point it's a red flag.
