I Can C Clearly Now

The following article contains much wisdom:
All I really need to know I learned in kindergarten.

I would this reword to:
All I really need to know about technical communication I learned from the letter C.

C is the first letter of all the important concepts, practices and other things that you’ll ever need to know about our profession.

We must, of course, excel at Communication, and not just the written kind. We must be excellent visual communicators, with a firm eye for the design and layout of images, diagrams, and text. This includes a good knowledge of typography, graphics, and effective diagramming – for example, formatting screen shots so that each part is clearly identified. We must be effective and Competent informational Craftspeople, taking great Care in every word we write.

We must strive for Clarity in our work. This means being Childlike, with an endless Capacity to ask foolish questions, and thereby obtain the answers our readers Crave.

Clarity includes being Comprehensible. If our readers (or Clients) cannot understand what we’ve written, why did we write it? We must therefore be Customer-focused. Ideally, we should observe our readers attempting to use our documents. At a minimum, we should provide a simple way for them to directly send us their Comments and Criticisms. This involves having Compassion for our readers. They are often stressed when they reach out to our guides. Our job, therefore, is to Care about our readers and create documents that gently guide them onto the right path.

The Content we develop must be Complete and Comprehensive. A document is a puzzle, but one in which you may not know the number of pieces. Knowing that you don’t know what you don’t know is the first step in knowing what you need to know, you know?

At the same time, our documents must be Concise. We should use as many words as required, but no more. We can achieve this balance through the Chunking of information. For example, we can create a simple overview page that contains links to various topics, rather than listing the entire contents of all these topics on one page.

Organizing and chunking the information involves Curating, the active management of all our informational objects. A museum curator decides what pieces should be displayed, where and how; we must do the same.

As we curate our information sets, we must be Cost-Conscious. This involves effective time and project management as we juggle all our guides. It also involves Content reuse at the topic, paragraph, sentence and even word level. Common copyright information, procedures and tasks, and templates are just some of the things that should only exist in one place. This will lead to greater Consistency in all our documents.

Consistency is extremely important. You should not call the same thing by different names, nor describing different things using the same.

Our documents must be Credible (or believable). If there is an error in a document, its credibility is destroyed. Also, we must be credible. Others must believe what we say when we give our advice on content and design and trust that what we say is true – this relates to Confidence.

As you grow in your career, your confidence grows. A junior writer asks others: What should I do? A senior writer is asked by others: What should I do? The difference between the two is confidence, which comes with experience.

Confidence enables you to deal with Conflict, of which there is no shortage of in the business world. When two SMEs disagree on the contents of your document, it is a conflict that you will have to work to resolve with them.

Confidence also enables you to deal with Change. Change happens on so many levels – in people, in companies, and of course, in our documents and the way they get created. Accepting and managing this change is a critical skill to have, and requires Courage. I remember a tumultuous time when, as a result of various mergers, the company I worked for changed about every year. It was a stressful time, but also exciting, as everyone worked to manage the change.

Of all the C-skills to have, Creativity is the most important, because it encompasses all these other ideas. People who win at job interviews do so because they show how they have creatively solved documentation problems. Both your resume and in your interview should overflow with samples of your creative genius. It’s great that you know FrameMaker, but so do hundreds of other people. Instead, focus on how you improved the documentation and the documentation process in a creative way.

Creativity also involves working Colloboratively with others. We tech writers are an introverted lot, a habit we need to break. No person is a cubicle. The more we interact with other writers and non-writers, the better. Have you ever stopped and asked a code developer what they do? What they like? What they think of your documents?

Practicing all these skills enhances your Career. Career management is a whole other discussion. Managing your career and network of Contacts is like tending a garden. It takes time and care, but the end results are worth it. I owe my current job to the contacts I had carefully maintained.

Now, there is one C-word that is not a skill, but a shape: Circle. The letter C is like a circle with a gap:


The gap is symbolic of the gap that is present in all documentation: the gap between what the reader needs to know and what is actually in the document.

Salespeople have a saying: A.B.C.: Always Be Closing. Whenever they interact with clients, their entire manner and tone assumes the sale has been made – they just need to “Close” it.

Technical communicators need to practice A.B.C. We must come full circle and close the gap. Because when it comes to us and our readers…

…we are all Connected.


Interviewing for the Job and On The Job – Part III

This article is the last of three in a series. It’s based on my presentation at the STC Career Day and describes the six basic principles to follow for both job interviewing and informational interviewing.

5. Get another job.

No, I don’t mean quit your job. Instead, recognize that there are aspects of many other professions within ours. You need to take on these other jobs during interviews, especially informational interviews.

Elementary, My Dear Watson

