Admin note: At one time, Eric Ray was asked to offer his thoughts on what to look for in hiring a technical writer. Following are some of his comments, which were provided in the context of hiring a technical writer for a fairly large and very techie technical publications department.

You need to keep four main characteristics in mind when hiring technical writers:

• Communication and Interpersonal Skills
  
• Writing Experience and Skills
  
• Tool-related Experience and Skills
  
• Technical Experience and Skills (with the material to be documented)
  

The following sections outline what to look for (and avoid) in each area.

Communication and
Interpersonal Skills

For most tech writing jobs, the communication/interpersonal skills angle is most important, and nothing else matters if those skills are missing. Some people might disagree, but it's hard enough to elicit information from busy developers without great
interpersonal skills, and enough developers/SME (Subject Matter Experts) have had bad experiences with tech writers that it's just not worth it to add other obstacles.

Additionally, the writers must be able to work effectively with our existing writers--different set of skills and expectations, but equally important. In some jobs, you can overlook personality quirks, but not among tech writers.

Particular warning signs to look for include the following:

• Insecurity (e.g., I coulda been a programmer, but I'm only a tech writer)
  
• Defensiveness (e.g., "sure, of course I know that...")
  
• Territoriality (either in the "not my job--engineers do that" or in the "stay off my turf" sense)

Particular good signs to watch for are:

• Active listening skills (repeating and paraphrasing to ensure understanding)
  
• Ability to keep conversions going...not letting "dead air" be noticed
  
• Ability to keep track of threads (e.g., "as we were saying 30 minutes ago...")

Writing Experience and Skills

This one will be the hardest one to evaluate, particularly for relatively less experienced writers (or non-tech-writer hiring managers).In addition to the obvious issue (for those who have not been writing/editing full-time for years), you'll also find a lot of writing samples that aren't really the work of the applicant, resumes that tell little and mislead frequently, and a lot of legitimately gray areas about actual authorship or contributions to documents.

In a face-to-face interview, ask to see samples or a portfolio, and ask questions like the following. In all of these, any hesitancy or evasiveness is a big red flag--a writer should be able to sound off for the rest of the interview on any or all of these issues:

• Did you collaborate with anyone on this? What roles did you assume, and what did the other people do?
  
• Can you point to a section that you wrote completely on your own, and tell me how you developed the information?
  
• How did you find the information you used? Acceptable answers include
  
  • Interviewing/talking with developers
    
  • Reading specs/reading code
    
  • Using the software
    
  
  

In my opinion, actively using the software is the only way to be able to write about it effectively, and you should give preference to that answer. That said, you'll also need to probe more there, as that choice is a "known to be safe" interview answer. Look for someone who asks you--proactively--about access to software, builds, and equipment. For a real tinkerer who has been around the block a couple of times, good access will be important enough that they ask you before you ask them. Other relevant questions might include the following:

• What was the process you followed for production? That is, what tools did you use?
  
• Who was responsible for doing illustrations, screenshots, printing?
  
• Who handled getting the stuff out the door?
  
• Did you have to integrate your stuff with development? How'd that work?
  

In this area, you're looking for an awareness of process and willingness to follow it more than anything else. There's nothing magical about any process, but stay away from a tech writer who tells you that there wasn't a process. For example, ask: What constraints did you work under when writing this (gesture to one at random) document? This gives the applicant the chance to disclaim any problems with the document as well as gives you
a good sense of the applicant's propensity to assume responsibility, point fingers, and own the work. Similarly, ask: If you had it to do over again, what would you do differently? Why didn't you do it that way in the first place? A good writer will have a laundry list of items for improvement on any document they wrote, bar none. If they don't have a list, they're either not enough of a perfectionist or they didn't write it.

In writing samples, look for both minor and major issues:

• Minor issues: If a document was created under time constraints or with other explicitly acknowledged issues, typos, inconsistencies from chapter to chapter or page to page, and formatting oddities aren't a big deal. That said, most good writers will volunteer information about the constraints under which they worked--if you see a document with visible issues and the applicant didn't explicitly state that "oh, I got that
  information two hours before it went to the printer and didn't even have time to spell check it", be concerned. If, however, you note issues like these and the applicant isn't aware of them or doesn't mention them explicitly, you should be very leery--either the applicant isn't detail-oriented enough to be aware, which
  is bad, or the applicant isn't aware because the samples don't really belong to the writer, which is worse.
  
• Major issues: Look at the overall structure and a logical progression of information from the beginning to the end of the section/chapter/book. Red flags would be issues like covering installation and configuration in chapter 5 of a 10 chapter book, or detailing how to start the application on page 28 of a 35 page chapter. Ask why those decisions were made.
  

In evaluating a portfolio, do this:

• Pre-interview, don't even try--seriously, there's little point in slogging through a portfolio unless the writer is (or will momentarily be) sitting across the desk from you. Without the context of discussions, you'll not know what, if anything, they wrote themselves or what the constraints and issues might be. Just glance at the stuff, then ask questions in an interview.
  
• Post-interview, assuming all else is in order, take a quick look just to confirm the decision you've already made.
  

Tool Experience and Skills

The importance of tool experience and skills is usually overstated. Given a good tech writer, the tools make little difference. While you'll obviously ask for the tools that
your group and writers use, I'd certainly not rule out a otherwise promising applicant who'd never touched a system or never used the tools of
choice. That said, that candidate should have demonstrated proficiency with a document processing program (Word, Frame, or the like), proficiency with Windows (or Mac or Linux/Solaris/X), and should give some reason to believe that new tools will be a minor handicap or challenge, not an overwhelming burden nor a need for immediate and long-lasting training regimes. It's very easy to succumb to the temptation (abetted by most agencies) of a checklist of tool skills, but that's not the way to find a good tech writer.

In other words, don't get hung up on tools...ask writers if they either use or can learn the tools you really want, and if they don't flinch, they're fine.

Technical Experience and Skills

Technical experience and skill will be most challenging to evaluate, in large part because there's no effective checklist to follow.

In broad terms, you're looking for the "ability to learn" rather than any specific set of skills. It's quite tempting when looking for tech writers to look for someone with specific and technical experience in a specific area (web servers, TCP/IP, security, or whatever), but that's generally not the best approach for a couple of reasons:

First, technical writers generally act as user advocates in much the same way that QA staff do. They try to anticipate how a new user would encounter the product, then provide the information needed for that to happen. Starting with too much knowledge about the system makes it more difficult for the writer to accurately assess how little a new user knows.

Second, although domain-specific knowledge is useful, it's not nearly as important as the ability to explain. That is, the reason that we hire tech writers is to explain clearly--
if domain-knowledge were all that was needed, we'd just hire more engineers.

What you need to find is someone who knows how to learn and can demonstrate/has demonstrated that ability. In other words,
have they documented (well) stuff from a variety of different disciplines or fields?

Questions to ask include the following:

• How would you go about coming up to speed on this application? What would you do first? Second?
  
• What was the most challenging documentation project you've handled, speaking from a technical/subject matter perspective? How did you address these issues? What do you do if engineers don't have time to help you and if the specs are hopelessly out of date?
  
• How do you approach such a problem? (Specify that you're asking for the technical answer, not the interpersonal-skills answer.)
  
• What kinds of technologies do you thoroughly understand? Can you hand-code Web pages? Set up a Web server? Set up a firewall? Do you run Linux at home?
  

More than anything else, you're looking for a plan of sorts. Blank looks or explanations that start with "after the training session..." are bad answers in this context. There are no right answers to this, but you're looking for anything technical--from computer stuff to woodworking to even baking with a capital B. More than anything else, you want someone who
has gotten into something--anything--deep enough that the "magic" factor is gone and it's old hat. Why? Because you need experienced writers who know how to learn in-depth, not
just superficially--you need people who know how to build an understanding and not a passing familiarity.

Employment [0]

• Employment General [0]