I've never contributed to any open source projects myself, but I still find this anecdote troubling.

I've always expected, as this anonymous emailer had, that open source work would be almost the very best way to create an impressive portfolio. As he wrote: a prospective employer "could inspect it if she wanted to assess my technical competence". It's an enormous real-world code sample available for review!

I agree with Jeff: "I'm not sure I'd want to work at a place where a programmers' prior body of work is treated as inconsequential."

When I'm hiring, I'm attracted to open source projects for one reason above all others: it shows a degree of passion. It shows that you're really not just a "clock out and forget about computing until you come in the next day" kind of guy.

It's certainly true that not all places will care about that - and in particular, HR staff and general recruiters may not be particularly interested - but if you can get as far as other developers, and if *they're* passionate about development, it can help a lot.

"if you aren't convincing at least a small audience of programmers that your project is worthwhile enough to join -- Then what are you really doing?"

You're solving your own problems, and making that solution available for free in case anybody else wants it. What's wrong with that?

I think the problem is with the recruiters: Often those have no or only a little technical knowledge/experience in the field they are recruiting for (instead they know about recruiting, of course). So they don't even think of checking out the sources of open source software. What matters mostly to them is what's on the CV.

The mentioned coding tests are often checked by "tech guys" who have no idea about the person who took them. They just see the few lines of code, but no CV or any other background information - those "tech guys" would probably take a peek at the open source software, but are never informed about them.

So the open source experience seems not to matter.

Assuming a large open source project is contributed to by many people, how could a person go and check to see what _you_ contributed anyway? Spelunk through the source control app looking at difs? That doesn't seem remotely likely in 95% of the cases.

In the end, _claiming_ to contribute to open source shows that you _claim_ to have passion -- which is a plus.

However, showing that you wrote some small utility app on the side, and bringing the app with you to the interview seems to work well. And the fact that it's closed source, and you have the source there with you, would indicate that you did _all_ of the work, making it very easy for the interviewer to quickly see what your work looks like. It's always worked for me.

