Overview of Interviews – Part II

See the source imageIn the sprit of Halloween, the following is a “scary” excerpt from an article entitled “True IT Confessions” by Chad Dickerson, appearing in the September 29 edition of InfoWorld magazine, sent in by Toronto STC member Dorothy Birtalan:

“…the dirty little secrets of your IT department generally remain hidden from view – but, oh, they can be ugly…One problem is simple: documentation, which sometimes hides the ugliness from the IT department itself…most developers and systems administrators finish a project and quickly put it to bed, sometimes without any documentation. Many times, I have scanned a particular system’s documentation during a crisis only to find that it had not been updated in several months (or even years). Small and undocumented changes can add up to large, undocumented messes…”

You can read the complete article here.

This quote reflects an unfortunate fact to be aware of during an interview: that documentation is often a neglected area within a company. During an interview, you should try to assess the state of the documentation department by asking questions such as:

  • How often do you update your documentation projects?
  • Do you view documentation as part of the development process?
  • Do you build review times into the development schedules?
  • Will I have access to the product to be documented?
  • Will I be included in product development and bug review meetings?
  • Are reviewers held accountable to the accuracy of the documentation they review, and the dates by which the reviews must completed?

Note that this probing works both ways: a good interviewer will try to assess how you well your would work for them by asking questions such as:

  • Do you work well under pressure?
  • How do you handle multiple projects?
  • How do you ensure others review their drafts on time?

Try to glean from all these questions what working there will be like. Do you sense there is extreme pressure and long hours? Does management understand the complexities of the documentation process? Is documentation something that is developed concurrently with the product itself, or is it something that is quickly “thrown together” at the last minute?

In doing so, you will find that all companies fall somewhere into the “Documentation Relevance Spectrum”, which can be represented as:

Importance of Documentation Process

(Less) (More)

At the far left edge of the spectrum, documentation is not considered very important, minimal resources and attention are given to it, and technical communicators are given little input, if any, into the development process.

At the other end, documentation is considered critical; full resources and attention are given to it, and technical communicators are given extensive input into the development process. They may even be asked to give feedback on product design and usability, review error messages, test the product and report bugs.

During an interview you need to determine where the company falls on this spectrum. Most will be somewhere in the middle, but you may find some closer to one end or the other. Obviously, most of us want to be at places nearer the “right” edge of the spectrum, but a few may not. Some people actually thrive in a high pressure environment and seek the challenge of improving existing processes.

However, even at companies where documentation is highly valued, never forget it is still one among many departments that must compete for limited resources and attention. Often technical communicators fall into the trap of viewing the work required to create a product as simply:

1. Documentation
2. Everything else

As a result, we often complain that we do not get the respect and attention we deserve. While there is some truth to this, it’s important to see things from the perspective of the product manager or project team lead – this person may even be the one interviewing you! For them, documentation is one of many areas required to complete a project, so they will view the development process as:

  • Research
  • Prototyping
  • Business analysis
  • Usability
  • Development
  • Documentation
  • Quality assurance
  • Performance testing
  • Training
  • Sales
  • Support
  • Customer relations
  • Marketing

Like you, people in these areas often feel they are not getting the time and attention they deserve. Therefore, your task in the interview is to convey the impression that you a reliable professional who is aware of these other areas, and who can help the company by making documentation one less thing to worry about. Even managers who value the documentation process do not want to devote any more time to it than absolutely necessary. They want writers who can quickly assess and manage their projects, in order to free up the manager to focus on all these other areas. This is the impression you must convey the interview – you must be “The Fixer” that feels their pain and eliminates it, or at least minimizes it!

In the next issue, I’ll begin discussing some of the specific questions you may be asked, and the effective responses to them.