I see your point, and I partly disagree. First because, they are doing it for fun, to solve things they want to make it work. That doesn't say they are learning something, or following clean code guidelines.
But let's assume they DO. They are better at coding. But are you sure coding is the only skill you want? I've seen my fair share of developers that lack "real world" experience, to the point they cannot see that what they are doing is not what a user wants, or how they want to do it.
In some cases, open source projects are made for developers, and managed/prioritized by developers, not someone with experience in project management, or with a roadmap with the users in mind. So, they might be lacking a lot of other important skills, and I would dare say that some also lack empathy towards non-programmers - the paying customers.
I'M NOT GENERALIZING GUYS!
I'm just point out things that I saw in some instances, with some people.
If we are going the "all else being equal" route, one could argue the hobbyist is a worse candidate because they have spent more time working and thinking about programming but still haven't been able to demonstrate their skills are superior to someone who has spent much less time refining them. Give me the person who is able to get the same thing accomplished with less effort and time.
This seems to be a pretty sensitive claim, but it also seems completely reasonable to me that people who practice something more are better at it than people who practice something less. Even if it's a completely different domain than your work, it's still developing your intuition and exposing you to new abstract concepts.
As someone who runs interviews occasionally, when you're sitting in an interview room, you're not making an immediate decision whether the candidate is better or worse - that comes after the interview. During the interview itself, your job is to learn as much as you can about the candidate. The biggest problem for both you and the candidate is that you might get to the end of the interview and still not be sure whether they're a good candidate, and therefore have to reject them.
You've got two probabilities to work out, "how likely is this person to succeed in the role we're hiring them to do?" and "how confident am I in the previous number?" Side projects usually don't change whether you think the candidate is a good fit (at least for me), but they usually do increase your confidence in your prediction, and turn some no-hires into hires.
Could go either way, right? I've seen folks who have side projects spend most of their work day working on their side projects. They might be "better programmers" (also debatable), but if they don't get their work done - does it matter? I've seen folks who do really solid work for 8 hours and then go home and do other things, some of those folks have said that the separation is helpful so they can really be at their "programming best" at work.
(I say this as someone who generally have multiple programming side projects going on at any given time and also freelances...)
If "Time technically participating in an activity" directed overall skill that clearly, yes. Unfortunately there are plenty of 10 years exp devs with thousands of hours in their chair that also just aren't very good.
No, because that doesn't say anything about the quality of his code. He could be sitting around writing complete chicken scratch if he doesn't have a team with good leadership and code review guidelines.
I write hobby code sometimes but I don't write unit tests for it and I almost never go back to refactor it. Once I achieve my initial goal, I tend to be bored with it and set it aside.
It baffles me how much this is an assumption. Like all the developers should not have any hobby that doesn't involve coding.