Applying for a Job II: Resumes

by William Grosso

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):

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?


2003-05-31 11:48:23
What is an expert?
I agree with your article.

I wanted to add, there are not probably more than a few hundred "experts" in any particular programming language or technology in the world. And I really do mean a "few hundred".

There is an extremely small niche where you can survive as a specialist, but most developers have to be generalists, so they are rarely experts in any one thing. In fact, with languages like Java you have expertise in specific areas of the language, and it changes all the time depending on the project. 4 years ago I was really good with the first versions of JAI - now I'd have to spend a few weeks working out the wrinkles. Later I suffered through the first crappy versions of J2EE - apart from the servlet spec I haven't worked with it in 2 years, so I'd hardly call myself an expert.

There is a right way and a wrong way to put this stuff on your resume, as you imply. Front-load your most current skills, and don't try to baffle your interviewer with BS. I don't usually mention that I know FORTRAN, because the last time I used FORTRAN was in 1983. :-)


2003-05-31 15:11:28
technically incompetent managers
well, i figured o'reilly folks would know better, but i guess not. managers, when i was young and not a manager and working in manufacturing, were **required** to know more about the work than the worker bees. this god forsaken notion that managing is some kind of separate (and Superior) skill is a crock. invented, alas, here in sunny new england at The B School. a manager Should Be more than a time keeper. secretaries and time clocks are good at that. do you (Mr. Grosso) really want to reward Pointy Headed Men?? it certainly reads like. shame.
2003-05-31 15:19:26
I don't understand your point. I think you're replying to the paragraph beginning with "Sidenote for programmers who want to become team leads or first-level managers." But I think you completely missed the point of that paragraph.

Managers do different things than the people they manage. I think that's obvious. Therefore, the skills that are required are different. I think that's obvious, too.

I never said anything about management skills being "superior"; that's a value judgement I don't feel like making. They are different, though. And if you want to get a management position, as opposed to an "individual contributor" position, you need to recognize this, and craft your resume accordingly.

Everyone with techincal skills who goes into management has to accept a tradeoff. To the extent that the technical universe changes, their technical skills will lose some relevance over time. They will lose track of the cutting edge, as that phrase applies to things like language specifications or gee-whiz widgets, or ....

And that's appropriate. Managers provide coordination and information and ... well .... management. Summarizing what a good manager provides as "timekeeping" really misses the point of management.

To insist that (for example) software managers keep up with the EJB spec (or even to insist that it would be a good thing and help them in their job if they did) is just plain specious.

2003-05-31 18:25:26
Manager knowledge.
At a dot-bomb I worked at, the managers weren't technical. They didn't know how long a project should take. They didn't know which of the "techies" were right when there were disagreements. I think you have to be at least as technical as the weakest tech person that you are managing.
2003-05-31 19:46:10
if the managers don't know the specifics of EJB (or any other relevant technology), and whether or not they apply, then all is lost. they are, after all, those making the choices; that's one of the perks of being a manager. if not knowing what they are deciding about is a qualification for management, well a quote from Napoleon is to the point: "There are no bad soldiers, only bad generals".

milestone determination is mentioned in the original piece. one of the reasons Scott Adams makes a lot of money portraying Pointy Haired Men, is that such people exist: those who set milestones for projects without having the foggiest idea whether such milestones are reasonable or achievable.

the notion is that management of techinical projects, space shuttle design or accounts payable modules, is *primarily* about keeping the technical bits right. the rest is just bookkeeping and brown nosing; neither of which aid in the completion of the project. no i don't have much respect for managers. from my experience, they just don't have much, well, Value Added.

there are reasons most software projects fail. from my experience, the most common is that managers of such projects come from sales and marketing. and my point is not that

what a good manager provides as "timekeeping"

but rather its opposite: that appointing managers *primarily* for reasons other than technical skill is the failure of the MBA paradigm of management. i've seen that paradigm fail. what most mangers actually do is keep track of time, and set milestones which please their managers.

the nearly guaranteed failure of software projects is not apochryphal. my point is that the generals simply use the wrong criterion for appointing managers of those projects. that management keep up with the specs (your choice of which) is hardly specious. if management had done so, we probably wouldn't lost 2 space shuttles.

that's the stuff they need to know in order to lead. leading is what management is really about.

if the criterion is talking with non-engineers, well, that sounds Point Haired Men.

2003-06-02 05:07:56
"if the managers don't know the specifics of EJB (or any other relevant technology), and whether or not they apply, then all is lost. they are, after all, those making the choices; that's one of the perks of being a manager."

A good manager won't be making such decisions. A good manager will recognize his, or her, limitations and leave that sort of decision up to a technical lead or architect to decide.

I think this is the biggest problem facing developers cum managers: Thinking they have to make every decision and know every nuiance of the project. This leads to Micro Managers, who are the most dreaded species of Pointy Haired Men.

2003-06-02 08:01:32
In any case, this is a separate discussion
I'm not sure why you're so emphatic. And I think you're wrong-- managers do need to understand some of the tradeoffs, and some of the basic facts of life. Do they need to control everything, and understand everything? No, and the attempt to do so will inevitably lead to failure.

Back to the point of the paragraph you objected to-- if you want a managerial position, you've got to mention roles and skills that would lead the reader reading your resume to believe you're qualified. And that means departing from a list of technical roles and skills, and focusing on things that are relevant to a management position.

2003-06-03 06:02:56
The bottom line...everybody is right.
a manager must be tech savy enough to know when the BS is piling up, and has to be balanced about the strengths and weakpoints of both the system of prod. that's in effect and the abilities/behavior of the team as both are crucial to a sucessful project. I've seen brilliant operators trying to work together, it's like being at a catfight with all the backbiting and constant bickering over what how where why. it's totally necessary to have a cypher for a great team and it is also necessary for that cypher to utilize the exp. + knowledge of the crew digital industries and their tools are constantly changing no one operator can say they have mastered it for long.
And to the point about business majors as tech managers, damn straight it's a problem, but don't be a manager hater some of us actually don't suck at what we do and get down and dirty with the rest of the grunts.
2003-06-03 09:25:53
technically incompetent managers
I guess the biggest hurdle managers will ever have to face is dealing with bad-attitude, generalizing tech staff. Managers must have the skills to deal with those holier-than-thou-cos-I-code-more folks who are disrespectful of any other skillsets a person may have, who resent managers in general, who can't work as part of a team effort within the context of the big-picture corporate goals ('marketing sucks' 'the suits suck'; those folks may be morons in instances, but not all are; they're tasked to address the business side of things, the side that brings in the money that pays everyone). Hostility and resentment towards management does nothing to increase morale, boost productivity, or achieve business goals. This is not 'us' versus 'them'. 'Them' is on your team, and the people who realize that and can work to improve those relationships with everyone across the board are the ones who have valuable skillsets to put in their resumes AND who can advance themselves further.
2003-07-03 08:30:14
It's wonderful article.I really appreciate the contents and look forward to further articles in thie series.

Jawaid Burney