Thursday, 1 July 2010
05:52 PM
Last time I talked a little about the interviewing process and investigating the technical side of technical writing in our group. If you don't pass a technical screen, we're unlikely to pursue the interview. But assuming you do get over whatever bar is set, comes now the writing side.
 A diversion. As I will touch on later, there's a difference between a person who can write and a person whose job is writing. A programmer who writes the occasional blog entry is not (yet) a technical writer, who in contrast spends week after week documenting not just the interesting and cool things that are fun to write about, but also the seemingly endless APIs, the unsexy readme files, the installation instructions, and all the other stuff that users need, and who do this on relentless schedules. (As people sometimes say, "that's why they call it work").
Ok, writing. How do you assess writing skills, and specifically technical writing? If anyone's developed a foolproof way, I haven't heard of it.
What about writing samples? A good start, and indeed, a necessary condition, but not a sufficient one. It's hard to imagine a candidate with no writing samples at all getting far in the process. On the other hand, impressive writing samples are always nice, but it's never clear how much of the work actually is the candidate's and how much was contributed by (for example) editorial review. In this regard, blog entries are (IMO) actually good writing samples. If a good blog is added to a sample that shows experience writing API docs, I definitely sit up and take notice. (FWIW, I haven't seen this a lot.) A writing sample can also become an interesting point of drilldown, as I'll explain in a minute.
Writing test? This idea has always been bandied about (you'd never hire an editor without an editing test), but it's never really come to fruition, at least that I've seen. Decades ago I used to administer a writing test that consisted of listing a handful of SQL-like statements and the resulting output and asking the candidate to sketch out the documentation for this "language." However, that's a pretty intensive effort that we don't have the time for in our brisk process. (We might also have some constraints associated with having to administer the same test the same way each time, but I'm not sure about that.)
So we do a lot of our assessment via questions. If I indeed have the charter to investigate the candidate's writing skills (I don't always), during the interview, I ask some questions that are fairly broad, along these lines.- I see that you did some writing for [Product X]. What does that product do? (I just pick something off their resume.) To me this is a pretty simple test for writing ability. Can you describe something to me that I don't know about? Did you bother to establish what I might already know about it? Can you tune your description to my knowledge and interest? Like that.
- You're given a 1.0 product to work on, and six weeks to do it. What do you do? Here I'm looking for thoughts on how to plan, how to prioritize, how to use available resources creatively, what to produce, whether they consider non-writing avenues (e.g. video), how to think beyond the next deadline, maybe how to negotiate with other teams, etc. If they've been in the business for a while, they've faced this one, so I'm all ears about how it went and maybe what they learned.
- What's your experience with editors? Tell me about a time when you and the editor disagreed about something. Obviously, I am leery of people who either have not been edited or who are grumbly about editing. (To be fair, I know writers who are justified in their skepticism about technical editors. Still, a response like "My editor was an idiot, so I just ignored them" is, as you can imagine, not encouraging.)
- How do you know if you've succeeded? I'm looking for some insights into things like getting reviews, checking customer feedback (or otherwise interacting with customers) — whatever they might think of. This might also tell me something about whether the writer is actively interested in doing a good job or has a "it's published, I'm done" attitude.
- What skills do you think make a good technical writer? If "good grammar and spelling" seems to be a focus, I start to have my doubts.
- What's the best kind of documentation? The winner here is "the best doc is doc that's not needed," but I'm interested to hear whether they've thought about the purpose of documentation, how it's used, by whom, etc. For our context, I also like to hear about code samples and other programmer-centric thinking.
- If you could do any job tomorrow, what would it be? This seems like a transparent snare, but an open tech-writer position can attract people who think they might want to look into this writing business because they're tired of what they're doing and hey, they wrote a whitepaper once and that was fun.[1]
If I have a decent writing sample, I might also ask some specifics about the sample -- what was the thinking, why this approach, what were some of the issues, how was it received, etc. I also hope to get some sense of whether they were using a style guide/sheet and had a formal editing and publishing process. I'll also ask what tools they've used, not because I care specifically about those tools, but because I am interested if they've worked in a professional environment and how they feel about that.
If they've provided multiple samples, I might ask which is their favorite and why. What I'm hoping to elicit here is some enthusiasm and pride for their work.
Hmm. I see that these are questions about writing skills in a very broad definition. But that's what we're after.
There's a million more questions (I have a 6-page document full of them), but the specifics aren't really that important. The important point is that what I probe for is to determine whether the person sitting across from me is, in fact, a writer. As Chris Sells once said, "Don't prepare. Be yourself. If you're not a fit for MS, no amount of preparation in the days before an interview will help." (Read his whole interview.)
There are times when it's obvious, either pro or con. There are other times when it's just not clear. (An odd case that I've learned to trust is the person who seems to be -- in fact, is -- a good writer but is not driven to it compulsively, and would not write except as a job.)
I know from experience that it's quite a bit harder to find a really good programmer/writer than I would have imagined in my younger days. As you might expect (?), I've worked with folks where the programming skills definitely were the stronger half of the binomial. That, I suppose, is where my job comes into it. :-)
[categories]
work, writing
|
link
|