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.
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?
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.
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.
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.
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.
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
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.
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.
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.