Firstly, you need to be a detective, a true Sherlock Holmes. Before a job interview, research the company and study their financial information. During the interview, look for clues that this may or may not be the right job. Arrive at the interview early, read any company literature in the lobby and observe any activity. During the interview, take note of how the interviewers behave, and listen carefully to what they say. How old is the documentation software they are using? Is documentation considered an integral part of the product development process, or is it just an afterthought? Do the questioners seemly overly anxious to hire you? Gather these clues to make an informed choice if you’re presented with an offer.

For informational interviews, recognize that the product you are documenting is a mystery that you must solve. All sorts of questions will arise as you create your documents, and the answers are not always clear. For example, a database I was documenting contained a field that no-one seemed to know about. After considerable investigating, I found out it was only present to ensure backwards compatibility, and documented this accordingly. On another project, I couldn’t figure out why I was unable to delete a user record. It turned out administrative rights were required. Again, this had had never been clearly documented. Follow the clues and the truth will be revealed.

Investigating the Truth

Similarly, you need to be a journalist, or better still, an investigative reporter. A good reporter always questions the status quo, and is healthily skeptical. That is how they are able to reveal the hidden truths that those in power wish to hide. You need to practice doubting, which is a skill like any other. A good way to develop it is study viewpoints that are diametrically opposed to your own on such controversial topics as politics, abortion, the Middle East, and the wars on terror and drugs. Reasonable people can hold opposing view on these topics. By studying alternate views, you are training your mind to question things.

Being an investigative reporter applies mostly to informational interviewing, including interviews about the documentation in general. For example, my co-worker and I questioned whether our ReadMe files really needed to be in text (.TXT) files, which is a very limited and cumbersome format. We investigated and discovered we could change them to the much more flexible RTF and PDF formats, with all of their inherit advantages. Had we not questioned this, we’d still be stuck with the old formats.

Trust, but Verify

During your investigations, recognize that ultimately you can only know what you can verify. For everything else, you have to trust others, so consider the source and their interests.

For example, there was an unusual documentation issue at the 2008 Olympics in Beijing. Some of the female gymnasts appeared to be below the age limit. As “proof,” passport documents of the athletes were presented showing their birthdates. Who issued the passports? The Chinese government. Who benefited from this? The Chinese government. How do you say “conflict of interest” in Mandarin?

In software, a developer may be reluctant to tell you something is not working, if they are going to have to be the one to fix it. A product manager may not like being told that the instructions on a screen are unclear, if the product manager wrote them. A good technical writer rises above all this, and does what’s best for the end user.

Document Diplomacy

Dealing with conflicts such as this means you also have to be an ambassador and diplomat. As an ambassador, your job is to bring two groups of people together: those who create the applications and those who use them. In doing so, you help solve misunderstandings and miscommunications between these two groups, just as a real ambassador does between two countries. You may even prevent a thermo-nuclear war.

Interpreting the Results

You also need to be an interpreter, which is quite different from a translator. An interpreter extracts the real, intended meaning from something, and this can often involve a complete rewording. For example, there may a screen that says, “Click here to enter application.” Does this mean click to type in the name of the application or click to actually open the application? It’s not clear from the wording. As an interpreter, you would reword this text to remove all ambiguity. Interpretation is also an important skill to have when working with error messages, which are often unclear and do not state a solution.

Mind Games

Finally, you need to be a psychologist. You need to understand the mindset of both the users you are writing for and the people you are interviewing. For example, developers are, for lack of a better word, autistic. (I have a son with autism, so I know a bit about it.) Autism is a condition of the mind in which a person is able to have incredible focus on specific details but is unable to connect with others or see “the big picture.”

To illustrate this, imagine a child named Alice holding a ball. She places the ball inside the first of two boxes in a room, closes the lid, then leaves the room. A second child enters the room, moves the ball to the second box, closes the lid and then leaves. Alice returns and is looking for her ball. The question is: where will she look for it? The obvious answer is the first box, the one that she left it in before it was moved.

However, when you describe this scenario to an autistic child, they will answer that Alice will look for the ball in the second box. When you ask them why, they will respond “because that’s where it is.” Incredibly, the autistic child does not realize that what they know is different from what others know. That is why autism is called a form of mind blindness, because it causes a person to be unable to comprehend another’s point of view.

Calling All Developers

Developers often exhibit these tendencies. For example, a developer may be asked to create a work phone number field for a customer information screen. They will neglect to leave room to enter a phone number extension, even though the developer’s phone has a phone number extension. They are not stupid – they simply cannot make the connection.

Therefore, your job, as a psychologist, is not to be mind-blind, but mindful. Stop and see the big picture when gathering information. Is there anything missing? Is there something there that shouldn’t be? Is this something an end user can actually use and understand? By being mindful of your SMEs and end users, you will create documents that are much more usable, accurate and complete.

6. Go to 11.

