In terms of an actual question, the only useful ones are ones that come from this chat, because it's where we have a back-and-forth conversation about tech decisions, what issues they had, what they had to overcome, and what decisions that particular dev made. My goal is to get a reaction, negative or positive, and dig into why that situation happened, what they did to overcome it, and what they'd do with hindsight.
Not only does it make an interview more interesting for all involved, it tells you more about the candidate than a quiz would. You learn what they do under pressure, what pisses them off, and what experience they have for the kind of work you do, because you've been using your experience against theirs in conversation. Sometimes, to make it fair, I tell them (without dropping client names) issues I've had recently, and I see if any of the solutions were raised by the team, or are ultimately the solution we went for.
I've had enough success with this approach that (when I did interviews) this was my approach:
1. A really basic take home test, probably in a language they don't use, just to see if they can write any code. Literally something that takes an hour to do. A favourite of mine was to get them to write an application in a given language to hit an endpoint, with a given code and their email address. When done correctly, an email is sent to our HR team, who then set up an interview. Based on our logs, you'd be surprised at how many candidates couldn't do this - by which I mean had clearly worked on the test, submitted something, and had failed to send a PUT request with the correct data.
2. A relaxed interview, like above, in neutral ground like a coffee shop. I use the walk from office to coffee shop to handle company questios, and the standard interview stuff,