What I want (and don’t want) to see on your software engineering resume
Asking what should be on a resume is one of the most common questions I hear. I’ve seen thousands of resumes, interviewed hundreds, and hired or helped hire dozens, so I’ll describe exactly what I’m looking for when I’m presented with your application.
Resume or CV?
In the US, documents describing your qualifications and work history are called résumés. In the EU and elsewhere known as a curriculum vitae, or CV. Either way, the purpose is the same: a relatively short document which summarizes your skills, work history, education, contact information, and anything else that can be used to estimate your “fit” for a given position.
I’m based in the US, so I’ll give a US-centric view of resumes, but I’ll attempt to point out differences with CVs in areas in which I’m familiar.
Why do I need one?
A resume is required as part of almost every job application. If you see a job listing online and click “Apply,” the next page will almost certainly ask you for your contact information and a resume file. Yes, getting a job is a highly-subjective process that involves interviewing and negotiation, but providing an employer with a resume is the standard first step before any of that can happen.
The resume serves to get your foot in the door. After a job listing is published (you can read how job listings are created here), a recruiter or hiring manager will be inundated with applications, and this person (or people) will compare your resume with all of the others, so it’s vital that you provide the same kind of document to put you on an even playing field with everyone else.
How long should it be?
Do your best to keep it to a single page. A second page is acceptable, but anything past a second page will probably be ignored.
Recruiters and hiring managers and other decision makers are usually looking at many resumes at once, so it’s important to put all of your best information up front, above the fold.
You can ignore this rule if you’re in academia, where all of your previous work and publications are expected to be listed out.
What format should it be in?
PDF, please. Dealing with anything else is a hassle, and Word docs and Google Docs links will just be converted to PDFs anyway. Plain text is hard to read when printed out. If the employer is using a decent applicant tracking system, it probably handles PDFs just fine.
Do I need a cover letter?
My suggestion is that, if the application process or job listing asks you for one, include it. If you aren’t prompted or asked for a cover letter, don’t bother. For software engineers, nobody really pays attention to them anyway.
You might be able to get some extra leverage up front by boasting about how excited you are about the company. But you can always make up for that by sounding excited after the interview.
If you need to write one, keep it short (2–3 paragraphs). Mention how you heard about the company and the opening, and mention how your specific skills and experience will be a good fit for them.
I’ve never made a resume. Where do I start?
A guide to resume structure
I want to see the following things on a resume, in order:
- Contact information
- Work Experience
- Projects (if notable or you don’t have much work experience)
- Any other awards or interesting things to help you stand out
I’ll expand on each of these below.
Please give me, at the very least, your name, email address and phone number. If you use a nickname, express that somehow, maybe using quotes: James “Buckeye” Fisher.
An exact mailing address probably isn’t necessary since we live in the digital age, but it might be useful to list the city, state and country where you currently live so an employer might know ahead of time whether they will need to offer a relocation bonus.
Do include any profile URLs you think are relevant, such as your GitHub profile or LinkedIn. Including a GitHub link (or equivalent) at the top is great because I’ll immediately click on it and start looking at your code.
Do not include a picture of yourself. This is much more common with CVs outside the US. Adding a picture only lessens your chance of success due to potential bias from one or more of the resume reviewers or interviewers.
Listing technologies you’re familiar with is useful for a handful of reasons:
- It gives me an instant overview of the breadth of your computing background and a birds-eye view of whether you’ll be a fit for the role.
- You’ll pass any human or software filters that are looking for the keywords we want.
Do include, in order of familiarity, your preferred programming languages, frameworks, operating systems, and any other software you care to mention or think might be an interesting icebreaker (like Adobe After Effects or Blender 3D).
Do customize this list of skills (and everything else on the resume, for that matter) to the job description. If the job is for a Ruby position, list Ruby first in the skills, regardless of how well you know it. You want to make the person reviewing your resume think, “Oh, good! This is what we’re looking for.”
Do not include anything you don’t want to be asked about in an interview. Anything you put on a resume is fair game. If you put MIPS assembly on there because you took a course in college years ago, I’m going to ask you about it.
Do not list “skill ratings” from sites that provide them. There are sites out there that will certify you as “five stars” in things like React or jQuery. These rankings are meaningless for the same reason as bogus certifications above. (This does not include your rank on StackOverflow or TopCoder or HackerRank, since those are noteworthy talking points despite being not that meaningful.)
Do not list Microsoft Word. Everybody knows how to use Microsoft Word.
This is the meaty part of the resume, hopefully. Work experience is important because it describes things you’ve been paid to do. If you don’t have a lot of work experience then you’ll have to fill space with projects (see below).
Each work experience should list the employer name, when you worked there, and 2–5 solid bullet points of what you accomplished.
Wording is important here. Use words that convey action and describe specific work, like developed, built out, created, delivered, oversaw, managed, shipped, designed, architected, led.
Do attempt to quantify the business impact of your work. If the software you built helped save time, whose time did it save, and how much? If you built and shipped a feature, how many users used it, and by how much did it increase revenue? These aren’t always easy to answer, but if you can, demonstrate that you understand that your work is about much more than checking in lines to source control.
Do brag about yourself. Yes, everything’s a team effort, but you helped build, test, and deploy that feature, so tell me how much of a good job you did. You stayed up until 3am to fix that broken server, so tell me about it. You found the root cause of a bug that nobody else could, and that’s important!
Do not lie. Lying can get your foot in the door, but in the software engineering industry, liars are quickly uncovered and dealt with.
If you don’t have a lot of work experience, you’ll need to fill some space with projects. Work experience needs to be impressive, but projects need to be interesting.
If you’re listing projects, I want to know not only what they are but why you built them. Good projects are ones where you were solving a problem you had. The best projects are where you solved a problem you and other people were having—sometimes these even turn into good business ideas. No matter the project, tell me about the hard parts you overcame and any other challenges you encountered.
Do provide links to the projects so I can click on them and poke around. Make sure that I actually know what it is, what it does, and what’s the most interesting thing to know about it.
Do provide links to the source code if possible.
This section is usually short, but required unless you’re self-taught. If you have a college degree, list the years and your degree here. If you graduated from a bootcamp, mention which one and when you attended. If you received any awards while at school, list them too. Include notable clubs and other accomplishments.
Do list your GPA if it was good. If not, omit it. (Why would a two-star restaurant advertise themselves as having two stars?)
This is the fun part. Put a line or two of things that people might find interesting about you, like notable extracurricular accomplishments or cool hobbies. You’re going to be in a room with people that don’t know you, and these little tidbits turn into good icebreakers that can get the conversation rolling.
Do not list languages you speak unless the job description calls for it. Listing your languages can be a source of bias that works against you.