Unless the job is responding to problems and being watched while you work, the argument here is that you're not actually assessing anything that's very useful.
Most engineers/developers, for example, spend a lot of time thinking about a problem or trying out their ideas (many of which quickly get thrown out). If you do this in most programming interviews, you're going to fail them.
What is relevant in my day to day is dumb shit like "What do you name things?" "How do you control access to classes internals?" "How do you construct an API?" "How do you communicate your designs to people living outside your head?"
Virtually none of which you can get done on a whiteboard with a problem set that you can define in five minutes or so.
Plus, too often it devolves into a game of algorithm trivia with the interviewer. Gotta prove how smart* you are.
"So what have you been working on?" "Oh I was the lead engineer on our new backend system. Built it on top of X, built a custom foobar because we needed to scale Y functionality blah blah blah" "Oh cool, cool. We actually are looking at building something similar. Well anyway enough of this obviously useless information exchange, here's a question about graph searches".
*smart may be substituted for grinding out leetcode questions for weeks beforehand, at the interviewees discretion.
Depends on what you're looking for.