Re: techwr-l digest: June 13, 2000

[Chris Despopoulos <cud -at- arrakis -dot- es>]

Describe the last three products/systems/projects you
documented.  Describe the audience.  What was the delivery
format?  How long did each project take?  How many pages
were your direct responsibility for each project?  Did you
manage any other writers or contractors?  How long did each
project take?  Did you complete your part of these
projects?  In each case, what did "completion" actually
mean?

Describe how you estimate your project schedule, or decide
whether a manager's expectations of you are realistic.

Any experience with SGML?  XML?  HTML?  WinHelp?  (Should be
in resume, so maybe you don't need to ask.)  Ask about the
nature of the experience.  

List programming languages you can *write*.  List
programming langueges you can read.  Maybe include some code
to read, if that's important.

Sounds like you're in the hardware realm...  Ask what's the
difference between VHDL and Verilog HDL.  SPICE and HSPICE.

***************

The first two "questions" are not so much questions as
conversation starters.  But you should be able to learn
plenty about the person's experience.  If he can't say he's
completed a project yet, that tells you something. 
Likewise, if he only worked on 20 page documents, that can
tell you about fit in your environment.  

And estimation technique says plenty about experience.  The
old hand will usually say something like, "Whatever I decide
is realistic for me to do, I usually multiply by three, just
to account for network problems, useless meetings, politics,
slow review turnaround, changes in the product, and schedule
slips."  Ok, so only a fool or a sarcastic jerk would be so
forthcoming.  But I hope you get the idea.

Unfortunately, open-ended questions don't have objective
metrics that let you check off a predetermined level of
experience.  But for precisely that reason, I say they're
more informative.

Cheers                      cud