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: Tools versus skill set From:Chris Despopoulos <despopoulos_chriss -at- yahoo -dot- com> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Thu, 8 Oct 2009 04:47:29 -0700 (PDT)
Advice for your friend...
Assuming your other skills are sufficient to land an interview, then you can start to address the situation. I will say, if the job posting is for an *expert* in tool X, then you're probably applying for the wrong position. Tool experts are usually there to rev up the tool beyond what the normal user can do. They're hired at least in part for their specialized knowledge of the tool.
A lower level of tools requirements is just exposure to the tool. Given that level, if it's a tools issue for tech writers, it's probably one of:
* FrameMaker
Find somebody who has experience with it. The main problem here is the concern
that a newcomer will screw up documents by deleting markers or not using the
templates correctly. Get a few personal tutorials, and make sure you understand
the things that can go wrong and how to avoid them. Then when you're in the interview
you can at least say, "I know how to take care of your files. And I'll be productive
in no time."
* Word
Heck, I'm a slug with Word. But everybody has *some* experience with Word. Either
that, or you have serious computer-skills issues to overcome in this situation. Exposure to
Word is essentially a computer literacy litmus test.
* XML system X (ArborText, most likely)
You won't have a chance to get your hands on a complete system in time for an
interview. But you can certainly read up on XML to understand what it's all about.
Dive in and at least learn the talk. Again, that means you understand why they
have the system, and how to keep from screwing it up. Any installation will be somewhat
vertical anyway, so exact experience is highly unlikely. Talk about your experience with
version control systems -- as a QA person, you probably have touched code and dev
environments. That's germane.
* Version Control
If you have QA experience, you probably have experience with this.
All the gloomy messages you got may be true. But your friend's experience may be sufficient to overcome that. You have to assume it is until you hear otherwise.
Free Software Documentation Project Web Cast: Covers developing Table of
Contents, Context IDs, and Index, as well as Doc-To-Help
2009 tips, tricks, and best practices. http://www.doctohelp.com/SuperPages/Webcasts/
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-