TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Anti-test comments below. Executive summary: there's nothing you can
get from a test that an intelligently worded interview question won't
give you.
Carey Jennifer (not to pick on you specifically, but you wrote some
intelligent comments that describe the pro-test viewpoint) wrote:
>What ultimately mattered was the document and how much time was
>necessary to create it. My aim was to replicate the actual
>working environment as much as possible.
Unless the work environment is to write short bits of doc about a
product you've never used in a few hours, with the SMEs sitting there
and staring at you the whole time, I'd say the testing environment
doesn't even come close to replicating the actual working
environment.
>By being available for
>questions, we were able to see how they approached the problem of
>documenting an unknown system.
If it were I being tested, you would not at all see the true way I
document an unknown system. I would first play with the product, read
some specs, and sketch out a list/outline of the features and tasks I
expect a user to want to accomplish. Only when I've done my homework
and have given myself some intelligent background would I go bug the
SME with questions. And believe me, I do bug them, but only once I'm
prepared. And if you asked me in an interview, this is what I would
tell you.
But in a test environment with the faux SMEs sitting right there, I
would know that they expected questions immediately, so I would just
start asking what I thought that they thought would be good
questions. But in the real world I would probably figure out the
answers to those initial questions myself before ever even talking to
the SMEs. So the test wouldn't accomplish your goals.
>For example, it's interesting to
>see whether they ask about the user or how the product will be
>used, or simply go straight to the procedures without this
>background. Do they use a lot of SME time, or do they resist
>asking questions? How they approach their work can reveal
>experience level as well as where their focus is.
Whatever happened to interview questions? Ask them how they get their
info, what their SME interaction is like, how they approach a new
project. Look at a writing sample and ask how they decided upon the
structure, how they determined what the tasks were. 'Cause the tests
described in these threads don't answer any of those questions as
they apply to an actual work environment.
>There are some
>other advantages as well. One is that they get to see what the
>work environment is really like and evaluate that in their own
>decision making process. Another is that since we would be
>working together, we both get an brief glimpse of how the other
>works before making the commitment.
As the testee (no jokes, please), I would have no clue as to what
your work environment is like. Except to assume that people enjoy
putting other people on the spot, believing themselves to be clever,
and then somehow applying that activity to a real work environment.
You would also get no glimpse at all of how I work (see comments
above), and the glimpse that I'd get of you would not at all be
favorable.
>In the end, I still think that you really can't KNOW what a
>person is like to work with until you've actually done it for a
>while, but how do you go about choosing a candidate?
The old-fashioned way. Interview questions and writing samples. If
you ask a smart question, you don't need a test to give you the
answer. If I want to know how they approach a new project, I ask "How
do you approach a new project?" I don't say "Here's a new project...
ready, go!" Because if they'd answer the question "I find out who the
users are," then the first thing they'll do in the test is ask "Who
are the users?" So the test adds nothing to my evaluation, except to
demonstrate that I lack creativity when it comes to interviews.
In case you're wondering, I have used tests on others. And each time
I came away thinking that I didn't get anything more out of it than I
did from my questions, that my perception of the candidate was
exactly the same after the test as it was before the test, that I
felt like a real ass doing it and perceived that the candidate felt
the same way, and that it was a complete waste of time.
__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com
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.
