January 16th. 2011
The responses to the “Testing Technical Writers” thread have been both generous and lively. My purpose was to get a general feel of the opinions of HATTers on the subject of how to qualify a technical writer applicant for a specific job. Your contributions have been most informative and helpful. Although I have had some experience in interviewing and hiring, I do not think I am qualified to write more than a short summary on the subject.
Whether we are called technical writers, technical communicators or any other label, we are referring to professionals who can transfer the knowledge of software or hardware engineers into clearly understood instructions or explanations. To do that successfully, we have to know the language well, be able to express the subject at the level of the intended reader and guide and instruct the reader in a form that is clear and concise.
The discussion about split infinitives brought up a very relevant point on the qualifications of a technical writer: competency in English. IMO, a writer in English should ideally have a complete command of the language and the jargon used in the particular field of the employer. I know of writers who use words that are common to a small group of people but unfamiliar to a wider and more universal audience. Therefore, the language used must be clear and unambiguous. Technical writers may also be required to be proficient, to a certain degree, in media such as graphics, diagrams, videos, presentations, according to the requirements of the job.
We have to test a candidate for suitability, based on the resume, the interview and the results of the tests. We can assume that the resume may not be fully reliable, and the interview, even when there are several interviewers, can be misleading. Therefore, we must rely on the tests to wean out the unsuitable. Testing candidates should be well-thought out and thorough.
First, we must find out the level of experience and professionalism of the candidate, or what we expect from the candidate, and select the appropriate tests. A test for typos, for example, may not be appropriate for a senior and experienced candidate who has already provided high quality work samples. Or, if a candidate has already stated that they have had no experience with HTML, there is no point in giving them such a test.
When testing junior writers we need to examine their ability to write instructions as well as their ability to copy writing style and format from a template that we provide. Experienced writers must show their ability to copy writing style and detail level as well as prove their technical competency with the tools. Although there is no question that grammar and punctuation are the essential qualities of a writer, a technical writer must also be able to understand complex concepts and express them simply and concisely at the level of the intended reader.
We have to prepare a number of tests suitable for the different levels of candidates that we expect to apply for the job. Customized tests would presumably give you a balanced evaluation that would justify, or not justify, spending time interviewing the applicant, especially when the higher echelons of management become involved. We must also make the tests reflective of the needs of the organization and the work environment. A candidate’s personality must be adaptable to a team, if such is required, or to work independently, if that is the criterion. If we are a hardware company catering to technicians in the field, we must test candidates for their ability to communicate with technical people. Applicants who provide an extremely long list of qualifications should be tested on as many of them as possible, and especially those qualifications that are on the list of requirements for the job.
Knowing the jargon of the industry is an essential requirement. A concrete example which actually occurred in my field, web application security, was where a previous writer had written in a manual intended for experienced web-application security professionals: “ … be aware that source code which allows attackers to penetrate and/or manipulate instructions may not be detected …” What the writer was referring to was “vulnerable code”. This should have been the sentence: “ … be aware that vulnerable source code may not be detected …”Any reader from this industry would have known exactly what is meant by “vulnerable code”, but would need to extrapolate the meaning of the first sentence.
Therefore, the ideal situation would be to include in your repertoire a range of tests that cover the requirements for a writer. For example, if you are looking for a technical writer to work within a team in an electronics and software company you would have questions that probe the extent of the team work experienced by the applicant, the extent of knowledge in electronics, familiarity with the jargon of the field, and how the applicant copes with writing about software, as well as suggestions the applicant might have on methods of obtaining information.
English – an example would be to verbally explain to the applicant how to operate a widget, and request a written procedure. As an additional twist to this test, especially if you have a suspicion that the writer is not wholly comfortable with English is to ask him to explain or write the procedure in the language he/she is most comfortable with. If they decide on another language then you will know that they are not fully comfortable with English.
Proof-reading skills for typos – provide a test that uses similar words such as: affect / effect — ensure / insure / assure – are / our — there / their – here / hear – to / too / two, alternate / alternative.
Grammar – provide quotes or short speeches by public figures with grammatical errors that lead to easy misinterpretation. Ask the applicant to explain the errors and how they affect the meaning of the sentences. (Note that a question on split infinitives is appropriate, but not to have that as the only test.)
Punctuation – check for spaces after the period at the end of a sentence and quotation marks and periods.
Jargon – if the applicant has stated that she/he has experience in the field, present her/him with a jargon filled document and request in return an explanation in plain English.
Summary Presentations – ask the candidate to prepare a 10-15 minute presentation of one of the works mentioned in their resume, or of the work samples they have brought with them. Or, request a summary of a past work. The summary should cover every aspect of the work while confined to a half-page.
Publishing Skills – request to have an original document in the publishing tool used by the writer, such as FrameMaker or Word. Check usage of styles and style sheets.
Writing Procedures – write a procedure for tying shoelaces without the use of graphics. Or write a procedure using the text of an obfuscated technical specification written by one of the engineers.
How do you start on a writing project, and how would you organize it?
What do you do if you cannot get the information you need?
How do you decide how long a topic should be?
Personality and Characteristics
Is the applicant alert and interested in the work involved and with whom he/she will be working, and not just what the company has to have to offer in pay and holidays?
You want someone who is curious, who can understand the technology that they will be describing, and can communicate effectively. Someone who is technologically inquisitive, good at troubleshooting, can think outside of the box (particularly when it comes to problem solving).
Ask the applicant to present their resume verbally, and ask them questions on the spot. Ask about their greatest design challenge, what did they learn from completing the last major project, and what they would do differently if they had had more time. Sometimes people look good on paper (or online) but you don’t really know what you are dealing with (strengths and weaknesses) until you talk to them face to face.
Again, many thanks to those HATTers who contributed.