10 Alternate Tests for Evaluating Technical Writing Job Candidates -- A List for Hiring Managers
I received an email the other day from a hiring manager who asked me what tests they should give to their technical writing candidates. She writes,
We are hiring two new technical writers and are trying to come up with a practical for the candidates to complete. We had been asking the applicants to write a quick how to (e.g make a pb&j, withdraw cash from an ATM, etc.) followed by a longer writing sample, but our HR rep isn't sure if this is the best qualifier. Any ideas? What test have you completed in the past when applying for tech writing
positions.
Although I've taken various tests before for job interviews, such as documenting how a small company widget works, or finding all the spelling and grammar errors in a document, or actually taking an IQ test, I'm not a fan of tests. Do you ever give doctors a test when you interview them? See now, go into the next room and try to figure out what kind of disease the guy has. You'll have 30 minutes to write a diagnostic report. Or to a lawyer -- we want to see if you're actually qualified for the position. Please write and deliver and 3 page court presentation arguing a case of insanity for the unabomber...
If I were hiring a technical writer, rather than administering tests, here are 10 things I would do to evaluate the candidate:
- Ask for writing samples. Writing samples are by far the best indicator of ability. The only problem is that often writing samples are proprietary and confidential to the former company, and if the writer is seeking a job without the current employer's knowledge, it's hard to acquire these samples legitimately.
- Ask the candidate to evaluate your company's existing documentation. What would he or she change? How would he or she approach the same material?
- Ask for evidence of enthusiasm. My favorite interview question is, "What have you done in the past 6 months to demonstrate your enthusiasm for the profession?"
- Check out the candidate's blog to see if he or she is an interesting person. If there is no blog, Google the candidate. If you can't find anything anywhere, be skeptical about the answer in #3.
- Ask the candidate to explain his or her strategy for single sourcing. This is a great way to gauge the candidate's awareness of current trends.
- Talk with the candidate about random things. Ask yourself if you would enjoy having the person as a co-worker.
- Have other technical writers meet with the writer, especially if you're not a writer yourself. Writers can sometimes quickly sense whether someone knows what they're talking about, similar to how developers or designers can judge the same about people in their fields.
- Ask the technical writer what his or her favorite manual is and why. This will get the writer talking about best practices.
- If you must give a test, ask the writer to create a video tutorial describing how to do something software related. Hiring managers often give writing tests, but hey, technical writers don't just live in the written word. You want someone who can do video too. In fact, I just received a comment today on a quick Dokuwiki video I made last year. Sarah writes, "I just finished watching your video on setting up Dokuwiki (https://s3.us-west-1.wasabisys.com/idbwmedia.com/podcasts/dokuwiki.html). This is not only a very useful video, it's the future of tech "writing." Thanks for sharing it."
- Check to see whether the writer formatted his or her resume with styles. This is my friend Mark Hanigan's pet peeve. Whenever he evaluates resumes, he first looks to see whether the content is structured with styles. It's subtle and anyone who isn't familiar with structured authoring will completely miss it. But you don't want to hire someone who doesn't understand the concept of styles.
Finally, if you are determined to administer a writing test, please make it software related (unless your company doesn't make software). And also make it difficult. For example, provide instructions on how to speed up your Firefox browser.
April 6, 2008 Update: I have officially changed my mind about writing tests. While I initially thought they were insulting, I now think they are essential. I guess I had to experience for myself an interaction with someone whose writing I felt to be subpar. It lacked thoroughness, wasn't easy to follow, was poorly organized, sometimes unclear, and was overall not something I'd want my department name attached to.
Many candidates pose as technical writers but really lack the skills. Writing tests can help weed these candidates out. I guess I've come full circle on this. I now would also encourage a writing test, and require that candidates provide instructions on how to document a typical company widget. When you get that writing sample, here are some obvious signs that you shouldn't hire them:
- The writer doesn't use numbered steps.
- The procedure had 20+ steps without being broken into separate tasks.
- The writing is unclear.
- The writing is poorly organized.
- The formatting is sloppy.
- The writer doesn't structure the content with styles.
- The steps are inaccurate.
- Field definitions aren't illuminating.
- You can spot misspellings and grammar errors.
My alternate tests are still valid. I'm just now endorsing the standard writing test.
As an added bonus, requiring writing tests will drastically reduce the number of candidates who apply.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.