Sounds more like a presentation problem to me - Getting past the recruiters is more or less unrelated to any technical ability. Describe that time as working for a company that just happens to release stuff as open source (no need to show the code, recruiters don't understand that) and you should make it past the filters to someone with enough technical knowledge to understand that open source experience is a good thing.

I'm sure that if you made a significant contribution to an open source project that the whole world uses, say Tomcat, then the recruiter would be mightily impressed.
From the recruiter's perspective, it seems more important that you're able to produce code that *sells* than code that *works*. And the two are simply not always the same.

I work for a company that values open source contribution highly when looking for job applicants. Like a previous commenter said, it shows a passion for writing software, self-motivation and gives us a pretty easy way to check if someone works well with others.

That said, having a body of open source work doesn't mean you don't need to take the coding test (or worse, don't need to take the coding test seriously). I'd much rather see an applicant write code myself than have someone else tell me about code they've written.

In anon's first example I am not sure why he is surprised. If he wrote an inefficient solution why did he point them at his open source projects? The coding test was probably more relevant for them and what they wanted.

If said OS projects were relevant to the technical aspects of the job then he does have a fair point. Even then, though, you have to consider that he might have spent hundreds of man hours creating that efficient code - and the code test helped prove to the company he was not able to program efficiently at their speed.

I think the reason he had problems elsewhere is because:
- He expected being maintainer of OS projects would give him automatic credence to every company, which is, of course, never the case
- He did the projects for gain & not love. And potentially that comes across in his approach to them - putting off the companies

He seems surprised that such companies wanted commercial experience: apart from rockstart startups just about every company wants commercial experience and you have to *convince* them to take you if you dont already have it. Maintaining an OS project is singularly different to work committed projects.

Telling a recruiter "What my experience of working in industry long ago did teach me was how to fill out a time sheet and estimate time for deliverables. But this experience would seem a bit dated now for recruiters." Just seems a silly silly idea. :P it's going to instantly put them off because your telling them that the validation they are looking for is worthless.....

And, of course, he is ignoring the fact he might have put off interviewers in other ways & that the "commercial experience" line was simply an excuse.

TBH I wouldnt employ him based on his story here. :)

AKA OS projects are a great addition to any job application but are not the be all and end all :D

Hi Jeff, its me again.

Perhaps that guy just really was not that great of a coder? I can write a bunch of crap, open source it, call myself "chief architect of project X" and it still doesnt improve the quality of the code. Also, I think it depends on the companies you apply to. Bragging to a .NET shop about all these open source projects youre on probably wont carry as much weight as a RoR shop. I know that is stereotyping, but I feel it is a point worth mentioning.

I have to agree that companies that don't value your open source work are most likely not worth working for. They will be filled with mediocre programmers at best who are not interested in the craft but just the paycheck.

As a side note, I landed my current job precisely because of my work with an open source project.

This guy sounds like either a mediocre programmer or someone who actually <em>does</em> have very little practical experience (commercial or otherwise)--there are several tips to that in his email. The fact that his interview went poorly because <em>he wrote inefficient code</em> is a strong indicator, as is the admission, "I don't necessarily claim my open source code is the best in the world but it works." Whenever you hear a programmer say, "I don't claim it's the best in the world....but it works!" you should brace yourself for what's in store when you dig in to the code. That's the battle cry of the inexperienced and unmotivated programmer: "but it works!"

It sounds like he's bemoaning open source as the issue rather than facing the fact that, well, maybe despite all those years of experience, he's still inexperienced (or in the wrong line of work).

I've never heard open source experience described as anything other than a good way to learn and a means to differentiate yourself from others with the same level of relevant experience.

So being fresh out of school and having open source experience is going to give you a leg up on someone who is fresh out of school and has no open source experience, but it probably isn't going to be as good as being fresh out of school with some internships in the field.

Working on open source software demonstrates (mostly) that you can generate working code, but that is hardly the only thing prospective employers are looking for. Can you work well in a team? Can you meet deadlines and/or estimate time well? Can you take customer requirements and feedback and turn them into specifications? None of these things are (necessarily) indicated by open source experience. Plus, a prospective employer is only going to see how well you can code if they have the time and inclination to actually read the code in question, which they probably don't if they have a dozen other applicants who do have the relevant industry experience.

It is possible, if you're involved in an exceptional open source project, that said project may in and of itself get you a job, but in the majority of cases open source experience is at best a bonus on a resume, and anyone who says differently is overrating it.

This anecdote troubles me as well, but I would still challenge the assumption that open source experience is overrated. For instance, if I was working for a web application development shop, and saw this on a resume:

Open Source Contributor - Mozilla Firefox - Jan 2007 to Present
* Helped tune gecko rendering engine to be more web standards compliant
* Optimized tracemonkey jit compilation times
* Implemented pieces of the new HTML 5 <video> tag in Firefox 3.5

This would immediately peak me interest and up the applicants credibility.

It's probably true that not every IT shop is going to value open source software, much less look into the breadth and depth of open source related experience a potential new hire might have.

In any case, I view participation in open source projects as a way of Sharpening the Saw (http://www.codinghorror.com/blog/archives/001236.html). Besides any altruistic intent, participating in certain open source projects is a great way of learning about little programming gems by being exposed to the work of those more skilled/experienced than oneself.

I challenge someone to provide a study demonstrating that open-source software is of lower quality than proprietary software. TheRealWTF site would suggest there is plenty of horrendous proprietary software as well.

All a question of scale, I think. If you've written and developed your own OS code with a small userbase, that says you have passion and interest, but says nothing (necessarily) about how well you work with others or the quality of your work. If you've contributed a less-than-trivial amount of code to apache, firefox, linux, etc. that says an awful lot more, IMHO.

BTW, I'd love to see the arguments against apache, the GNU toolset, or even Firefox having changed the world, at least within the context we're discussing.

@Alex: Agreed. The vast majority of 'commercial' (in-house) software I've worked with has been inferior to that of the average OS project.

I think open source work tends to peak a greater interest for smaller teams of software engineers than larger ones. When you have to maintain, develop, and document something all on your own (or in a small group) it prepares you for doing it in the real world.

Condemning this guy's humility though over his project leaves a bad taste in my mouth. It actually is a sign that the applicants quality of work has improved over the years and he says areas in his project he can make better.

Last the economy is not exactly the greatest in the world so maybe he is just getting some tough breaks.

@Alex

I assume you wanted to say The Daily WTF, not The Real WTF.

In any case, coders are coders not mather whether the source is open or not.

To be honest, I never worked on open-source project and probably never will (unless I retire and have nothing to do with my life).

Yes, I get in at 9, punch in, work, punch out at 5. Go home, spend time with family or friends. Read, do anything that isn't related to coding.

Why? Because I like having a life and having one makes me a good coder between 9 and 5. It amuses me that everyone seems to advise people to contribute to open source, or for some magical reason, they have to get out of work, and keep programming in their spare time like they have OCD. A plumber doesn't finish his job and goes home and takes out/puts in all his pipes in his spare time. I don't see requirements for doctors going home after 8-10 hours work and do free consults. What for some reason a good programming has to have some OCD is beyond me. I produce good code. Have the references to prove. Usually find a job in days (just quit my job a month ago, after 2 days already had another one) and I go home and do nothing, but what I do at my job I do well.

Stop with the 'Contribute to Open Source' recommendations to people. It is bull. I rather have someone work for me that goes home, rests, and come back at 9 fresh and ready to work, than someone than goes home, has dinner and spend 4-5 hours coding whatever OS he does and comes the next day with his brain fried.

I would hesitate to measure the value of an experience in terms of how impressed other people are when you tell them about it.

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.

This story represents my exact experience with recruiters.

Jeff, I would love to read up on your experience with less conventional job hunting channels that respect academic and other non-commercial experience.

You know, having been frequently on both sides of interviews for programming positions, I can tell you that there's a big difference between "hey! I work on open source projects" (which tends to brand you as a fruitcake - it's not deserved, but there it is) and "I've contributed to x, y, and z."

The problem is that there are a lot of people out there that *only* have open-source projects as programming experience - and there's a lot of bias around that. OSS projects are seen as "hobbyist" pastimes; and for the most part, they are. There's nothing wrong with that, but many, many hobbyist programmers fail miserably in a structured commercial environment.

Like most things in interviews, it's a matter of presentation. If you say "I have experience developing package 'x', which is in use by Fortune-50 companies and the US government", then it doesn't matter much whether it's open-source. If they ask to see examples of your code, you can reply "well, package 'x' is open-source, so I can give you my work on that if you'd like".

The fact that your projects are open-source needs to be a footnote, not the thing you feature in the interview.

Putting open source credits on my CV has helped immensely.
Reasons for this I think are:

1. I am not afraid to show my code, thus implying some competency
2. I display interest in creating logic
3. I display ability to work with others
4. I recognize the advantage of the open source development model

Note one may not have attributes 1 & 3, but at least a potential employer can get this information from your contributions.

I think Tom Clarkson had it right when he called it a presentation issue. The simple fact that a project is open source, and that you worked on it, actually means nothing. The potential employer needs to understand that you went through a "commercial process", and it just so happens the process was for an application that is open source. The application needs to either be a part of an SaaS model, or there needs to be an enterprise support option. It has to have some commercial viability, and you should present it that way. Forget all the community aspects, or your passion for open source -- if you want to get past the recruiter, then it should be presented as having commercial appeal.

If a company's interviewer does not take time (or lack skills to) read the code of an important position like a programmer, or worse, thinks programmers are not so important, or thinks to be able to judge the cleverness, consistency, experience, focus, passion etc etc (add all the qualities needed to be a good programmer here) with a single test...

...probably that company doesn't need a PROGRAMMER, needs an INTERVIEWER!

My contributions to opensource were rare, sparse, and generally minimal, with two major exceptions which ended as epic failures.

Is OSS experience overrated? I don't know, but ofter my experience with it, I've committed myself to not contribute anymore. Never. I'm having no trouble in enforcing this self-imposed rule.

So OSS experience turns out to be not so useful?
Thank you for sharing the experience. It helps knowing that I probably went for the right choice.

I'm with you Bruno. When you get home, do something else. Variety is the spice of life. On the other hand, if you are unemployed, an OS project will show a good employer that you continue to be serious about programming.

I have to wonder though, if all the "good" (as opposed to purely academic) OS projects are already "taken". That is, can a person jump into a "good" OS project and make meaningful contributions?

I'm doing some personal projects of my own. I figure they'll do me *some* good if and when I go looking for another job. It certainly can't hurt.

And maybe, just maybe, what I'm doing will one day make a big impact. But probably not. In any event, I'm having fun, and I'm checking whether some approaches I've come up with will actually lead to more stable, maintainable, and performant software.

But I don't expect everyone to just go "wow... you created your own project! Let's just skip the rest of the interview and bring you right on board!"

The problems this guy ran into:

1. He's not talking to the right people. Some interviewers want to see your portfolio. Others don't.
2. Anytime someone asks you to write code, especially if they've made it pretty clear that they're going to be judging you on it, write the best damn code you know how. Don't phone it in and then expect to bring in other code that they didn't ask you for to make up for it.
3. The economy sucks. People can afford to be picky. And they're sometimes full of crap when they "explain" why you didn't make the cut. Sometimes they don't quite know themselves... they "feel" one guy is better than another, but can't put into words what exactly makes them feel that way. That's just life.
4. If the main reason for the OS code's existence is to impress potential employers rather than to solve a problem or to practice or experiment... it's not going to work. The good employers are looking for a passion towards programming, not a passion towards doing whatever you think will impress them. It's the same in other areas of your life... if you [i]try[/i] to impress people, you won't. If you strive toward excellence in whatever you love, you can't help but impress people.

Agreed Bruno.

There is something patently wrong with this profession when the practitioners themselves are the primary source of this ridiculous expectation. I can only imagine it's a self defense mechanism for their own insecurities. My chemist friends don't go home and practice their chemistry (at least to my knowledge :D), my statistician friends don't go home and work on some personal statistics and my doctor friend does everything he can to get away from medical questions. Why do we need to be any different?

I really enjoy writing code but at the end of the 8 hour day I've had enough. The last thing I want to do is sit in front of a computer for another 3 hours of my life. Life is far too short to spend all of your spare time working in one way or another. I'll stick with my downtime being for friends and family and pursuing my other interests.

About niche open source projects: most OSS projects are made to scratch your own itches, as the saying goes. That's something I would add to the first part: "pick one", but one which is useful for you, for which you have a real need. Related to another saying, eating your own dog food.
I contributed a lot to a text editor, because the topic was interesting me, and because I wanted a good editor: I still code with it.
Same for my work on a PHP framework, etc.
I wouldn't help on an accounting software, even for improving my skills on a given language or what's not: the topic is too boring for me, and I have not interested nor love for that.

I mention my OSS work on my resume, but I never counted on it to win an interview: I doubt employers will have the time to check the site, even less the architecture or the sources. Supposing you are the main, or only responsible for that project.
On the above OSS projects, I am just a contributor among others, so even if some parts I gave are significant, they are more or less diluted in the overall code, altered by others, etc.
Listing the contributions, as Nick shows, is more useful: the proverbial executive summary (but that rely on good faith, of course).

I've had two interviews for coding positions, and in both my experience with OSS was valued. In both, I was also asked to point to things I had contributed to the OSS projects - the interviewers were well aware that OSS projects can be large and have lots of contributors.
In the end, that's what it comes down to: are you facing an intelligent and capable interviewer or not. If you're not, forget about anything but blind luck - you're not getting the job based on anything else. If you ARE facing an intelligent and capable interviewer, that person will know what the position to fill requires and will also know whether any given OSS experience is relevant.

As for the whole "don't do OSS, go for other aspects of life" - that's a load rubbish. After hours, do whatever gets your boat floating/rocking. If that's coding a huge OS on your own, go for it. Just don't listen to meaningless generalisations about what makes the better employee.

Regards
Fake

Good, thanks for the information.

What Bruno said.

"When I'm hiring, I'm attracted to open source projects for one reason above all others: it shows a degree of passion. It shows that you're really not just a "clock out and forget about computing until you come in the next day" kind of guy.

It's certainly true that not all places will care about that - and in particular, HR staff and general recruiters may not be particularly interested - but if you can get as far as other developers, and if *they're* passionate about development, it can help a lot."

See, my personal opinion is I'd rather hire and work with people who have well rounded lives and aren't about IT 24/7. While I don't think this is necessarily relevant to TFA, this attitude does concern me slightly having worked for a place that forced its employees to work mandatory weekends.

I'm passionate about programming, that's why I chose it as a career - spending all my free time doing it would indicate I'm obsessed rather than passionate in my very humble opinion ;)

Most good professionals have a passion for their work, and spend some time outside their day job dedicated to their profession. That doesn't mean getting off work to go home and write code for hours every night. But if you aren't devoting some spare time to reading, working on personal/oss projects, experimenting with ideas, etc., it's going to be hard to stay on top of things, let alone expand your abilities beyond the limited scope of your day job.

Let's answer the question directly, shall we? "Is open source experience (OSE) overrated?"

If you expect OSE to eclipse the necessity for legible code, sure.
If you expect OSE to carry more weight than passing a programming test, possibly.
If you expect OSE to matter more than domain knowledge, probably.
If you expect OSE that cannot be verified to be credible, likely.
If you expect OSE to be a panacea, definitely.

In short, everyone rates OSE on a their own subjective scale. This candidate might have rated it a little too highly himself.

"That's a terrible interview track record for the open source experience"

Is it? It sounds to me like a terrible track record for companies who don't take 60 seconds to look at your work, and a terrible track record for recruiters. But that's hardly surprising, open-source or no.

How's this candidate's success with people at companies that don't suck?

Ah yes indeed - the inmates are running the asylums

Dear oh dear.

Two things. First, anyone who thinks that the main reason to contribute to an open source project is to get a "real" job is sadly deluded. Isn't that a bit like trying to play rock 'n' roll guitar and hoping for groupies? You contribute to an open source project because you're passionate about the project goals, because you have a desire to see a particular problem solved, and because you want to make the (software) world a better place (well, you can scratch that last one if you're feeling particularly cynical).

Second, do you want to work for an employer who has such a narrow minded outlook? I guess not all of us are in the position where we can choose who to work for, but I've always taken the view that an interview is as much a chance for me to work out if I want to work for the prospective employer as the other way around - I've turned down a fair few job offers because the employer simply didn't measure up to my standards.

In my (not so) humble opinion, your anonymous contact should quit their whinging - either contribute to their open source project or don't, and get a *good* job - don't end up working for chumps.

Yours sincerely,

AnnoyedOpenSourceGuy

Personally, I tend to shy away from open source as a user - about 90% of all open source I've ever used turned out to be have massive flaws - mostly in regards to it doing what the programmers considered to be cool, instead of what I, the 'customer', actually needed. Requests for help were answered in the overwhelming majority of cases with "Just do it yourself if you want it so much".

Over the years, "open source programmer" has come to have the same ring in my ears as things like "Linux zealot".

Your own view towards open source oddly seems to confirm my vague feelings - people program for open source projects FOR THEMSELVES instead of for a customer. Neither I as a customer nor I as a leader in any commercial project would want someone like that to work on my software.

Don't get me wrong - I don't think OS-programmers are bad people. But I also don't delude myself into thinking they are selfless saints who give me great software for free.

How much time does a programmer expect a hiring company to spend looking at his open source code? Get real. You've either got demonstrable successful experience with a reputable employer, you ace their coding test, or you've got an open source project that people love and which your name is plastered all over.

You can rock the linux code base, but unless Linus sends them a letter saying "Joe has been invaluable to the success of Linux" the recruiter's not going to care.

So to your conclusion: Duh.

Companies give programming tests so that they can make sure you actually know what you are doing, and aren't just a fast talker. The programming test will not get you a job, but it will weed out a lot of people.

It doesn't matter that you wrote open source software...they aren't going to look at it. If the comparison is between you and every other candidate who comes in, the programming test is a good baseline for comparison...if you wrote an inefficient solution, then they'll assume that you'll write inefficient code for them.

I think the anonymous emailer is somehow mixing in the fact that he worked on open source software to something unrelated. I know people who won't even look at a resume when they interview someone...if they can answer the technical questions they they are in, if not....out.

Why is anonymous surprised by the first incident? I don't see where the fact that anonymous wrote open source software is even relevant there. S/he provided a solution to the test, it wasn't received well and the interviewer evidently didn't want to be bothered with looking through the open source work that anonymous had worked on in some capacity. If the solution wasn't up to the expectations of the interviewer, why would anyone expect the interviewer to spend his valuable time on a candidate that he wasn't all that interested in?

Secondly, why would anonymous be surprised by the recruiter's response? I'm not. Often recruiters aren't willing or able to spend a bunch of time trying to determine just how much of a part I actually played on an open source project. If they can find someone whose resume says they worked at XYZ software house for 6 years doing this and that, they've "done their job" without having to dig into sourceforge and determine how much the candidate actually did on an open source project.

I think that open source projects afford you the opportunity to work on projects of interest and gain technical skills in areas that interest you. That's how it should be viewed - as a way to gain experience so that you can sell yourself at the interview. "Making job interviews easier" is, in my opinion, a poor reason to get involved in an open source project. You should do it because *you* are interested... potential employers might not have the time nor inclination to do much looking at an open source project to determine just how much you actually worked on it. And if they don't have the time or inclination, it doesn't mean they are necessarily a bad place to work. There are multiple reasons why they might not seem to care about your open source experience.

Pick something that interests you and get involved, but don't expect it to be your ticket to a job somewhere. It might, but it might not.

There's one part within your quotes that summarizes it all:

"A lot of open source projects are probably poorly written [...]"

That is my experience, too. The coding standards at our company are very relaxed and our code is by far not always the best that could be done... but most open source projects have a quality level that is subsurface! We would never to dare to ship anything coded that bad.

OpenSource is like "Take it or leave it", and as you don't have to pay for it, OpenSource project managers also don't have to listen to the users.

My biggest sorrow is that not just OpenSource projects have such horrible code, but most closed source projects have as well... I just don't know it as I can't see the code. Maybe not just 90% of OpenSource is crap, maybe 90% of all code in the world (open or closed) is crap. ::shudder:: However for commercial software I won't see it at least. I wont run into situation like with OpenSource were I'm trying to fix a tiny bug, look at the code, bang may had against the table spluttering "No... no... and why... how can anyone... no evil code, go away!"

I think your anonymous correspondant is having trouble because he is dealing with recruiters or managers who don't have time, or don't know how, to evaluate his open source code. Open source projects are useful to have on a resume, especially when you find a company that's hiring that "gets" open source (uses it, maybe produces some). But to others it will mean nothing, so it's not worth making it the number one focus of your resume and cover letters.

It sounds completely unreasonable to expect a hiring developer to go through your Open Source code. He might glance at the project website, but he's not going to check your code.

He asked you to write sample code - he's going to look at that, because he knows what should be a good solution to it. Now I have no idea how unfair he was being with whether your code was inefficient or not, or what standards he told you he was looking for - but that's the code you should expect to be judged on. Everything else you've done just falls into "he's done something vaguely like programming for 14 years, so he should know something." I don't care if you have 20 years commercial experience at the coolest place in the world, if I ask you to write sample code and you write shitty code, I'm not going to hire you.

And as for recruiters - every recruiter I've talked to for the last 2 months has passed me over for entry level Java positions because my last job was in C++. On the job I finally landed, once I finally talked to a programmer he of course said "oh, yeah, it's exactly the same, you'll pick it up in a day" which I then did. So don't just the usefulness of skills on what recruiters say - you just need to learn what bullet points their looking for and how to speak to them so they can fill in their little checkboxes.

"if you aren't convincing at least a small audience of programmers that your project is worthwhile enough to join -- Then what are you really doing?"

You're solving your own problems, and making that solution available for free in case anybody else wants it. What's wrong with that?
John on April 16, 2009 06:14 AM

Fair call

Whenever you are asked to write code in an interview (either during the interview or as a screen) you should ALWAYS ask what they are expecting. E.g.

a) Do you just want code that solves the problem?
b) Do you want me to write it as I would on a daily basis?

