Interview Questions – Part III

Image result for funny interview memesThis 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.

Interview Questions – Part II

See the source imageWe continue our series on interview questions and strategies for dealing with them. And the first question is…

List three of your greatest strengths.
This is a difficult question because many people are quite modest and don’t want to appear boastful. The key here is not simply to list your strengths but to show how they are valid by including specific examples of them.

For example, don’t just say that you write from the end user’s point of view; state how you do this.
You could say that you discuss in detail with business analysts and product managers who your typical users are, their technical abilities, how much training they will have, and ultimately what they will be using the documentation for, and develop your documentation accordingly.

To develop your list of strengths, you need to carefully examine yourself and the projects you have worked on, and derive a list of the positive qualities you have used when managing these projects – these may include qualities such as:

  • the ability to lower costs creating documentation that reduces the number of technical support calls
  • the ability to improve efficiencies by merging duplicate documentation and using conditional text to distinguish multiple versions
  • demonstrating innovation and creativity by taking the initiative to improve the layout and design of documentation templates

What is your greatest weakness?
The antithesis of the previous question, and also a difficult one to answer. Most experts suggest stating a weakness but then giving it a positive spin by indicating how you compensate or learn from it. For example, you may say that you sometimes find it stressful to rush to complete a project when there is not enough time. As a result, you have developed a good system of creating a documentation plan with specific tasks and dates, and ensuring that you and others follow this plan to avoid a last-minute rush.

How would your boss (or co-workers) describe you?
Ouch – a nightmare question. Often we may have no clue what others think of us – we hope they like us, but it is impossible to know for certain, which makes this a very loaded question. Some of the qualities you list may be among your strengths discussed previously, but you should try to state those qualities that emphasize you are a “team player”. For example, you could say that others would describe you as friendly and approachable, and then give an example where you worked with others to solve a problem or meet a deadline.

Tell me about a time you failed.
Another question from hell. Always have one or two stories ready about a project that did not go as well as you’d hoped. Then describe what you learned from the experience. For example, you may talk about having to release a document only to discover later that due to time constraints, certain procedures that should have been documented were missing. As a result, when you had time, you later reviewed the application and included all of the missing procedures in time for the next release.

By the way, this is a great example of a “stress question”. The interviewer is looking not only at the content of your response, but the way in which you respond. It is critical to remain unfazed and to answer the question slowly and clearly. The interviewer is trying to trip you up to see how you respond under pressure – recognize this is part of the game and remain confident.

What do you like about your job? What don’t you like?
Most technical communication jobs involve similar activities, so it should not be to difficult to find tasks and responsibilities that exist in both your current (or former) job, and the one to which you are applying. Therefore, try to list two or three things that you enjoy doing in your job which you know that the job in question also entails.

For example, if the job involves working on a wide variety of projects simultaneously, and that is what you are currently doing, then mention that, and say you enjoy this kind of variety. Other tasks you may list could include working with certain tools, using and testing the application you are documenting, creating indices, and so on.

Describing what you don’t like is a bit tougher. It’s probably not to advisable to say “I don’t like the fact I have to be at work every day!” Recognize this is another form of the question “What is your greatness weakness?”, your weakness being that you do not enjoy putting up with some aspect of your work.

Again, the strategy is to state how you deal with this weakness and learn from it. For example, you may say that it’s frustrating if critical information that could affect the documentation is not being passed on to you. Because of this, you make an extra effort to stay within “the loop” and ensure that you are getting all of the information you need, by keeping in continual contact with your SMEs.

Interview Questions – Part I

See the source imageHappy New Year! This year, we’ll start looking at specific interview questions and some good strategies for responding to them. Many of these are actual questions that I have been asked. Although there is never only one right answer to a question, there are effective methods that can help guide you in your response.

Some general principles to keep in mind when answering questions are:

  • Think carefully before you speak – if necessary, ask if you can respond later. But note that the more questions you have practiced your responses to, the less likely you will have to ask for more time.
  • Give short, clear, direct answers; 30-45 seconds is usually enough. Less is often more.
  • Speak slowly and clearly – it’s very easy to talk quickly when you are nervous – remember it’s the not quantity of what you say but the quality.
  • Always be honest – never lie, embellish or distort the facts – eventually it will catch up with you.
  • If you don’t understand the question, say so. Rephrasing the question back to the interviewer is a good way to clarify its meaning.

Now – on to the questions:

Tell me about yourself.
This is probably the world’s most dreaded interview question, because it is so open-ended and vague.

