Ah - ha: I've been a victim of bad advice!

I am freshly disabused of a wide-spread piece of ill advice that I now dare expose.

When I left Novell and entered the job market as a candidate years ago, I learned a number of skills for job-seeking. The one I'm thinking about today is the resume. (If you've been following my blog at all, you know that I've been looking casually, then more intensively for another position since earlier this summer.)

Like everyone else in the software industry, the more years I worked and the more places I worked at, the longer my resume grew. It had disturbingly reached about 4 pages already back then. (Almost sounds like a line out of the mouth of Jacob Marley, doesn't it?)

A veteran of twice attending the LDS Employment workshop, I learned that your resume must not exceed a page or two and, anyway, no one will ever read even to the bottom of the first page before making a decision on whether to consign it to the "round file" or keep it in the list of people to consider.

This makes a great deal of sense to me. Human Resources people process incredible numbers of resumes and can't afford to become students of the life history of everyone applying with their company (times the number of job postings for that company).

Fair enough then, the resume must be short.

Second, the resume's content, like the cover letter, must hook the reader with the idea that you are at very least one of a short, few good candidates for the job. Resolved: the resume must be carefully composed.

However, that's where the resume advice currently propounded by modern would-be employment advisors stops. These would have you eliminate the traditional list of places worked, activities, associated skills and objectives accomplished in favor of a more succinct, "Here's what I can do for you" evoking your entire work history without exploring any of it.

That idea of a short, killer resume is seductive, but erroneous, particularly in my industry.

The truth is that even assuming your resume gets read, you'll be rejected no matter how "cool" it is if the hiring manager or even HR person is unable to get a feeling for who you are and where you've been.

Now, I admit that this may just be my industry. For a teenager vying for his third job as night manager at Pizza Hut, the results-oriented resume may be better. However, I've spent a great deal of effort hob-nobbing with software recruiters, HR folk and engineering managers. To a man (or woman), each has insisted on getting my traditional resume.

In the last few days, one of them took pity upon me cued by an oblique comment I made on the telephone to the effect that I kept having to ante up my old-format resume when I'd been told never to do that. He enlightened me a great deal and I'm relating some of that here.

Merely listing a skill set and technologies employed is meaningless to the resume reader. It's crucially important that your skills be named it is true.

I'm also told that the cover letter gets the resume read or left in the stack (no argument from LDS on that point). And I'm told that the list of skills and technologies performs the same function, i.e.: it keeps the resume reader from tossing the resume into the trash. So far, so good and...

(A parenthesis: To this end, the skills must be listed clearly. The human eye can sort out mistakes at this point, but if the manager is using a query to search a database like Monster, Dice or his company's that comes from a blind, robotic extraction mechanism, he can't be bothered with trying out Java AND Java/JEE AND Java/J2EE, etc. He's only going to try Java AND J2EE or JEE, etc. If you've put "Java/JEE" it's unclear that both "Java" and "JEE" will come out of it: you're at the mercy of the resume parser on that point and you didn't get to write it. You'll probably fair better with something like "Java, JEE (J2EE)" and "Linux (UNIX)", etc.)

But, I'm also told that the engineering manager wants to know "how much skill" one has and "how much acquaintance" one has with the technologies listed. "Extensive experience with relational databases" goes nowhere. What the hiring manager wants to know before going to the trouble and spending the time to interview you is how you gained the skills and the technological familiarity.

The engineering manager figures this out by undertaking an examination of where you've been and what you've been doing most recently. Therefore, it's crucial to say what you've done and how you've done it in order for him to gain an idea of how deep the skills run.

This is an important point: say what technologies and skills were used company by company and project by project. In this way, the manager knows he wants to speak with you. If it's unclear, you're relying on having piqued his interest enough and there not being an adequate number of other candidates.

Another person I'm in contact with actually works occasionally for LDS Employment (I shan't give out his name). He's required to toe the party line on this point even though he knows full well that the advice is unsound or, at least, misapplied when it comes to the software industry. So he's quiet on this point during his "volunteer" life.

In summary...
The resume must be virtually short with content to grab the attention of a) the HR person who is probably not very technical, but has a list of keywords to search on, and b) the engineering manager who wants meat to eat, expects a seasoned professional to have been around the block and have something to show or say about it (i.e.: four pages or more).

If the manager is interested, he'll want to save time by delving into the short statements about each place worked and be able to weigh in his mind the likelihood that the whole resume adds up to someone he wants to go to the trouble to interview. The length of a traditional resume gives him that capability.

Unless your name is Mahatma Ghandi, a one-page resume with a few really powerful statements about you will probably not suffice. Software engineers can only rarely cough up some heart-grabbing assertions such as "increased sales through field leadership by 80% year-over-year" or even "saved three companies' payroll departments 46% in the first quarter after shipping a second, refactored version of the software."