Coding Horror: Is Open Source Experience Overrated?(codinghorror.com)
codinghorror.com
Coding Horror: Is Open Source Experience Overrated?
http://www.codinghorror.com/blog/archives/001255.html
33 comments
I know this is off topic, but just wanted to thank you for your wonderful efforts on Django etc.
Absolutely. It also matters where you apply-- obviously everyone here would want to work in an environment where they value open source, and we actively seek those workplaces out.
I have a friend who two years ago got a summer internship at Microsoft because his work in Open Source had made a reputation that preceded him. Mind, MS is hardly the most OSS-friendly company out there, but they at least recognize that work on it is well worth paying attention to.
I get the feeling that there are two alternate universes of hiring.
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!
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!
"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."
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 ... ).
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 ... ).
The original poster also said one word that rang some big alarm bells in my head: architect. So, he's written a small pile of OSS from the ground up, which while certainly not worthless, isn't anywhere near as impressive as somebody who fixes bugs and contributes valuable patches to existing projects.
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.
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.
To be fair, he does say one of the reasons.
Open source experience shows one important thing above all else: You actually LIKE doing development!
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...
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...
You can do everything you said without contributing to an open source project.
Sure, but then how do you prove you did any work on the project? A lot of companies won't let their source code out of their site so you can't brag about some clever hack you wrote. With an open source or free software project, you can just say "look up revision 12903810938 and the file is awesome.c" and voila, your example of clever hackery is there.
Java Enterprise Software Land has always been a weird alternate reality where they only care about specific Experience, Experience, Experience. They don't care that you're super smart with a wide and deep software background -- all they want to know is whether you've used J2EE Frobenator version 1.35 before or not. Solution: get the hell out of Enterprise Java Land.
(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.)
(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.)
As a Java Enterprise architect/developer/hire-ee/hire-er I have to disagree. I've worked at a large number of places, and as long as you have relevant experience, and are smart, that's usually what people want. I don't care if you've used the exact thing we do, as long as you've worked something similar and understand the basic concepts involved.
"One of the reasons I worked so hard on open source projects was to make job interviews easier."
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.
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.
I have interviewed people recently with the same view.
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 ;)
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 ;)
Commit logs can give you at least some idea of this stuff, surely, and they tend to be available for a lot of open source projects.
to a point but I'd want to spend a few hours looking through the major revisions of the work and for multiple candidates that is painful :)
Certainly if it was a close call something like that would help a decision.
Certainly if it was a close call something like that would help a decision.
It's not that it's overrated, but rather that it doesn't fit into the company's interviewing process.
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.
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.
>They're not going to value unknown OSS over a test they created themselves.
Because nothing tests a programmer like writing a 5 line string reversal or fibonacci program
Because nothing tests a programmer like writing a 5 line string reversal or fibonacci program
The point isn't which one is better. The point is that for most companies, it has to be done their way or not at all.
The only absolute benefit of open source experience from the hiring perspective, as I see it, is that there is (presumably) an existing verifiable repository of code samples, as well as possibly examples of "soft" and/or managerial skills from things as mundane as mailing list posts.
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.
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.
I think a problem in these discussions is the tendency to ignore how different "open source" projects and related experience is.
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.
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 this topic how many of you have seen the following:
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?
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?
If they're a contributor rather than the BDFL of an open source project, it might not be possible for them to fix style inconsistencies, or do much about design problems. It's not always clear exactly who wrote what without going through the versioning logs. Of course, that also means that an open source project might not be the best thing to give to an interviewer as example code, unless you wrote a significant percentage of it personally.
Oh I am with icefox. Proof: when asking for code submitted from people without public open source credentials, people will actually send in uncommented code!! I mean there are two issues here - knowing the right thing to do and being too sloppy to do it, and not even realising what the right thing to do is. shake head
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?
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?
When I ask for code they usually send a project they wrote entirely, a file, or a class. I try to stay within the code they told me they had control over.
[deleted]
Yes. The best developers I know do not contribute to open source projects, and have no interest in doing so.
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?
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?
I have often wondered about this. From an employer's perspective what would be more impressive, minor work done on a large open source project or major work done building one's own app from start to finish? By "minor" I'm assuming here that starting in any large well known open source project means you have to work your way up to get into the small core set of developers that really have a say in the project and as such most of your contribution will be minor at least initially.
Usually companies try to evaluate a candidate independently; unless your side project is exactly what the company wants, I'd be surprised if your open source projects are the deciding factor in your getting the job.
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.
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.
[deleted]
Depends on who is doing the hiring. Working on opensource or writing your own compiler is on the high value end of a programmer, but "real" experience may be valued higher for a manager. Usually it is the manager doing the hiring.
As I also posted there: Open source can help land a job, but it certainly can't be your only experience, only relevant experience, or only recent experience, if you're looking for anything other than entry- or junior-level. Personally, if people write worthwhile whitepapers, do UG presentations for their development communities, or found/contribute to viable open source projects, yes, they get bonus points with me when I interview them. However, I'm still going to grill them, and I still want to see and hear answers that are relevant to MY company and the role we're looking to hire the candidate for.
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.