To properly answer it, you have to understand that this question really means: “Tell me about yourself in relation to this job, what is you have done, what you are doing now and what you hope to do in the future, to show me that you would be the best person for this job.”

You need a solid response to this question that nearly sums up your history and abilities, for example:

“I’m a technical writer with six years experience working on a wide variety of projects from user manuals and online help to technical and installation guides. I’ve also been involved in product design and have submitted many valuable product enhancements. I enjoy the whole process of creating documents that are accurate and helpful to the end user. Eventually, I hope to become more involved in the area of content management, which can greatly reduce costs by eliminating the duplicate information within an organization.”

You should also mention the specific tools that you have used, especially if they are the ones required in the job.

Name three things you like about technical writing.
I was once asked this question, and admit I had a tough time answering it! Everyone will have their favourite activities, so practice stating what these are so that you have an eloquent response, in which one activity flows neatly to the next, for example:

“I enjoy the process of gathering the information required to create a document, including meeting with the subject matter experts, reviewing the technical material and using the product itself. Next, I like the process of organizing and “translating” this highly technical information into a comprehensible format. It’s very intellectually satisfying knowing that I have created something orderly and meaningful out of chaos. Finally, I like the process of continually improving the project, both before and after it is complete. I feel that there is always room for improvement and welcome feedback from others.”

This response shows that:

  • you genuinely enjoy what you do
  • you have a sincere desire to make a quality product
  • you are willing to accept suggestions from others and be a team player

Why are you interested in this position?
One of the most important questions you will be asked. You can only answer this question effectively if you have:

  1. Analyzed yourself and thought about your skills and what you like to do.
  2. Carefully studied the duties and responsibilities of the position itself, and studied the company and its “personality”.
  3. Demonstrated how there is match among all these things: you, the job and the company.

In otherwords, you must state how there is a harmony between:

  • yourself, your personality, your skills, the things you enjoy doing
  • the job, the company and the people in it.

The more you can show how similar these things are, the greater your chances of success. You must show how you were “born” to do this job, at this place, at this time, and that it represents a great opportunity for both you and the company.

Here’s a sample response to this question:

“I’m very interested in this position because it would allow me to continue using the skills that I enjoy the most, namely – using FrameMaker to create complex but well-organized documents for a software product, and scheduling and prioritizing a wide variety of projects. Also, this position involves testing the product and giving feedback, areas that I think are particularly important. I’m very much a “user advocate” and in my current position have submitted many suggested changes for screen, field and button names, dialog box messages including error messages, and screen design and layout, all of which made the product easier to understand and use.”

The point you want to make in your response is that you are a professional communicator who brings a unique outside perspective, and who is genuinely enthusiastic about this position because it matches your skills and desires.

We’ll look at more questions over the next few issues.

Overview of Interviews – Part III

Related imageThis month, we’ll examine the best strategies for answering interview questions. To introduce this topic, it can be quite educational (and very amusing) to look at some wrong approaches. Here are various actual reasons interviewers have heard when asking applicants why they wanted the job:

  • he could be an asset to the company softball team
  • he had a great smile
  • she was a redhead, and the company had no redheads
  • he had just won big at the casino and was on a roll
  • he was tired of living with his parents
  • he had been rejected by all the good agencies
  • he wanted to be able to ride his bike to work
  • she had always wanted to work in our building
  • he was the sole source of support for his puppy

Aside from being hilarious, these answers have one thing in common: they all reflect the fact that the applicant is only thinking about their needs and what they want the company to do for them. Although most people are intelligent enough not to give answers like these, these anecdotes reflect a common problem people have during interviews: they are so focused on themselves they forget or ignore the fact that they should be equally focused on the company’s needs. However, it can also be a problem if you focus too much on what the company wants and not enough on your needs. A successful interview, therefore, is one in which both parties:

  • know themselves and what it is they want
  • recognize they are equal partners in a potential business proposition
  • know what the job entails
  • recognize if there is a good “fit” or not
  • do about the same amount of talking

