"Asking the same questions also makes it easier to compare between candidates and the questions can become optimised over time to ensure they are fair and valid performance predictors."
I've seen this claim getting bandied about a lot lately, but I'm increasingly less convinced. You receive 10 n-dimensional vectors of programming and engineering skill, aka "applicants". You take their dot product with a ten-dimensional vector. Even assuming you can do that correctly and reliably, on what basis are you so sure that the ten-dimensional vector you've chosen has any relationship to what you really need? Repeatably and accurately asking a detailed question about recursion and pointers in a job that rarely calls for it just means you are repeatably and accurately collecting irrelevant information.
I've been chewing on this claim for a few months as people have been making it, and it's not like I'm entirely unsympathetic to it, as hiring does obviously suck. But lately the more I think about it, the less convinced I am this is the path forward. It just seems like a great way to institutionalize bad practices.
I think you need to embrace the diversity of the incoming n-dimensional vectors and pursue a strategy of exploration. Fortunately, they're not all uncorrelated and you do have an idea of what you're looking for. I see interviewing as a process where I'm seeking the answer to the question "What are you capable of?", and I want to seek out answers focused on how that relates to what I'm looking for, and that may mean I thought I was interviewing a dev candidate but I'm actually interviewing someone suitable for QA, or vice versa, or I thought I was getting an academic and I've got an old UNIX sysadmin, and these are just the examples I can quickly give. (What really happens is even more detailed, like, they clearly know their APIs but they're pretty sloppy in their naming, or I started looking at their personal projects for skill and was surprised at the documentation, etc.) It's not an easy approach, but why would we even expect there to be an easy way to analyze applicants?
(Or, to put it in more statistical terms, rather than applying a fixed vector dot product, I approach applicants in terms of a multi-armed bandit, where I'm trying to find their strong points. It helps in this case that the "multi-armed bandit" is actually incentivized to help me out in this task.)