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:

0. Look at the pile of thirty to fifty resumes and sigh.
1. 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?
2. 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.)
3. Put the ones with red flags that make you hesitate on the bottom of the pile.
4. 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.
5. 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.

Your resume will consist of:

• Contact information
• Professional experience
• Education
• Any professional books and peer reviewed publications

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. billpjones377@gmail.com is bland. sexkitten1069@gmail.com is not okay. blackwarlock5@outlook.com 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.
2018—present

• Thing you did.
• Other thing you did.
• Yet another thing you did.

Site reliability engineer, Bancroft GmbH
2016—2018

• Thing you accomplished.
• Imporant thing you did.

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:

• Why was the project done? What preconditions led the company, and you, to undertake this?
• What was done? Give a one or two phrase summary of the technical work. Make sure you work in the keywords about what languages, databases, etc. that the project used…provided you’re comfortable being grilled on those systems during an interview.
• What Impact did the project have? What revenue did it enable? What costs did it reduce? What risks did it mitigate? You needn’t detail everything. Pick a representative measure. If I tell you I worked with six ton herbivores, your mind will fill in something roughly elephant sized without me telling you that it’s twelve feet at the shoulder. You also may not be able to publish some details about your current employer or for clandestine past employers like the CIA. In such cases, don’t violate their secrecy.

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.

Education

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

mkwhittaker@outlook.com
(123) 456-7890
http://github.com/mariannaw/

Professional Experience

Software engineer, XYZ Systems, Inc.
2018—present

• After unexpected spikes in cloud billing, built an automatic auditing system in Python to find unused AWS resources, reducing the company’s AWS bill by 33%.
• Led a five person team to replace the company’s legacy portfolio management system, used by all projects in the company, with a Java and PostgreSQL based system after all support ended for the previous system’s platform.

Site reliability engineer, Bancroft GmbH
2016—2018

• Replaced a mishmash of several thousand Linux systems run by fifteen groups with a single infrastructure on CentOS managed by Chef, getting rid of fifteen different sets of shell scripts, READMEs, and undocumented processes in favor of one automated configuration system.
• With another engineer and an intern wrote a web based capacity request and management system in Python, Flask, and PostgreSQL to replaced individual departments ordering servers. Managed a buffer of servers, reducing average time to get capacity from two weeks to half an hour.

Education

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:

• She’s saved someone a bunch of money on their cloud bill. If she can pull off that trick again, that pays for a lot of her salary right there.
• She’s led teams on critical projects, and understands what makes a project critical.
• She understands that rewriting a system requires some justification…and that all support vanishing for its platform is justification.
• She’s worked with thousands of servers at a time.
• She’s done some capacity planning and management.
• She got groups of people to give up their local mishmash, so she must have some political savvy, and she made sure their lives were better for giving up that control.

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.

« Home