Of course this deals more with things like reusability, level of comments, error handling and so on rather than just efficiency. If you provide an O(n^2) answer to a problem that has simpler solutions then you only have yourself to blame.

Your success in job interview depends primarily on how you come across in the interview, not upon your prior experience. If your resume got you a job interview, your resume was good enough.

Whenever you find a person who has an easy time getting interviews and a hard time passing them, the trouble is in the way the person interviews.

What crap excuses for not getting a job. The economy sucks and you're not guaranteed to get anything. Don't blame open source projects or say that they're useless. I understand being frustrated, but its not fair (or factual) to say that open source contributions are ignored.

If you want a job its not enough to tell people they can go search for your work on the internet. You need to present it and market yourself better. No one is going to waste their time looking into your work when the next 3 people marketed their experience better.

My response, on my very new very rough blog:

http://angelbob.heroku.com/posts/39

Summarized: in the first case, the open source experience *was* as valuable as commercial experience. In the second case, he loses because the recruiter is looking for specific buzzwords with no understanding.

I think, if you are going to participate in an open source project, then that should reflect the sort of work that it is you really want to do.
ie. if you want to work in audio processing,or radio, or... ear things, then go and work with audacity. Then when the interviewers ask about it, they may know the sorts of software you are talking about.

If you are a clock in clock out type*, then maybe it doesn't matter if you hammer away at excel for 8 hours a day, but if there is programming stuff you genuinely enjoy, look for a company that works in that field.

