That's certainly a valid way to do things and in some contexts it can work. I've done it too for roles that weren't coding.

It's hard to scale. People are very easily BSd in interviews without training. If you need to define a repeatable process that's fair (for a fast growing team), it's easier for people to objectively evaluate coding skills they've watched than to handle an open ended conversation. If you don't need that framework, super, that's a rare and useful skill.

At the same company where I made aforementioned interviewing mistake, when I first joined they were in the process of interviewing a guy who billed himself as a high-flying consultant type. They were impressed and intended to offer. They asked me to meet him and ask some questions too, just as a last minute double check. He turned out to not actually have some of the most impressive sounding skills on his CV, in particular, he claimed to be an expert on the internals of HotSpot but when probed couldn't answer even basic questions of the sort you'd learn by reading the user manual. Several other claimed hard skills fell apart under direct questioning too. I got the sense that he had previously been talking about work and projects done whilst he was around, but not by himself.

After that I put in place standardized coding tests. My managers continued to do the open ended interviews they'd been doing before. After six months or so we noticed that whilst the coding tests were selective i.e. we sometimes said no, the open ended interviews had never yielded a reject. They were pointless for both us and the candidate because the answer was always yes. When I sat down with the second stage interviewers, we went through some of the questions being asked and I posed a meta-question: what answers to this question would cause you to reject the candidate? They couldn't come up with any.

Well, it worked for me, but I know that I also have some fairly unique qualifications. For example, I never stopped being a practicing software engineer, throughout my management career. I usually had to do it "on the side," though, because my company did not encourage managers to be working technical people.

I never made a bad technical choice, but I did make a couple of personality mistakes; people that had the tech chops, but couldn't work in the team. That is a lot more difficult to determine than tech chops.

I think one thing that helped, was that my company paid "competitive" (i.e. "low") salaries, although we were a marquée brand. I suspect that kept the grifters away. It made my job a challenge, though.

One thing that software companies, in particular, are obsessed with, is hiring "cookie cutter" people. We seem to have an allergy to hiring competent, skilled, experienced people. We want to hire lots of people with mediocre skills, pay them ridiculous amounts of money, and force them to write top-shelf software, using structure and process.

I don't think it works well, and is attractive to grifters.

My group was a small, high-functioning team of experienced C++ engineers, writing cross-platform, image processing pipeline algorithms. Not work for the faint of heart, and each one of my employees had a specific personality, strong point, and weak point. It was my job to understand each of them, as an individual, and help them to integrate into a pretty massive team, that stretched across three continents, and included some of the best engineers and scientists in the world. We were always under a spotlight, and we had to be constantly delivering.

Companies have relied on "key players" for hundreds of years. If they keep their "key players" happy, and productive, they do well. If they don't, they fall down. These companies aren't always able to get very large, though. With scale, comes mediocrity. Sort of can't be helped.

But it also brings bags of cash, which is nice. It's just that I see small companies, all the time, trying to act like big companies, and I don't think that works very well.