We’re currently working on developing some new tests to assist clients who need to assess the writing skills of candidate Technical Authors. Writing test papers is a challenging task – it goes against the grain to make mistakes deliberately!
English is a language where sentences can be written in many different ways. Today, many people would find “to boldly go” to be acceptable, as well as the more traditional “to go boldly”. I was taught to use Oxford commas (but not in lists), whereas many of my colleagues prefer the grammar rules taught to TEFL tutors. It means, often, there can be more than one answer that’s acceptable. The ultimate goal to communicate information to users in an understandable way.
We believe it’s best to create a series of tests. Our tests comprise a proofreading test, an editing test and an exercise requiring the candidate to write some instructions.
What approach do you take?
When I set tests I’m looking for consistency. It doesn’t matter what particular school of thought they subscribe to as long as they are reasonably consistent. Last time I recruited we were keen they could think logically so I also set a logic test based on instructions written for our product.
Clarity and brevity is important for me. I like setting tests that provide information that is a bit muddled to see if they can bring out the salient points. I like to see if they can chunk like information together and how they go about that. Only after that would I look to their grammar and punctuations skills.
It also depends on the type of writing you are expecting someone to do. I really like the old fashioned ‘Describe how to make a cup of tea to an alien’ as it shows you how they deal with assumptions and lay out structured procedures.
As David commented – I think consistency is important. Most companies I write for have a ‘style guide’ which I am expected to follow which takes care of any variations in expectations.
Give candidates the option to explain their design decisions. Possibly, a candidate has an insight that the test designers did not think about.
Recently had some good results with the following writing test.
Get the candidate to view a screencast explaining part of your product, then ask them to write up some information that would form part of a User Guide.
Interesting to see the different approaches.
Caveat: this was to fill a graduate position, and none of the applicants came from a technical writing course. Still got some great stuff though!
I certainly wouldn’t care whether or not the candidates split their infinitives or used an Oxford comma. We have house style rules about these and a million other things that they can’t be expected to know yet, but will be taught.
We have a test with a number of sentences to improve (note “improve” not “correct”); write a set of instructions for a task, based on a load of given info; write an essay on any technical subject. This give a good view of their general ability to express themselves clearly and succinctly, and understand what to include and what to leave out.
In my experience language and grammar tests prove to be very inconclusive of the comprehension and articulation capabilities of a candidate. We therefore prefer providing case scenarios, similar in nature to the work that the candidate will be engaged in, and judge them on their analytical capabilities, ability to organise and finally the ability to put things in perspective and express them in simple, lucid words and sentences.
I try to combine all of the above – we have the first draft of a small User Guide for an existing piece of software, written by an Italian, updated by a Dane. It contains typos and incorrect language. It’s got half a dozen screen shots and text that peters out in detail and consistency over just 4 pages. I give them the whole 6 pages, say to read the first 2 introductory sections but to work on the 3rd section and “make it more user friendly”. It’s a Word document on a laptop and they can spend as long as they like on it, after an on-site interview. I can tell by the time they take and the changes they make, how well they meet our requirements.