1984 was an interesting year. It was the year George Orwell’s dark novel was named after. On a lighter note, it was also the year that the film This Is Spinal Tap was released.

The film is an mockumentary of a fictitious, aging British heavy-metal band named Spinal Tap. The band members are hilariously portrayed as dimwits. In a classic scene, the lead guitarist, Nigel, shows off an unusual amplifier to the interviewer, Marty DiBergi:

Nigel: The numbers all go to eleven. Look, right across the board, eleven, eleven, eleven and…
Marty: Oh, I see. And most amps go up to ten?
Nigel: Exactly.
Marty: Does that mean it’s louder? Is it any louder?
Nigel: Well, it’s one louder, isn’t it? It’s not ten. You see, most blokes, you know, will be playing at ten. You’re on ten here, all the way up, all the way up, all the way up, you’re on ten on your guitar. Where can you go from there? Where?
Marty: I don’t know.
Nigel: Nowhere. Exactly. What we do is, if we need that extra push over the cliff, you know what we do?
Marty: Put it up to eleven.
Nigel: Eleven. Exactly. One louder.
Marty: Why don’t you just make ten louder and make ten be the top number and make that a little louder?
Nigel: [long, awkward pause] These go to eleven.

The expression “going to eleven” has come to mean giving it that little bit extra, or as we say in the business world, giving it 110%. Often a little difference makes all the difference. It can mean the difference between winning a gold medal and winning nothing.

Going Beyond

In a job interview, go beyond the minimum by following all of the principles described in this series. Dress sharp. Practice your responses and your questions. Show passion for the job and your work. Describe how technical writing is not just your job – it’s your religion. Talk about how you are involved in outside activities and groups that involve technical writing, such as the STC or Editors’ Association of Canada. If you’ve done volunteer writing for charitable organizations, describe it. Most of all, show how you’ve gone the extra mile in creating and improving your documentation.

Letter Perfect

For example, our FrameMaker templates used to be an odd size: approximately 5” x 9”. This is because we used to send our documents to a printing house, and that was the size of the manuals they produced. Later, we stopped having them printed this way, and simply created PDFs, but they were still at this odd size. Customers were wasting paper because they were printing the files on letter-size paper. I decided to change the templates to letter size, or 8 ½ x 11. That’s right – my templates do indeed go to eleven.

Summing Up

These are the six basic principles of effective job and informational interviewing. If you study them, and practice them, then everyone will say of you, “there goes a great tech writer, because that tech writer goes to eleven.”

Interviewing for the Job and On The Job – Part II

This article is the second of three in a series. It’s describes the six basic principles to follow for both job interviewing and informational interviewing.

3. Honestly, Now

I remember a strange incident at my workplace years ago. A manager kept popping out of his office, bursting with laughter. He was fact-checking a job applicant’s resume, and discovered that almost everything on it was a lie: where the applicant went to school, where he worked, the groups he belonged to, and so on. Each time the manager confirmed another lie, he couldn’t wait to fly out of his office and laughingly inform the other managers.

I often thought about that job applicant. What was he thinking? Was he thinking? What if the manager hadn’t checked the resume, and the applicant had been hired? For the answer, we need to look to history.

King Pyrrhus vs. The Romans

Many years ago, a Greek King named Pyrrhus defeated the Romans, the superpower of the time. This was an incredible feat – it would be like Mexico beating the United States. (Can you imagine what would happen? There’d be millions of Mexicans living in America and the government would be trillions of dollars in debt…OK, bad example.) In any case, although Pyrrhus defeated the Romans, he did so at enormous cost – many of his men were slaughtered. That is, he won, but he lost, hence the expression Pyrrhic victory; a victory that really isn’t much of a victory.

So it is with applicants who lie their way to a job. They get the job – now what? They’ve got a job that they are not qualified to do, that requires skills they don’t have, at a place they don’t want to be, working with people they can’t stand – congratulations! When you lie or embellish the facts on your resume or in an interview, you’re only lying to yourself.

Therefore, in an interview, always be honest. If you don’t know how to use a particular piece of software, say so, but also describe how you are a quick learner. If you worked on a project that went bad, be honest about it, but say what you learned from the experience. A little honesty goes along way.

For example, if asked, “Why should we hire you?” answer the question honestly. State how you sincerely believe that you’d be a good fit for this position, and that you have much to offer.

Another question that will test your honesty is: Tell me about a time you failed. Without hesitating, state the failure, but then explain how you learned from it. For example, perhaps you were rushed and released a user guide that you later discovered was missing certain procedures. Talk about how you learned from this, and more carefully planned your schedules and reviews, so that the next release was better than ever.

By the way, this question is a good example of a stress question, where the interviewer wants to see your reaction, and is not just concerned with the content of your response. Be strong and show how you can easily handle the pressure.

