1. Original Entry + Comments2. Write a Comment3. Preview Comment
New comments for this entry are disabled.

July 01, 2010  |  Technical writer interviews: Part 2  |  14155 hit(s)

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

[1] I had a boss once who was a genius at sniffing out people's real motivations, and who could and did end what were supposed to be all-day interview loops after 15 minutes.

Jim Glass   02 Jul 10 - 7:55 AM

I used to be known as a manager who could find good programmer writer talent within weeks of opening a position. I had a number of peers who had open positions for months and would have a number of candidates interview unsuccessfully for the position. I developed some tricks to finding great candidates, pre-screened them myself, and then only brought the best one in for a loop. We won't go into those tricks here, most of the time the candidate was selected. Many have gone on to positions much higher than I ever obtained.

My favorite kind of questions were those designed to determine the intellectual horsepower of a candidate. I know, this is different from your 'can they write' question. First example, we'd walk to a food dispenser and discuss flaws in the design. There actually was a machine in our building that put apples on the top shelf and when purchased delivered them to the bottom with a resounding clunk. Oh, and the instructions were so bad they were humorous.

Another example I used was based on the Washington license plate. With a letter number allocation of XXX123, how many possible unique plates could be made. It always surprised me that this was hard for people to figure out.

I was always surprised how nervous some people were too. Where else do you get to talk about yourself and people really want to hear what you are saying? :O)

mike   02 Jul 10 - 8:29 AM

>We won't go into those tricks here

Why not? Can you give a general idea?

Jim Glass   02 Jul 10 - 9:53 AM

Well that was five years ago as I'm now an individual contributor but here goes the top four ideas:

1. Use various job search sites like Monster (HR has an account) and develop great key words for your team. For the SDK team two that I used to great effect were "IIT" (best school in the world?) and COM programming. Don't wait for someone else to find you a great candidate.

2. COM is very difficult. If a programmer writer can talk to COM effectively, you have a very good programmer writer indeed. I don't know what you would use now-a-days as the new, smart programming languages make COM programmers harder to find.

3. Screen applicants with your best programmer writer. Ask the hard questions on the phone and make the job look like it's going to be incredibly challenging. If they get past that, you probably have a good candidate.

4. If you find that one in a million candidate, start recruiting them during the formal interview process. Most of these folks have many offers to consider; make your offer hard to resist.

Once you have this great hire, the challenge becomes keeping them for more than a year. I ask these folks to give me at least a year. The very best work super hard but find that one perfect job in the corporation. I've had super great people give me one year and a day and then leave for the job they've cherry-picked based upon working in the company. Think of Barb, Brett, Madura, Matt and Sirkku for examples. I could list more but that would just be bragging. :O)

Rob Caron   19 Oct 10 - 8:37 PM

Where's the Facebook Like button? :o)

mike   19 Oct 10 - 9:21 PM

@Rob -- Yeah. Waiting for me to reimplement this creaky old thing as a nice, new, streamlined ASP.NET Razor app, complete with the Facebook helper, I guess. :-)