Overview of Interviews - Part III

This 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.

Read More

Overview of Interviews - Part II

In 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.

Read More

Overview of Interviews: Part I

In 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.

Read More

Résumés - Part III

In this issue, I'll explore the remaining two main sections of your résumé, and will wrap up the general discussion of résumés.

The first section that should appear after your Experience section is your Education. Most people simply list all of their relevant post-secondary certificates or degrees and where they obtained them. To add a bit more value to this otherwise dry section, consider including the following information:

• the website of the college or university, and perhaps also the website of your specific programme: you can include these as hyperlinks in Word documents
• a description of the programme: this can include a brief list of your major courses
• your grade point average (if it is high!)
• any major accomplishments that you made while in the programme, especially if your work experience is limited

There is some debate about whether you should include your year of graduation. Some say that if your graduating year was many years ago, it may make you or your educational experience appear "stale". However, if you omit the year, you may be raising concerns with potential employees as to why you have left it out. Therefore, I recommend including the year if possible. If nothing else, it shows that you are open and honest.

The other section that you can include is your Professional Associations and Activities. Here you list any work-related groups that you belong to, such as the STC, any STC SIG (Special Interest Group), editing or writing associations, computer groups and so on. If possible, include the range of time that you have been a member, for example, "2002 - Present". You can also include groups other than technical communication, such as charitable organizations, provided that that you can include descriptions of relevant experience with these groups.

In addition to listing your associations, give details of the major accomplishments or activities that you have done as a member. This includes volunteer work, writing contributions such as flyers and newsletters, websites, board duties and so on. You can split up your Professional Associations and Activities into two separate sections or you can simply include your activities in the Professional Associations section.

Unless relevant, do not list hobbies or interests - these should all be implied in your Associations section. Finally, you do not have to state at the end of you résumé: "References Available Upon Request". Employers know that if they do decide to interview you, you will supply them references if asked.

The key points to remember about a résumé is that it:

• is a marketing tool (with you as the product) which must grab the attention of the reader
• highlights the relevant information about you, your skills, experience and achievements
• gets you through the initial screening stages by "ruling you in" instead of "ruling you out"
• documents your qualifications by listing clear, meaningful and quantifiable accomplishments
• must be easy to read, comprehend and remember
• is better if it is too short rather than too long
• is a combination calling card, door opener and statement of your competencies

Finally, note that there is no one "right" way to do a résumé. Study as many résumés as you can and use the techniques in them that impress you. By doing this, and by constantly reviewing, updating and fine-tuning your résumé, it will be as unique as you are.

Read More

Résumés - Part II

In the last issue, I discussed some of the main elements of the résumé including the identifier, objective and profile. In this issue, I'll cover the Skills and Experience sections.

The Skills section is an optional segment that you can include after your profile or objective. This section lists your various skills, specifically your computer and software skills. Potential employees will appreciate a clear and concise listing of these skills as they try to match potential candidates to the job. You should therefore emphasize the skills that you have to the job for which you are applying.

For example, if the position specifically requires knowledge of FrameMaker and WebWorks Publisher, and you have used those products, list them at the beginning of your Skills section. You may wish to divide up your software skills into different sections such as documentation tools, graphical tools, operating systems, programming languages, and other programs such as spreadsheet and database applications.

There are, of course, other kinds of skills that you can list other than software, such as management and organizational skills, but generally speaking, it is often the software skills that employees are keenly seeking for most technical writing positions.

Next is the most important section of the résumé: the Experience section. Here you list your previous positions, starting with the most recent. Include your job title, the name of the company, the years that you worked (you do not have to state the months), an overview of your duties and responsibilities, and your accomplishments.

In addition to the name of the company, you can include a brief one-sentence description of that company, and the company's website, for example:

XYZ Limited - www.xyz.com A major developer of transportation management, supply chain and e-business solutions.

Decide whether to list the job title or the company name first. Because I have had the same title at my last few positions, I list the company first to easily distinguish each position. Whichever you choose, be consistent for all your listed positions.

