Last week I published The Worst Developer Résumé in the World, which resulted in three things.
- We are not alone – The article resonated with many hiring managers and recruiters who immediately recognized this style of résumé. We’re forming a support group.
- RIP Inbox – Readers wondered “Is that my résumé?“, with many reaching out to me or my résumé review/writing side project (Résumé Raiders – shameless plug) for a personal inspection. Some résumés were good. I had to open some reviews with “Are you sitting down? Because you might want to sit down…“.
- Thanks…but where is the rest?– A handul of readers asked for details on best practices and tips for résumé writing. “You told us what not to do, now tell us what to do.” OK, I’ll do that.
WARNING: Keep in mind that entire books have been written on résumé writing, which I’m also considering as a future project. I dedicated a full 20 page chapter to résumés in my 2013 ebook, so a few hundred words is only going to scratch the surface of what it takes to craft a résumé that gets results (interviews).
That said, here are some best practices for a good résumé.
A Short, Detailed Summary or Profile
In my opinion, this is the most important piece of a résumé and the section most often overlooked by job seekers.
Why? There are two simple reasons you need a good Summary.
1. Your résumé’s audience. We must assume a human will read your résumé at some point, and we (unfortunately) must also assume that the human is not highly-qualified to assess your background. At many companies the reader will be an HR or recruiting professional who may know little about technology. Startups too small to have dedicated recruiting/HR personnel use administrative or operations staff to review incoming résumés, as dev time is too valuable.
Do you want to miss out on a great job because the résumé screener was an accountant unable to decipher that you have the required five years of Python experience? Or because the reader didn’t understand that the “J” in J2EE is Java? Make it easy for them, which in turnbenefits you.
2. It may be all you need. A well-written Summary can be the only thing a reviewer needs to read before passing your résumé to the next step. In those rare instances where I receive a résumé leading off with a descriptive Summary that includes the skills and experience level we are seeking, I can immediately reply “I like your background. Let’s talk!“. I’ll read the full résumé later as I prepare for our phone conversation, but the powerful Summary got an immediate “Yes” answer from me. The résumé’s purpose is to try and start a conversation, and a Summary alone can do that.
How? A Summary should be written in a way that leaves the reader little room to misinterpret who you are and what you can do/have done. It should be no more than a few sentences. The biggest Summary mistakes, which were detailed in the previous post, are ones that go way too long (and cease to be summaries) or those that contain useless, homogenized, non-descript content.
A Summary that reads “Passionate software engineer with excellent communication / interpersonal skills dedicated to writing elegant code” sounds nice and might be someone I want to talk to, but says nothing about qualifications. Does this Summary make it any easier for the reader to say “yes” to you? No, it doesn’t.
A quick aside: And while we’re talking about self-assessments of communication skills and interpersonal skills on résumés, do you think any hiring manager in history has said, “Did you see this résumé Frank? Says here that Ms. Thomas has excellent communication skills. VERRRRRY INTERESTING… Get her in for an interview at once!” No. Don’t waste this space with self-assessments that every résumé on earth also uses. Show me (don’t tell me) your written communication skills by writing a decent résumé, and we’ll cover speaking in an interview.
Back to the story…
How about “Accomplished software engineer with seven years of experience building SaaS products using a range of technologies including Java, Python, and JavaScript with multiple frameworks.” This quantifies experience and includes more detail on at least some skills that might be required (or requested) for the role.
If you’re thinking “but DAVE, the job spec listed like 50 languages and tools”, let me stop you there. The Summary isn’t the place to test out your ATS-gaming SEO skills. It’s an overview, like a quick plot synopsis for a movie on IMDB. It’s not meant to give every detail and spoiler.
Realistic Skills in a Digestible Format
Why? Long laundry lists of skills gives the reader a few impressions of the applicant. First, we hear the theme song to our favorite game show – let’s play Buzzword Bingo, Résumé Edition!
Recruiters are often accused of just matching keywords, which is a fair assessment at least for the minimum requirements of an initial résumé screening. Development managers are likely to start with the same method. A suitable candidate needs relevant skills and accomplishments. Has this candidate done anything relevant to our job opening? That determination entails scanning for certain required technologies, experiences, etc.
A long list raises the question as to how much the candidate actually knows these technologies. The barometer for experienced professionals is usually to include something you’ve used (at home or work) enough to answer some questions. When someone posts what is likely an impossible list, the reader may get a sense of some dishonesty which could be verified in a conversation.
The digestible format is also important. If recruiters are playing Buzzword Bingo, they need to know which columns and rows to look in to find their desired words. Again, make it easy for the recruiter in order to maximize your own positive outcomes.
How? Keep the list to a reasonable size based on your overall experience, and remember that listing outdated skills may do more harm than good. If you are now doing Go and Node.js work, listing all the technologies from your days cranking on AS400s might not be a good use of space. You don’t need to be an expert to list something, but show some restraint.
Separate the skills into a few sections. Common categories might be Languages and Platforms, Frameworks, Databases, Operating Systems, and perhaps a catchall like Tools orOther. If you find yourself creating categories for just one or two skill listings (e.g. IDEs: Eclipse, NetBeans), you run the risk of adding unnecessary length to the document and might be better served with using an Other section.
Clearly List and Bullet Accomplishments, Ideally Quantified
Many résumés use the Experience section to bullet multiple responsibilities instead of detailing specific accomplishments. It’s not always easy to point to accomplishments, but it’s important to try.
Why? The reader wants to know what you have done, that you can communicate what you have done, and (most importantly to some managers) that you understand how your accomplishments positively impacted the business. Writing about accomplishments also gives you the opportunity to influence your interview, as projects that are on the résumé are infinitely more likely to be discussed than projects you don’t list.
How? It’s best to list responsibilities before accomplishments, with the responsibilities written in paragraph form and accomplishments bulleted. Just below the employer, title, and dates, you’ll have a few sentences you may use to describe the company’s business (if unknown to most) and how your role helps the business (usually entails either saving the company’s money or making the company money).
Bulleted accomplishments should list your role, some details on the technology used to solve the problem, and outcomes. Quantifying details such as dollars saved, revenue generated, or performance improvement metrics are a nice touch when possible. Accomplishments can be both individual or as part of a team, and it’s important to differentiate so you don’t accidentally claim too much credit.
Trim the Fat, and Optimize For Relevance
Why? There are a few reasons for résumés to be kept as short as possible while still covering the necessary content. First is the signal-to-noise problem, where relevant and impressive accomplishments get lost in a sea of useless bullets. Second, a long résumé intimidates a reader, which is another reason for a lazy recruiter to hit delete. When you see a résumé is seven pages, you may look for reasons to stop reading it on page one or two. Lastly, a long résumé with irrelvant content makes it appear that the writer is overestimating the value of a past accomplishment. Hiring managers mostly want to know what you can do today, not what you did in the 90’s.
How? Most of us can safely eliminate details on jobs from 10+ years ago, as they are usually less relevant to today’s work. Your job title and employer for early jobs is enough to give you credit for the experience without giving the reader the impression that you are clinging to accomplishments that are now distant objects in your rear-view mirror.
Lightning Round
Some other quick tips that didn’t warrant full sections:
- Email handles shouldn’t sound like they were created by a teenager, and AOL addresses aren’t retro cool (yet). If you need to ask, you should change it.
- Contact info eats up valuable page space if you stack it (name above address abovephone above email), and it’s the least important thing on the document that ironically gets the most prime real estate. Use a small font (like even 6 or 8) and try to keep all of this to a line or two at most.
- Personal web pages, blogs, GitHub, and LinkedIn links are nice to have if they are neat. Just remember that if it is listed, it’s fair game.
- Nobody cares what you got on your SAT/ACT tests 20 years ago. Same with college courses.
- If you decide to list non-industry positions, consider that the reader may have a hard time thinking of you as “Joe the DevOps engineer” instead of “Joe the former pizza delivery guy“. Most of us have had other jobs, but we don’t need to list full employment histories.
- Don’t list your references names or email addresses on your résumé, unless you want them to hate you. Some recruiters will try and recruit them even if that recruiter never spoke to you. Provide references when asked for them.
- Listing graduation dates gives away your age using the formula 22 + (CURRENT YEAR – GRADUATION YEAR) = CURRENT AGE. If you fear possible ageism, deleting graduation dates and removing your earliest experience is one way to prevent discrimination. It’s a résumé, not a full autobiography. In some countries it is popular to list birthdays and even photos on CV’s, but not in the US.
| Reference: | The Worst Developer Resume in the World, Redux: Best Practices from our JCG partner Dave Fecak at the Job Tips For Geeks blog. |