Interviewing is very similar to dating. In both activities, you and the other party are trying to learn as much about each other as possible in a relatively short amount of time, and often under pressure, with the goal of a potential long-term relationship. Neither side wants to appear too anxious or too aloof, and this can be a very difficult balance to maintain. The attitude you want to subtly reflect during an interview (if the job interests you) is that you would like this job, but that you don’t need it.
Recognize that behind every question an interviewer asks, there is fear. Fear that you will not fit in. Fear that you are lying or overstating your accomplishments. Fear that you will not get along with the interviewer or with the other workers. In other words, fear that you are not the right person for the job. The interviewer is often just as scared as you are – scared that they will select the wrong person and cost the company time and money.
Your task, therefore, is not only to destroy this fear by showing that you are a professional who is genuinely interested in the job, but to replace it with another fear: the fear of what will happen if they do not hire you. That is why you must solidly know your accomplishments and be able to list them strongly and succinctly. For example, by showing how you have improved processes and contributed to the quality of a product, you are planting a seed of fear that if the interviewer does not select you, their company’s products and documentation will continue to contain hidden problems and will not be as effective as they could be. Presenting “before and after” samples from your portfolio that graphically illustrate how you improved the documentation or the product itself can be tremendously effective.
Over the next few issues, we will begin reviewing various questions that you may be asked. However, all interview questions are really different variations of the same, basic question: Why should I hire you?
You may not be asked this question directly, but you still must know the answer to it. You have to be able to explicitly state your strengths and what distinguishes you from all the other applicants in order to win the job.

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.

Overview of Interviews: Part I

Image result for funny interview cartoonsIn the first year of this column, I explored some of the introductory stages of the career management process including: knowing yourself and your skills, researching companies, and creating effective résumés. This year, I’ll be continuing on to the next logical stage: job interviews. Because this is such an important topic, I’ll be devoting several issues to it.

Job interviews can be quite stressful for many people. It may be impossible to eliminate all the stress, but through careful preparation, you can minimize it.

In the days before your interview, learn as much as you can about the position and the company. Study the company’s official website, but also try to get additional information through other media sources, as well as through friends and contacts.

Try to anticipate the company’s documentation requirements. Using your résumé and the job description as a guidelines, plan how you will relate your previous experience and current skills to the needs of the company and the position. For example, you may have experience working with certain software or managing specific kinds of documents. You need to “tie in” these things to the job requirements to clearly demonstrate that you are the perfect match for this position.

Generally, companies are looking for workers who:

  • are quick learners and “team players”
  • are flexible and adaptable
  • work well under pressure
  • can handle a wide variety of projects
  • can add value and lower costs

Carefully plan how you will show the interviewer that you are this type of worker, using specific and quantifiable examples. Companies will assume that how you have worked in the past indicates how you will work for them.

Practice the interview with another person. Anticipate the kinds of questions you will be asked, and rehearse your general responses to them. I will be covering specific interview questions over the next few issues, but most career management books will have good sample questions, such as “Tell me about yourself” and “Why do you want to work here?”

In addition, you must plan and rehearse the questions that you are going to ask the interviewer, such as:

  • What are your greatest documentation challenges?
  • What kinds of documents and tools do you have?
  • How frequently is your documentation updated?
  • Who is involved in the development and review of documentation?

At least one day before your interview, ensure that you have everything ready. Do not wait until the day of the interview! This includes:

  • your clothing
  • your portfolio, printed or on a CD
  • a leather folder, notepad and a good pen for taking notes
  • extra copies of your résumé
  • directions to the interview (call to confirm if you are unsure!)

Note that first impression are critical: studies show that people will formulate an opinion of a person within the first 30 seconds of meeting them. Your physical appearance, therefore, is crucial.

The following advice may sound “preachy”, but it is a fact that you will be judged on your physical appearance as well as your technical abilities.

Your hair and clothing must be clean and neat. Conservative dress is best: wear a simple, neutrally-coloured dark suit, such as grey, charcoal or navy. Men should wear a long-sleeved solid white shirt, freshly pressed, and a silk tie with a subtle pattern. Women should wear a pale-coloured blouse that goes with the suit. Shoes and belts should match. Keep jewelry simple and to a minimum: a high quality analogue watch and no more than one ring.

If you have not purchased a outfit in several years, now is the time to make the investment. If you’re not sure what to get, ask the salesperson for advice! Don’t be shy about explaining that you are going to an interview and must look professional.

To sum up: the more you can prepare for an interview, the greater your chances of success, and the lower your stress level will be. No one goes to an interview planning to fail; they usually fail to plan.

I will continue with the topic of interviews in the next issue.

Informational Interviews

Related imageIn the previous issue, I described how to narrow down the list of companies you want to work for. This is a critical part of the investigative stage of your job hunt. This issue, I’ll discuss the process of interviewing individuals at the companies you are researching. Note that you are not asking for a job at this point – you are simply trying to find out as much as you can about the company and what they do. It is important, therefore, to keep the meeting brief – usually no more than 15 to 20 minutes. Ideally, you want to interview the person who has the authority to hire you, such as a technical writing manager or VP of Development.