Im mucking around with papervision, looking at terrain generation, so I'm thinking of cartography, or surveying.

If we wait a bit, before we jump into jobs (hard, admittedly, in these days) then we should be able to find something that will have an employee who would value the dedication to working on a project that has a clear relation to the industry we work in. (Yes, we are in IT, but IT is in everything else. It's not all spreadsheets and databases). If we can do this, then, as a bonus, we'll get a job where we value our contribution

*i am, it's ok.

If the interviewer cannot tick the boxes then they will not be interested, if you fail the test then no matter what you say, especially that they did not tell you what they were looking for, will not help

Interviewers look for relevant experience, and this may include OSS work if it is relevant to them, but if the interviewer is just ticking boxes then relevant experience may be defined very narrowly

A lot of OpenSource code is horrible because a lot of code is horrible, but please do not compare a 2 person OSS project that someone thought was cool, with a major company sponsored project that happens to be Opensource, I suspect a lot of commercial software has some horrendous code in it somewhere, and it causes bugs, but I can't tell because I cannot see the code...

I think the original issue suffers from what I would call: Ticketpunchitis. As in, tell me what I need to do to get my card punched that will guarantee me a lucrative programming job. PhD: check, OSS: check, local UG: check. Why don't I have a job yet????

What gets lost in the shuffle is that the most important thing is that you are a good programmer. How you got there is not really important.

If you boot the code exam then you can't really complain about the unfairness of it all. Maybe you got the code exam because of the OSS experience and many others didn't even get that far. And if the person evaluating your code was an idiot then you don't want to work there anyway.

Myself, I would never even respond to a "cattle call" interview anyway. It wastes everyone's time. I have a network of fellow coders who know what kind of work I do. There's no better recommendation than a bunch of respected programmers who can vouch for you. Certainly, OSS can help build that network if you are choosy about which projects you work on.

Matt

I agree that some open source software may not be as well written as it could have been, but how often is it that any of us encounter a codebase that _is_ really well written? I mean, we all joke day after day about how bad "enterprise" software can be, which is generally attributed to it being written behind closed doors without the scrutiny of an open source community. Maybe this guy/gal had a string of bad luck with companies that do have a clean code base and high standards to keep it that way. However, when I hear "industry programming" my brain does not imagine tight, clean code. I more think tight deadlines, and doing whatever it takes to please customers/management so the bills are paid.

I guess my point is if corporate recruiters/managers are going to hold everyone to this high of standard they better be able to back it up. Personally I think we all do just as well as everyone else, we've just optimized in different ways, and could all probably stand to learn something from one another.

OSS is helpful - but anon was using OSS to break into the wrong IT job market.

There are really 2:

* Commodity Jobs - ones you get through recruiters, to companies that are not going to know you from the masses.
* Network Jobs - ones you get through your relationships.

OSS helps in the latter, but unless you are Joel Spolsky or Phil Atwood famous, is patently useless in the former. The commodity job market exists because there are companies that run such bad IT departments that nobody would recommend a friend from inside the network to go there. You think places like that give a rats ass about OSS? Most of them are mills where you will probably be miserable anyway.

1. recruiters don't know jack about programming
2. HR people don't know jack about programming
3. if someone gives you a coding test, you'd better take it seriously. I don't care it you wrote Apache in binary on a PDA if you can't solve a simple problem efficiently in a reasonable amout of time.
4. disparaging comments about commercial experience do not win points with people that sign the checks, or with the people that recommend you to the people that sign the checks
5. save the OS wank spiel for the technical interview with other programmers that are also OS wanks; 90% of OS, like everything else, sucks, so "I work on OS projects" may mean "I invented Ruby" or it may mean "I waste a lot of time on dead-end projects on your dime" - or both!
6. if you want a commercial job, tell me how what you do will benefit the customers. I don't care if your OS project feeds the homeless and clothes the naked and prevents global warming, if you can't tell me how hiring you will improve my business or make my customers happy, then you're useless to me.

I have to say that I think the real problem here is that a lot of IT recruiters are really, really bad at their job. I've been turned down for all kinds of spurious reasons. And every one I meet wants to pigeonhole me as a "C programmer" or a "Java programmer" or a "database programmer". I try to emphasize that I'm all of those things and more, but some just don't get it.

If someone failed at a phone screen and pointed me to their open source code to review, I wouldn't for two separate reasons:

First, my company delivers closed source code. There could be issues of "taint" that our legal department is concerned about if I review a potentially competing/similar open source product. I'm not going to get legal clearance to review your code.

Second, you failed the phone screen. We get a lot of applicants and need some way to reduce to a manageable number. I'm not going to spend the better part of a day reviewing your contributions to some product, since I don't see how that would invalidate the phone screen.

I guess you're more inclined to doubt OSS, Jeff.

Your posts always have titles like "Is open-source viable?" and start like "I'm a big advocate of open-source, but..."

hi there,

An interviewer might NOT have the time to go through the source code publicly available. It might help to have small excerpts of your source code analyzed in your blog. Blogs go a long way in establishing your expertise. Did the anonymous open source guy have a blog ? Did he discuss the various algorithms that he/she used in the open source project ?

BR,
~A

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.

Jeff

I value experience in Open Source software, however I think that this experience is not and should not be mistaken for actual "work experience" that is considered valid to employers (even though I disagree with this notion).

Contributing to an OSS project teaches a developer valuable skills, making them a better developer which will ultimately make them more valuable in the job market. The thing to remember is that your contribution is for the benefit of you and the community, if it helps you land a job then great but don't count on it.

I wrote an in-depth article on preparing for technical job interview, it can be viewed at http://www.mknopf.com/articles/preparing-for-technical-job-interviews.html

Michael

What Bruno said.

Maybe this guy sucks...just a thought

"1. recruiters don't know jack about programming
2. HR people don't know jack about programming
...
irrelevant on April 16, 2009 10:30 AM"

And despite this fact these morons have a large amount of power and influence to filter programming job candidates. I believe that *experienced* programmers should *always* make the call on which developers get hired. The craptastic code that we've all seen before happens the most where experienced developers don't have as much influence as they should in the hiring process. *Sigh*

My thought is that the people interviewing him really weren't that much of programmers themselves, or at least narrow minded ones.

If the guy failed the first test, then how is the recruiter to know that the OSS code he has written is even his? He could have plagiarised it from another project, or heck, someone else could have written it.

I don't blame the recruiter from moving on.

Programmers should never make the call on which developers get hired.

Many programmers live in their own world and are "Fachidioten" ;-)

I would never hire such an open source freak, because i would fear he spents his work time on other things, and discloses company work outside or take company sources and starts an open-source-project with it. We want to live from our work, and get money for our hard work. I never understand these open-source people, why they give away hard work for nothing only to be famous to other nerds.
If you have to offer something valuable, you deserve money for it. If no one will pay, it's simply not worth your efforts.
They destroy markets without any sense, i will never assist such people. I should pay them money, and they spent it to kill markets - never ever. Go to north corea, they need such willingly morons :-)

(attention: a little bit of sarkasm and a little bit exaggerated, but with some truth in it)

