This month, we continue our series on interview questions.

Where do you see yourself 5 years from now? 10 years?
The dreaded “crystal ball” question. Many of us have trouble knowing what we’ll be doing 5 months from now, let alone 5 years. (By the way, a wrong response to this question would be to say to the interviewer: “Doing your job!”)

A good way to handle this question is to turn it around by asking what opportunities will be available in the time period specified. From that, you can base your response, and say something such as: “It appears you’re heading towards a more XML-based environment. XML is definitely an area that I’d like to be involved with.”

Your response also depends, of course, on where you are now. There is no absolute standard on what constitutes a junior, intermediate, or senior technical writer, but the following guidelines are a start:

• Junior writer: 0-4 years experience
• Intermediate writer: 4-9 years experience
• Senior writer: 10+ years

So, if you’re a junior writer, for example, you might want to say that you are planning to handle the larger and more complex projects that an intermediate writer would be expected to manage.

Who makes a better technical writer: a technical person who has learned writing skills, or a writer who has learned technical skills?
This is an actual question I’ve been asked. At first glance, you might be tempted to answer this question depending on which type you are: a technophile who’s learned writing or a writer who has learned technology. You’d assume that you would defend your particular background versus the other type. But if you did, you might fall into a trap. Some interviewers will have strong opinions on this question – they will honestly believe, rightly or wrongly, that one type is favourable to the other. You want to avoid expressing an opinion that might be the polar opposite of the interviewer’s.

The truth is that people from either backgrounds can make good technical writers, and this is true for most “hybrid” professions. For example, a medical illustrator may have started out in the medical profession, and then learned illustration. Another medical illustrator may have started out in art and design, and then become interested in medicine. It would be impossible to determine solely from these facts who is the better illustrator: you’d have to look at their portfolios to see.

This is the point to make in responding to this question: that either type of writer has their strengths and weaknesses, and ultimately the only way to judge these writers is on the quality of their work.

You might briefly emphasize how your particular background has helped you, but don’t paint yourself into a corner by dismissing a particular type of writer.

Do you prefer writing from specifications or writing based on actually using the application?
Generally, the correct response is “the application”. Employees will hope that you become an expert user in the product itself, so that you can more accurately document what a typical user would need to know.

However, keep in mind you may not always have access to the application as early or as frequently as you’d like. Therefore you may want to add that you can use specifications, white papers, product descriptions, marketing documents, use cases and other internal documentation to get a good head start. Then, once you have access to the product, you can flesh out your documentation, verify it and fill in all the missing pieces. As many of us our painfully aware, the final, released product is often very different from its specifications!

What is the purpose of technical communication?
This is such an obvious and general question that it’s hard to believe you would actually be asked it, but in fact, this is another question that I have been asked. Note that a wrong answer is: “to keep technical communicators employed”!

Initially, you might think the answer would be something like “to instruct the reader on how to use a product”. That may be true, but then you have to ask yourself – what is the purpose of instructing users through documentation? The answer to that is: to reduce technical support costs. From a business perspective, this is the reply you should give. If possible, show how your documentation has done this. Maybe you created a troubleshooting section that helped users identify and fix common problems. Perhaps you added missing content or updated an index to make it more comprehensive.

Companies hire technical writers not out of the goodness of their heart, but because the alternative is unthinkable: users constantly calling technical support for every single possible question. By indicating that you’re aware of how critical it is that documentation be as complete and accurate as possible, and thereby lowers support calls, you show that you recognize the important role documentation plays in minimizing costs and thereby maximizing profits for the company.