tech-writing resumes

[cellio]

Someone on a tech-writing mailing list today asked the following: "As a hiring manager, what are you looking for in a resume? Do you think hiring managers with a technical writing background look for different things than one that is just getting to employee their first technical writer?" I want to record my response here:

I am a software developer and manager who was formerly a full-time tech writer. (I still do some writing, but it's not the majority of my work any more.) When I was hired it was for a sole-writer position.

What I look for in a resume is: technical expertise (what domains do you already know?), types of writing, size/complexity of past projects, and classes of tools. On this last: I don't care about the long list of tools (my eyes kind of glaze over, actually), just as for programmers I don't care about the long list of languages dating back to college. I do care about whether the candidate has worked with structured editing (e.g. XML) versus just working in Word. I care about whether a candidate has built or maintained the tool chain. But I don't really care if you've used Epic or FrameMaker. Tools are tools; I assume you can learn the ones we use. We'll sanity-check that assumption in the interview.

You may have noticed an absence of actual writing skills on my list. I can't judge that from a resume (except in the negative); that's what the writing samples are for, and they're essential. I want up to a few hours with them, not just what I can see while we're talking during the interview.

I don't have a lot of data about what non-writer hiring managers look for, but I believe the factors that got me hired by my current company were: technical skill (both writing and programming), ability to work with geeks, ability to work independently (demonstrated by past positions), and asking insightful questions about their software (showing that I wasn't going to just parrot what the SMEs told me, and also that I'd done some homework). (Granted, you don't get to demonstrate some of that until you get the interview.)

(Not posted on the mailing list because it would have been topic drift: For what makes an excellent writer in my particular domain, as opposed to just what I'm looking for in candidates, I find that an entry I wrote almost seven years ago still sums it up pretty well.)

Comments

[pedropadrao.livejournal.com]

What if most of your work is technical-to a certain extent-but it's not your standard handbook work? For instance, most of the writing I've done at work is in the shape of a couple of dozen bibliographies & resource lists. Not that I'm currently looking, since I'm very happy where I am, but these are strange times.

[cellio]

When I look at writing samples I look at a few things, starting with: can this person write coherently (grammar, spelling, an appropriate level of detail, consistent style, etc). For this, I don't much care what the material is. (Heck, for fresh grads they're unlikely to have more than a few article-length pieces; that's fine.) Next, I want to get a sense of scope, because some of our projects have large docs or doc sets with lots of moving parts. Not being able to show this doesn't rule you out; it just means we'll talk about it in the phone screen. To take your case as an example, we'd talk about how you organized all the research, how you decided what to include and exclude, how you keep it current over time, and so on. If someone has sound methodologies but just hasn't ever written a 1000-page doc set, that's not a blocker. (Plenty of people who have written 1000-page doc sets don't do it in a way that it can be maintained over time...) If your samples show that you can write decently, then most of the time we're going to talk about other things.

For my particular department you're going to need some code skills (at least reading, preferably writing at least simple stuff). But that's not true of the other group, which does user doc and sys-admin doc. (I help them out with their interviews.) In all cases, we're going to talk about how you gather information, verify it, maintain it over time, deal with contradictory input, assess user needs, etc. I presume that you face many of these issues in your work, so we wouldn't want for conversational topics. :-)