As a hiring manager (and a programmer - not an HR recruiter), I believe, and tell people, that open source experience would be something I'd love to see in an applicant. But in the end, I struggle to get much information from most people who list this on their CV:
1. I unfortunately don't have much time to spend on hiring decisions, and to really look at a large body of someone's code enough to evaluate it well can be time-consuming. The test, while limited, is a distilled way to get information on them in a short space of time.
2. A large part of making hiring decisions is making a _relative_ decision: how does this person compare to others I've interviewed? How do they compare to people I've hired, and how did those people work out? Using a standard test makes this relative decision far easier.
3. It's hard to know for sure exactly who contributed what code on many open source projects, without spending a fair bit of time to dig into it (e.g. by looking at revision histories of files). I've found in the past people who say they worked on a project, but when you dig into it, you discover the vast majority of the code was written by someone else and they just chipped in some bits and pieces. Even if you discover they wrote it all, it's still hard to know how long they took on it, what help they had etc. A test in controlled conditions eliminates those factors.

The sad fact is that hiring in real life is fundamentally not a process of spotting talent in people. It's a process of eliminating people who don't have talent. You still end up with talented people, so it works out just as well for the employer. But it can end badly for some talented applicants who get rejected unluckily. This is because the cost of rejecting a good person is very small (you'll find more), but the cost of letting a bad person through is enormous. And eliminating people can be done so much more efficiently.

The good news is, if you are talented, you just need to keep trying. If you're just unlucky, it won't stay that way forever. Don't get put off by one or two rejections.

He probably used tabs instead of spaces on his coding test.

In my experience of getting interviewed, alot of times the HR Person / Recruiter never passes the Resume on to the Hiring Manager because they don't think it meets the requirements. I think a lot of times the Recruiter doesn't really understand the idea of Open Source, or the the Hiring Manager didn't Specifically Say "Open Source Experience" in the requirements. So, consiquentially they don't pass the resume on to the manager. This is really just as bad as someone requiring 5+ years of experience and not even considering you if you only have 4, or not considering you if you don't have a degree even though you have 7+ years of experience.

I say, there are plenty of companies and jobs out there. Go find one that you'd really like to work for, that would also fully appreciate your skills. Or, alternatively you could always start your own company!

Slightly biased as we deal primarily with Open Source software, but my company looks extremely favourably on free software projects.

I can think of one particular employee who has worked out very well who wouldn't have got the job without open source experience. His interview wasn't the strongest, but the ability to see concrete examples of his work and just as importantly his interaction with other people swung it for him.

>...How many open source projects labor away in utter obscurity, solving problems that nobody cares about, problems so incredibly narrow that the authors are the only possible beneficiaries?

Over the years, I've developed a serious bias against programmers who work in obscure languages (e.g Ocampa, Lisp, Haskell). It's a little like a dog peeing on food he doesn't want. Good or not, he just doesn't want the other dogs to have it.

So unless the candidate's work is created in a well commented C-form or VB-form language (Python and PHP and perhaps Ruby are popular enough to be exceptions), I tend to discount that candidate, not on coding ability, but on their ability to deal with other humans in the real world. Moreover, if the problem domain looks very narrow, and the candidate wasn't paid to do it, I once again have to start wondering about whether the candidate can realistically set priorities.

As for open source, this is pretty dubious as an accomplishment. First, there's no barrier to entry other than the ability to create such a project. Moreover, what did the *candidate* write, and what was rewritten? For all I know, the thing could be a clever forgery where the candidate knew just enough to answer some questions.

Could I ferret this out from source code check-ins eventually? Maybe. Do I have the *time?* Are you kidding?

So, Open Source? It can work for or against you. Choose your samples carefully.

the emailer wrote: "One of the reasons I worked so hard on open source projects was to make job interviews easier."
Wrong reason for working on open source. Do programming because what you build helps you in some way. Share the source because what you write helps others in some way. Why bother programming for some business building something you yourself aren't interested in?

I agree with Luke Halliwell about the potential difficulty of knowing exactly what work a person did on an open source project, how long it took, if they had help, etc. A standardized test does eliminate many of those questions.

But the problem with that sort of testing is it is frequently the "gotcha!" type where they are focused on some particular criteria, and if you don't quite meet it (perhaps because you focused on some other aspect), you're out. ie: Are they looking for "efficiency"? "coding speed"? "correctness"? "cleverness"? "best practices"?

So on the test, you might quickly write simple, clean but somewhat brute force code you can be very confident in that it will work first time through, with no bugs. Then, you get scuttled because it's not the clever, efficient solution the interviewer expected.

Or, on the test, you might take your time, come up with a really efficient, but complex code and a class that provides a whole interface layer to the functionality. But then, you get sunk because the interviewer detects an off-by-one bug on one of your boundary conditions - you "took a long time and your code still was buggy".

Unless you've already made your reputation (and there's not many that have), you're facing a multistep hiring process, in which your goal in each step is to get to the next step. Most places get too many resumes, and need to thin the herd quickly. They aren't going to be fair about it, because being fair would cost them time and effort without obviously getting them better people. Bitch about that if you like, but live with it.

Your resume isn't going to get you a job. You want it to be free of obvious reasons not to hire you, buzzword-compliant with the job description, and standing out from the crowd in some way or another. It needs to survive the nontechnical HR person and the hiring manager, both. Put OS experience on your resume unless you know it will hurt (there are people out there who are anti-OS, and in today's economy you can't afford to avoid the clueless). That way you probably get to the next step.

Now, the OP did get to the next step, the coding test, and blew it. Nothing's going to help you if you blow a step. If you can't pass the test, odds are you can't code up to company standards. This may be incorrect, but nobody's going to take the time to find out. There's enough candidates that passed that there's no need to waste time and effort on also-rans.

Eventually, if you get through all other steps, you get to the point where you tell stories about your exploits, and how you approached problems, and you can talk about your OS experience. You'll also want stories about how you got along in close proximity with annoying people and how you coped with being told to do something you didn't want to do, and those will more usually come from regular work rather than OS experience.

You might find a way to introduce some particularly good code you wrote, and if it's OS you can legitimately do that. Never show code you don't have a clear right to show, or break confidentiality with anybody previous. You don't want to give the impression you might treat them badly.

Don't expect anybody to go through an OS project, cold, figuring out what you did and getting an idea of its quality. That's a good deal of work, and nobody's going to do that unless you're going to be hired anyway.

So, while the benefits are there, they are limited. Don't count on them to get a job.

And never denigrate in any way the ability to fill out a time sheet and estimate completion times. Those are valuable skills as a developer in any sort of commercial application.

A sample of one company, and two recruiters?

I don't mean to sound condescending, but hell, in this economy, you can't give up that quickly.

Open source experience is not a silver bullet to get you a job.

Seems the OP expected that and deservedly crashed and burned.

Your value to the company you want to join is the deciding factor, period. Does having worked on OSS projects contribute to that? Peripherally.

I didn't even mention my OSS experience in my interview, I only did when they asked me about it explicitly. I got my current job based on the strength of my interview and my performance in the test.

Sounds like OP needs to work on those..

I have sympathy for this guy’s position. I had problems last year, when recruiters would insist that they were only looking for experienced C# developers, and my 15 years work experience in C and C++ was not considered relevant.

However, I can see why some companies would be less impressed with open source work than commercial experience. The open source work would only demonstrate the strength of your coding skills, there are other aspects to working in a company, such as communications, team work, meeting deadlines, satisfying customers etc.

Also, considering the attitude that some OSS advocates have towards corporations, licensing, secrecy etc, it wouldn’t be surprising if some companies would look at someone working on such software with suspicion.

Yes, it's part of your coding portfolio.

That doesn't mean that your portfolio is *good* or anything.

Hate to say it but it sounds like the Interviewer(s) read more of Jeff's stuff then Anon has.

Live coding test! How dare they?

Inefficient code, no big deal. After all they had 14 years of experience.

Open source project, nice deflection. Could have written all of the code, or, none of it.

Why didn’t they print some of it and show it to the interviewer as an example of their work.

Me thinks the idea of working on Open Source Projects is to get better at designing and writing code so YOU DON’T FAIL LIVE CODING TESTS AFTER 14 YEARS EXPERIENCE.

I remember Jeff pointing out an excellent blog post from Steve Yegge called "Ten Tips for a (Slightly) Less Aweful Resume" and the poor Anonymous user mentioned in this article should have read it before his interviews.

Particularly Tip#4: Avoid Weasel Words and Tip#5: Avoid Wank Words.

Putting his statement through the Wank-o-tron turned:

I am the architect of a couple of open source Java projects

Into:

I am the wanker of a wank of wank wank wank projects…

