John Fuex has been working in software development professionally for over 15 years in Austin, Texas. Although he still keeps his hands dirty in code as much as possible, he has spent most of the last decade managing software development teams for a litigation services company. His passions are software development process improvement and mentoring aspiring novice programmers. John is a DZone MVB and is not an employee of DZone and has posted 5 posts at DZone. You can read more from them at their website. View Full User Profile

DZone Top Article of 2011: Your resume. It’s the little things that hurt. (The Programmer’s Guide to Getting Hired)

  • submit to reddit

A skill that emerges naturally for managers after conducting a relatively small number of recruiting efforts is the ability to recognize common anti-patterns in resumes that are contra-indicators of good developers. I’m not talking about the major faux pas that have been repeatedly covered in generic articles about job hunting, but rather the nuanced messages that are communicated to a technical hiring manager who has learned to  read between the lines. This article is intended as cautionary advice to help prospective developers avoid the most common and damaging mistakes beyond simple typos and grammar considerations.

Risk Level: For senior candidates, most of the mistakes described below are fatal to your candidacy. For more entry level technical positions I am more likely to let these types of issues slide, but do use them to differentiate candidates that are otherwise equally qualified, so it still makes sense to be mindful of them.


Tip #1: Don’t be hyper-specific

One of the most effective ways to portray yourself as a novice or one-trick-pony is to pile on the trivial details when describing past jobs or projects. I understand that you are proud of your accomplishments, and know how easy it is to get wordy when drafting the Book of Moi, but remember that a resume is a brochure, not a biography. The prime objective of a resume is to get you booked for an interview, not to close the sale. The interview is a much better forum to brag about the implementation specifics of the “Monolith 3.0 Infrastructure Upgrade Project” because it allows you to adjust the message as you deliver it to hone in on whatever aspects resonate with the interviewer.

The key problem with being too specific arises from the undesirable subtext it creates. I think this is demonstrated well in the following excerpt from a real resume submitted for a Web developer job that I was trying to fill.

“Created stored procedures to fetch query results from the database for higher performance. Involved in writing complex SQL queries that required data from multiple tables using inner and outer joins.”

Gems of this type are hardly rare. I see variants of this exact statement so often in developer resumes that I can now spot them as quickly as if they were marked with a yellow highlighter pen. My mind automatically drifts to the same questions every time I see something like this…

Question 1:  Why is this person making such a big deal about menial tasks like writing a stored procedure and using specific join types?
Option A: They find writing SQL/Stored Procs very difficult and consider it a major accomplishment to have done so.
Option B: They didn’t have much to talk about in the resume and are padding it with trivialities to seem more qualified.
Option C: They just learned about joins and are proud of that accomplishment.

Question 2:  Why call out that they wrote the procedure specifically to query data?
Option A: Maybe they have never written a query that modifies data, are they that inexperienced?
Option B: Are they trying to educate me about what a stored procedure is? Do they think this isn’t common knowledge? Perhaps it isn’t to them.

Another example from the same resume:

“Designed online store by using ASP.Net. This system allowed user to order the products from the store and user can accept the order or cancel the order. “

Question 3: Did this person do substantial work on the project or just write the code for the “Accept” and “Cancel” buttons?

My advice to the author of this resume would be to take Vince Lombardi’s advice and “Act like you’ve been there before.” By assuming the details, it conveys a tone that the candidate considers the specifics of optimizing queries as routine and not worth bragging about. The discussion about the specifics of the clever optimization technique are best saved for the interview. Here is a reworked version that generalizes the same sentiment without dwelling on the trivia.

“Substantially improved performance of company’s core accounting package by profiling and optimizing database access code.”

Another major problem with getting too far into the weeds on a resume is that it implies that the resume is a comprehensive. By being asymmetrically specific about experience with various technologies, it has the effect of implying that the applicant is less competent in skills that are described more generally and not skilled in those that are not explicitly mentioned. In the above example, by specifically calling out experience with SELECT queries, it leads the reader to the conclude that the candidate might not be able to form other types of queries.Be mindful that what you do say often speaks volumes about what you don’t.

Tip #2: Don’t egregiously add keywords in the narrative sections

It could be argued that being specific in a resume gives you an opportunity to get all the buzzwords in, and this is true. The gatekeepers to most jobs are recruiters and HR people who use keywords from the job requisition to locate candiates on sites like and internal recruiting databases often without understanding their meaning. For this reason, I like the idea of separating out the keywords in to a separate “skills” section on the resume. This makes it easy for recruiters to scan your list of competencies by grouping them together, and makes the narrative parts easier to read for the hiring manager who doesn’t need to be prejudiced by that level of detail.

