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:Re: Lying applicants (long) From:Niebergall Peter-APN001C <apn001c -at- EUROPE -dot- MOT -dot- COM> Date:Mon, 21 Sep 1998 15:06:08 +0200
Nice airing of concerns here, Sue. I can't help but to blow into your
horn here:
What the hell is wrong with project leaders these days? If they don't
have a clue about their project manpower and qualification needs, who
can ?? I'll garnish the <RANT> with a recent experience...
Currently I'm in the process of checking out my market value by loosely
searching which projects need tech authors within Europe. JobServe, a
UK-based webmarketplace for IT professionals, does a neat job in
presenting consulting firms job postings Europe-wide, so every morning I
get an e-mail about new contract possibilities, filtered to "Technical
Author" and "contract"ual work only, which currently generates a daily
result of about ten to fifteen more or less new job offers.
Here's one thread: One company was looking for a tech author with
extensive MS-Office background and experience in banking. OK, that fits
for me, so I sent them an English CV (yes, they have different layouts
in different countries), so far, so good.
I got back a confirming e-mail (which is the least you can expect from a
decent agency that isn't just a CV-shunting yard), stating that all the
client expects is the willingness to produce a "single-source" (hoho)
documentation using only MS Office and Acrobat. OK, I figure, writing
something in Word, then taking it to the Distiller for .PDFing shouldn't
be outside of my learning curve (especially with a resource like this
list in the background), so let's have an interview... Two hours later I
got a call from the project leader, who started the phone interview with
an unfriendly "I don't want to hear a word about Framemaker and SGML, we
don't have the time for it...but knowledge of VB, VBA and Access is more
important to us than technical writing experience...".
Another ten minutes into the interview I found out that they were
looking for an information designer to roll-out an Access
business rules document control database with a very tight schedule and
numerous, undefined interfaces to produce printable documents and html -
in German we would say that this guy wants an "egg-laying,
milk-producing wool hog". They don't know what they want, yet they want
it done quickly and, even worse, they refuse to allocate the time to
introduce the tools to do the job right: the project is bound to be a
white elephant.
Why the hell did they ask for a "Technical Author with MS-Office
background" (btw, Access is in Office as of "Pro" version) when they
wanted a database designer in the first place ? Or am I overlooking
something here ?
They could have gotten what they wanted by buying the product
HTML-Transit Central Station for less than half of a consultant's daily
fee, but I think destiny will take care of that project... </RANT>
So Sue, let's not get too upset here - it's the good old GIGO-game:
Garbage In, Garbage Out. You can't blame the agency (they just repeat
what they're told), you can't blame the consultant. You can blame her of
overestimating her abilities, but in the world of databases and SQL
there are lots of simple questions one can ask in an interview to figure
database skills out very quickly.
Andrew, one thing I can surely blame you for: you didn't set up the
initial interview with an inhouse database designer/SME and your
contractor (among others) in a proper fashion. All interviews I ever had
for database programming or design jobs included questions like "Explain
the difference between entity-relationship diagrams and storage
classes..." - and it's hard to bull on those...;^>. So work on your
client's interview skills, that'll keep the dead cats in somebody elses'
(??) back yard.