You are correct, you do get the "can this person actually write _any_ code" info. More than that I think you get the "is this person good at writing trivial code".
I'm not sure the groups of people that "write good production quality code" and "write trivial interview code" intersect all that well.
Worse it would push for people that _excel_ at writing trivial interview code, which in my experience is inversely proportional to how much they are going to contribute to the success of the company. Though this is admittedly anecdotal.
Worse still you're going to be sending a signal to the interviewee that you are a kind of company that values trivial code. It's an interview both ways, the company gets evaluated too. The better the dev, the more offers they have so they might just not pick you based on stuff like this. They'll just get a _gut feeling_ that it's not a place they're going to like - that kind of thing.
As an interviewer, I personally don't think it's worth that bit of information, both in a game theory best outcome sense and just as a basic human decency.
Let's say you are an awesome C/C++ systems engineer.
Interviewer can pose a programming problem expecting an answer using recursion. But as you are C/C++ systems programmer, you know recursion is inefficient and you have never used it in production code.
So, it will not naturally occur to you to use recursion. You will go down the path of coming with a clever iterative solution with complex hand-crafted data structures etc. If the interviewer isn't well-versed in these low-level techniques then they may end up judging incorrectly. And usually such a low-level solution won't be easy to complete in a short 20-minute interview setting. whereas a recursive solve would be doable. which would lead to the interviewer feeling justified in judging negatively. That's how you can be good at production code and bad at trivial code :)
Well writing trivial code is still a skill, you could have been coding for 10 years and in your day to day work have managed to remove little annoyances and quirks, allowing you to express business logic concisely. I mean we usually don’t go about implementing linked lists and bubble sorts and such.
And this skill gets pushed down, forgotten.
It’s perfectly possible to write excellent battle tested and performant production code for years without encountering any of the stuff you see in the interviews.
And then they go to an interview and someone demands they wiggle out that piece of info from their long _long_ memory, in an unfamiliar env / os / periphery. With a huge time pressure...
Some people are good at that sort of thing, some people are good developers. Doesn’t mean they’re the same people.
Worse it would push for people that _excel_ at writing trivial interview code, which in my experience is inversely proportional to how much they are going to contribute to the success of the company. Though this is admittedly anecdotal.
Worse still you're going to be sending a signal to the interviewee that you are a kind of company that values trivial code. It's an interview both ways, the company gets evaluated too. The better the dev, the more offers they have so they might just not pick you based on stuff like this. They'll just get a _gut feeling_ that it's not a place they're going to like - that kind of thing.
As an interviewer, I personally don't think it's worth that bit of information, both in a game theory best outcome sense and just as a basic human decency.