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.
Subject:FW: Long Summary: Good Interview Questions From:Alexia Prendergast <alexiap -at- SEAGATESOFTWARE -dot- COM> Date:Thu, 31 Jul 1997 08:06:42 -0400
This e-mail message I received from Stuart Burnfield
has some good ideas for interviewing for more junior
positions -- I'm posting it with his permission.
A.
--
Alexia Prendergast
Senior Technical Writer
Seagate Software mailto:alexiap -at- sems -dot- com
>----------
>From: Stuart Burnfield[SMTP:slb -at- fs -dot- com -dot- au]
>Sent: Wednesday, July 30, 1997 12:00 AM
>To: Alexia Prendergast
>Subject: Re: Long Summary: Good Interview Questions
>
>
>Alexia -
>
>when I was interviewing for junior programmers it was hard to tell them
>apart because they'd always have impressive transcripts and samples but
>not much else to go on. I used to like asking about testing. This was
>my sneaky way of finding out if they had any sort of customer focus, or
>if they were just good at turning out artificial programming assignments
>for lecturers.
>
>I'd ask:
>
>- why do you test programs?
>- how do you test programs?
>- how do you know how much testing to do -- that is, how much testing
> is enough?
>
>I found this an excellent way to weed out unsuitable applicants. Some
>people were absolutely floored by the question. Answers I liked to hear
>were:
>
>- to show that the program performs as described in the spec
>- to find hidden assumptions I made in writing the program
>- to show that the end result is acceptable to the end-users
>- the cost of testing should correspond to the cost of failure
>
>Answers that didn't impress me were:
>
>- (ten second pause) to prove that the program works?
>- test every possible combination of inputs
>- see if the program produces the right answer
>
>To bring it back to your message, I think similar questions could be
>very useful for assessing TWs. When is the documentation finished? How
>do you know if the documentation is successful? Who else might see the
>documentation apart from the writer & end user?
>
>I wouldn't necessarily use this on experienced writers -- they should
>have a track record and references anyway -- but for aspiring TWs I
>would like to find out if they know who pays the bills, and how they
>judge the quality of their own work.
>
>Regards
>---
>Stuart Burnfield
>Functional Software Pty Ltd
>mailto:slb -at- fs -dot- com -dot- au
>
>
>
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html
