How to Hire a Technical Writer
Hiring a Technical Writer
Most of this site is about getting a job as a tech writer. But you know what? Tech writers sometimes move up into management and need to hire other tech writers. Often the person hiring a tech writer is not a writer, and doesn't necessarily know a whole lot about how to hire a tech writer, or what makes a good one. So here is a brief guide on how to hire a technical writer.
Establish the requirements
If you're a manager who doesn't know exactly what it is that tech writers do, you need to find out before you start your search. How else will you know who meets your requirements?
Some suggestions:
- Talk to the outgoing writer, if there is one, or other members of the writing team, if any. Ask them what makes for a good writer in your organization - which could be very different from the success criteria in another. Find out what technical skills and tools the writer needs, but this shouldn't be the focus. Any good writer who knows one tool can pick up a similar one fast. The focus should be on how the work gets done in your company. What knowledge, skills, or characteristics make for success in discovering, or ferreting out, the required information in your context? Do they need to understand fiber optics, or clinical pharmacology, or robotics in automobile manufacturing? Do they need to be able to read and follow the flow of programming code, even if they're not themselves programmers? This stuff is far more important than which version of a help authoring tool the writer knows!
- Talk to your HR department and get them to provide updated salary range information for technical writers in your industry and geographic area.
- From a business perspective - after all, you are a manager - figure out what you need the writer to produce, and figure out what makes those documentation sets, or widgets, or whatever, a success for you in the context of your business.
- Now it's time to sit down and put these all together. You might find it helpful, especially if you're comfortable with spreadsheets, to put your criteria into columns, and put the various candidates in rows, so you can compare one with another across the board.
Evaluate the resumes
You might not be a technical writer yourself, but you can read! Look at the resumes. Are they really well-written? Do they tell you this person's story? Are they error-free? (If anyone can be rightfully expected to have a perfect resume, it's a technical writer, who is supposed to convey accurate information simply and effectively.) Next, do you see the progression or level of experience that you expect? Is this person close enough to your requirements list to move on to the next step?
Interview the writers
Interview techniques for writers are probably not much different than for others. Basically, the interview is an opportunity for both sides to get to know each other a bit to see if there's a possible match. Just like when interviewing for other positions, you should ask open-ended, experiential questions about the candidate's past work projects listed on the resume. If you ask candidates if they get along with others, they'll all say yes. But you can get more useful information if you ask them to explain the details of how they got and processed the information for the XYZ project that they did last year.
Review the samples
Some hiring managers put great stock in writing samples, but others don't, for two reasons: first, they're not hard to fake, and second, it can be hard to evaluate quality without understanding the context in which the samples were produced, especially if they were from an industry unfamiliar to you. If you have a team of writers that the candidate would be joining, have them go over the samples while you interview, and then have them join in for detailed questions on the samples.
Give a test
Some writers object passionately to this, but it seems clear that the best way to see whether candidates are able to perform a job is to give a test that approximates what they would be doing on the job. Don't demean the writers with grammar or spelling tests if these are not what your company produces. It's far more useful to have them produce an hour's worth of work on a small piece of what you actually do. If the job involves taking a convoluted specification and extracting the relevant information from it in order to make a first draft of a user manual, take an old spec and have them work on it. You can simplify or shorten the test to keep it in a reasonable time frame for the candidate. Give detailed instructions, and see if they follow them.
You will be amazed at how some candidates who might seem unpromising in the interview show that they can really produce in the test. And vice versa. Of all the criteria, the test is probably the single best predictor of success on the job - provided that you construct a good test!