This reaction shouldn't shock anyone. I think whether or not Open Source projects are to be considered relevant depends entirely on where you're applying and who's on the other end of the phone. I had similar experiences when speaking with recruiters and HR people (sometimes even 'technical' people). They are trained to look for keywords in your responses whether they be brands, languages or experiences. "Did he just say 'object oriented' and 'embedded' in the same sentence?... awesome, he's our man."

If the people doing the interview are more technically savvy (like if you're applying at a small game studio for a programming job where a technical lead is present at the interview) they may even know the open source projects you're referring to and be impressed by it. But if you're applying to Acme Consulting or Acme Telecom or Acme Computer Solutions or Acme We'll-Take-Your-Money-For-Random-Computer-Technology-Work then it's likely Open Source work will be completely irrelevant to them. What will matter to them is what they can say about you to their non-savvy clients.

Hi,

Jeff, sorry to say you're incredibly idealistic. Or maybe my own experience leads me to other conclusions about those recruiters. Their answers have in fact no technical background check, that's just bullshit.

Please, tell me I'm wrong, but most companies don't care about great developers. In fact, a) they think developers are all the same, they only vary on the technology they use ; not on quality or productivity. 10x developers are unicorns that only exists in Fred Brooks' mind. b) they don't even know the difference between programming and configuring c) a developer only knows one language, one OS, one IDE. They want a "specialist" who did the very same thing every day for 2, 5, 10 years. d) what scares them the most is having a rebel among them e) THEY JUST WANT YOU TO FIT

And that's the reason why they don't want any of these opensource idealists, they just want single-minded zombies.

Maybe his code was crap? I can point to a number of Java Open Source projects where involvement would be something I'd try and hide...

About the anecdote.

it's not because the guy made an open source Java project that he didn't suck.

opps.. I'm not the first one to say it.
I think it's all part of this reality distortion field about open source that if it's open source, it's probably good.

IMHO it's a bad road to 'participate in an open source project'. What helps is participating in a project with other people you can interact with, in person, with a senior/mentor. Going actively in a project with remote peers people is just going to take a more time, which you'll be wasting arguing pointlessly, emotionally, and waiting for email responses.

Now browsing open source projects to see how they're structured, however, it awesome. Small ones are fun, but personally I enjoed Firefox and webkit are the best

Read Bruno's comments above. It hits the nail on the head...

The problem with open source projects, as the recruiter sees it, is they have no intrinsic value. Because they are free (as in beer), no one can put a price on its value to the organization or to society as a whole.

When you say on your resume that you did X for an employer, what you are really saying is that X and the costs associated with you (ie, your salary and operational overhead) resulted in a net gain in value for the company. That is, X in dollars provided Y revenue (in dollars) where Y > X. That differential (Y - X) is how much X is worth.

In the open source situation, X = $0 (zero dollars) and Y = $0, so Y - X is $0. In fact, if time=money, the time you invested in X costs money, but the return is zero, so the net revenue is negative. Not good. Recruiters may see open source as a money sink or, at best, worth nothing.

An employer wants to see that your contributions positively affected the bottom line. With open source projects, there's no bottom line.

An employer wants to see that you were able to deliver a product on time, under pressure, to the satisfaction of the customer. With many open source projects, there's no deadline and no customer.

If you're going to use open source on your resume, you need to show real value for your work.

For me, contributing to an open source project is not really viable. I am not competent in any languages that open source projects are using, or maybe there's some open source VB project lurking in the bowels of the Internet somewhere that I don't know about. The obvious solution: learn another language. It can be done, but I can't justify it. I don't have any personal needs that can't be fulfilled with VB or PHP. At work, all code is VBA running on top of other apps. We don't write standalone software because we're not a software company.

As a consolation, I started a blog last year where I post a function every week.

First off, thanks Jeff. I have learned a lot from looking at this blog entry. It's a bit of a dismay for me to see a lot of intelligent people spiralling into derivative rants rather than trying to look at the original letter. Kudos to the few people who were polite enough to at least use the same tone of conversation I might even expect them to use in person. I'd like to say that some time has elapsed since I first sent Jeff my original letter and thankfully I'm employed now. I now have the benefit of reflection and reluctantly felt I should say something on the postings for this thread.

I didn't fail a coding test, I gave a solution which they thought was very inefficient. Admittedly I probably have a bit of test anxiety, which ironically goes back to a degree when I used to study for tests all the time. I was a stellar student in the first few years and I did so well studying to the test that the money I won bankrolled part of my schooling. But the strategy was a form of intellectual bulimia: read, purge, feel empty, look 'great'. Losing those shining grades forced me to define my worth to a project in terms of what I could do. And so began a new era where I got used to demonstrating to people what I did in past projects.

I was undergoing something of a re-education when I first wrote Jeff and was reminded of the culture clash out there. If you wanted to impress an interviewers who are in areas of scientific computing, you could often demonstrate your past work and indeed many in that community got used to dealing with open source code. And I suppose over the years I've gotten too used to dealing with people who do open source work. I'm not saying they work in high profile open source companies but many of them do write good code - I've seen it. But I made a mistake by subconciously extending that ethos of development to the IT world in general. I just got used to it and should have better remembered my time in commercial settings from long ago. As for leaving it open that my code wasn't necessarily the best in the world - yes - as one poster implied, that was a marketing mistake. My modesty was probably mistaken for a lack of confidence in my knowledge.

But over the years, I have felt that my ability to readily demonstrate technical ability has allowed me to become more confident in also admitting some ignorance. I thought that would provide currency in an interview but now looking back, that probably only suits a very specific audience.

Some of the contributors make a good point - it is the recession and it sucks for a lot of people. And I hope some of them would stop a moment and pause to consider or remember what unemployment can do to self esteem. On the interview trail I found it amazing just how few interviewers actually asked me about my past work. Many asked intelligent general questions which were valid whether I got them or not. But I did think they would have considered both coding tests and open source work. Contrary to what some people may think, doing a lot of good open source work does not mean you're going to always provide the best solution or even pass an arbitrary test rated in an arbitrary way. I reasoned that you may recruit based on skills with syntax or code tightening techniques. They're easy to demonstrate...they're also easy for candidates to fake. But you're going to pay someone based on their capability of making scalable software. This ability can be much harder to demonstrate, especially when you reference prior closed-source work. There I thought I could present an advantage but again, this was probably a mistake.

I was looking for neither sympathy nor diatribe from people who read the post that Jeff so kindly offered to put up for me. What I was hoping to find were people who could tell how their work in open source affected their job hunt. Did it help or didn't it? I got some of that, but not nearly enough.

A year ago, I resisted the urge to get certified in technologies I've already long known. The original motivation was to simply encourage myself to adapt to new features as we all do. But increasingly I became concerned with the way interviews were conducted. Still, I concluded that for the sake of my own personal interest and sense of practical thinking, I would have preferred to spend that time working on OS projects instead.

If I had any doubts before about pursuing certifications, I have none now from reading some of the posts. I have a renewed urge to learn everything in the books, ignoring the Paredo principle that might be used to question the return of doing that. It is not because I haven't done real programming. It is not because I haven't made working applications that satisfy use cases. I have.

But if the norm for market-place recruiting continues to emphasise low-level coding details and assumes I am a black box programmer, then I have to begin studying for tests again to appear as a black box programmer. In some ways, studying to the tests again brings me full circle. It is reasonable because every interview is a test, isn't it? This is not a new lesson I've learned, but a reminder. And I'll thank all of you (especially the polite ones) for reminding me of that with sobering clarity. This is all I'll say on my own post because I wish to remain Anonymous.

Why would I just pick an OS project and "contribute" to it? I would never do that for a freakin resume! I'd only do that for myself, not to tell others and toot my own horn.

@John (3rd comment) puts it nicely...

You're solving your own problems, and making that solution available for free in case anybody else wants it. What's wrong with that?

Things an OSS project reveal about the candidate.

1. Can the candidate meet deadlines? Because real programmers ship, preferably on-time and under-budget.

2. Can the candidate prioritize effectively in order to meet deadlines? Because real programmers don't always have time fix what they want, only what they're told needs fixing.

3. How long did it take the candidate to produce the working OSS, in terms of dedicated man-hours? Because real programmers have deadlines and know how to estimate production time.