Here are a couple of examples from resumes that work a little too hard to jam keywords into the job history.

“Debugged and fixed the bugs which reported in TestTrack Pro by Seapine Software, Inc. according to SDLC.”

“Designed the database in SQL Server using database normal forms to prevent data redundancy and ER (Entity Relationship) diagrams.”

Although it is amusing, I’ll forgo a discussion on whether using normal forms actually “prevent ER diagrams.” If only…



Published at DZone with permission of John Fuex, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Chris Emerson replied on Sun, 2011/07/17 - 8:29pm

I applaud your strategy for reading resumes but most companies use a different approach. Due to high volume of candidates, they rely on algorithms and HR (non technical) staff to filter resumes. Resumes with their dumbed down geek speak and buzz word bonanzas are actually calculated to get a foot in the door. Blame the hiring practices, not the candidates for poorly written resumes.

Philopator Ptolemy replied on Mon, 2011/07/18 - 8:02am

Over the years, i have come to similar conclusions. For me, excessive details indicate lower level of abstraction. A higher level of absraction on the other hand, hinted by more generalized concepts, is the marking of senior people.

Nicolas Bousquet replied on Tue, 2011/07/19 - 3:20am

"A higher level of absraction on the other hand, hinted by more generalized concepts, is the marking of senior people."

We are in software developpement. You can give good impression in dinners with high abstractions, but that's all. That the main difficulties of software developpement. Most people tend to generalise and don't want to see the details, computers need very detailled things to work properly. That why we have software engineers.

So I agree that a CV should not enter into details, in particular because most people are borred by them, don't understand them anyway. This is not their way of thinking. But if you want to hire a good software engineer, you'll want somebody that can speak both worlds fluently.

Astrid Training replied on Tue, 2011/07/19 - 8:50am

Dear Sir,

I'm really (REALLY!) not trying to be a troll, but I'll be one anyways, because:

1. what you're saying here are not things that hurt a candidate's general chances, but things that YOU don't like to browse through while looking on resumés, and that's not at all the same thing. Yeah, sure, you're right, having overdetailed descriptions and snuk in technical terms every 5 other words is annoying, but necessary. You skim to quickly over the HR people's eye for these key words. I've been to many (MANY!) interviews in my life, and I can assure you that while, like 20% of them were decent talks with people who knew what they were looking for (and talking about), the other 80% started with an HR guy looking over my resume and saying "ah, NetBeans, oh, SQL, JSP and JSF, very good" (one actually asked me if JSF is not a typo for JSP), ok? If the keywords weren't there on my CV, some other guy who had them would have stand a better chance. I've seen this in 3 countries from both eastern and western Europe, IT'S ALWAYS THE SAME.

2. You make a very nice list of things you DON'T like, with plenty of examples for them, but you don't say one (count'em, 1) word about how you think, in your experience, a good resume should look like, and by good I mean one you'd like to read, because we've already established that that's not the same thing as actually useful.

Finally: Yes you are right on the fact that this kind of resume is embarassing, and reeks of unprofessionalism to the trained eye, yes, oh yes. But hurting your chances of getting the job, or, in other words, not having such a corny resume helping you chances is just not how it is. Since the first triaje of CVs is almost always done by non-technical (usually HR drones, it's not like they'll call you, the 15 years experienced software engineer to meet all the 300 dudes that came that week for the job), it's better to have a corny CV that passes that deseased hump, and then, if you actually get to have a discussion with a technical guy you can very well detail and explain with your own words what your experience is, and I really think that if the interviewer actually knows he's business he'll be able to evaluate you, the canditate, very well from that discussion, and will not get hanged on the fact that your CV contains about 43 occurances of the words Java and WebServices (each). I mean he know why you did that, it's so that those chicks from HR that seem to drink coffies all day won't dump the guy on the first try).

Sura Sos replied on Sun, 2012/01/08 - 11:25pm

No, that is bad advice. If I am hiring for short term, then I want to see technologies that are listed on the job description listed on the resume or on the cover letter. I believe most technical interviewer filter 95% resume using this technique. No one has time interview all the candidate that has applied for a position to find out what they have used.

David M. replied on Mon, 2012/01/09 - 12:42pm

I agree with the author.  Some of the commenters need to re-read the second paragraph.  As a developer who sometimes advises on a pool of resumes after collected by an initial screener, he echos almost exact conversations I've had.  If it is for a senior position, wasting the space to specify that a person knows the obvious such as the different types of joins in the SQL example, is a good way to not get selected to the next step in the process.  That example screams of an junior level person.  Also, I'm sure the author didn't mean your can't drop a technology keyword in the job description, you just have to be "senior" about it.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.