Writing a good resume

Status: Finished
Confidence: Very likely

I get asked for career advice by a lot of programmers, and one of the things we inevitably do is rewrite their resume. It’s basically the same fixes every time.

Note: This advice is largely focused on the USA and Canada. Resumes/CVs are different elsewhere in the world. A lot of the details may still apply, but you’ll have to translate them to your country’s norms.

When you apply for a job and submit a resume, it goes into a pile. For when you find yourself on the receiving end of that pile, here’s how you process it:

  1. Look at the pile of thirty to fifty resumes and sigh.
  2. Throw away any resumes with terrible spelling or grammar. If they can’t be bothered to proofread or get someone else to proofread their resume, they obviously aren’t very serious about this, so why would you waste your time on them?
  3. Throw away any resumes that are obviously unqualified. If you’re looking for a tech lead, you’re not going to bother with new college grads. If you’re hiring for a cybersecurity role that requires a US citizen, you’re not going to bother with someone in Bangladesh whose name is Bangladeshi and whose entire employment history is in Bangladesh.
    (At this point at least half the pile is in the garbage can.)
  4. Put the ones with red flags that make you hesitate on the bottom of the pile.
  5. Sort the ones who have produced results for previous employers to the front. The best indicator of someone producing results for you is that they have done so for other people.
  6. Pick out the top three to five and talk to them. Shove the rest in a drawer in case none of the top three to five pan out.

Obviously you want to be in those top three to five. Let’s talk about how.

Note: There are rare people for whom what follows doesn’t produce an adequate resume. They tend to be those that have changed careers several times, had nontraditional educations, or spent years outside the workforce but still exercising their skills.

If you got a degree in a technical field and have had a job or internship, this advice will probably work for you. If you go through this advice and end up with a resume that your colleagues (not you!) look at and say, “This doesn’t show what you can do at all,” feel free to email me. Maybe we can come up with something for you.

Your resume will consist of:

If you have less than ten years of experience, try to keep it to one page. If you have more, try to keep it to two pages.

And don’t lie! I feel like I shouldn’t have to say that, but experience tells me that some people need to be told: don’t lie on your resume.

Before we talk about how to write each of these, let’s talk about some commonly recommended things that are not in that list.

Don’t: Career summary

College career counselors often advise you to write a paragraph summarizing “the professional you” and what you’re looking for. That’s a useful exercise. But it’s for you, a tool for comparing positions to what you do and what you want.

Don’t put it in your resume. The person reviewing your resume doesn’t care what you’re looking for. They only care if you can fill the hole in their organization. Likewise, the description of your professional self is at best trite and wastes the reviewer’s time or at worst makes them think that octagonal you isn’t going to fit into their triangular organizational hole. This section can only produce red flags. Don’t sabotage yourself.
Don’t: Skills list

It’s tempting to list the programming languages, operating systems, and databases that you’re conversant with. But this is the wrong place to do it. If someone puts Java on this list, does that mean they once read a post about it? That they did a side project in it? That they deployed and maintained a hundred thousand line application with a team of four and suffered through tracking down dangling references that were causing allocated memory to grow steadily on the running system until it OOMed every night?

You might be tempted to break the list up into headings like “Expert” and “Learning.” This makes your situation worse, especially when you invoke the word “expert.” When someone says expert, someone competent with the topic will expect to descend into the depths of that subject with them and learn something. For example, when I see someone say they’re expert in Python, I expect them to be able to work with asyncio and explain how its event loop works; use Cython to optimize inner loops; do metaclass programming; and use reflection to rewrite functions in the running system. You can imagine my reaction when someone claims to be a Python expert and doesn’t know what a generator is. (That is not a made up example.)

The right place for these keywords is in your professional experience. You can easily slip in whether a project was in Java or Python. If you produced results that depended heavily on your ability to wrangle PostgreSQL, it will be easy to get the word “PostgreSQL” in there. And it tells someone reviewing your resume that you have used those skills professionally, that is, someone else was willing to pay you for your skills, so they must be at least somewhat okay.
Don’t: References
Don’t list your references on your resume. If someone wants to talk to your references, they can ask you for them. And don’t say “References available upon request.” Everyone assumes that you will be able to provide references upon request.

With that out of the way, let’s talk about what to do.

Contact information

Your resume starts with your name, your email address, your phone number, and any professional portfolios you may have.

Your name
Write it large by itself on the first line of your resume.
Your email address
Absolutely do not use your email address at your current employer! That will get your resume put straight in the trash. Use a bland address. is bland. is not okay. is fine for your gaming guild, but don’t use it on your resume. Stick to some variation on your name unless you have a stable, inoffensive online handle that all your friends and colleagues would recognize. No one would blink at Randall Munroe using xkcd. I use madhadron the same way, but I’ve been madhadron for well over a decade.
Your phone number
Include your area code. Include a country code if you’re outside the country where you’re applying for a job.
Professional portfolios
The first question I have about any programmer I’m looking to hire is, “Can this person write code?” The answer is “no” disturbingly often. If you have a GitHub account with a couple of projects that you don’t find embarassing, put the link here. Being able to see a commit history of a decent program being developed reassures me that this person can write code and didn’t copy and paste this from a book. It lifts you up in the pile surprisingly fast.

Professional experience

List your jobs most recent to earliest. For each, list the company, your job title, and the dates of employment. After that write a few bullet points describing what you accomplished in that job. It will end up looking something like this:

