Re: Resumes/certification

[Gary Merrill <merrill -at- HYPERION -dot- PDIAL -dot- INTERPATH -dot- NET>]

>   Ben Kovitz <bkovitz -at- igs -dot- com> writes:

>  One other note very relevant to the hiring process:  Get *samples of the
>  writer's
>  work*.  That'll tell you one of the three things you most need to know to
>  make an
>  intelligent hiring decision:

>          Does the candidate do good work?

Unfortunatelly, it may not tell you this as accurately as one might suppose.
Editors are wonderful, aren't they?  Their expert work can easily obscure
the true quality of a writer's.  Also, simply from a pre-existing sample of the
applicant's work you can have absolutely no idea of how long it took the
candidate to get the document to that stage, how many revisions were
required, or how much editing was applied.  In fact, in pathological cases
you cannot even be sure that it *is* the candidate's work -- or how much
of it is.  Still, I agree that this is a good (essential) thing to examine.

>  Obviously, to tell if the candidate is the sort of person you can work with,
>  you'll
>  need to sit down and talk.  As for background knowledge, you can usually get
>  some idea of that from the person's work history, and again you can tell a
>  lot
>  (if you're skillful) by talking with the person.

And you need to take this opportunity to explore the applicant's understanding
of the writing samples that have been provided.  This can tell you how well
the applicant has understood that work and the degree to which the work truly
is his.

A number of companies are now giving an on-the-spot writing test:  something
along the lines of " provide documentation for the following task".  If this is
accomplished in good form with few mistakes, and the result matches in overall
quality the samples provided, then this tells you that those samples do in fact
reflect the applicant's ability.  If the test contains numerous mistakes or is
otherwise flawed, this serves as a good consistency check against the samples.
You don't expect perfection on such tests, but even so, the results can be
extremely valuable.

You need to be careful of being too nit-picky with such things.  I used to be in
an environment in which applicants for jobs as developers were given a test
in C programming.  This was done as an "oral exam" sort of thing and frequently
became simply an opportunity for the examiners to attempt to show off their
own prowess.  I never endorsed this type of test because anyone with half
a brain can learn a particular programming language -- it doesn't make you a
good programmer.  And I have known enough programmers who were expert
in various languages but were incredibly poor software developers.  When I
first sought to move from my academic position to software engineering I
interviewed with a small company which asked me to come with samples of
code I had written -- the language didn't matter.  They were using Pascal,
and I had been writing in C.  The interviewers (the two owners) then took
my samples and retired to another office for about 15 minutes.  When they
returned they asked rather specific questions about why I had done things
in the way I had and why I had not done them in certain alternative ways.
This remains the best and most complete (and I think objective) interview
I have ever had.

Likewise, in the area of writing it might be valuable to probe an applicant's
skill in identifying grammar and style errors.  But someone could be exceptional
at such editorial tasks and yet be virtually unable to construct a coherent
description of anything.  So you need to know what you are looking for and then
design some simple methods to see whether an applicant has it.

It is not terribly difficult to look quite good on paper.  It is much more
 difficult
to look good on paper and then back that up by being able to discuss those
accomplishments in detail and to produce something similar on the spot.

-------
Gary Merrill