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.”
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.
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 – firstname.lastname@example.org