I had originally intended to write this post about “acing the phone interview.” But that’ll have to wait for a while. Based on feedback to an earlier blog, though, a lot of people have questions about resumes and cover letters. In this article, I’ll
say a few more things about resumes.


But first, bear in mind that this is an idiosyncratic point of view, based on my experience in interviewing and hiring people over the last three years. I’m not claiming
deep wisdom or scientific truth here, just a few helpful pointers.


In general, you should have more than one resume, depending on what position you’re applying for. I’m not saying you should write a resume for each application, but the resume you send in, for example, for a “research programmer” position should look a little different from the resume you send in for a “team lead” position.


Resumes should also reflect your goals. This might sound obvious, but far too many resumes out there are lists of facts. They state what people have done, in a fairly unorganized (or, organized solely by time) way. And, frequently, at least for technical positions, they focus on technologies.


For any job, there are at least 6 important facts: why you were there, what you did, what role you played, what skills you used, what skills you acquired, and why you left. Not all of these belong on your resume. But, think about the job you’re hoping for, and think about what you want to include. Very often, the role you played is important, and barely mentioned.


There’s a subtext to the things you mention. Anything you mention on your resume should satisfy at least one of the following criteria (and usually more):

  • It occupied a significant amount of your time.
  • It was important to you
  • It indicates a change from your previous position that you want to emphasize
  • You’re proud of it

Again, this might seem obvious. It boils down to “Don’t mention writing stored procedures unless you spent a lot of time doing it, or you want to spend a lot of time
doing it” (in fact, it really boils down to “Only mention things that are important”). But you’d be surprised how many people include things like “Wrote HTML pages” on their resumes when they spent all of a week doing it and they
really aren’t interested in writing more web pages. This leads to conversations like:

“So tell me about your HTML skills”

“I didn’t really do much work with HTML.”


As an interviewer, I can tell you– four or five exchanges like that are fatal to your candidacy.


Sidenote for programmers who want to become team leads or first-level managers. Many programmers think that the road to a managerial position is paved with technical skills. For the most part, it isn’t. Technical skills get you a
team lead position or a cubicle in the corner where nobody bothers you because you’re working on something difficult. Getting to a management position is about being able to talk to non-engineers (or, at the very least, being able to talk to engineers who are working on different projects). The ability to define schedules, to define milestones, to report out on what you’ve done in ways that make sense
to the other groups, are crucial. If I’m looking for someone who’s going to be a manager, I’m looking for things like “helped define milestones for project completion” or “participated in requirements definition meetings at customer sites” or … I’m not especially looking for “was worshipped as a God during C++ segment of Machack.”


Another question that comes up is: “Well, but many companies have scanning programs that look for keywords. Shouldn’t I include all those keywords on my
resume?” While the answer depends on what you’re looking for, the answer is
often yes. The slightly subtle part is: include them in a skills section, at
the end. Why? Because scanning programs will get to the end of your resume
and find them. Scanning programs don’t get tired, and they don’t make conclusions
based on first impressions. Humans, on the other hand, do get tired, and do
make conclusions based on first impressions. Therefore, you should structure your resume
to impress the human and put the “it’s here for the scanner” stuff at the end.


While we’re on the subject of skills-lists, be honest. I’ve seen literally
hundreds of resumes over the past three years which say things like:

Skills: Java, C++, MQSeries, Perl, DCE, C, Lisp, SQL, PL/SQL. J2EE (EJB, Servlets, JDBC),
COM, DCOM, CORBA, JFC/Swing, Tibco, Firewall management, ATL, MOP, ….


Anybody who knows technology and has more than half a neuron reads these lists and thinks “Oh yeah.
This person is listing any technology used within a half-mile radius of
where they were sitting.” If you must include long lists of technologies,
you should, once again, be kind to the human and stratify them (”Expert”,
“Proficient,” and “Know” seem like reasonable labels). Otherwise, I’m either
going to ignore them, or spend a good chunk of the phone interview trying
to find ot which ones you really know.


Trust me, you don’t want me to ask you questions about technologies you don’t understand. It’s only
going to make you look bad.


In the next installment, we’ll go over cover letters. And then, after that, we’ll talk about phone interviews.
In the meantime, I hope this has been useful.

What do you think? If you’ve reviewed resumes, what do you look for?