View source for FreeSoftwareOnResumes:Writing

=How To Put Free Software Experience On Your Resumé=

This document recommends best practice for putting free software<sup><small>0</small></sup> 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 list free software experience. Employers tend to be looking for good educational pedigree first (sad, maybe, but true).

Having said that, it's good to participate in free software development because (among many other reasons) it will lead to further opportunities. Experience starts to trump college the older you get. After your first job or two, people care much less about your college grades. (Hopefully this will give you a sense of perspective about them when exams are looming.)

Unless you are fortunate enough to be applying for a job working on the same free software project you contribute to, the primary value of your free software experience to an employer is:

# acquired <b>skills</b> using a set of tools;
# <b>experience</b> of real-world development;
# real work you can point to, and get <b>references</b> for;
# a public record of your ability to work as part of a distributed team.

==Skills==

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 overly precise in other contexts. That's OK.

In larger organizations, it is likely that the first person to review your resumé will be someone in HR (Human Resources). HR staff may not be intimately familiar with the skills related to the position you are applying for and may not be able to infer that, for example, having Mercurial experience means that you have experience with revision control systems. 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"). 

Here are some skills you may well have picked up while working on free software which you may not have thought of adding:

* Experienced at talking to people from different countries and cultures
* Ability to work with and motivate volunteers 
* Written real-world, long-term-maintainable software as part of a globally distributed team

==Experience==

There are things you can do even while you are contributing to increase the usefulness of your contribution in helping you get a job. For example, make sure your contribution is documented somewhere so you can point potential employers, HR people, or technical reviewers to a full description of what you did. For example, you could say "I QAed 7 packages according to these guidelines", and then point to the guidelines. You get bonus points for documenting your own processes and work because it shows you can do documentation.

Statistics on your contributions can help lend additional context and credibility to your credentials. The more lines of code contributed, packages maintained, and releases touched you can list, the more impressed HR will be. It may also be appropriate to list some statistics about the project and the impact of your work.

E.g.:

* Contributed N hours of testing...
* QAed N packages for release X...
* Project Foo is used by 50,000 software developers and organizations, such as Sun and IBM (who has used Foo as the base of their Foo+Bar project.)

These are quantifiable things that can give you a significant edge over others who can only list educational credentials. This is much better than talking about "the cool lab project I did" which no-one can look at.

You should have a "Top Accomplishment" section for each position held, which tells a short story about something great that you did in that position. E.g. explain that you tracked down and fixed a critical bug which was blocking a release, and give a link to the bug report itself.

Resumes typically assign a job title to each chunk of relevant experience. Unfortunately, most free software projects don't give people job titles. However, a job title is just a two or three word summary of what your role is, which is not something intrinsically bad. 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. Position the title so it's credible and relevant to the job you are applying for. Shy away from vague terms like "volunteer" where more specific and credible terms (like "developer" or "author") are available, and get specific where appropriate - i.e., don't just say "volunteer", say "QA volunteer" or better (if accurate) "QA core team member". 

A key aspect of the free software world is that people's contributions are not judged based on whether they are paid for them or not. However, not everyone reading your resumé will understand that, and may erroneously think less of positions which are voluntary. This is another reason to avoid words like "volunteer" or even "contributor" in favour of more specific terms.

==References==

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 [http://linkedin.com/ LinkedIn] or [http://xing.com/ Xing]. You can then reuse the references in the future, and potential employers can validate their credibility. In the resumé itself, you should instead reference the relevant website, and instead use the space to excite the potential employer with descriptions of what you actually did. 

==The Hiring Process==

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 has expertise relevant to your position. If they do not, they will likely do the same thing as the HR person did, and look for keywords. So the same features of your resumé will appeal to them. 

If the hiring manager is technically savvy (or when it gets to a member of the technical team to review), they will dive deeply into your experience. They will care not just that you have just used version control, but that it was git, Mercurial or Subversion. They'll read entry in the project's 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.

If they find you've written the truth and they like what you've written, your name may be put forward for interview. The goal of your resumé is to persuade the company to interview you. Don't put anything on it which doesn't help achieve that.

==Interviews==

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 seems to be just looking for a salary.

An interview serves two purposes. Your potential employer has an opportunity to assess you, and you have an opportunity to work out whether this job is right for 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 FLOSS? Is it done on my own time or company time? 
* Will continuing to contribute to FLOSS during employment cause a problem?

It is much, much easier to do this during the interview than on your first day, and it shows someone who understands OSS that you know about and care about making a significant ongoing contribution, and being part of the community. Asking these questions actually helps sell your skills. You are a fun and engaging human being to work with because you are excited about what you are doing.

==General Advice==

People will review your resumé on paper, so make sure your CV is something which is useful without being able to click links. Put a URL to the hyperlinked version on the resumé. It's worth tracking your analytics - these will tell you if your CV is interesting to employers. If no-one's looking, it's not well-targetted, or there's a global economic crisis.

Also, when job hunting, you may have better luck looking in places that value free software job experience, such as the Free Software Foundation's [http://fsf.org/jobs job listing's page]. 

Best of luck!

==Examples==

This section will contain sample listings to help you get started

===PHP Volunteer===
...

===Bug Hunter===
...

===Release Manager===
...

===Project Lead===
...

<hr>

[0] Or open source. 

<small>Document by Gervase Markham with edits by Zak Greant and Luis Villa. Thanks to Leslie Hawthorn for many of the ideas.</small>