I think programmers need to realize that getting hired for a job has little to do with your ability to write excellent code. Right or wrong, the hiring process at most companies involves a series of ‘tests’ you have to pass.
I was involved in the hiring process at the last company I worked for, so I got to see it from both sides. Here’s how it worked…
1.) The Resume Test
You send in a resume. They review it. If it’s not good, for whatever reason, that’s it. End of line.
2.) The Phone Interview
If your resume looked good, didn’t have to many glaringly obvious mistakes, and we thought you had a chance of being a decent developer - you got a phone call from HR. So, a non-technical lady would call you up and give you a phone interview. She’s non-technical and the questions were all non-technical. They just wanted to see if you could have a normal conversation without sounding like a retard. Bonus points if you had a decent story involving software.
3.) The Office Visit
Okay - so, you have a decent resume and can handle a 20-30 minute chat with a girl on the phone. So you get an office visit. Up until this point, nobody has even tried to assess your technical skills - and I’d say ~10% of candidates make it this far.
The office visit is, again, mostly about appearance. They want to make sure a customer isn’t going to be bothered by how you look, smell, talk, etc. This is also when they first start to sell you on the company. You get to see the game room, and the library, and the cubes and hear how great the place is. You’d also go out to lunch with other developers. Again, their opinions of you would be recorded later - but really, a decent liar shouldn’t have any trouble talking their way through an unofficial/non-technical lunch.
4.) The Final Interview
If you were liked, didn’t do anything stupid, then - you get invited back for the ‘Final Interview’. The final interview was scary - you’d find yourself alone, in a room, with one of the seven partner’s that owned the company. These guys were the best-of-the-best in terms of programming skills. They’d sit you down and ask you to explain ‘something’ of a technical nature. They’d ask as many questions as it took - mostly large open-ended questions, until they felt as though they knew if you were good enough to hire. If you weren’t - they’d thank you for your time and say they’d be in touch. If you were…
5.) The Final, Final Step.
At this point, the partner wants you to come on board - but…he wants to make sure you want to come on board. He’ll go through the Pro’s and Con’s of the company. Why consulting is different from contract work is different from a corporate gig. Do you really want to work at this type of place…or are you just looking for a pay check.
My point is - 95% of people who applied for a position at the company ended up never making it to step #4 - where their technical skills really mattered. Up until that point - 95% of applicants got rejected because they lacked people skills, were d-bags, or just didn’t impress. Some of the people who got rejected were probably very, very good programmers - but the position required MORE than being a good programmer.
Some people really want to live in a bubble - they want to receive an e-mail with clearly defined requirements and hammer out code all day long. That’s it. And those jobs exist - but not all positions for software developers are those types of jobs.
An open source project, typically means, you work from home, producing code at your own pace, to add to a project that, ultimately, has no good measure of success. I can make an open source project that sucks, does nothing, and throw it up on my resume. I think it’s little surprise that it doesn’t carry much weight. If it makes your technical skills better, that should be reflective in the results of the coding test they give you, or your answers to technical questions. Unless it’s an open source project people have heard of (and HR has heard of maybe one) - it just doesn’t carry much weight.
