You’re putting together your resume to highlight your software development experience. How does it look? What do you put on there? What do you leave out? How do you know you’ve done a good job? Today I’m going to share some of my advice for writing up a resume for programmers.

As always, I’m no expert so take all this “advice” with a big grain of salt. Having spent time on both sides of the hiring process, I’ve been able to identify some things that work and some things that don’t. I suspect that none of this advice will be seen as controversial, as it mostly consists of advice I’ve heard elsewhere and am simply bringing together in one place.

Length

A resume is like a Google search. It’s all about matching keywords, and almost nobody looks past the first page. Recruiters look at your keywords and search for jobs with similar keywords. Hiring managers look at keywords to see if they fit in with the technology stack they’re trying to staff.

A resume should be One Page Long. Yes, this means you. I know you and your type, you think that you have more things to talk about, and every additional detail you can cram in there will make you a more attractive candidate, and you want to be the most attractive candidate possible. More is better, right?

No. Bad programmer. Stop that.

Your resume is all about keywords, and the longer the document is the harder it can be to find relevant terms. Most interviewers won’t look past the first page. Some rushed hiring manager won’t look at the bottom-half of your first page. Length is important, and going longer doesn’t make you look better. It makes you look unfocused, disorganized, unrealistic, and like the rules don’t apply to you.

One small exception, and this probably doesn’t apply to most readers, is that certain types of senior-level people may opt for a longer format if they need to mention many different projects. For example, if you’ve been on many small short-term contracts it is probably necessary to list each one. If you have worked across many projects using different technologies and ideas, you might benefit from listing those out. Keep in mind that this may have the effect of demonstrating versatility but not deep expertise. If your job history just has lots of entries in it, you should consider omitting the ones that are shortest or least relevant (and be prepared to explain why you don’t seem to stay in one place for very long).

Formatting

Your resume should be formatted with bullet points and sentence fragments. It should have lists of projects with the technologies and techniques those projects employed. This is not the time or place for prose or lots of little details.

Don’t say “created websites with a variety of technologies”. List those technologies out so people can see exactly what you have experience with: “Created websites with Python, MongoDB, JavaScript and jQuery”.

For every job you have, formatting more or less wants to be the same:

Title, Company                               StartDate-EndDate
    Brief description, if necessary
    * Bullet points listing individual projects/technologies
    * and individual responsibilities

Use a fancy resume template from the internet if you want, but these few bits of information are what are important: Where, when, for how long, and what you did there. This is all that matters. Hiring managers need to know when you’ve worked with relevant technologies and for how long. This helps to indicate how much knowledge you have and how fresh and current it is.

Important notice: If you are a front-end person like a designer, you might want to take some care to make sure your resume looks nice. If the employer expects you to make nice-looking websites or UIs, your resume should be a little mini-example of your good design sensibility. Make sure that the design is appropriate for the purpose (serious, focused, professional). If you aren’t involved in design, make sure the resume communicates the necessary information in an effective way.

Basic Rules

Here are some of the most important rules for developers of all levels:

  1. It should fill exactly one page, no more and no less.
  2. Do not list anything on your resume that you are not prepared to discuss, in detail, during the interview.
  3. Do not include things that aren’t relevant
  4. Avoid qualifiers like “expert in” or “master of” if you can’t talk about that concept at a high level.

Resume Over Time

Now that we’ve covered the basic rules, let’s look at what you probably need to put on your resume at each stage in your career. As a dramatic over-simplification, there are probably three important stages in your career: junior level, mid-level and senior level.

  • Junior developers have little to no relevant work experience.
  • Mid-level developers probably have a year or more experience, are capable but don’t have lots of individual responsibility, technical leadership or deep expertise. These developers, depending on company and trajectory, probably have beween 1-6 years experience.
  • Senior folks have been doing this stuff for a long time, have expertise, and can be trusted to do big projects themselves with minimum oversight. Senior developers, depending on company and individual skill, probably have more than 6+ years experience.

These are rough guidelines. If you’re not sure exactly where you fall, read all relevant sections below and see what section most accurately describes what your resume needs to hold.

Entry Level

For an entry level resume, your education is probably paramount. List that and make a big production of it: Relevant courses, GPA (if it’s better than about 3.5/4.0), Honors, large projects, independent study and things like that.

List the relevant courses you took. These are probably the high-level major courses only. You don’t want to list gen-ed classes unless it’s something particularly relevant to the position like a foreign language (if the company industry has particular need of that language) or arts (if the job may involve design work).

Internships and open-source projects (You do have some of that on there, right?) are good but probably not as important as your schooling. Your first job is going to involve a lot of learning and training. The employer wants to see that you have the necessary baseline knowledge, so that you stand a good chance of surviving the necessary on-the-job learning that will be expected of you.

If you do have significant open-source experience, feel free to list that prominently as well, but don’t make a mountain out of a mole hill. A few commits to a project, especially a well-known one, are interesting but not extremely impressive. Now, if you have made significant contributions, that’s a different story entirely.

From top to bottom, your resume should have:

  • Some sort of objective statement, one or two sentences long, talking about how you are looking to start your career and what you bring to the table in lieu of actual work experience.
  • Your education: Degrees earned (if any), relevant courses, large projects (especially group projects where you played a significant role), GPA, etc
  • Relevant experience: internships and open-source projects.

If you still have space to fill, list technologies and programming languages with which you have any experience or familiarity. Nothing fancy. Have a heading for “Relevant Skills” and just list them with bullet points. The purpose of this section is just to fill whitespace at the bottom of the page, nothing more.

Mid-Level

Work experience is your most important asset now, so that becomes the star of the show. From top to bottom, your resume should include:

  1. Objective statement showing where you want your career to go from here.
  2. Work experience, highlighting both technology and process. Process includes things like Agile, SCRUM, TDD, etc. Make sure to highlight things for which you had ownership, leadership or responsibility.
  3. Internship or Open Source contributions (if relevant), any professional certifications, or anything else of professional relevance.
  4. School, focusing only on dates and degrees. Leave out GPA. Don’t list individual courses, but do list areas of concentration or particularly big projects, if any are relevant.

Again, if you still have space, list bullet points with individual technology competency. Only list the most important things, and only to fill space.

Senior Level

Work experience is really your only relevant asset here, unless you have a substantial body of open source or extra curricular activities (writing books, publishing papers, technical training or certification, public speaking, etc). Your resume should contain from top to bottom:

  1. A professional summary. One or two sentences telling what you do, how you specialize, and where you are headed.
  2. Work experience, highlighting big projects, key responsibilities, and any expertise. Most recent, most important things go closer to the top.
  3. Professional certifications, open-source projects, publications, etc
  4. Education summary. Just degrees and dates. Nothing else is relevant anymore. Some companies won’t care about education at all at this point, some other companies will require a degree but only care that you graduated or not, no other details matter.

If you still have space, go back and expand on your biggest work projects. At this point you shouldn’t be listing things that aren’t directly related to the jobs you’ve worked.

Overview

The resume serves one purpose: To get you in the door for an interview. Your resume should be a very short, focused overview of who you are as a technology professional. It should contain lots of keywords and make them easy to find. Once you’ve been in for an interview, your live performance there will matter much more than anything written on paper. If you follow some basic guidelines and highlight the important things, your resume should be enough to get you in the door, and that’s all that you need.