Programming interviews are horrible. This may be a better way.
If Jesse (employed by you as a software engineer) is good at her job, and she writes the following bit of code:
x = 10
//this is a nice-looking assignment
And Sydney (applying to work for you as a software engineer) writes the following piece of code:
x = 10
//what an awesome assignment
And Charlie - looking at each piece of code, but not knowing which came from which engineer, cannot reliably pick the one that came from the engineer you actually employ, then you know that at least for that narrow task - Sydney's abilities equal Jesse's.
Put a slightly different way: If you already know Jesse is a good coder, and you cannot distinguish Jesse's code from Sydney's, then you know that Sydney is also a good coder.
If you do this with a sufficiently broad range of tasks (this should be doubly-easy if you've been diligent about testing) then not only do you have a much more objective measure of your applicants suitability for the team - you cannot help but select for people with specific expertise in your stack and an intuition for your coding style.
One last thing: if you're hiring a person to do something no one on your team has actually done - then just find an appropriate project on Github and use that codebase as your standard.