Spray-and-Pray Developer Resumes

I interview a fair amount of software developers (although not as often as I used to, sadly), and so I have people ask me about a variety of issues related to finding programming gigs. What certifications, what schools, what questions to ask, and even what attire to wear.

I really thought interview attire was something of a solved problem, but apparently not.

I digress. When I’m asked one of those questions, I usually try to stress that it’s hard to hurt yourself when answering any of the above questions. Yeah, some schools are better than others, but that doesn’t matter too much for programmers, especially once they have a year or so of experience. Certifications usually don’t hurt or help too much unless it helps you meet a job’s requirements (although an XML Master Certification is resume poison).

However, there is one particular brand of resume that, regardless of talent, really irks me and makes it difficult to get on my good side, let alone get a recommendation from me. I hate, hate, HATE finding a “spray and pray” resume. This is the kind of resume that is two pages long for every year of experience and is absolutely crammed with a wide range of unrelated technical terms. It’s the kind of resume where someone has liberally sprayed the document with verbiage and prayed that some of it tricked someone into interviewing them.

It doesn’t work.

Telltale signs you’ve written a Spray and Pray Resume

  • Under “Programming Languages,” you list every single programming language you have ever encountered.
  • You list every job, ever.
  • For each job, you list an insane number of different, unrelated responsibilities.
  • You have the world’s most vague Objective Statement.
  • You list at least one OS for which you don’t know how to navigate the file system from a command prompt.
  • You list any UI framework for which you cannot instantly tell me the base class/method/approach for displaying a “Hello world” window.

What’s so bad about that, huh?

Many people would say these resumes looks desperate, and you generally want to avoid looking desperate in an interview. I don’t really care too much about that however, as Lord knows I have been desperate for work before and lucked out to find a job despite it.

A more significant problem with this kind of resume is that is just looks lazy. If you can’t make the time to trim your resume down to only those things the interviewer has a chance of caring about, then why should the interviewer make the time to talk to you? Just 2-3 minutes spent making a specific objective statement, removing irrelevant items (or moving them to a Hobbies/Interest section if you really, really want them on your resume) and tightening the resume up in general can work wonders.

Worse than looking lazy is looking dishonest. If you are confident enough in some skill that you put it on a resume, then you’d damn well better be at least at an intermediate level in it. If you haven’t touched that programming language since high school, leave it off your resume. Otherwise, as soon as you have to tell an interviewer you don’t know much about something on your resume, you bring everything into question. It reflects poorly upon you, and the interviewer will subsequently devote a fair amount of time fact-checking your resume rather than really engaging with you.

Even if you don’t look lazy (which you might), and even if you don’t seem dishonest (which you will), you’re still doing yourself a disservice. Why? Because your strengths will be lost in the “noise” you create with unrelated terms and bullet-points. I promise you, even if you are just graduating from school, you already have strengths that are worth showcasing on a resume. It’s many times more effective to have three bullet points that prominently highlight things you excel at than to hide those amongst umpteen other areas where you aren’t so hot. By paring down your resume and saying less, you can let your strengths shine that much more and seem stronger.

Almost all of those problems listed earlier can be solved by simply going over your resume, and asking yourself “Could I answer a simple question about this?” If the answer is no, leave it off your resume. Otherwise, you might just be sitting across from someone like me who ALWAYS picks one of the programming languages you put at the end of your list and asks you to compare and contrast it against a language from the front of your list.

Oh, and never list XML as a programming language. (Although if anyone ever says that they really meant XSLT and that XSLT is Turing complete, I’ll be suitably impressed to overlook the mistake. Throw in a “Duh” for good measure though)

Updated:

Comments