Use a realistic work sample test. It's marginally more time consuming than a whiteboard interview, but it's fairer and more effective. Most candidates would vastly prefer to commit and document a small patch than solve brainteasers in front of an audience. You'll learn a lot more about their practical skills.

Oh 100%.

I give 60 minute programming exercise in a language of choice as the first part of the interview.

I do that part first because it separates the doers from talkers quickly. Measurable and objective.

Certainly measurable, but what are you really measuring? If I gave one of my junior devs a serious problem to research, consider and solve and they came back to me 60 minutes later, I wiuld tell them to go jump in a lake...and I'm certainly not looking over their shoulder while they do it. I always say I do my best development in the shower when thinking about a problem fir a while. Unless you plan on jumping in there with me, you'll miss a lot of where my actual problem-solving happens. Short syntax questions to screen and longer-form 2-dayish take home problems for the win... with practically every other approach you're measuring things that just aren't really germane to how good software is developed.

When you have a large volume of applicants and new hires (like Google does) then you can actually start to measure the correlation of the things you can assess in the interview vs long term job performance. Then you can make your decisions about who to hire based on this evidence rather than gut feel, subjectivity, biases or even CS trivia. It's much harder for a small company to do that, so at best they can end up copying the methods of the large ones and hope that their situation is similar enough.

Yeah, I got to see that first hand at my last company. Very difficult to judge someones capabilities without some technical test or something.