RE: Technical Writing Tests

[cpwinter -at- rahul -dot- net]

On 11 Feb 2003, at 9:18, Erika Yanovich wrote:

> 
> Laurie,
> 
> Forget about the nonsense tests you'll find in the archives (I was given a
> test once for explaining to aliens how to boil an egg!). 

    I wouldn't mind taking such a test. ( Step 1. Darmok and Gelad at the 
henhouse. Step 2. Darmok and Gelad in the kitchen. Step 3...)

    No, that isn't how I'd proceed. I'd use sketches, and assume they have 
a visual system like ours. I just couldn't resist throwing in a little Star 
Trek humor.    8-)

    But on to the main point.

> What we use here is
> company specific (so it won't help you), but the idea is that we explain
> about a simple product, give the candidate the actual product and a few
> examples of written material (data sheets) of similar products. The
> candidate is expected to write a data sheet based on the above (real work
> situation).
> 

    As others in the thread have already pointed out, this in not a real 
work situation and doesn't tell you much about how the candidate would 
perform in one. Also, it exposes anyone taking the test to your 
proprietary product. Do you have them sign a non-disclosure agreement?

    If I had the asignment of devising a technical writing test, I would get 
some obscure or obsolete commercial software product, install it on a 
computer in a quiet room, sit the testee down in front of it with a pad of 
paper, and give them a fixed amount of time to come up with a user 
manual. I wouldn't expect them to get very far; but the result would tell 
me a lot about two things: their facility at hands-on learning of new 
software applications, and how well they organize their written output.

    (Which software product, you ask?  AH ha ha ha -- Lotus Manuscript! 
That be the one to shiver their timbers, arrr.)

    On second thought, that would probably be /too/ diabolical.

    As I read the comments in this thread, one comment frequently made 
is that such tests are worthless because they reveal nothing about the 
day-to-day personal interactions required on the job. And this is true, but 
it doesn't make the test valueless. For one thing, if a prospective TW 
doesn't know a tool your company uses, and you can't provide training, 
the only way she will learn it is by trial and error. (Or to use Heinlein's apt 
phrase, the way the cat learned to swim.) For another, if all the SMEs 
are tied up in a meeting, such independent exploration may move things 
along. IMO it is as important to be able to "talk to the hardware" as it is 
to effectively interview SMEs.

    Another aspect is what such a test reveals about self-confidence and 
the ability to "wing it". I recall what an instructor at DeVry (Chicago) told 
me about an interview he went through for an EE job. The interviewer took 
the pipe out of his mouth, pointed at a pad of paper on the table, and 
said "Design an FM transmitter." The candidate tried to ask some 
questions. The answer was always, "Design an FM transmitter." So he 
did, making whatever assumptions he wished about power output, etc. 
He got the job.

Chris

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
Buy or upgrade to RoboHelp X3 today and receive the WebHelp
Merge Module for FREE ($299 value). RoboHelp X3's all-new
features include conditional text, completely re-engineered
printed documentation output, Context-sensitive Help Toolkit,
single-source layouts, and more!
Order online today at http://www.ehelp.com/techwr-l


---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.raycomm.com/techwhirl/ for more resources and info.