4. What percentage of the production time was spent fixing bugs? Because real programmers have a solid regimen for ensuring quality, and one of the worst ways to fix design flaws is with a debugger.

5. How much other existing OSS software already solves the same or similar problems? Because real programmers can use existing libraries in order to ship sooner, and can evaluate the utility of such libraries, even when it's not the prettiest code ever.

6. Is there an overview document, a design document, or another way to understand the OSS product in 10 second, 1 minute, 10 minute, etc. intervals of attention and detail? Because in the long run, if you cannot explain what you have been doing, at different levels of detail, then your doing has been worthless.

7. Can the candidate proofread adequately before committing? Apparently not, because:

"Things an OSS project reveal about the candidate."

shoud have been:

Things an OSS project DOESN'T reveal about the candidate.

Maybe the person is expecting the wrong thing from his open source experience.

I've gotten jobs from open source projects not because I am some sort of coding whiz, but because my work and comments on these projects have made people on these projects realize that I am a knowledgeable person and can be a valuable asset for their company.

Working an open source project is similar to doing a computer presentation, going to a conference, or meeting various people for lunch: It's part of an overall networking strategy.

I would like to work on a open source project mainly because of my willingness to learn and collaborate. For a academic student, open source projects give a great exposure to the software industry, even before getting a software job. And, to a software developer, open source projects, helps him to work on the technology of his choice, rather than what he/she was asked to work on his day job.

I think the subtext is that the very concept of job interviewing "performance" and hiring decisions being predominantly based on technical merits is overrated. More of than not, it is a largely a matter of first impressions, "cultural fit", and self-salesmanship. Of course a modicum of subject matter competence (or at least perception thereof) has to be there. That goes not only for interviews, but all career aspects.

As for reasons given why one is turned down, many things in the social arena are illegal or lawsuit bait, so subject matter pretexts will be made.

I have to add that I would include in "first impressions" the "track record" and "pedigree" information stated on the resume.

It is too bad that the anonymous emailer had the experience he did. Personally, I think that it is par for our (immature) software development industry and nothing really to do with anonymous eamailer himself - dude, don't take it personally, I have been through similar and much, much worse. I am 50 and still programming and the only advice I can offer the anonymous emailer is, don’t give up man, keep it up! Don’t get discouraged. Yes, I know our software development industry is one of the most wildly WTF misunderstood industries in the world, but as the saying goes, sometimes the dice rolls the other way, be patient. As far as open source is concerned, I spent a year writing an open source project and I really don’t care if it is useful for anyone other than myself, because that is who I wrote it for. So what? Hey anonymous emailer, have fun, life’s short!

Ok, I'm not going to read through all of the 93 comments currently attached to this post, so I may be redundant at this point.

However, businesses work off of a bottom line. They want someone that either "saved X corp Y amount of money", or "helped to improve X corp's process".

Saying you worked in open-source, however significant, has no bearing on the bottom line. They want active, tangible achievements from a recent employment.

+1 on Thomi's and Noah's comments.

I interview people and examine their coding skills all the time. The questions I ask are in general simple to grasp and have efficient (generally linear) solutions. The efficient solutions are not the most obvious (only about 4 in 100 applicants get it immediately) but it's reasonably easy to start with a correct and simple solution and then optimise it into the most efficient solution. So, when an applicant writes a correct and inefficient solution, we discuss it and I ask if they can go faster. They think again, and (often) come up with a faster way.

It's that exact discussion with the candidate that forms the basis of the hire decision. I want to know how they think. Just coming away from the interview with a single binary digit ("did they write an optimal solution?") is a terrible waste of an hour, for both participants.

As far as the coding test taken by the anonymous developer goes, if the interviewer gives a test but does not indicate what the criteria are for evaluating the result, is it any surprise they don't get what they want? After all, if I ask you to develop code without telling you what my non-functional requirements are, should I be surprised that you didn't meet them? No.

One problem is that in most cases interviewers won't spend much time on each candidate, its natural. That's why they say don't send in a 10 page C.V, because they will go directly to the trash.

Saying here look at my 20K L.O.C. on the web to see how good I am, is practically the same thing. Unless you shine in their interview process, no one will look at the code, it'll go directly to the trash

Someone mentioned the guy being a mediocre programmer.

Sad fact is that most of us programmers are mediocre programmers as most plumbers are mediocre plumbers.

I am probably a mediocre software engineer just as you are.

If that hurts you then tough.

If the standard of work by the mediocre engineer is not acceptable by society then there is a problem for all.

Damn! I miss being able to upvote comments/answers.

I would say that merely contributing to some random open source project isn't necessarily a helpful addition to your portfolio. Anymore than spending X years at some random job would. Making solid contributions to a reasonably high-profile open source project (mozilla, apache, jquery, linux, chrome, etc.) definitely punches up a resume. Though to be honest I think having a well-written blog would be even better. Determining code quality is non-trivial, even for open source contributions. But it's far easier to get information about someone's skill level and passion for software development from a blog.

I put on my resume that I had written and published a free/open source World of Warcraft add-on. In one of my interviews, 2 of the 3 interviewers played World of Warcraft, and asked me about the add-on...I think it may have (slightly) helped my chances of getting the job, but I wouldn't say it was a key item that swayed their opinion (for one thing, WoW add-ons are written in Lua, which is not used much elsewhere in the industry). But I guess what Jeff said is true--*what* you contributed to or authored may be more important/relevant than the fact that you did it.

If I'm hiring an actor for a movie, and one of my applicants tells me that he's been pretty active in Sheboygan community theater, I'm not impressed.

I think this person's experience has less to do with open source v. commercial biz experience (he seemed to have both), but rather with the total inadequacy of most recruiters - and some interviewers. Let's face it, most recruiters don't have a clue - they send spam emails to anybody and everybody that might remotely qualify for a position, then shoot them down for the most trivial things which they don't have the slightest understanding of. Most recruiters don't have the foggiest idea regarding the differences between different languages, APIs, frameworks, technologies, protocols, etc.

I try to avoid recruiters at all costs. No independent recruiter has ever resulted in me getting a job and they are mostly a waste of time. At least half of the recruiters can be bypassed because they don't have an exclusive relationship with the employer and the employer is often accepting direct resume submission (if they are smart).

As for coding tests - eh. I would rather see code someone has put some time into, that has gone through some refactoring, testing, thought and user feedback. If there is a source repository with a history, then it would be nice to see how the code evolved. That could tell me a lot about how well a person can write/design code, and how deep their understanding is of any frameworks/APIs they used.

I also like to see the docs. If at that point the code (and docs) suck, then I can eliminate them from the candidate pool. What most people come up with off the top of their head in five minutes on a white board, or on paper at an interview stands a good chance of being crap. Coding tests that where you give a person a day or so may suck less - depending on how much time they could devote to it (they may have a day job, kids, be taking five other coding tests, be sick, whatever).

> "perhaps open source experience is only valid if you work on a project that attains some moderate level of critical mass and user base."

Harumph! I'd actually go along with that for the most part, but there *are* very narrow projects out there for very specific niches. We need them too.

For instance, try searching the web for how to develop Flash on Linux. There's maybe four tiny living projects out there, the rest are DOA. But having a complete FOSS toolchain for making Flash apps is honey to me. In fact when I have been blogging about SWFTools and the cool stuff I'm making with it, people are starting to quote me as an authority on the subject. That's right, idiot little me!

Take another example, ReactOS. An open source Windows! Should be big news - hardly anybody on the planet seems to know or care, and they're still piddling along in Alpha versions after 10 years.

Really, I wouldn't rip open source experience out of a resume based on this one anecdote. There's plenty of jobs that even involve working directly with open source software. Companies that make Firefox toolbars and Wordpress plugins, for two examples.

But yeah, walk in saying "ReactOS" or "SWFTools" or "Nethack", I'm sure there's some headhunters whose eyes would glaze over. That's because software in general isn't nearly the glamorous job we all wish it were.

I agree completely with Bruno. I've worked with people who have comp sci degrees, install different OS's, learn new languages, jump on all the latest tech bandwagons, contribute to open source projects. And they are terrible at their jobs, I'm so glad they've moved on to other jobs and I no longer have to correct their work. You're either a great programmer or a mediocre (and in some cases terrible) programmer. When I hire programmers now, I base it solely on coding tests. I never trust resumes or prior experience anymore. Both can be and usually are exaggerated.

