Over five years ago I wrote two posts about Resumes and common resume mistakes. It’s amazing to me that I still see the same kinds of mistakes and failures in resumes I see today. I also discussed some topics related to resumes and interviews last year, specifically about interviewing architects. While my posts back then were pretty good, there are a few points I want to reiterate and a few that I want to update.

If You’re Going to Mention It…

Let me repeat, verbatim, this gem from my original posts:

Do not put anything on your resume that you do not want to be asked about

I see this all the time, people putting things on a resume that they aren’t prepared to discuss in an interview. I’m a simple man: I read the resume, look for relevant keywords, and ask about them. If you mention database optimization, software design, design patterns, refactoring, or unit testing on your resume, I’m going to ask about those things. Putting something on your resume, if you aren’t prepared to speak about it, is an embarrassment at best and a sign of deception at worst. In either case it speaks very negatively about you as a candidate.

If it has been too many years ago and you don’t remember it, don’t put it on your resume. If it’s something that somebody else on your team did, and you didn’t do it yourself, don’t put it on your resume. Don’t call a passing familiarity with a topic “expertise”. Don’t pretend to be something you are not.

On the other hand, if you have things that you are particularly good at and want to make sure you have a chance to talk about it, list it prominently on your resume. The more time you can spend speaking to your strengths, the better the interview will go for you.

Pick Your Battles

There are some awfully weird places to hang your hat. I see all the time people making big mention of little ideas on their resume. Things like “I’ve used database indexes to improve query performance”. Yeah, who hasn’t? It’s like you want to get a job building houses, so you list “Have used a hammer” as a skill. Using a hammer isn’t interesting by itself, it’s what you’ve used the hammer to do that becomes interesting. How did you determine that a necessary index was missing? Did you start with the queries you wanted to execute and then decide which indexes were necessary to support those, or did you start by modeling the natural keys of your data object and craft queries to work with those? How did the indexes affect performance of update and delete operations? How much performance did you gain in your queries? Were you able to make those changes with zero downtime or limited downtime? These are some of the bigger, more interesting topics that I am going to want to talk about. Indexes are just a tool and lots of people use them.

Don’t list little things on your resume. First off you don’t have the space for it because you’re trying to keep the resume down to 1 page, right? Second off, listing a little thing as if it were a big thing really causes me to question your perspective and sense of achievement. Listing little things on your resume makes me think that little tasks are a huge hassle with you, and getting even the basic details right will be a challenge.

Pants on Fire

If I catch you lying on your resume, I’m not going to hire you. Full stop.

Shorter Resumes are Still Best

I don’t need a lot of explanation here. The resume is a way to highlight relevant experience so that I can make a quick decision about whether to invite you in to an interview or not. Nothing more. If you write 6 pages of prose and expect me to read it, you have both misunderstood the purpose of a resume and you have shown a marked lack of respect for my time. In either case it doesn’t reflect well on you. I’m not going to read this entire pile of crap that you gave me and you know it. Or, you should know it.

Your resume should be short and clear. If you want bonus points, take a look at the job posting I’ve sent out and give me a resume that highlights the intersection between what I need and what you have experience with. You can almost certainly do all that in 1 page or less.

Say “I Don’t Know”

This isn’t related to resumes per se, but something you can do better in interviews. Sometimes you can’t answer a question. Maybe you put it on your resume but you’re having a little brain thing and you can’t find the words right now. Or maybe we’ve gone on a fishing expedition and asked about things that aren’t on your resume. In either case, it’s better to say “I don’t know” or “I can’t answer that right now” than it is to talk about something unrelated and waste our time. I know I mentioned above that it can be embarrassing to not be able to talk about something you have mentioned on your resume, but it’s better to be a little embarrassed than it is to waste my time and risk making me bored or even angry with a bunch of word vomit because you’re trying to salvage a bad question. Keep it short. If you’re supposed to know it and you can’t find the words, tell us you’ll get back to us, and then send us a follow-up email later filling in the parts you missed. If it wasn’t on your resume and you don’t know it, just say that.

Shut the Hell Up

One of my least enjoyable experiences is when I’m interviewing a person who Just. Won’t. Shut. Up. I’ve been in an interview before that was scheduled for 1 hour, and it took 20 minutes for the candidate to get through the first question. That’s a horrible start, and doesn’t bode well for the rest of the interview agenda. I’ve had candidates who were so uncontrollably wordy, that when my coworker asks me “Do you have any questions for the candidate?” I said “no” just so I wouldn’t encourage more talking. If you’re a bit wordy sometimes, especially when you’re nervous, make an effort to practice reigning it in. The last thing you want is to lose out on a position because you can’t shut up and the interviewers get impatient with you, or you run out of time and can’t complete the interview.

At best I have a few hours to talk to you, and at worst I’m on a very tight schedule. I need to learn enough about you as a worker and a person to be able to tell if you’ll fit in with our team and if you’ll be able to do the work that we need. If you ramble on, waste what little time we have together, and annoy the hell out of me, you’re probably not going to be coming onboard with us.

Understand What’s Happening

You need to understand what the different pieces of the job application process are, and put effort into each part accordingly. The resume isn’t the novella of your entire working life. It’s basically a short advertisement that is used to get the attention of the hiring manager and highlight your relevant skills. It’s like a lost dog flier: “Lost dog. Yellow Lab. Responds to the name Skittles. Call my phone number if you see him”. It should be short and catchy. It should draw attention to the important parts and leave out the unimportant parts. Do your best to understand this, and you will have more success with interviews I promise you.

Now let’s talk about those. Interviews have different purposes depending on who they are with:

  • Technical Interview: Especially for coders and engineers. You’re going to be interviewing with people who you will probably be working directly with. You need to both demonstrate that you have the relevant expertise, but also that you’re a kind of person the team wants to work with. You need to show off what you are capable of, but you also need to shut the hell up sometimes. It’s a dialogue, not a monologue. Also, besides generalizations, this really isn’t the place to be asking about compensation, benefits, etc.
  • HR Screen This is where you’re meeting with somebody from HR. They’re probably doing some psychological evaluations to make sure you aren’t going to be a liability for the company. They’re also going to be checking that compensation and benefits expectations are a match. There’s no sense wasting time for the technical team or management scheduling interviews if you’re not going to be able to meet on money. They may ask you some basic technical screener questions, but again it’s mostly to make sure you’re a good enough fit to warrant scheduling interviews with the real technical people. This is the place to ask questions about pay and benefits, but not the place to be asking things like technical process or equipment.
  • Manager Interviews After you’ve been through the other two types of interviews, the company will probably want you to speak to the hiring manager, or other managers. For very senior positions you may be meeting with executive-level folks. These people are typically not deeply technical (though they can be, sometimes). What these interviews are about is whether you’ve got a good personality, whether you’re easy to work with, and whether you can communicate effectively with non-technical folks. This is probably the place for plain English, not technical jargon.

There’s More

There’s more I could talk about. There’s always more. I know because I see so many people making so many avoidable mistakes. People who maybe could have gotten the job, but were passed over because of some blunder, some lapse in understanding. You need to think about it. You need to try to understand this process and the steps of it just as much as you would try to understand the important tools of your trade. Walking in to some of these blunders without preparing is a really boneheaded thing to do, and you don’t have to do it.