How to write up open-source experience when you don’t have any

Around here we like to prove rather than just say that we have skills. One really easy was to do this is by showing off your open-source contributions. If I want to prove to someone I really am a Perl programmer, I have a CPAN repository that demonstrates a whole bunch of different areas I’ve touched, and a GitHub account that shows contributions to other people’s projects too.

Hooray for me, right? But this doesn’t help you at all if you’ve not got any open-source experience already.

First a caveat

I don’t want to be that guy, but it’s worth pointing out before we get to the sneaky tricks, that the best solution here for writing up your open-source experience is to go and get involved in open-source projects.

Submit some patches, bug reports, features suggestions, or whatever to the code you use every day. Got some functions hiding away for solving a problem, and that you always come back to? Pull them together into a coherent whole and release them.

Find out if there’s anything in your work’s code-base that they wouldn’t mind you putting together and releasing. You may find that the senior developers haven’t done it because they simply can’t be bothered — I do some work for a company where we have four or five good libraries that are ready to go, but most of the senior development team are already heavily involved in open-source and don’t have the time to take on new projects to maintain.

However, this would be a pretty pointless article if my solution to writing up non-existent open-source experience was to simply gain some, so with that in mind, let’s move on to other solutions…

Talk about anything you’ve done but haven’t released

Interviewers are looking at your open-source contributions as proof that you’ve got an inherent interest in tech and programming, are exposing yourself to ideas of those that you’ll see purely in the workplace, and genuinely have some of the skills you’re claiming.

You’ll still cover most of those bases if you talk about personal programming projects you’ve completed, and can talk coherently and fluently about challenges and motivations for them. Maybe you never released your iOS app that allows you to scan crossword puzzles from newspapers, but you can still talk on your resume and your interview about challenges you faced getting OpenCV to recognize the outline of the puzzle and extract text. You can still describe what you liked about using Swift (or ObjC) and how it compared to the technologies you use in your day job.

Many developers run their own co-located server, especially now it’s so cheap to get a VPS. What OS is it running? How do you keep it up to date with security patches? Did you turn off password logins with SSH to secure it? Configure virtual hosts with Apache? Mess around with Puppet in case you ever needed to rebuild the machine from scratch? Put WordPress in a container because it’s a security concern? Manually setup the firewall with iptables?

It’s all in scope, it’s all relevant, and you should talk about it! It can’t be independently verified like open-source contributions can, but if you can insert your opinions into the description, talk about the challenges you faced, it’ll look credible, and it can be discussed in interview.

I’d consider collating all of this under “Personal Software Projects” where an “Open-Source Contributions” section might go on your resume.

Talk about anything you’ve learned

Anything you’ve read that was particularly interesting, any online course you’ve taken, or any interesting talks you’ve attended also hit our criteria of:

  • Exposing yourself to new ideas
  • Showing an interest in technology
  • Supporting the skills you’re claiming (if you’ve applied them, anyway)

I’d look favourably on anyone who’d read Seven Languages in Seven Weeks. If it’s mentioned, followed by an idea you took from it and applied, even better! Maybe something like “I recently completed Seven Languages in Seven Weeks and was inspired by Haskell’s typing system to look at introducing strongly-typed JavaScript variants into our work codebase”.

Tech talks also work well for this! “I recently attended a talk on Vagrant at the London Hackspace and used a work Hack Day to build a development image for our main production application”.

The basic structure is: you took the time to seek out a new idea, you were inspired by that new idea, and this either benefited the company you work for or led to further investigation and learning for you. Coursera and friends are full of interesting ideas: “I’ve recently completed ‘An Introduction to Compilers’ on Coursera, and have applied the sections on state machines to building a business rules engine in my latest project”.

All together now

Once you understand why open-source contributions are looked upon so favourably on developer resumes, you can start to highlight related experience that may not actually be open-source contributions to fit the same aims. One more benefit of understanding the process.

Published by


Peter is a former developer and CTO turned recruiter who wants to demystify the recruitment process so that developers can find jobs and get paid more.