Tagged: resumes for software engineers

The Worst Resume of the Week: Who are You?

Anyone who has either been a client of Resume Raiders or has read my articles about resumes knows that I am a firm believer in powerful summary/profile statements. There are many who feel a summary is not necessary, and in some cases that may be true, but I see an increasing number of resumes that either include a somewhat cryptic profile section or exclude a summary altogether (sometimes including an objective instead, which is worse).

This Week’s Resume

The inspiration for this post was a resume that led off with a somewhat long summary that I won’t include to protect the innocent, but here are some highlights:

Quick learner…motivated…team player…self-driven…solutions-focused

After reading the summary, even the most experienced technical professionals would have a hard time guessing

  1. What this person actually does for a living
  2. Whether this person is entry-level or senior
  3. Why this person might be a fit for almost any position imaginable

Image title

Although the claims being made are considered positive attributes, they could apply to candidates in virtually any profession with any range of experience. When the introduction doesn’t bring the reader any closer to a decision, we may wonder how patient the reader will be before abandoning the task. In the case of this resume, omitting a summary (and getting right into the experience) may have yielded better results, as at least the reader would not have wasted any amount of time on material that doesn’t help solve the problem.

No Summary

If you choose to exclude a summary statement, what is the result? It forces the resume screener (let’s assume it’s a human) to go through your document and arrive at their own interpretation of who you are. If the reader’s interpretation does not match the job requirement the resume is trashed. What could possibly go wrong?

The choice to omit a summary is equivalent to blindly trusting an unknown person to read a document and arrive at the same conclusions as the writer intended. From experience, I can tell you that the aforementioned “unknown person” can be almost anybody. At best, it’s a highly technical person with an open mind who understands your experience and is interested in learning more. However, it is almost as likely that the person is a temp six months out of school that doesn’t know the difference between CoffeeScript and COBOL who was tasked with managing the jobs@ email inbox simply because nobody his time is considered the least valuable to the company.

Cryptic Summary

A poorly-written summary can potentially do even more damage than a blank space. Most summaries are only guilty of being a waste of space, with lists of trite phrases, corporate-speak, and self-assessments that mean absolutely nothing to the reader. These don’t necessarily hurt the candidate’s chances of interview, but they require the screener to both read further and interpret correctly. It’s a missed opportunity.

Inaccurate Summary

Being that the summary is essentially the tl;dr of a resume, if a summary seems to indicate that the resume belongs to someone lacking the experience sought (to include relevant skills at the appropriate career level), why would anyone bother reading further? Even resumes of candidates who are highly-qualified for a job can lose their reader if they overshoot on the summary (emphasizing inapplicable expertise, overstating management vs hands-on experience, et al).


Include a summary and use the space to clearly lay out what you do and the amount of experience you have doing it. If a stranger can’t easily determine these things after reading your summary, you are better off removing the summary entirely.

The Worst Developer Resume in the World, Redux: Best Practices

Last week I published The Worst Developer Résumé in the World, which resulted in three things.

  1. 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.
  2. 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…“.
  3. 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.

Who Needs Side Projects?

The topic of side projects or personal projects for software professionals (commonly in the form of mobile apps, websites, various GitHub repos, and even technical blogs) has been fairly well-documented in the past few years. The concept of side projects as hiring barometer is still a relatively nascent industry phenomenon that emerged in parallel with the rising popularity and eventual ubiquity of open source software, web-based repository hosting, and usable blogging platforms. I distinctly remember the first time a client of mine indicated a preference (however slight) for candidates that could demonstrate coding from outside their employment. It was 2004, still a few years before GitHub.

The growth of SourceForge and then GitHub provided the opportunity to collaborate easily and effectively with friends, colleagues, or even strangers. Some engineers chose to code off-hours and some chose not to. As has been written before, others may not have had the time. Whether engineers did or did not contribute to open source or create side projects, all eventually became aware of the trend, and some likely predicted that the landscape for job search may be changing.

Flash-forward to today, where we commonly see job advertisements requesting a résumé and links to GitHub or personal projects. College seniors scramble to assemble a code portfolio while balancing internships and coursework in their final semesters. Highly experienced engineers with 20 years of stable employment and a formidable list of professional accomplishments still wonder if their work alone is enough to compete for jobs. Even high school students ask questions about starting to build things in preparation for a job search several years down the line.

It’s clear that many engineers are concerned with the perceived necessity for personal projects, regardless of experience. Blogs like mine are probably guilty of unintentionally feeding fears, as career advice is not one-size-fits-all. It’s a useful exercise to clarify the benefit of side projects for different groups.

Who benefits most from side projects?

Entry-level candidates, new college graduates – When a group of largely homogenous candidates compete for positions, side projects are a differentiator. Typical résumés for new grads list GPA and select courses. Without internships or projects, they are virtually identical in every way. Even a link to rather mundane GitHub repos might give employers a bit of insight into ability.

Recent industry entrants without marketable experience – Many professionals are forced to accept undesirable jobs due to personal circumstances, while others make poor career choices early on. Two or three years of professional experience in the wrong shop might not lead to any real accomplishments. Side projects may be the best method to demonstrate skill early in a career.

Stagnant employment history – Candidates who have held the same position in the same company for many years are subject to somewhat unique scrutiny, with the most common theme being the concept of whether someone has “ten years of experience or only one year of experience ten times“. Showing some other skills gained outside work might shed the one-trick pony image and demonstrate an interest in learning.

Dated skill set, limited technical environment – For some engineers, side work might be the only opportunity to play with the new and shiny toys that other employers use. If the day job only allows archaic languages and tools, future marketability may depend upon side projects.

Those looking to change their path – Similar to entry-level candidates, professionals attempting to alter career direction may look to side projects as their most powerful strategy to gain some credibility. A good example of this is the large number of budding engineers who accepted QA positions while intending to move into development roles, or web developers who seek employment in mobile.


Side projects are often effectively used in lieu of work experience and tangible accomplishments in order to establish credibility and demonstrate skills. Their importance fades over time for professionals in ideal technical environments, defined as places where engineers are productive, learn continuously, move between projects and groups, and are able to develop a varied set of marketable skills. The value of side projects may vary over the course of a career depending on factors in the workplace, which are usually beyond the employee’s control. The groups outlined above derive the most benefit from side projects. For established and highly accomplished professionals, side projects can be completely unnecessary.


Why Your Résumé is 10 Pages

Even though there are hundreds of articles professing the beauty and efficiency of the one page résumé, not a day passes where I don’t see a five pager. The issue of length has even surfaced amongst college undergrads applying for internships, who seem to have increasing difficulty trimming their list of accomplishments and experiences into a single page (really). This is a troubling sign for future HR and recruiting professionals tasked with selecting applicants, as job seekers who are unable to shorten their credentials will continue to have difficulty in their search.

The amount of time a recruiter or hiring manager spends reviewing any single résumé varies by the individual.  When offered a single page résumé, the reader is much more inclined to give that page a proper scan to make a fair assessment.  A two page offering should get a proper review as well.
Continue reading