Re: Advice for interviewing new tech writers

Subject: Re: Advice for interviewing new tech writers
From: "Peter Neilson" <neilson -at- windstream -dot- net>
To: techwr-l -at- lists -dot- techwr-l -dot- com
Date: Thu, 22 Jan 2015 10:14:43 -0500

Indeed, a short test such as Lynne suggests is a good idea if you are permitted to use one. Once in a while there is a policy forbidding such tests as "discriminatory." If you are not allowed to use a written exam, you can still revert to "tenth-grade English class," methods and ask for corrections to a three-sentence paragraph you've written out on a whiteboard beforehand. There is then no written record of a "test" but only your recollections of the candidate's reaction to the problem.

A similar approach is to prepare a written sample, but to ask for oral comments rather than for a mark-up.

To evaluate a writing sample before the interview, take choice technical phrases and shove them into Google. You would be surprised, or rather you probably wouldn't, at the number of hits that reveal copying. I edited a PhD thesis for a candidate who did not have native English a few years ago. Some of was "just too good" and Google showed me why. Large parts came straight from Wikipedia!

On Thu, 22 Jan 2015 09:33:00 -0500, Lynne Wright <Lynne -dot- Wright -at- tiburoninc -dot- com> wrote:

That's the problem with candidates submitting writing samples -- they may have been cleaned up by an editor, or have been produced by someone else. I've experienced plenty of job applicants who proved, once hired, that they could not produce work anywhere near to the standard indicated by their samples.

In addition to asking for a writing sample, I had candidates write a short product intro based on a fact sheet, and had them proofread a short procedure that had a bunch of common grammatical, structural, and logical errors built in. You'd be surprised how many candidates who claimed to have a "keen eye for detail" who missed a really obvious typo in the procedure title, did not correct instances of awkward passive-voice constructions, and missed a lot of inconsistences in names and formatting.

The tests gave me a more accurate idea of the candidates' real skill level and tech writing knowledge, and allowed for me to discuss what areas they might need to work on (and their willingness to learn and take editorial feedback) during the interview.

Doc-To-Help: The Quickest Way to Author and Publish Online Help, Policy & Procedure Guides, eBooks, and more using Microsoft Word |


You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.

Looking for articles on Technical Communications? Head over to our online magazine at

Looking for the archived Techwr-l email discussions? Search our public email archives @

Advice for interviewing new tech writers: From: Kelly Smith
RE: Advice for interviewing new tech writers: From: Dan Goldstein
RE: Advice for interviewing new tech writers: From: Lynne Wright

Previous by Author: Re: #Personal#: Technical Documentation Quality Measurment
Next by Author: Re: Upload versus download
Previous by Thread: RE: Advice for interviewing new tech writers
Next by Thread: Re: Advice for interviewing new tech writers - Samples and legal issues

What this post helpful? Share it with friends and colleagues:

Sponsored Ads