aaron evans

There is no shortage of advice available to guide you in writing a resume. I’m going to pollute those waters a bit more and lend my advice which is targeted at software developers.

It’s fairly easy for an intelligent person with a bit of work experience to write a mediocre resume: insert contact info, insert previous jobs with duties, list skills, list education. I read a fair number of these kinds of resumes. People with this class of resumes get jobs. Odds are you have one of these resumes.

There is another class of resume that vaguely resembles the outline above but is much, much better. Something about these resumes quickly and accurately gives the reader a good idea of the writer’s skills and personality. I’m pretty sure that this class of resumes is almost always written by people who have either read many resumes and/or understand how the hiring process works at larger companies. I don’t claim to have a resume that is in this upper class. However, I’ve read so many resumes that I’m starting to learn how to make my resume more like those written by the upper-tier.

Let’s go through the life-cycle of the resume:

1. writer posts resume on web or submits resume to potential employer
2. keywords scanning computer may scan resume for keywords
3. resume enters company where human resources looks at the resume
4. human resources passes the resume to a technical contact in the organization who is a potential manager
5. manager reviews resume during a phone screen to formulate questions
6. on-site interviewers briefly review resume to formulate expectations and questions
7. resume may be used during interview to formulate questions during the face to face interview
8. the resume is carried by interviewers to a meeting where the decision about the candidate is made

There are some things to note about this process:

• technical people don’t look at your resume before step 4
• most people don’t get to step 4
• technical people only briefly look at your resume
• technical people use your resume as a source of questions to ask you

When the non-technical reader reads your resume, they need to quickly determine if your skills match those on the job description. If you paint an inconsistent picture of your skills, the reader will pass you over. If the jobs is for a Java programmer and you mention the Java bullet point in your skills but your experience doesn’t talk about all the things you did using Java, then you’re not a Java programmer no matter how well you know the language.

When the technical reader reads your resume, they will most likely scan it for interesting items. If there is something unique like an objective or summary at the top of the resume, I will probably read it (if it’s short). I look at the experience and try to see what meaningful things the person did at their last two or three jobs. If they try to impress me with overly descriptive or buzzword-laden summaries of their jobs or duties, I stop reading. There are no bonus points for big words, technical acronym soup, or descriptive prose. The reader wants to quickly know what you’re good at and what you’re going to do at work.

I only recently revised my resume with the intent of making it something better than mediocre. I’m not sure if it’s there yet. Note the following about the resume:

• keywords at the top: keyword scanners are welcome. Sure it’s a bit cynical but I think it works
• third-person summary: I’m not sure I really like this yet but the intent is to give a reader a quick overview of who I am. If you’re a brand, you have a mission statement. On a resume, this summary is basically my mission statement: who I am and what I do. It probably needs some help but it’s a start.
• experience as bullet points: All the interesting things I did at a job get a bullet. These bullet points are my friend when I am being interviewed by someone who is looking at my resume. Bullet points will turn into questions and I can talk about these items.
• skills divided by skill level: Developers are generalists by necessity. We should know how to program in C, use Unix, write some HTML, etc. We also have a few strengths that are our core strengths that get us jobs. If you combine all your skills into one section, you’re diluting your really good skills and overselling your less honed skills; they all occupy the same amount of space in a list of skills.

Let’s hope these tips help you make your resume more than mediocre.

This entry was posted on Thursday, August 23rd, 2007 at 9:18 pm and is filed under Development, Me. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.