FreeSoftwareOnResumes:Writing: Difference between revisions

This document explains best practice for putting open source experience on your resumé. It is primarily aimed at college students or people who have not yet had a first job in software.  

If you are a college student, your primary "experience" is education. So list it first and prominently, and only then open source or other experience. Most employers are looking for pedigree first. (Sad and terrible perhaps, but true.)

# real work you can point to, and get <b>references</b> for.

The way you present your skills and yourself to recruiters and HR staff is not necessarily the way you'd present them to your peers. You may end up saying things that would sound arrogant, weird or anally precise in other contexts. That's OK.

The first person who reviews your resumé will be someone in HR (Human Resources). They may well be less technical, and will focus on keywords. So when you are putting your resumé together, it's useful to list out relevant skills, even if you don't think of them as "skills". What source control systems have you used? What IDEs? What languages are you familiar with? Give your proficiency with each. It helps to tailor the list for whatever job you are applying for; it should be apparent from the job description whether to emphasize that you're good with git or with mercurial. Give your skills a heading that makes sense to someone who plugs terms into Wikipedia (e.g. "Version Control").  

* Able to persuade people to do what you want when they don't have to

Most Open Source projects don't give people job titles. However, a job title is just a two or three word summary of what your job is. So it may be worth discussing with the project lead what appropriate and accurate title you could use when listing your experience on that project. "Contributor" sounds like you just hung out ("I fixed a typo in the documentation - that's a contribution"). Avoid the word "Volunteer" entirely. Something like "QA Engineer" is better. Suggest a title to the project lead, and see what he says. Position the title so it's relevant to the job you are applying for.

People are really obsessed with numbers. The more lines of code contributed, packages maintained, and releases touched you can list, the more impressed HR will be. E.g.:

These are quantifiable things that a college student has done, which is more than you usually see. This is much better than talking about "the cool lab project I did" which no-one can look at.

If you've already done software work well, with peer accolades, that will make companies more comfortable hiring you than an untested person. Most project leads will be happy to provide a reference or endorsement, assuming your work has been good. However, full references on resumés are actually clutter. If you are obtaining endorsements or references, it's much better to get them put into a business social networking tool like LinkedIn or xing. You can then reuse them in the future, and they are automatically authenticated. In the resumé itself, you should instead reference the relevant website, and use the space to excite the potential employer with descriptions of what you actually did.  

 

After HR has seen your resumé, what happens next depends on the firm. Your CV may be passed to a hiring manager for review. Hopefully, you are dealing with a hiring manager who is not a PHB. If they are a PHB, they will do the same thing as the HR person did, and look for keywords. So the same features of your resumé will appeal to them.  

Alternatively, the next stop may be with someone from the technical team, or a non-PHB hiring manager. They will dive deeply into your experience. They will care not that you have just used version control, but that it was git, mercurial or subversion. They will also care about what you've done specifically. They'll read the issue tracker when you landed the mission critical patch. They'll go to your website and see the CV online and click all the links, and confirm that you are indeed mentioned in the release notes for the last six releases, as you claimed.

Your first interview will typically be by phone. You will be asked about everything you list on the CV, so don't over-inflate your experience. Be ready to talk about areas of strength, and why you are passionate about those areas. Passion is important. Companies would rather hire someone who loves testing and breaking things rather than someone who is laid back about it.

An interview is just as much about you trying to work out whether this opportunity/job/career path is for you, as it is for them to assess you. So come prepared with questions about the work and the environment so you know if and when you accept, you'll be doing something you are excited about. Useful questions to ask:

* What is your company's view on employers contributing to OSS? Is it done on my own time or company time?

<small>Document by Gervase Markham, with thanks to Leslie Hawthorn for most of the ideas and and Zak Greant for kicking things off.</small>