Software engineer, XYZ Systems, Inc.

Site reliability engineer, Bancroft GmbH

If you were promoted through levels of a job at a company, list the most senior level you achieved. If you transferred to a very different job (UX designer to software engineer or salesman to software engineer), list them as separate jobs with separate headings.

Now, what do you write for those bullet points? Obviously be concise and accurate, but too often I see a bullet point like “figured out a legacy system to add missing components on a tight timeline.” When someone says “on a tight timeline,” was it the CEO’s nephew who was managing the project being an ass and setting unreasonable deadlines or had a judge ordered that some protections be put in place by some date or everyone involved was going to jail for contempt of court?

Such phrases are also a great time to work in your skills. “Legacy system” can easily become “legacy Java system” or “legacy Ruby system.” But be careful: if you worked on the JavaScript frontend and wrote three lines of the Java backend, you might want to leave Java out of it. Any technical detail like this that you mention on your resume is fair game for an interviewer to grill you on.

Or consider something like “Drove adoption of modern web technologies like Python, Django, and responsive design.” What actually happened here? Was it a one man team reading up on Django and porting their hobby project? Or was a company’s operations dependent on a homegrown, legacy web framework understood only by one old guy who was coasting into retirement?

So for each bullet point, you should have three things:

If you’re not accustomed to thinking of the business context and impact of your work then you may feel adrift figuring out the why and impact, and may question why you should bother. Remember, the person reviewing your resume is looking for someone who has produced results in the past. The code you wrote isn’t a result. The effect it had is. And if the person reviewing your resume isn’t technical (as sometimes happens), or has a very different technical background than you, your description of technical details will be so much nonsense. But if they’re reviewing resumes, they will understand business impact.

Finally, put in all your experience since you began your professional career. I’ve heard people advised to avoid ageism by not putting in all their experience, and even leaving off the years they got their degrees. If a company is going to treat you poorly because you’re not in your twenties, you don’t want to work for them. Put in all the dates and let them filter themselves out for you.


Don’t mention anything below an associates degree. List your degrees from most recent to earliest. For each degree list the degree, the school, and the year it was granted. If you’re finishing up a degree, list the expected year you will finish with “expected” before it. When I was still in graduate school, I would have written

PhD Biology, The Rockefeller University, expected 2010
Bachelors of Physics and Mathematics, University of Virginia, 2005

They threw me out of graduate school with a masters degree, so I now write

Masters of Biology, The Rockefeller University, 2009
Bachelors of Physics and Mathematics, University of Virginia, 2005

If you have certifications or other special training relevant to the position that a reviewer who knows the field would recognize, add it in chronologically. If I were applying to a job involving microscopes, such as biological image capture software or some kind of optical design, I would add

Masters of Biology, The Rockefeller University, 2009
Analytical and Quantitative Light Microscopy, Woods Hole Marine Biological Laboratory, 2007
Bachelors of Physics and Mathematics, University of Virginia, 2005

Any microscopist will recognize this course. No one else would, and I don’t include it on my resume anymore because I’m far from microscopy. Similarly, if you have a Cisco certification or two you would certainly add that to any resume for a job where you might be handling networking hardware. If you were applying for a UX designer position at a design agency, you would probably omit it.

Books and publications

If you haven’t written a book or published a paper, don’t worry. Most people haven’t. Just ignore this section and move along.

People are unreasonably impressed with books and papers in peer reviewed journals. Take advantage of the cachet attached to them. If you have published a book on programming or something related to it, list it. If you have peer reviewed publications in math, engineering, physical science, or social science, list them. The person reviewing your resume is looking for evidence of past results, and these are gold stamped evidence that you managed to do something.

On the other hand, don’t list the novel you wrote, your collection of poetry, or peer reviewed publications in postmodern critical theory. Most people in software perceive these as too distant to be evidence that you will produce results for them in a programming job. Does this reek of snobbery by a community that doesn’t know much about poetry? Probably, but vanishing to the bottom of a stack of resumes is not an effective way to tilt at that windmill.

Putting it together

So what does all that look like when we put it together? Here’s a fictional example:

Maria Whittaker
(123) 456-7890

Professional Experience

Software engineer, XYZ Systems, Inc.

Site reliability engineer, Bancroft GmbH


Bachelors in Computer Science and Music, University Southern North Dakota at Hoople, 2015

So how does a reviewer read this? The header has exactly the information needed to contact Maria, plus a link to her GitHub profile. There is a two minute digression while the reviewer checks for code samples. Oh, thank heavens, she can write code.

Then the professional experience. As the reviewer reads through, they immediately assemble a list of technical skills (Python, Java, PostgreSQL, Flask, AWS, CentOS, and Chef), and has proof that she has used them in professional practice. The reviewer also picks up some other important facts:

Imagine listing those as bullet points on the resume. How do you write “politically savvy and able to get people to change their ways for their own good” on a resume without sounding either clueless or sociopathic? And why would anyone believe you if you did?

The reviewer then moves on to education. She has a university degree in computer science, so hopefully she knows not to sort a linked list in place. Oh, and music, how nice. Maybe she’ll be able to carry on a conversation with a non-programmer. U of SND at H is hardly a powerhouse, but whatever. If she can cut our cloud bill by 33%, I’m sold. Let’s bring her in to talk to her.