Speaking as a developer, why do you feel it's reasonable to disregard side projects? If, say, I claim LLVM knowledge based on a publicly available language developed on my spare time, why shouldn't be taken into account in the recruiting process?
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.
All that said, I deal in corporate style CRUD apps (there is a bit more to it that that but that's the core). That's an area where OSS - the best sort of out of work project as it's team based, real world and so on - isn't that active so it's not a consideration I have to make too often.
As for the rest, I think it's reasonable to assume that a candidate with commercial experience will favor over hobby experience. I'm sure there are plenty of examples of where that doesn't hold true, but I suppose it's a decent rule.
Recruiters don't have the experience to know, so it is your job to help them out with your CV. They are looking at many applicants and can't research them in depth and get through the stack at the same time.
I believe this is essentially true for hiring managers as well, although they will probably be able to tell fluff from something interesting, they won't have the time to do it. And it will reflect poorly on you if you aren't willing to work your CV for relevance to the job.
When you get through those gates to a peer interview, you can talk up your side projects all you want, and these are the people who might look at it and incorporate it in their decision making.
But you've mentioned part of the problem, "Recruiters don't have the experience to know", therefore there is an issue with some recruiters being the gatekeepers. Especially when they state things that imply if you didn't explain things in the magic way that they want to read it then they'll pass on your resume. That's my issue. It's one thing to say "please phrase your experience in simple terms for a non-technical person might be able to understand and can easily use as a basis for research" as opposed to "write it the way I like it or I may disregard". It's not as bad as the guy who throws out resumes stating he doesn't hire unlucky people, but it is a problem.
After all, if someone writes that they have AngularJS experience and the recruiter can't be bothered to think "I don't know what that is, maybe I should look on Google" then there's a problem. I'm not saying that the recruiter in this thread is that person, but does seem to have something close to that mindset.
Which, I feel the need to point out, I've personally never had a bad experience with a recruiter nor hiring manager. I'm not sure if that means that this problem that crops up quite frequently in the community is not that big a deal as it seems or I'm just lucky. I've also been on the hiring side of the table. It's just my personal experience and it may or may not mean anything to the discussion.
You are the one seeking something here, lost in a pile of other seekers. Why wouldn't you do everything you could to make it easy for the person looking at your CV to pass it on to the next stage of vetting.
Why would someone bother googling some obscure reference on your resume when they have dozens or hundreds of others that fit the bill? The key is learning what it takes, in general, to get to the next stage. While there are always horror stories about oddball reasons for not getting selected, they aren't the norm.
Understand the job you are going for, understand the expertise and expectations at the different stages, and you'll do fine. It is basically a numbers game at that point.
I don't disagree with you that using proper keywords is common sense. I'm not complaining about that in any way. But, as it has been pointed out in many places, stuffing your resume with keywords is a bad idea. So, I simply cannot list off every single little thing I know, I have to cull it down somehow. If I didn't find the magic pattern required for the gatekeeper when choosing my keywords then my resume gets passed over. For example, if a developer specializes in AngularJS, among many other things, then they are likely to list that and leaving off Javascript. It's only common sense because AngularJS IS Javascript. Remember, too many keywords is bad. What if that developer happens to specialize in multiple Javascript frameworks? Remember, too many keywords is bad. If the gatekeeper doesn't understand that AngularJS is Javascript, but fails to see the Javascript keyword then they may disregard. That's a simple example but could easily be understood to be possible.
Another example, how many times has a recruiter mistaken Java and Javascript as the same thing? To me, that's a problem that potentially keeps good candidates from being matched to jobs they are good matches for. Good candidates that the hiring manager never even knows about.
Realistically I can't interview everyone and it wouldn't be in anyone's interest to do so. The current stats I have say I will first interview one in four screened CVs. Out of those about one in three will get a second interview and half of those an offer. So I interview maybe half a dozen people per appointment from about 25 CVs).
That means right now if you give up an hour of your time for a first interview (plus travel and so on), you've got a one in six chance of getting a job. If I interviewed more people, your chances go down. I may end up with a better recruit but I'm actually externalising a lot of the costs to the other candidates who don't get the role.
As for interviewing people after the first selection round based off of resumes; that's a totally different situation and I can't say I disagree with your viewpoint.
Ultimately this is why I don't take any of my side projects seriously anymore, and if there's something I want to learn, I'll find a way to get paid for it. That way I can figure out where it fits in the ecosystem of working with other professionals to deliver production code that fits specs and actual business needs. I still have side projects, I just use them to scratch an itch rather than to try to conjure something truly useful to someone out of thin air.
When I wanted to learn how to do TDD, I first sold it to my boss, and when he saw how powerful an idea it is, said to go all in with it. I got him to buy a book and the Destroy All Software screencasts.
Basically, whatever the business you work for needs, find a way to deliver it in a way that scratches your learning itch.
Side projects for me have been relegated to just exploring new domains, with technologies I already know well. When I'm having fun on the weekend, I don't want to get hung up on high-friction, high-buy-in paradigm shifting. I just want to have fun and focus on gathering insight.
Any attempt to deviate from that is not permitted because it leads to compatibility issues with the rest of the codebase & it reduces the ability of other programmers to work efficiently on it.
I suspect many programmers operate under similar restrictions.
I've worked three jobs in the last year where I had a lot of flexibility in this regard. And I enjoyed it when I was freelancing too. The world's a lot bigger than the little bit of it you're seeing now. Get out there and see some of it.
> I've worked three jobs in the last year where I had a lot of flexibility in this regard. And I enjoyed it when I was freelancing too. The world's a lot bigger than the little bit of it you're seeing now. Get out there and see some of it.
Ah, the patronizing tone of someone without a clue. Some of us enjoy working on large, important things that need standards. I'm responsible for millions of dollars of revenue and financial transactions. That means I'm going to be conservative 'cause, y'know, money.
Many, many people work in situations like that.
The majority of programmers aren't web developers with one-off projects they mostly do by themselves.
I'm telling you the way you value/put things is specific to you and a smaller percentage of the programmer population than you imply. It works for web developers working on small projects. It doesn't work in larger team environments where having 90% of the developers needing to learn X to maintain the project is a noticeable impact.
> Ultimately this is why I don't take any of my side projects seriously anymore, and if there's something I want to learn, I'll find a way to get paid for it.
Side projects should be taken seriously because people aren't going to rearrange their careers to scratch itches like "I want to see if I like Django better than RoR".
If that falls under the category of "career goal" for you, we honestly should stop talking to each other because we operate on two very different levels. We are never going to agree.
The problem becomes when you [like the OP] try to apply your limited world view as a universal truth.
One of my side projects that I run for fun and setup in a couple weekends generates thousands of dollars a year which I then reinvest into my side projects to amuse myself. It is a hobby that pays for all of my computer-related hobbies. So when people like you and the OP dismiss them, I'm amused because I realize I can't take either of you seriously. You don't consider the possibility that you are wrong when told you are mistaken but instead resort to claiming I don't know what I'm talking about.
I know another developer whose side project generates non-negligible revenues and consulting gigs.
So when you said can't take your side projects seriously to reinforce the OP's point, you reinforce this idea that side projects should not be taken seriously.
I guess you're right, we're never going to agree. The choice of platform to specialize in is in my opinion a very very important career decision you have to make, because the switching costs are greater than we're going to see. Platform familiarity has bought me 90% of the flexibility I have at my job. I got to be that familiar because I happen to really like Rails. I got to learn Rails because I got someone to pay me to learn it.
At one point, a career goal of mine was to "get paid full time to work with Rails." Now that I've achieved that goal, I have bigger and better ones. I don't know what level you are operating at, but my new goals involve putting together a cohesive team that can knock out projects really fast, followed by starting a company with the experience gained from accomplishing the former.
> One of my side projects that I run for fun and setup in a couple weekends generates thousands of dollars a year...
Thousands a year? I just don't get spending that kind of time for that little of a return. I'd rather roll that effort into being a better coder and the best way I've seen to do that is to work on projects bigger than yourself, that bring lots of people with different talents in to build something that much more interesting and viable. If I just wanted a few thousand more, I'd ask for a raise. Just because it's non-negligible doesn't mean it's worth my time.
I'm just asking because that is the only way your comment makes sense. If not, I suggest you re-read.
> At one point, a career goal of mine was to "get paid full time to work with Rails." Now that I've achieved that goal, I have bigger and better ones. I don't know what level you are operating at, but my new goals involve putting together a cohesive team that can knock out projects really fast, followed by starting a company with the experience gained from accomplishing the former.
I wish you the best of luck with your goals, for whatever that is worth. I don't mean any of this personally...I just think the view you and the OP take is far too narrow.
The reason I said "different level" is our goals are so completely different as to be incomparable from an objective viewpoint.
Yeah, the difference is that hobby code means that you can take the time to do it right and "commercial contexts" (aka coding in a rush) means that you can't so you never learn how to do it properly.
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.