Before you approach the company, you should have done as much research as possible. You need to have a good knowledge of what the company does and be able to anticipate what their documentation requirements might be. The questions you want to ask, therefore, should be those which give you information that is not publicly available or common knowledge. In a sense, you have to be a bit of a reporter and detective – figuring out the company’s needs, wants and current problems.

You might ask:

  • What kinds of documents do you produce?
  • Are there any documents that you would like to offer that you currently do not?
  • What changes, if any, would you like to see in your documentation?
  • What software tools are you currently using?

Note that these are also questions you can ask at a job interview, in order to show that you are interested in the company and its challenges, and are not simply there to find out what they can do for you.

If appropriate, you can share your experience with similar projects or problems. But don’t be too aggressive on these points – remember, you are not asking for a job.

Like a job interview, you should also be prepared for questions that they may ask you directly or indirectly, such as:

  • Why are you here?
  • What can you do for us?
  • How have you added value in the past?
  • Why should we be interested in you?
  • What are your future plans?

After the interview, it’s important to send a thank you note (or email) within one day.

The point of this whole process is to get critical “face time” with potential employers. Companies are much more willing to hire people who have shown initiative and who they have actually met. That is why this method of job hunting (contacting companies directly) has about an 85% success rate.

Detailed Profile

The blog offers my views on various topics and how they relate to technical communication.

I’ve been a senior technical writer at Oracle Canada in Toronto, and have worked in software and technical communication since the early 1990s.

Valuable, well-designed information that can be easily accessed and understood is critically important. As Gordon Gekko said in Wall Street, “the most valuable commodity I know of is information.” The challenge is to get the right information from the right sources, and then act on it.

Documentation itself is rapidly evolving from its traditional page/chapter/book format to a pure object-oriented format, in much the same way that programming code has evolved. Text reuse is not an option in my “book” – it is an absolute necessity. Content needs to be separate from its form.

Currently, many technical writers function both as information developers and information designers. Eventually, we’ll need to specialize in one of these areas, the same way that architects create the basic structure or architecture of a house, and interior designers work with the interior and content of the same house.

Enjoy the blog!


Finding Your Future Workplace

Related image

Last month, I discussed self-assessment, which included knowing exactly what work you want to do and where you want to do it. This month, we’ll look at the best ways to find the place where you want to work.

At first this may seem like an overwhelming task because there are literally thousands of companies that exist. However, by doing some logical analysis, you can narrow down the list to a manageable few places.

The first step is to decide the size of company you want to work for. Most job growth is happening in small to medium size companies, with about 200 employees or less. The large corporations are simply not hiring like they used to, and even if they were, consider this: at a large corporation, you may be one of many technical communicators, either at a specific location (if the company has several offices) or within the organization as a whole. You will therefore be more expendable than if you were the sole technical communicator (or one of a small group) for a smaller firm. Therefore, it makes sense to target the smaller companies. I am fortunate to work for a company of about 90 people, and am the sole internal technical writer. Although there are no guarantees, the smaller the company, generally speaking, the greater your value and the opportunity for growth.

Another step to reducing the number of companies is to consider location, not just in terms of distance but travel time. How far are you willing to drive to get to work? If you live in Toronto, are you willing to commute to Mississauga? Are you willing to work downtown?

But more than just size or location, consider the specific industry in which you want to work, and be more specific than just choosing, as an example, “the software industry”, which could mean almost anything. To narrow things down, you must study the trends in business and industry as a whole. For example, because of Canada’s aging population, there are tremendous opportunities in the medical profession, and all of its associated industries like medical diagnostic software and equipment.

Although you can use the Internet to research specific companies, keep in mind that a company’s website is simply the picture that the company wants to paint of itself. It won’t have all the inside information such as the problems the company may be having or the specific challenges facing its documentation department. For this kind of information, you must turn to other sources such as newspapers, trade journals, business magazines, and most importantly, networking.

Many people think networking is a tool only for discovering hidden jobs. In fact, it is one of the best ways to gathering information about companies and industry trends in general. Ideally, you want to develop a network of contacts that will include people who work at companies that you wish to work for, or people that know these people. This allows you to make a “warm call”, where you can introduce yourself as a mutual friend of the person you are contacting.

The purpose of the warm call is not to ask for a job but simply to arrange an informational interview. I’ll cover this topic in detail in the next issue.