Coding Horror: Is Open Source Experience Overrated?
codinghorror.com
codinghorror.com
Here we have a single programmer -- about whom we know very little -- and his personal experience. It says nothing about the state of the industry as a whole
My personal experience, by the way has been precisely opposite: my open source experience has led to more job opportunities, easier interviews, and more career freedom in general.
But again, that's just another anecdote. The only way to draw a conclusion like "open source experience is overrated" would be through a study that pits potential employees with open source expertise against those without.
One is HR driven, heavily dependent on a hiring "process" that involves lists of skills with a little score placed next to each one for each candidate. These sorts of companies often use recruiters. An example would be a large bank that wants to start using SOAP for web services in Java, so they create a bingo buzzcard with (SOAP, JAX-WS, J2EE, and so forth...), call up the recruiter, and start matching candidates with requirements.
The other is very immediate and programmer driven. In this world, I have a feeling that open source contributions carry a lot of weight - not just because it's impressive, but because it increases the chance that the people hiring you have heard of you, used and read your code, and perhaps even worked with you personally. A prime example is 37Signals - which mentioned in a blog post that they probably wouldn't hire anyone they haven't worked with on open source in some regard.
The thing to keep in mind is that it takes just as much skill to hire in this context as it does to get hired. Very few organizations are talented enough to be contributing substantially to relevant OS projects. Of course, those are probably the ones you want to work for!
This is my experience too and that in a screwed up job market like India/Bangalore where most companies are essentially bodyshoppers who couldn't care less.
Open source has helped me (a) get interesting job/consulting offers (b) cut out large chunks of useless interviews from the recruiting process(One interviewer started the interview with "Your open source work is impressive enough to the point where a technical interview is not required and to be honest you are much better technically than I am, but hey we have to go through the motions of an interview so tell me what you want to know about the company and what we do ") (c) connect me to very talented people in the fields I am interested in (d) generally open all kinds of doors I didn't know existed.
I've also been on the other side of the process where someone started his cv with "I wrote [impressive piece of code we used every day] that is shipped with the Python distribution". I checked out the repository, just to make sure - his code was very high quality -and added my comment to the electronic copy of his cv "hire this guy NOW. Pay him whatever he wants. Don't let him get away." And since I was known to be a "tough interviewer" who rejected large numbers of people, HR was happy to oblige. The rest of the recruitment process was just a formality.
All this is so contra the experience narrated in the blog that I found it very surprising till I happened across this line
"One of the reasons I worked so hard on open source projects was to make job interviews easier."
This doesn't make any sense to me. I can't imagine writing open source code in order to make interviews easier. That is (sometimes) a side effect certainly, but I've chosen projects based on what interested me and "scratched my itch". I frankly could give a damn if no one else used it or found it interesting as long as it tests out a theory/ saves me time or money/ teaches me something.
Open Sourcing the code is something I do besides whatever value the code provides to me, as a behavioral norm in support of a community that has given me so much quality code. (I have an Ubuntu workstation , use django, gcc ... ).
Anybody can write a program from scratch to do X. It takes programming skill, to be sure, but it's much easier to start with a clean slate. Adding functionality to an existing codebase is much, much harder, and requires exactly the sort of skills required to be a truly excellent programmer. Not only do you need to understand the complexities of the existing system, but you need to work with other people, and write code that doesn't stomp all over other parts of the system.
From the hiring standpoint, this is HUGE. I want to hire and work with people who are genuinely interested and passionate about what they do. While I can respect people for whom development is a job, and nothing more, I'd much prefer to work with people, who like myself, finish up their day job, and then start working on side projects, open source projects, teaching themselves some new technology that just came up, playing with a different language or framework to see what they can learn, etc...
(The above opinion was formed by watching out of work scientific programmers trying to break into the Java world, and discussions with Enterprise Java manager types.)
Well, that shouldn't be the primary reason to work on open source projects.
I don't know his background; however, most people I know have exactly opposite experiences with regard to open source. But I wouldn't hire anyone either who would try to impress me like that.
They pushed their (admittedly good) OS projects at us heavily as examples of their greatness. But it was quickly apparent their interest was held only as long as it was useful to their job prospects (aka no passion) and that these projects were covering a lack of technical ability for the job in hand.
We used OS projects as a benchmark to see how well someone deals with bugs, user feedback, community and support issues. The code is fairly immaterial (ot a point) because you have no way of knowing how many man hours went into making it as good as it is....
The best programmer in the world is useless if it takes him a year to complete simple commerical projects ;)
Certainly if it was a close call something like that would help a decision.
He said they gave him a test: that implies they have a set way of evaluating the code he produced and they want him to meet their criteria. They're not going to value unknown OSS over a test they created themselves.
We only give "coding" tests to people with no professional experience. Even there we don't care much about the code. We care about the process you use to arrive at the answer: the code is written while the interviewer watches and asks/answers questions. You can make all kinds of mistakes and I'll still give you thumbs up if you know what you were doing but were just nervous.
I hired someone with impressive OSS experience, but never looked at their code. I care less about code than I do about design, knowledge of how to architect something, deal with bugs, etc. I can learn all that stuff and more in 30 minutes of interviewing; it would take a lot longer than that reading your code to get the same information.
I've yet to meet a good designer/architect who couldn't code well, but met lots of good coders who couldn't design their way out of a paper bag.
Because nothing tests a programmer like writing a 5 line string reversal or fibonacci program
Whether the company chooses to avail themselves to this information is a different matter, as are any moral judgments they may make based on their stance on and knowledge of open-source in general.
From the programmer's perspective, particularly a novice one's, just <em>having</em> experience to be able to point to is good. The additional benefit is the networking that necessarily takes place as part of any open-source project, and might not otherwise happen. Knowing people is very, very useful (and, well, nice.)
Perhaps there exists, though, a group of people whose primary motivation is to <em>be known</em>, rather than to know others. That is where I would expect to see diluted value.
By way of anecdote, I will say that I am currently enjoying my (open-source) work at one of the biggest tech companies, hired specifically because of the open-source work I am engaged in.
Of the six programs I list on my CV, five are free software. For two of those I was paid full time to program, and the other developers were all likewise paid. One was a personal hobby/learning project I released the source for because there was no reason not to, but never build a community around. The last two were community oriented, in the first I was the project manager, integrating contributions from all over the world, but writing less than half the code myself. In the other I contributed a large and potentially disrupting change to a high profile project that required active adaption from the other developers to be successful. Here the social engineering was as important than the code itself.
They represent four very different types of experience, and grouping them as having "Open Source Experience" would be unhelpful. The only common element is that it is easy for a would be employer to see the code, but that might even be possible for non-free code if I owned it myself, or had permission.
On several interviews when asked for code they point me to an open source project they are currently working on. I do the natural thing and download the code and start reviewing it. Every time I find countless things, from simple stuff like style inconstancy to actual bugs and design problems. If they know that the code will get reviewed by someone for a job, why don't they take the time to review their own code and fix even the most basic problem?
As to the OP - if a company doesn't value your O/S contributions, and if those contributions are indeed valuable according to your O/S peers, just don't work for that company. Do you want to have a career with people who can't reliably judge good code?
I can understand why. It take a HUGE amount of effort to digest a big codebase; why do it when the most fun in programming is to be had when you're designing/implementing a new system?
But your o-s contribs can get you an _interview_ and indirectly help you in the interview.
Hopefully all practice you've been getting through your side projects would have made you a better developer and that will be apparent in the interviews.
From this point of view, I would say major work building one's own app makes one a better developer than minor work on a major project.
Your skills development is what matters in the end, not the "name recognition" of having contributed to such-and-such project.