Talk to them.

Have a conversation about "how would you solve this (real) problem" - the same kind of conversation you have with a peer when they're stuck on a problem. If both you and they are professional developers, you will be able to get into a nice in-depth discussion of the pros and cons, and go into nice tangental discussions along the way.

If they aren't a professional developer, it will show in no time at all; the longest I've let such a conversation go was 10 minutes just to see how long the interviewee would keep trying and snowball me.

I've found this is simply much faster and more informative about their experience with subjects that matter in the daily work of a software dev.

Small project, on your own time, expected to take about 3 hours or so. Automated tests can do the very basics of evaluation. Then, 1 to 2 hours explaining the decisions made, and adding one more feature to the project. It lowers stress levels of the candidate, as they get to a lot of the thinking in advance. It's practical, as it requires more detailed programming skills. It provides a better sample of the candidate, as 5 20 lines of code snippets don't compare with a larger codebase, and makes the candidate explain something they really did themselves. Total time spent by the candidate is probably about the same, but the employers saves engineering time.

I've been through that system a couple of times, it was both more enjoyable and gave people a far better picture of my skills than just how well I remember a tree traversal algorithm that I haven't had to write in forever, as data structures often handle their own traversal.

need context to determine what would be better. giving the same interview for every position you're hiring for is not usually the right thing to do. Google is very unusual in their practice of hiring into a general pool. Most companies hire for more specific openings.

In general though, when I interview it has three main sections, tailored for the role.

First, is conversational. Talk about the resume, talk about work experience, talk about technology, etc.

Second, is a practical example. Sometimes (but not always) this involves solving an algorithmic problem on a whiteboard. Sometimes it involves a guided tour of the codebase and functionality of a relevant project the candidate has worked on. Rarely it might be a take-home coding task.

Third, is a more general example usually of some kind of system design problem. A lot of candidates like to write/draw on the whiteboard for this section but it's not strictly necessary nor do I ask them to do so. There's a board in the room if they want to but I don't ask them to use it.