Fool Me Once, Fool Me Again, Please!

Honesty also applies to informational interviewing. Often times, when interviewing the SMEs, we’re too embarrassed to admit we don’t understand something. Just remember – it is your job as a professional informational developer to go from not understanding something to understanding it. If you are not initially confused and bewildered, then you’re not doing you’re job. If you don’t understand something, say so! You may look foolish – so what? It’s better to be a fool in private that to create foolish documents, documents that may come back to haunt you – then you’ll really be the fool.

Chaos Theory

All great products and services got to be great by having people ask dumb questions. There’s so much chaos that we don’t see. If you’ve ever been backstage at fashion show or a play, you’ll see it’s often total mayhem – people yelling and screaming at each other, doing dumb things, and asking dumb questions. But the audience never sees this– they just see a beautiful show, or a beautifully complete and concise document.

4. Don’t Be Anti-Active; Be a Pro

It’s no coincidence that the words professional and proactive both begin with the same three letters. To be a professional, you need to be proactive. Proactive should really be called pre-active, to indicate that you take action before (pre) there is a problem, and thereby pre-empt the problem.

Explosive Issues

Being proactive means being responsible, and responsibility is something you hear about in the news all the time. In 2008, there was a huge explosion at a propane facility a few kilometers from our home. We were far enough away that we weren’t directly affected, but we did hear it. Afterwards, almost on queue, no-one wanted to take responsibility for this disaster. The city blamed the licensing facility. The licensing facility blamed the city. The province blamed the city. The city blamed the facility owners. The owners probably blamed the employers. No one wanted to take responsibility.

Compare this with the disaster that followed shortly after, in which various meat products at the Maple Leaf processing plant became infected with listeriosis and several people died. Incredibly, the president of the company, rather than blaming others, took full responsibility. He did not blame the government. He recognized that the buck stopped with him.

Responsibility is an important issue for us, because it relates to the question of who ultimately owns the documentation. The very definition of a senior technical writer is someone who owns, and is therefore ultimately responsible for, the documentation, in the same way that senior coding developers own the code.

Pro-Active Interviewing

Being pro-active and showing responsibility applies in two ways during a job interview. First, you need to be proactive before the interview. Carefully study the company, its history and products, and the position itself. Secondly, show during the interview how you have been proactive in your job. Examples include redesigning the templates, improved the indices, and enhancing the documentation development and review process. Bring samples to indicate the changes you made. Show how you avoided documentation explosions before they happened.

A question you may be asked that will show how proactive you have been is: Why do you want to work here? To answer this question effectively, you must have proactively researched company and the position, and reviewed your skills and work history so that you can clearly state why you’d be a good fit.

Finally, you may be asked: What is the purpose of technical communication? You might think the answer is to instruct the reader on how to use a product. That’s true to some extent, but the real purpose is to reduce technical support costs by creating documents that people actually use, and thereby help avoid the users from having to call in. Therefore, you need to show how you have proactively done this. Examples include creating a detailed troubleshooting section, adding critical missing content, developing training guides, and writing a glossary.

For informational interviewing, being proactive means planning your questions carefully before you sit down with the SME. It means creating documentation plans and schedules, and reviewing and testing the product to find all the hidden and potential problems. It means recognizing that a SME’s time is valuable, so you want to be able to zoom in and get clear answers to your questions by having used and tested the product you are documenting. It also means constantly following up with the SMEs to ensure they answer all your questions and review every draft.

Interviewing for the Job and On The Job – Part I

First of three in a series

This article is based on a presentation I gave at the STC Career Day, held at Seneca@York, September 22, 2003. It describes the six basic principles to follow for job interviews and informational interviewing, including asking and answering the right questions, of the right people, at the right time.

The DNA Interview

The science fiction film Gattaca envisions a future where everyone is genetically engineered to be a perfect match for their job. For example, a classical pianist is bred to have an two extra fingers so that he can play more notes. (I presume he would also give good back scratches.)

In a scene from the film, the main character is applying for a job as an astronaut. A lab technician scans a sample of the applicant’s blood to verify that the applicant is who he says he is. (He’s not really, but that’s another story.) The technician tells the applicant he’s hired. The applicant asks, “What about the interview?” to which the technician responds, “That was it.”

Ah, if only it were that simple. If only there was some magical machine that could scan our minds, determine if we were the right fit for the job, and spit out a message: “Technical writer – level 4 – please proceed to your workstation.”

The UnSystem

Alas, there is no such system. Instead we have the following “system”: you enter a room with one or more people, answer a series of questions, and based on how well you respond, you get the job. (Your portfolio, while important, cannot salvage a bad interview.)

Now, does this so-called system make any sense? What have you really proven? You haven’t shown you’re the best person for the job – you’ve simply shown that you can answer a series of questions, and that you can find the company’s building.

