> What I would say is that there is a difference between hobby code where you get to do what you want and code where you didn't control requirements and had to deliver to unreasonable people in unreasonable timeframes (aka commercial software development). Obviously it would depend on the projects but generally someone who has commercial experience would probably be viewed more favourably as it's more directly comparable to what I need you to do.
1) If I can write a backend integration for some well known property (say, Amazon) as a hobby in Language X.
2) If I can show I can write backend integrations for some well known standard (say, EDI) in Language Y at my Day Job.
The idea I could write a backend integration for some API in Language X at a new job in situations where I don't control the requirements, etc. is quite reasonable.
"Commercial experience" is really managing expectations and timelines to make it clear what you can/cannot do. It doesn't magically make the choice of X vs. Y a significant difference if you are experienced enough in both to produce functional projects. Tbh, I'd be more worried about domain knowledge (How well does the programmer understand accounting?) than I would be about whether the programming language is X or Y is the one they use at their day job.
The quality of code isn't going to massively change because a different language is used. You aren't going to know the quality of code from their Day Job anyway, for all you know its unsustainable crap and they are trying to bail before their boss realizes it. At least with a hobby project you can check the basic boxes like "Does this person like OOP vs. functional programming?".
The most that would change is how often the Dev would need to refer to the documentation and honestly, for anything that matters, that is going to happen alot anyway since no one wants to write something moving 5-6 figures a day worth of product without double checking everything first.
If you aren't building something that handles that kind of value, the bar makes even less sense since you aren't worried about them screwing up language specific edge cases that might cost you more than their paycheck if it goes unnoticed for an hour.
If anything, it seems to me this is testing for the absolute opposite of what you'd want to test for. Sure, it'll work if the other measures are good...but communication ability + domain knowledge + ability to write code in Language X is what is required. Caring about whether or not Language X is or is not a hobby language...isn't testing for anything relevant to the job if they've had programming jobs before.