RE: Technical Test

Subject: RE: Technical Test
From: KMcLauchlan -at- chrysalis-its -dot- com
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Tue, 27 Feb 2001 16:54:54 -0500

About tests, during interviews, Andrew said:

> So how would you respond? Anger, frustration, reason?
> You'd be surprised. Its easy to say "oh, I'd reason it out."
> But when you're
> under the gun, people respond to their true nature. If your a
> person who angers
> when you feel dumb, its hard to re-engineer that response.
> Scientists and
> doctors are taught in grad school that you have to remove
> yourself from the
> equation and confront everything as a problem. The key to
> that is to remember
> that there is ALWAYS a solution - you just don't know it,
> yet. If your patient
> and let your reasoning abilities work on the problem, 9 times
> out of 10, you'll
> solve it, or get very close to a solution.

That view is very comforting. Unfortunately, it is functionally
negated by another feature that is always present in such tests.
It's called a time limit. One strategy I've always employed on
tests is to work until I encounter something iffy or "impossible"
and then skip it. Later, if there's time, I go back and revisit
the bad questions, often making a good showing because the rest
of the test has put me in the right frame of mind or has given
me more info to work with.

Like many people in the biz, I can figure out just about anything,
given enough time. The time shortens as my access to resources
increases. If the resources aren't readily available, but I'm
sufficiently motivated, there's a good chance that I'll still
figure it out. Problem is, in a test situation, I won't be
allowed the time to "sleep on it".

At work, on the other hand, my usual approach to a new project
or product is to take an early peek, skim some e-mails and initial
docs (if they exist) and then ignore the whole thing, for a
a time, while I get on with other work/play. The next time
I approach the topic, somebody in the back of my head has
offered up some preliminary guesses/approaches, and organized
a line of inquiry. I ask (of other people, or of myself)
questions that I wouldn't even have thought to ask, the first
time I encountered the problem.

"Stewing time" is a necessary requisite to my picking up new
concepts and integrating knowledge. It can be relatively
short if the number and scope of new stuff is limited. If
a whole whack of things are thrown at me in a short time,
the buffers overflow and I'll be lucky to manage one or two
out of the crowd (thus that test-taking strategy of hitting
the high-spots and then going back to ponder the pot-holes).
I don't get to pick which "one or two" will come through the
noise and pressure, unless physical survival is at issue...
which is usually not the case. I don't know what an astute
interviewer would pick up from observing me at such a test
in a short time-frame.

I, though, would immediately form two equally-probable

1) the interviewer is (legitimately) testing on a (if not
normal, then) not-rare situation in that company, and
I probably don't want to work there, or

2) the interviewer is (illegitimately) testing on a
situation that is unlikely to ever arise in the company,
and is therefore an asshole (pardon my esperanto...),
and I probably don't want to work for a company that puts
people like that into positions of power.

If you need the new writer to be immediately as well-versed
in your industry and product as are your seasoned engineers,
then a specific, nasty test is useful and valid -- assuming
it tests for the requirements you advertised (and why
wouldn't it, if you value your time at all...).

If you need a writer who can learn your product and document
it for customers then, give applicants a chunk of spec and maybe
some data and, ask them to write a page or two, explaining
it to a defined audience. Let them do it on a text editor,
so that you aren't testing for immediate familarity with
a particular tool (unless that's an urgent hiring requirement).

In other words, test for what you really need. But first,
give some thought and discussion to what it really IS that
you really need... and are willing to pay for... <g>


Develop HTML-Based Help with Macromedia Dreamweaver 4 ($100 STC Discount)
**WEST COAST LOCATIONS** San Jose (Mar 1-2), San Francisco (Apr 16-17) or 800-646-9989.

Sponsored by ForeFront, Inc., maker of ForeHelp Help authoring tools
for print, WinHelp, HTML Help, JavaHelp, and cross-platform InterHelp
See for more information and free evaluation downloads

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 for more resources and info.

Previous by Author: RE: (was RE: Software for Students, Take 2)
Next by Author: Web-based Tutorial Needs TOC (Cross-posted to HATT list)
Previous by Thread: Technical test
Next by Thread: Re: Technical Test

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

Sponsored Ads