What companies should do, after weeding out the candidates that have truly rotten resumes, is temporarily hire the various applicants to see how well they perform on the job – in other words, apprentice them. This is, in fact, done for certain professions, but not often for technical writers, as it’s a very expensive and cumbersome option.

So we’re stuck with the system where the best interviewee (and not necessarily the best candidate) wins the job. Therefore, excellent job interviewing skills are critical. However, as important as these skills are, you’ll only need them several times in your life.

Assuming you work about 40 years in your life, for an average of 4 years per job, you’ll have experienced ten interviews on ten separate days. On the other hand, while on the job itself, you will be conducting informational interviews all the time, hundreds, if not thousands of times, during your working life. Therefore, good informational interviewing skills are also very important.

Master of Disguise

Job interviewing, is, in fact, just a form of informational interviewing in disguise. Interviewers are trying to obtain as much information about you as possible, and you’re trying to get as much information about them, the company and the position as possible, all in a limited amount of time. That’s why these interviews are so stressful.

Also, informational interviewing isn’t used just for finding out information about documentation, but about how things work at your company. The company I work for was recently acquired by Oracle, and we’ve all been receiving vast amounts of information about the company, the new people and the many new policies and procedures. I’m thankful that as an information developer, I can sort through it all.

Indeed, you can use informational interviewing to find out about anything, including what’s really going on at your company, your family and colleagues, with technology and our profession, with your finances – anything. So you will find it is an extremely useful skill to have, and not just at work.

Let’s now look at the six basic principles of effective job and informational interviewing.

1. Shhhhh – The Audience is Listening

The first principle of interviewing is also a basic principle of information development. It is that before you write a single word of a document, you must know who the document is for and its purpose. In other words, you must know your audience. For example, the readership for a digital camera guide is quite different than for an administrator’s guide that describes how to set up a complex network. You need to target the language, structure and organization of the document accordingly. Ideally, you should imagine that you are that audience.

So it is with interviewing – you need to target your questions and answers to your audience.

The Three Musketeers

In a job interview, you’ll typically encounter three different types of interviewers:

1. The HR (human resources) specialist
2. The person you’ll potentially be working for
3. The person (or people) you’ll potentially be working with

You need to carefully craft your responses for each of these three types.

HR – Humane Responses

HR personal are generally non-technical, and therefore know little about technical writing. Do not talk over their heads with mindless techno-speak. For example, if asked to describe your best accomplishment, don’t respond with something like: “I effectively single source with FrameMaker using a complex combination of text insets, conditional text and variables.” The HR interviewer will silently nod in agreement but will have no clue as to what you just said. Instead phrase your response to their level, for example:

“We had lots of text that kept repeating throughout our documents. Every time it changed, we had to manually find the text in the various documents and change it, which took a lot of time and effort. I was able to fix this problem by storing this recurring text in a single file, and then using references, or pointers, similar to a Windows file shortcut, to repeat the same text in different locations. Now whenever there is a change, I just have to change one file instead of many, and the change magically propagates throughout the entire documentation set, greatly lowering the maintenance…..(Can you dig it? I knew that you could….)”

Don’t Boss Me Around

If you survive the HR gauntlet, you’ll be interviewed by the person you could be working for. This is the most important person who will interview you, because it is they who will usually make the final hiring decision.

The person you may work for will be one of two types:

1. A technical writer – e.g., documentation manager, publications manager, technical writing team lead, etc.

2. Not a technical writer – e.g., a development manager, QA manager, product manager, marketing manager, etc.

Again, if they are not a technical writer, don’t use heavy tech writing industry jargon; talk at their level. If they are a technical writer, you can be a bit more technical, but don’t overdo it, as they may think you are trying to mask other problems.

