RE: Technical Test

[KMcLauchlan -at- chrysalis-its -dot- com]

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 
assumptions:

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>

/kevin

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-Based Help with Macromedia Dreamweaver 4 ($100 STC Discount)
**WEST COAST LOCATIONS** San Jose (Mar 1-2), San Francisco (Apr 16-17)
http://www.weisner.com/training/dreamweaver_help.htm 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 www.forehelp.com 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 
http://www.raycomm.com/techwhirl/ for more resources and info.