You know this really is a shame. One of the reasons I actually got my current job (though not the current position anymore) was because of my contributions to open source. I was able to say I did this that and the other thing, and they literally googled my name to see if it would come up on these projects. When they did show up, it gave them a reason to believe me when I said I could do the job.

You know Jeff, you might tell the person this blog is about to contact these employers again, and have him emphasize that he has the experience and it is demonstratable. Just because a person hasn't done "Exactly" what you are looking for, having a reviewable code base shows perspective employers that you can code, and good coders can be coached and steered. Maybe not all coders, but most coders I know are very happy to learn how to do things better.

It also seems since I didn't read all the comments that the original job seeker is also here. To the job seeker (who seems to have a job now), what I might recommend next time you have to go through this and have to do a code test is ask, "What are you looking for?". Answers might be "time to completion", execution efficiency (coding efficiency and execution efficiency are not necessarily the same thing), readability (good commenting), creativeness, and others.

Just an idea for anyone who has to take a "coding test". Find out what the interviewer wants to see.

Oh my, aren't we pretentious. Also, you rush to judgment pretty quick based over little evidence.

I guess not all the companies and software segments work the same, but my personal experience is that contributing in Free Software projects have opened many job opportunities for me.

When I hire someone I receive between 20 to 40 resumes. I don't look at cover letters, but just at the experience simply because I don't have the time. Based on the experience/skills and what I'm looking for, I call for an in-person interview.
During the interview, open source experience is not relevant because:
1) I don't have the time to dig through god-knows-how-many diffs to find the prospective employee's code.
2) He claims he worked on it, but I can't verify the claim (while with a company I can at least call someone who can lie to me about how wonderful Joe Coder was), plus he's 99.9% inflating his impact on the project.
3) Very often open source projects are frameworks and not concrete solutions, thus not quite what I look for, which usually is people who can hit the ground running.
4) A coding test, in person in front of me, will tell me a whole lot more about how you think and what you do when presented with a problem, than a project out there.

I guess the main reason is #2. I've been lied so much, so often, and so blatlanty, that I don't put much faith in what I'm told.

For me hiring comes down to answering well to some key questions (data structure and caching questions are my favourites), writing code in front of me, and having a personality my team can go along with.

I do have to agree with the others. Saying you worked on an Open Source project won't mean much to corporate grunts. No one cares but even if they did they probably wouldn't believe you.

Especially if you can't code to their satisfaction right in front of them. I think there was a Daily WTF about a guy that went online during the interview to get answers to a coding test...

So! Asking them what they are looking for is akin to asking them what answers they want. Ask for clarification, make sure you understand the problem, then code in your own style and if they like it they like it.

Then again they may just be incompetent and don't want you to get the job because they know they'll be working for you in a few years.

I'm no Linus Torvalds, but I'm high profile enough that I was beating out a congressman and a big name professor at the top of all the search engines for awhile.

I can't get a job operating the computer at Burger King.

That recruiter was probably reviewing hundreds of applications and didn't have time to go through everyone's examples of work. Plus, they were not satisfied with his coding solution on a test. When you have a lot of potential candidates to choose from, you don't loose your time on those who didn't pass the test you gave them, and check their additional coding work they suggest.

I think this case isn't good example of underrating open source experience, but just a poor job interview.

A couple of years ago, I took a year off from working, for personal reasons. When I was ready to get back to work, there were some recruiters who assumed that after a year off, I knew nothing about how to code any more (despite seven years of experience), and was basically starting over at an entry level position. I was glad that they said so up front, so I could avoid wasting my time, and instead I talked to the 20 other recruiters who actually had useful things to say.

There are always going to be idiot recruiters. As long as you can find some of the good ones too, it doesn't matter how many idiots are out there.

There's a simple reason why firms put so much store in 'commercial experience' - basically it means someone else thought you were competent enough to get paid for coding, which assures your potential employers of a certain level of competence. How to get it in the first place though...mmm...

have to agree with what 'bruno' said days back, people who program in their spare time just scream no life, cheesy puffs and tab clear in a darkened room to me, once you're past the undergraduate stage you really have to snap out of that, and you have no choice if you have a family or significant other (or ever want one). If you want me to program, you have to pay me, I've got more enjoyable stuff to do if I'm not.

In most of cases where OpenSource developer is rejected, HR/Job recruitment company are culprit.

It's true, currently the amount of employers who'd check your free-software track record are few and far inbetween.

But, on the flip side of the coin, I believe that within 5 yrs of time, if you haven't worked on free-software for at least 10 yrs, you'll have a hard time landing a job with *any* serious employer.

There's also a vast difference in the general quality of open source software, depending on how high level the language is.
Scripting languages such as java, PHP etc. will never lift your portfolio as much as a programming languages.
Most of the serious free software is written in C (kernel, gnu etc.) and that's where most of the action and qualified code review is happening.

Oy vey....multiple thoughts here:

First - I think we're confusing two issues here:

a) Value of contributing to an open source project
b) Lack of Recent Commercial Experience

His problem is the latter not the former - there are significant differences in the day-to-day workplace culture and expectations between a corporate/consulting position and an academic or public sector enviroment. Specifically: greater focus on results and/or deliverables, more accountability for quality, easier to get fired, adherance to acceptable standards/architecture, better documentation, more competition with peers, stronger engagment from the customer (I'm aware there are probably some snickers out there but you get my drift...any GOOD corporate IT department will be have some of these). His challenge, pure and simple, is to show that he can run with the big dogs and toe the line on quality, efficiency, and teamwork... (incidently, there is probably a converse of this for corporate IT people going into the public sector....to be fair & balanced....)

Unfortunately, contributing to volunteer open-source projects has about as much relevant to proving you can function in a corporate technology organization as being president of the board for your homeowners association has to proving you can be mayor of a city. While both roles involve exercising the same underlying skills, there's a big difference in standards/pressure/margin for error.

The recruiter is just being honest...your counterpoint (that you have used the same technologies in open-source) doesn't refuse her view. Your real issue here is that the company she is working on behalf of wants people with a commercial background...probably because they've experienced the same fit issues I mention above. Speaking as a hiring manager myself...we don't (usually) impose this stuff just for fun - generally speaking, certain backgrounds tend to work out for certain roles and others..."struggle".. which isn't fair to the company, other qualified candidates, and ultimately the applicant (while we all gotta eat, do you really want the stress of "struggling" at work because I hired you for a role that my experience tells me you aren't well prepared for? I don't....it's a slow painful death of the soul).

Second...there is another major red flags in your approach:

If I give you a coding test, I expect to see some solid answers to MY PROBLEM, which should be fairly strongly related to what you will encounter in the daily job. That should also be a very MAJOR signal that I'm not interested in analyzing your open source code which - by the way - I'm not even sure you personally wrote (if these are collaborative projects). Not sure about the rest of you, but it usually takes me about 5 - 10 minutes to understand how another coder is approaching the problem (assuming it's a decent sized piece of work) and figure out their coding/commenting style as well as any unique objects/libraries which they are using. I'm going to invest that time later - before I hire you - and after you prove yourself worthy of my attentions by solving the exact same problem I gave the other four candidates. Bringing up the open source work as a rebuttal to failing the test is ARROGANT...and ultimately burns bridges...

(actually, in my case, you would probably get a piece of my mind about how small time open source projects don't always run with a high level of rigor, admittedly with some significant exceptions)...

So...regarding the first point...as a corporate IT hiring manager, I DO see significant value in open source experience..particularly if you are working on problems and/or using languages that indicate you're smarter than the average bear (major applications, crypto, unique services, early adoption of new technology, LISP, etc.)

But don't expect me to use that in lieu of relevant experience in my space...

Some OSS bashers just don't get it. I've coded OSS for years and every once in a while, I get a call from company "x" or "y" stating that they want to hire me to customize my OSS app to their specific needs, I charge them for my services and in return I earn probably more than selling a "commercial" application, heck for at least 6 years this model fed 5 mouths and was enough to pay for the bills and then some, with the additional benefit of allowing me to be *with* my family and all.

And to the "work 9 to 5 and then forget about programming" drone, I feel sad; this is a passion, an art, there is no "switch" to turn it on or off, I would not want to participate in any project with you, do you like to paint? or play guitar? do you stop doing these things "at 5:00PM sharp"?

Sometimes you need to "live" the OSS freedom to understand it.