Whether or not your potential boss is a technical writer, what you want to emphasize in your responses is that you are:

  • flexible and adaptable
  • a team player – you play nicely with others
  • friendly and approachable
  • intelligent, organized, knowledgeable and resourceful
  • able to hit the ground running with minimal ramp up type – a quick learner
  • honest and responsible

    Just One of the Guys (or Gals)

    When being interviewed by the people you may be working with, typically other tech writers, it’s very important not to come across as a condescending, obnoxious, know-it-all. Recognize you are at their level, and act accordingly. Share horror stories of tools. Get their advice on a challenge you face. Have a sense of humour – tell them you still have troubling spelling XML and PDF. Show them you can work with them by actually working with them in the interview.

    Be Afraid, Be Very Afraid

    Be aware that behind every question you’ll be asked is fear – fear that you are not one or more of qualities just listed. Fear that you are unqualified (or overqualified), difficult to get along with (and therefore manage), a liar, a cheat, dishonest, irresponsible, arrogant, stupid or just generally psychotic. You must allay these fears in the interview by giving concrete examples of what a fantastic worker you are. Talk about how you enjoy working with others, how you have made great improvements to the doc set and the doc process, and how you are always learning new things. Most of all, you need to show a genuine and solid interest in the position. Studies show that the candidates who win interviews came across as most passionate for the job.

    Be Yourself, Not

    As described previously, the principle of knowing your audience obviously applies to informational interviewing, because you have to ask questions that get the answers the typical reader needs. That’s why it’s best if you can imagine you actually are the end user – with all of their needs, wants, fears and neuroses.

    This principle applies another way: to the person whom you’re interviewing. You need to understand them and what level they are at, so that you can ask relevant questions.

    Nuts and Bolts

    Imagine you’re developing the user manual for a car. You go down deep into the assembly plant, walk along the vast assembly line, and ask the big, burly factory worker, the one who tightens the bolts on the engine, “Hey there – do you know how the radio works? And what sort of person typically drives this car?” You won’t exactly get warm responses, or even accurate ones. This is because it is not the job of the assembly worker to know these things. They just have to know how to put the cars together so that they won’t fall apart or explode too much when you drive them. (Ford and GM notwithstanding.)

    Conversely, can you imagine asking a car salesperson how much torque should be applied to the engine bolt to tighten it? Again, that is not their job to know. Recognize that subject matter experts (SMEs) are on a spectrum, from the most removed from the end user (developers), to less removed from the end user (QA testers, technical writers) to those in direct contact with end users (product mangers, business analysts, salespeople, technical support.) They are all various parts of the food chain, like amoebas, snakes, leprechauns and other creatures.

    Therefore, when asking questions of SMEs, ensure the questions are relevant and appropriate. For example, I would expect the developer who created the multiple N-up printing field (the one that allows you to print several smaller images of pages onto a single page so that you use less paper), to know how it works, and the mechanics of it. I would not expect them to know specifically why a user would use it, or that the user should use larger fonts to make the printouts more legible. However, I would expect the product manager or business analyst to know why ths field would be used.

    The challenge when conducting interviews is to find out the ultimate, true reason for a procedure, element or thing. Therefore, your questions must match the SME.

    2. Know thyself – know what I mean?

    Everyone is like a computer program: they are hard-coded with certain likes, dislikes and personality traits. They blossom in some environments and wither in others. It is therefore absolutely critical that you know the contents of your “program”, so that you can recognize if it is compatible with the job you are applying for.

    Just as you have a unique personality, the job you’re applying for has one too. It has strengths, weaknesses, skills and other characteristics. If you don’t know yourself, how can you know if you’d be a good match for the job?

    Why We Write

    One of the questions you may be asked in an interview that will quickly indicate if you know yourself is: Why are you a technical writer? I’ve been asked this, and have asked it of candidates I’ve interviewed. You need to know the ultimate reasons why you’re a writer, and it’s not enough to say it’s because you like working with documentation – that’s obvious. Why do you like working with documentation? Is it because you like helping others? Is it because you enjoy making order out of chaos? Is it because you’re an end user yourself and get frustrated when you encounter a guide that is incomplete? Is it because your parents used to beat you with dictionaries? Know yourself to know these reasons.

    The ultimate question where you must know yourself, is Tell me about yourself. Because this is such an open-ended question, most people dread being asked it. It is not an opportunity to spout your life story. The question really means: “Tell me about yourself in relation to this job, what you’ve done, what you’re doing now and what you hope to do, to show me that you’d be the best person for this position.” You must practice your response to this question. It may be something like:

    “I’ve been a technical writer for over 10 years. I work mostly in FrameMaker, WebWorks Publisher and Adobe Acrobat, to create a wide variety of documentation including user guides, online help, technical guides and Release Notes. I like doing what I do because I enjoy the entire process of gathering and organizing information from a wide variety of sources, and putting all this into a guide that people can actually use. Finally, I’m very much a believer in content management so I’ve been studying it quite a bit, especially XML and DITA, and hope some day to work with these areas.”

    Other questions you may be asked where you really have to know yourself and why you do what you do include:

  • Name three things you like about technical writing. Have a list prepared!
  • What are your greatest strengths? – Are you a good multi-tasker? Are you persistent? Do you have good interviewing skills? If so, say so, and give examples.
  • What is your biggest weakness? State a weakness and show how you overcame it. For example, you may say you find it stressful rushing a project, so you have developed a good system of creating a doc plan with tasks and dates, and ensuring everyone follows it to avoid a rush.
  • Why are you interested in this position? You can only answer this if you know yourself, skills the job, and the company to show that there’s a match.

    Passionate Documents

    It’s important to know yourself and exactly why you’re a tech writer because this will help motivate you when gathering information for your docs. One of your ultimate passions should be to help – change won’t happen unless you are passionate about it. You need to be as passionate as the followers of Obama, and say:

    Yes we can – create great documents.
    Yes we can – convince management that documentation is important
    Yes we can – convert all our docs to XML

    Because we are the track changes we believe in.

    Andrew Brooke – abrooke@primus.ca

  • Interview Questions – Part V – Conclusion

    This month, we complete our series on interview questions. Although we’ve covered many potential questions, note that we’ve only scratched the surface. There literally hundreds of questions that you could be asked. Although it is impossible to anticipate every question, the more that you can plan responses to, the greater prepared you will be.

    Here’s an extensive list of other questions and statements to think about, from the sublime to the ridiculous, in no particular order. If you can think of a response to each one, you will be far more prepared than most people.

    • What exactly does a technical writer do? Why do I need one?
    • What are the most critical aspects of your job?
    • What’s your energy level like?
    • Describe a typical day.
    • What’s your job experience?
    • How do you feel about your progress so far in your field?
    • What do you know about our company?
    • How long would you stay with us?
    • What are your qualifications?
    • What would you do here on your first day of work?
    • Do you take risks? Tell me about a risk you took that went badly.
    • How do you organize and plan your projects?
    • Can you work under pressure?
    • What kinds of people do you like to work with? What kinds don’t you like?
    • Define “technical communication”.
    • What interests do you have outside of work?
    • Why are you leaving your current job?
    • Have you ever done product testing?
    • What kinds of decisions are hardest for you?
    • Why were you fired/laid off?
    • How do you get information out of people? What do you do if they don’t cooperate?
    • What are you looking for in your next job?
    • I don’t know if you’d fit in here.
    • How do you cope with change?
    • Define “usability”.
    • What have you learned from your mistakes?
    • What can you do for us that someone else can’t?
    • Describe a difficult problem you’ve had to deal with.
    • If you could change one thing in your past, what would it be?
    • What makes this job different from your last one?
    • What are some of the things you’ve worked on in the past?
    • How do you take direction?
    • I’m not sure if you’re qualified for this job.
    • What other areas could you help out with?
    • What have your other jobs taught you?
    • What do you do when you disagree with others?
    • Are you a leader or a follower?
    • Tell me a story.
    • Do you work well with others?
    • Can you manage other people?
    • What do you think of your current/last boss?
    • Wouldn’t this job would be a big step down for you?
    • What have you done that shows initiative?
    • What personal characteristics are important for this job?
    • Explain your role as a team member.
    • Describe a situation where your work was criticized.
    • What kinds of things do you worry about?
    • What is the most difficult situation you have faced?

    Note that some of these questions came from a recent episode of “The Apprentice” reality TV show. The remaining four candidates (all vying for a plum job with real estate mogul Donald Trump) were subject to series of gruelling interviews. It was no surprise to see Amy fired: one the interviewers commented that she was insincere, irritating, bored and acted “like a Stepford wife”!

    A Travesty of a Mockery of a Sham!
    We’ve been looking at interview questions like these for the last few months, but now, a confession: it has all been a sham! Here are two incredible facts: a 1989 British survey revealed if an interview was done by someone who would be working directly with the candidate (which is usually the case), the success rate dropped to 2% below that of picking the name (of qualified candidates) randomly! And if the interview was done by a “personnel expert”, the rate dropped to 10% below picking the name randomly! It makes you wonder what on earth personnel experts are paid to do.

    Why then do companies waste huge sums of money and time conducting interviews, when they would probably be better off just picking names randomly? I believe it is simply because they know of no other way to hire people, and most of them would certainly have no idea that the interviewing process is largely useless.

    However, the fact that the process is useless is not your problem – it is the company’s problem. Your challenge is to learn the tricks and techniques that can help you win interviews. The fact that the process itself is flawed is irrelevant. There is simply no other way to play the game if you want to work for a company. Even freelance writers often have to go through the interview process, at least with new clients.

    Winning the Interviewing “War”
    The Chinese general Sun Tzu wrote in his famous military treatise “The Art of War”: every battle is won before it is ever fought. When you are heading into an interview, you are going into battle. You are up against every other person who is applying for that job. Fortunately, it is a peaceful battle, and you will probably never see (much less have to kill) your opponents. Tzu’s statement simply means “planning is everything”. What is astonishing is that Tzu wrote these words 2,500 years ago, yet they are still incredibly relevant today.

    All major endeavors, from warfare to job interviews, involve three major areas: an objective, strategies and tactics. Do not make the mistake of getting these mixed up. The objective is the ultimate, single purpose of something. The strategies describe at a high level the ways you will achieve the objective.
    The tactics are the specific actions you must take to achieve the strategies, which in turn lead to the completion of the objective.

    Comparing these areas for warfare and job interviewing, we get:

    Warfare Job interview
    Objective To win the war. To win the job interview.
    Strategies Weaken and confuse the enemy.

    Overwhelm them with force.

    Show the interviewer your strengths.

    Position yourself as a problem-solver.

    Show how you are unique and a good match for the position.

    Tactics Eliminate the enemy’s leaders to create chaos.

    Carefully position all your divisions.

    Bomb the enemy’s factories, bridges and roads.

    Capture the major cities.

    Continually rotate your troops to wear the enemy down.

    Cut off the enemy’s supply lines.

    Destroy the enemy’s communication system.

    Practice interview questions.

    Prepare a one-minute summary about yourself.

    Be able to list several examples of your accomplishments.

    Bring a portfolio of your work that graphically illustrates these accomplishments.

    Appear confident and interested in the position, but not desperate.

    Show how you lowered costs and improved efficiencies.

    Tie the job description to your skills, point by point.

    Whether it’s war, job interviews, dating, getting in shape, or any other task, planning is critical. The more you plan, the more you strategize and think about how you will behave and respond to these many questions, the greater your chances of success.

    Remember – the person who wins the interview isn’t necessarily the best person for the job, but is the person who is best at getting that job.

    Interview Questions – Part IV

    This month, we continue our series on interview questions. But before we begin, here’s some excuses people have given for taking time off work, according to a recent study by Accountemps, a Canadian recruiting firm:

    • I need time to find myself.
    • The pool is broken.
    • My cat has hairballs.
    • My partner and I need to practice for the square-dancing contest.
    • I’m taking a few days off to start my own business.
    • I’m going to jail.

    It’s a wonder these people got through the interviewing process. Now, on to the questions…

    Why do you want to work here?
    To effectively answer this question, you must have thoroughly researched the company and the kind of work they will expect you do do. This will allow you to state specifically why you would be a good fit. For example, you may say:

    “The type of documentation projects I’d be working on are similar to those I’ve done previously, and involve the type of work I enjoy doing best. I find that when I’m doing what I like, it’s a great motivator to do a good job, and therefore I think I’d be able to make a solid contribution here.”

    What have you learned at your previous jobs?
    This question represents a good chance to restate your strengths and tie them in to the current position. You may say, for example, that you’ve learned the importance of being approachable and always encouraging open communication with your peers. This has resulted in a higher quality of drafts during review time, because people are not shy about approaching you with practical suggestions for enhancing the documentation.

    How long would it take you to make a contribution?
    You need to get more information before answering this question. Ask a question such as “What are your greatest areas of need right now?” or “What would be my responsibilities for the first six months or so?” From this, you can base your response, which may be something like:

    “It might take me a week or two to get settled in and learn what I need to about your documentation process. But during that time, I can be making a real contribution. Are there any special projects that you want me to be involved in right away?”

    The strength of this response is that it gets the interviewer already thinking of you as an employee.

    How do you handle stress?
    A good strategy for this question is to state the ways you minimize or eliminate stress. You can list things like:

    • carefully planning all projects to minimize “surprises”
    • continually monitoring the status of your projects, and following up with others when necessary
    • recognizing that new and unexpected events can happen, and reprioritizing when necessary
    • taking regular breaks to clear you mind and get refocused

    If possible, give a specific example of a particularly busy time that you had, and how you handled it.
    Keep in mind that some stress is actually productive, because it can give you the energy needed to get the job done. It’s only when you have too much stress that your work can begin to suffer. Also, although most people associate stress with having too much to do, note that not having enough work to do can also be stressful. You may want to say that you handle any down time by reviewing other projects such as older documentation that has not been reviewed in a long time.

    Why should we hire you?
    This may seem like a tough question, but it is, in fact, a “dream” question, the one question that you should hope you will be asked. In fact, as I stated at the beginning of this serious on interview questions, all the questions you will be asked are simply variations of this question. The interviewer wants to know exactly what makes you so special that they will pick you over the many other equally qualified candidates.

    You need to highlight the areas from your background that relate to the needs of the job. Recap the job description and match it point by point to your skills. Drive home the fact that you are enthusiastic, a team player and that you are ideally suited for this position, but be specific. This question represents one of your single best opportunities to sell your strengths. A sample response would be:

    “This position needs someone who’s able to handle multiple projects at the same time, has strong technical skills and is able to give effective feedback on product design. My experience has shown I’ve got these skills, and that I have a genuine enthusiasm for what I do. This has meant I’ve been able to make a meaningful contribution at all of my positions. And I’m proud of the fact that I’ve always been able to improve both the documentation and the processes for developing it wherever I’ve worked.”

    Next month, we’ll wrap up our discussion on interview questions.

    Interview Questions – Part III

    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.

    Interview Questions – Part II

    This month, we 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

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