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.
> On my team, we are working to improve our interview process.
> Our current
> process relies mostly on what technical writers (or their
> references) think
> their skills are and does not really give them much
> opportunity to exhibit
> those skills. I am looking for suggestions from other writers
> on effective
> ways to determine a candidate's true skill level with tools
> and writing style.
If a requirement of the job is that the person be able to
read code in a specific language, and they need to start
being intensely productive within a day or so of starting,
then I suppose it makes sense to have a sample for them to
decipher.
I don't "speak" any modern programming languages (and have
forgotten the ones I learned in the distant past), so it
would likely take me a couple of weeks to be able to read
(say) C# or Ruby or whatever. So, given that I'd be
wasting your time because that's most of what would be
expected of me and I couldn't do it right away, it would
be in your interest to find out in the interview... just
don't spring it on me as a surprise ... or I might find
out where you park your car... :-)
For general writing skills, you'd have my samples,
and if you don't trust me to be presenting my own stuff,
you could ask for a quick para or three on some topic.
Probably the most useful test, and the one that I'd least
resent (and most expect) is an editing test. I should
be able to read a few paragraphs and pick out the goofs.
If there are some parts with which you disagree, I should
be able to defend my choices (to change or to leave as-is).
As for tools... that's a very hit-or-miss thing. I may have
used Word (or Frame, or you-name-it) for years, and not
needed to do the specific tasks that you test for. I'd likely
fall on my face under really short time pressure (in a test
situation). But when it comes to getting the job done, I'd
just figure out the new-to-me aspect of the tool while
working, just as I do in every job. I have a resourceful
brain, and I know where to go for Help and for help.
Just because I couldn't figure out and fix your arcane
header-numbering-and-ToC-munging system in fifteen minutes
doesn't mean that I was lying about my experience with
the tool. I just hadn't done THAT with the tool before.
Of course, if part of your joy in the interview process is
humiliating people who thought they were good for the job...
well that's another story... :-)
Kevin
The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today! http://www.webworks.com/techwr-l
Easily create HTML or Microsoft Word content and convert to any popular Help file format or printed documentation. Learn more at http://www.DocToHelp.com/TechwrlList
---
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-
