Jeff Atwood has an interesting, if somewhat bait-y, post where he asks if open source experience is overrated. To be fair, Jeff has espoused support for open source development in the past and even starts the post re-iterating this position.
If you’re looking to polish your programming chops, what could possibly be better, more job-worthy experience than immersing yourself in a real live open source software project? There are thousands, maybe hundreds of thousands, and a few of them have arguably changed the world.
He then shares details from a personal correspondence, a developer recently undertaking a job search expressing extreme frustration at his open source experience not apparently helping persuade any perspective employers. He culminates with the thought that Jeff uses as his bait-y head line.
One of the reasons I worked so hard on open source projects was to make job interviews easier. By providing prospective employers with large samples of publically available working code, I thought I would give them something more useful to think about than my performance on a particular coding test or whether the acronyms in the job skills matched my “years spent”. I am very aware of the hype behind open source. I’ve heard it, lived it and even spun some of it myself. But sometimes it’s good to take a sobering reality check — is open-source experience overrated?
Jeff certainly didn’t share the entirety of this person’s message but in the parts he does share with us, I fail to see the candidate doing much to actively answer the most important questions a prospective employer should be asking.
In principle, it’s simple. You’re looking for people who are
- Smart, and
- Get things done.
The irony that this advice comes from Joel Spolsky, Atwood’s partner in crime at Stack Overflow should not be lost on you.
As someone who has sat at least as many times on the hiring side of the table as the candidate’s, I have to say that being presented with a large blob of code by a prospect is less than helpful. If I develop specific questions about coding style and competency then having such a work or set of works is indeed quite invaluable. Its mere presence isn’t enough to persuade me of much of anything.
Don’t get me wrong, when I am sitting on the other side of the table, I include a small set of active open source projects as part of my arsenal. But I don’t rely on their existence and availabilty alone. I prepare for any given phone screen or interview by considering how my open source projects, as well as the rest of my skills and experience, are relevant for the position I am pursuing.
I see it as my job as a candidate to be my own best advocate. I have to share truthful, accurate stories about how I am 1. smart and 2. get things done. Open source or proprietary doesn’t really matter. You have to get your foot in the door, spark enough interest until your interlocutor is prepared to look at some bit of specific work that you’ve done. Merely presenting a portfolio of code doesn’t do much in the way to answer either question on its own without the narrative you provide to engage the interviewers interest and convince them your assets are not only applicable but valuable to the specific job requirements.
If you want to include your open source work as enticement, which parts of what you have done demonstrate your smarts? Did you learn something during the development of the code that you did not know before? Have you released multiple versions where you can speak to clear improvements made? Is there a particularly clever or efficient bit you are justifiably proud of?
On the getting things done side, how many people are using your code? How did you handle the inevitable bug reports? Did you yourself use your tool or library on a larger project where it made a decisive difference in that other projects outcome?
These questions aren’t unique to open source experience. They and many more focused questions like them are the sort of mental framing a candidate should prepare for all of their experience. Tools, experiences, open source projects–they are all fodder for your advocacy efforts.
I am also stunned at Jeff’s lack of insight on the typical success ratio of a job seeker, even in a good economy. To be fair, maybe he reserved any more constructive thoughts for a private correspondence. But practically speaking, a candidate has to be prepared to continue applying for positions and advocating themselves until they have offers in hand. Yes, multiple offers. Not to play any games of leverage which I think are foolish and ill advised but to prevent you as a candidate from merely leaping at the first job that comes along. Having more than one offer encourages you to consider each opportunity as a whole.
From snippets Jeff shared, it sounds like there may have been some cultural fit issues that this candidate ran into. I have run afoul of more than one organization that puts too much stock in coding tests or, worse, brain teasers.
One company seemed impressed with my enthusiasm for the job but it was part of their policy to provide coding tests. This seemed perfectly reasonable and I did it by using the first solution I thought about. When I got to the phone interview, the guy spent about five minutes telling me how inefficient my coding solution was and that they were not very impressed.
Did the candidate ask questions up front, such as whether the efficiency of the solution was a concern? Really, though, I am more concerned at the prospective employer’s response. It seems to me to be more of an excuse than a reason. If they genuinely felt that efficiency was the problem, an excellent follow up question would have been to ask the candidate to characterize the solution in terms of big O notation or efficiency in general. If that went well, then an exercise in re-factoring could provide further insight into how a candidate approaches improving their own code. This is how an interviewer gets good information on the candidate’s intelligence and effectiveness.
In my experience, the urge to pontificate is a siren call when on the hiring side of the table. It is heady to show off when you know more than a candidate but that’s missing the point. If this interviewer felt this strongly, this negatively, then it would have only been worth the time to share an in-depth code review if they felt the candidate might have some potential worth mentoring. And only then after exhausting the follow ups I recommended. My advice to the candidate here is that this interviewer isn’t worth the time, not that it is a poor reflection on the candidate’s actual skills and experience.
Better yet, to keep this in the frame of using open source as fuel for self advocacy, did the candidate point out a specific example in his open source work that shows where he was able to address issues of efficiency? Again, asking the interviewer to just review the totality of an open code base doesn’t demonstrate any particular grasp of the issues or questions the interviewer is pursuing.
Open source is no magic bullet. Not a novel idea though in this case perhaps a novel application. Just like a business cannot magically make its business model solvent by adopting open source, a developer isn’t guaranteed an edge by contributing to or starting open source projects.
I remain convinced by Jeff’s original stance, though my conviction long predates any expression of it on his blog. Open source software can provide the benefits he lists. But in any given situation, it is up to the developer to figure out how best to leverage that experience, whether it is with more straightforward tool support or code sharing directly enabled by the open licensing of a project or as in this case indirectly by way of the skills and experience acquired from being able to take the initiative to work in an open collaboration rather than waiting for the right opportunity, and abit of luck, to acquire those through traditional professional development.