When summarizing each position, have one or two sentences that describe your overall responsibilities, then list your specific duties and overall accomplishments. Include the tools that you used, even if they already are in your Skills section. Here is an example:

XYZ Ltd.- Technical Writer - 1994-1996 Wrote and managed user manuals and online help for a time management application using FrameMaker, WebWorks Publisher, and Microsoft Word. Interviewed Developers, Quality Assurance Engineers and Product Managers to develop documentation that was accurate and relevant to end users. Reorganized documentation to lower maintenance and translation costs.

After your summary, you must list what is probably the most critical part of the résumé: your accomplishments. You need to think very hard about how you improved things by lowering costs, increasing quality and improving efficiencies. You then must carefully word your accomplishments so that they clearly showcase your actions by using strong, positive action-oriented verbs. When possible, quantify your accomplishments with specific numbers.

Here are some good examples of accomplishments:

• Merged online help and user manual into a single source document, cutting translation costs in half.
• Combined three related user manuals into one, using conditional text to distinguish each version, reducing maintenance costs by 50%.
• Added missing documentation to the user manual, increasing the content by 35%.
• Corrected over 50 technical errors in the documentation that the developers had missed.

Remember - companies are looking at what you have done in the past to see what you can do for them in the future. If you can clearly show in your résumé that you have gone the extra mile to improve your projects, you will greatly enhance your professional image.

The next issue will cover the remaining sections of the résumé.

Read More

Resumes - Part I

Resumes are such a critical part of the job hunting process that I will be devoting at least two issues to them. Although a resume itself does not get you a job, it can get you an interview which can get you the job.

Effective resumes "sell" you. They are, in effect, a detailed business card and summary of your accomplishments. Employees are looking for workers who can add value, cut costs, work independently and are flexible and adaptable. Your resume, therefore, must show that you have these qualities.

There are two basic types of resume: chronological and functional. Chronological resumes list your careers in reverse chronological order. They are the more popular type, and for good reason: employers want to easily see how your career has progressed. Functional resumes list your skills by type or function, and are often used if you are trying to cover gaps in your employment history. Because of this, they may be viewed suspiciously, so try to use the chronological format if possible.

Resume Basics

In general, a resume should:

• Be printed on white or creme-colored 8 ½ x 11 paper.
• Use basic, legible fonts, such as Time Roman or Arial.
• Avoid wasting space by using graphics, rules, or fonts that are too large.
• Make good use of white space.
• Be written in clear, business-like English.
• Include bulleted points.
• Be a maximum of two pages.

Resume Elements

The top section of the resume is your identifier: it includes your name, address, phone numbers and email address. Include your title next to your name, for example, Joe Smith - Technical Writer.

I am against including any kind of objective on a resume. The objective should be obvious based on the rest of your resume.

The profile section is perhaps one of the most important areas of your resume, and one of the most difficult to write. It must describe you as a worker, and summarize your skills, strengths and experience. Avoid clichés like "team player" and "cost-cutter". Be specific about what makes you unique. Remember that the profile is often the first thing potential employees will read about you, and first impressions are critical.

Here's an example of an effective profile:

• Five years experience creating and enhancing a wide variety of documentation including User Manuals, Online Help, Release Notes and technical reference manuals.
• Able to work effectively with developers, quality assurance engineers and others to create clear, concise and meaningful documents from the end-user's perspective.
• Expert knowledge of a wide variety of applications including Word, FrameMaker, RoboHelp, Visio, and WebWorks Publisher.

The next issues will discuss the remaining sections of the resume.

Read More

Informational Interviews

In 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.

Read More

Assorted Information Development Sites

• Society for Technical Communication (STC)
• Toronto STC
• TECHWR-L Email List
• Online Technical Writing Textbook
• Technical Writing Course
• Writers Write
• tekwriter.com

Read More

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!

Andrew

Read More