All Content
All Content
Podcast in iTunes
Follow me on Twitter
10 Alternate Tests for Evaluating Technical Writing Job Candidates — A List for Hiring Managers
I received an email the other day from a hiring manager who asked me what tests they should give to their technical writing candidates. She writes,
We are hiring two new technical writers and are trying to come up with a practical for the candidates to complete. We had been asking the applicants to write a quick how to (e.g make a pb&j, withdraw cash from an ATM, etc.) followed by a longer writing sample, but our HR rep isn’t sure if this is the best qualifier. Any ideas? What test have you completed in the past when applying for tech writing
positions.
Although I’ve taken various tests before for job interviews, such as documenting how a small company widget works, or finding all the spelling and grammar errors in a document, or actually taking an IQ test, I’m not a fan of tests. Do you ever give doctors a test when you interview them? See now, go into the next room and try to figure out what kind of disease the guy has. You’ll have 30 minutes to write a diagnostic report. Or to a lawyer — we want to see if you’re actually qualified for the position. Please write and deliver and 3 page court presentation arguing a case of insanity for the unabomber…
If I were hiring a technical writer, rather than administering tests, here are 10 things I would do to evaluate the candidate:
- Ask for writing samples. Writing samples are by far the best indicator of ability. The only problem is that often writing samples are proprietary and confidential to the former company, and if the writer is seeking a job without the current employer’s knowledge, it’s hard to acquire these samples legitimately.
- Ask the candidate to evaluate your company’s existing documentation. What would he or she change? How would he or she approach the same material?
- Ask for evidence of enthusiasm. My favorite interview question is, “What have you done in the past 6 months to demonstrate your enthusiasm for the profession?”
- Check out the candidate’s blog to see if he or she is an interesting person. If there is no blog, Google the candidate. If you can’t find anything anywhere, be skeptical about the answer in #3.
- Ask the candidate to explain his or her strategy for single sourcing. This is a great way to gauge the candidate’s awareness of current trends.
- Talk with the candidate about random things. Ask yourself if you would enjoy having the person as a co-worker.
- Have other technical writers meet with the writer, especially if you’re not a writer yourself. Writers can sometimes quickly sense whether someone knows what they’re talking about, similar to how developers or designers can judge the same about people in their fields.
- Ask the technical writer what his or her favorite manual is and why. This will get the writer talking about best practices.
- If you must give a test, ask the writer to create a video tutorial describing how to do something software related. Hiring managers often give writing tests, but hey, technical writers don’t just live in the written word. You want someone who can do video too. In fact, I just received a comment today on a quick Dokuwiki video I made last year. Sarah writes, “I just finished watching your video on setting up Dokuwiki (http://www.idratherbewriting.com/video/dokuwiki.html). This is not only a very useful video, it’s the future of tech “writing.” Thanks for sharing it.”
- Check to see whether the writer formatted his or her resume with styles. This is my friend Mark Hanigan’s pet peeve. Whenever he evaluates resumes, he first looks to see whether the content is structured with styles. It’s subtle and anyone who isn’t familiar with structured authoring will completely miss it. But you don’t want to hire someone who doesn’t understand the concept of styles.
Finally, if you are determined to administer a writing test, please make it software related (unless your company doesn’t make software). And also make it difficult. For example, provide instructions on how to speed up your Firefox browser.
April 6, 2008 Update: I have officially changed my mind about writing tests. While I initially thought they were insulting, I now think they are essential. I guess I had to experience for myself an interaction with someone whose writing I felt to be subpar. It lacked thoroughness, wasn’t easy to follow, was poorly organized, sometimes unclear, and was overall not something I’d want my department name attached to.
Many candidates pose as technical writers but really lack the skills. Writing tests can help weed these candidates out. I guess I’ve come full circle on this. I now would also encourage a writing test, and require that candidates provide instructions on how to document a typical company widget. When you get that writing sample, here are some obvious signs that you shouldn’t hire them:
- The writer doesn’t use numbered steps.
- The procedure had 20+ steps without being broken into separate tasks.
- The writing is unclear.
- The writing is poorly organized.
- The formatting is sloppy.
- The writer doesn’t structure the content with styles.
- The steps are inaccurate.
- Field definitions aren’t illuminating.
- You can spot misspellings and grammar errors.
My alternate tests are still valid. I’m just now endorsing the standard writing test.
As an added bonus, requiring writing tests will drastically reduce the number of candidates who apply.
Like this post? Subscribe to the RSS feed 
.
Related Posts
- Defining Experiences: Five STC Candidates Share Influential Stories from the Tech Comm Field
- STC Candidates: Submit a Story about a Defining Moment in Your Career
- Special STC Election podcast: Call for Participants
- The coolest thing ever — Total Tech Writer Blog Aggregation
- Special STC Elections Podcast: Interview with Nicky Bleiel, Candidate for Director
Tags: hiring, managers, writing tests
March 13th, 2008 at 10:47 pm
The photo used above is from here.
March 13th, 2008 at 10:50 pm
While you’re doing tests, here’s a fun psychological one that I read in Malcolm Gladwell’s Blink. Have one of your colleagues stand in the hall wearing a cap talking to another colleague. Then give the job candidate a “grammar” test in which he or she has to spot grammar errors. Pack all the sentences full of polite words (e.g., praise, kind, respect, thoughtful, nice, etc.)
After the candidate finishes, ask him or her to go to the person wearing a cap in the hall and ask for the next assignment. Make the person in the hall appear busy talking with a colleague. See if the candidate interrupts the conversation to ask for the next assignment.
Gladwell found that people who read polite words end up not interrupting the person in the hall. They wait more than ten minutes or more patiently waiting for the person to stop.
In contrast, give the candidate a grammar test full of rude words (”aggressive, angry, belligerent, foul, etc.), and they interrupt the person in the hall in just a few minutes.
It might not tell you anything about the candidate’s ability, but it sure would be fun to watch.
March 14th, 2008 at 6:48 am
A job I got recently required I write about how to get a sock monkey on eBay:
http://www.associatedcontent.com/article/578845/sock_monkey_got_me_a_great_job.html
March 14th, 2008 at 7:33 am
I don’t agree with what you say in #4:
“Check out the candidate’s blog to see if he or she is an interesting person. If there is no blog, Google the candidate. If you can’t find anything anywhere, be skeptical about the answer in #3.”
As if you can’t be an enthousiastic tech communicator without having your own blog.
The only things you can find when you google my name are my LinkedIn and Naymz profile, and that’s how I like to keep it. For me the fun lies in creating helpful documentation, sample code, video tutorials, etc… without being in the spotlights myself. And that really doesn’t mean that I’m not serious about tech communication.
March 14th, 2008 at 9:34 am
Interesting list, Tom. I wonder if I’d get hired if I went through your interview process.
I take issue with #9 and #10.
For #9, when you are hiring a writer, I think it may be unfair to test their writing skills by creating a video. That doesn’t make sense to me. When I consider the deliverables at my current writing gig, hiring somebody who can make a great video wouldn’t help me much.
Personally, I’ve never done much video. If I were asked to do that task, I’d spend so much time trying to figure out how to use the video creation software that the overall quality of the user help would be horrible. If you don’t require video or video software as part of the job requirements, it is unfair to test your applicants on their ability to use it, in my opinion.
(Of course, if video is a deliverable, by all means test them on that.)
I think that if I were to re-write your #9, I’d say “If you have to give a test, be sure the test reflects the format and type of work you’d expect the writer to produce in your company’s real-world work environment.”
Instructions for making a sandwich or withdrawing cash from an ATM aren’t particularly helpful if you are trying to find a writer of API documentation. The skills are totally different. A video also wouldn’t be a great medium if all you deliver is PDF-based printed documentation.
Later, you say to make it hard. I disagree with this too. Your example of speeding up Firefox seems weird to me. Why would I want to hire somebody who knows how to speed up Firefox if I don’t work for Mozilla? Making it excessively hard will skew the work samples so you can’t properly evaluate the responses. It seems it would be more helpful to ask them to complete an assignment that is at the same difficulty level as the task they’ll be documenting, and I think it should be in a related area. Not only do you not see the type of work you will be expecting from the potential employee, but you are also being unfair to them by implying that the work environment will be substantially different than reality.
The thing is, generally, you’re not hiring a content expert. You’re hiring somebody who can interface with your content experts in a positive way to get the information they need in order to write high quality documentation. It helps if your writer has domain expertise, but asking a candidate to document a hard task just for the sake of making the test hard isn’t really that useful. Far more useful might be to give the user a hypothetical situation of documenting a hard task, and ask them how they would go about beginning the project, and how they would get the information they need in order to write the documentation. It seems that the process is really more interesting than whatever output you might get from your difficult test.
As for #10, I don’t think I’d want to work with a boss who disqualified me solely on the basis that I made an administrative decision not to use styles on my resume.
I understand the power of styles. But on a one page document, I don’t always use styles. Sometimes local formatting is a better choice than style-based layout. Rather than simply disqualifying people because they haven’t used styles, why not ask them why they made the decision they did? If I can coherently explain why I chose not to use styles, isn’t that my choice as an author? On my personal resume, I don’t use styles. However, when I helped my brother create a resume template that he could continue updating, I did go to the effort of creating the styles and teaching him how to use them so the formatting would be consistent across his resume. It took a lot more effort, which is great for him, but would essentially be waisted effort for me (because I can get the same output faster and with less effort.)
But this is actually why I generally don’t provide my resume in .doc format. I provide a text version and a PDF version. I just don’t like the idea of people dissecting my Word document.
Anyway, sorry for the long rant. Good list!
March 14th, 2008 at 9:45 am
Paul, thanks for the comment. I agree with what you say. I suppose I made the post too quickly, and this is one of the benefits of interactivity — you enrich my view.
However, about the video. One writing test I took required me to document a widget, and I not only wrote the instructions, but also created a short video tutorial showing how to do it. This put me ahead of others, I believe, in a significant way.
Video simply isn’t on the radar of many employers. They think, I need a technical “writer.” My opinion is that technical writing — if it is to be helpful and appealing to users today — must begin to include audiovisual media as well. Simply providing written documentation isn’t enough anymore. If I were hiring someone, I would want to make sure the person’s skillset included more than just writing.
That said, I think most writers could easily learn to create video. Video tutorials are actually a lot of fun to make. And of course I would allow the writer to use whatever video creation tools he or she was familiar with.
But ultimately you’re right — if the hiring manager doesn’t want video tutorials as a company deliverable, then the test would be inappropriate. I included only as a wake-up call to hiring managers, to say hey, technical writers do more than simply write.
I agree with your other points. Thanks again.
March 14th, 2008 at 9:56 am
So maybe the video thing should be directed more towards candidates as a way to differentiate themselves, rather than telling hiring managers to expect it.
I think that a writer going into an interview would be much better positioned if they included some video documentation in their portfolio. That I totally agree with.
I just hope a hiring manager doesn’t have unfair expectations of potential employees. If you can do video, great! But does it have to be a requirement? Maybe not.
March 14th, 2008 at 2:57 pm
Another thing that I think would be important is to find out how fast a learner the candidate is. Judging this may involve asking the candidate to download a software trial and learn as much as possible about how to use it within 20 or 30 minutes. Then ask the candidate to articulate what he or she has learned and even show you.
This would give you an idea of how quickly the candidate can pick up new tools and also how well he or she can explain how to use them to other people.
This may be relevant mostly in software companies, but it may be helpful in other companies if your methods of delivering documentation and training is subject to change.
March 14th, 2008 at 4:58 pm
See I disagree with Paul-
I believe that you need to hire someone who is an expert (or at least very competent) in a specific field of knowledge. I’m not saying that someone who’s going to write about heart monitors needs to do the firefox task. But experience tells me that for everyone whose hand is in reviewing documents (engineering, marketing, customer support) they don’t always have the unassisted user’s frame of reference. THey will tell you if you’ve got it right, but don’t have the faculties to know how much detail you need, or how much background is really needed as a basis for an explanation.
I’m swallowing my pride by saying this, but a great tech writer is a user-advocate. But not just that - the great tech writer needs to write from a level just above the user. In a sense, you are mentoring the user, and you really have to know his or her place.
So ok, for instance, if you are writing about a product that can take you a few weeks to become an expert in (like PoS software), that’s one thing. But if you’re documenting a software API - you better have some pretty solid software engineering skills, at least as a basis.
March 14th, 2008 at 8:52 pm
Siska, thanks for commenting on my post. I realize there are a great number of highly competent, skilled, knowledgeable technical writers who don’t have blogs, don’t participate in forums, and don’t appear anywhere in Google. But in this day and age, that’s getting to be harder and harder. If you’re truly enthusiastic, and you create helpful documentation, sample code, and video tutorials, where are you putting them? Aren’t you asking questions in forums? Are you participating in online communities? Why don’t you have a blog? What about articles you’ve published? Questions or comments you’ve left on listservs? Haven’t other people mentioned your name somewhere?
10 years ago, I would have never made such a comment. But now everything is online. If you don’t appear in Google, I’m not convinced that you’re engaged in the field of technical communication very passionately.
March 14th, 2008 at 8:53 pm
John, thanks for sharing your article on sock puppets. It sounds like it was a fun assignment.
March 15th, 2008 at 5:53 pm
March 16th, 2008 at 12:02 am
[...] 10 Alternate Tests for Evaluating Technical Writing Job Candidates - A List for Hiring Managers [...]
March 17th, 2008 at 3:28 pm
I don’t know that I necessarily agree that requiring a video is unreasonable or an unfair judgement. Many technical writers are also required to be technical “communicators.” During school, my fellow majors had to pick a concentration to make “Technical and Professional Communication” a more marketable major; I chose “Multimedia Writing.”
My point: If you cannot communicate via flexible mediums, you may lose out.
March 17th, 2008 at 4:51 pm
Shauna,
I don’t think it is unfair in every case, but I think if you are going to require it, then (1) it should be clearly laid out in the job description that you want somebody who can create videos, and (2) you should provide the test in a way that doesn’t put the candidate at a disadvantage from the start (i.e. locking them into creating a video only using the tool you are using in your environment).
If you don’t clearly state that you are looking for somebody with video qualifications, then you are being unfair to potential candidates, as it isn’t reasonable to expect that all technical writers come with video-creation skills as standard.
If you require your candidates to create a video as a test during the hiring phase, then you better do so in a way helps you determine if you want the writer or not. If your candidate is forced to focus on the tool, then you may not get an accurate idea of what the candidate is capable of creating in a real-world environment. There are so many tools out there that you will probably not find that every candidate has experience with the same tools. What is more interesting is does the candidate understand communicating in a video medium? Can they write content for creating a video? Do they focus on the correct steps with the appropriate amount of emphasis? Do they understand their audience and can they create content that helps address the needs of that audience? The best way to find that out MIGHT not be to make them create a video on the spot using a tool they are unfamiliar with.
Do I think video creation is a great skill for a technical communicator? Absolutely. My only point is that if you are going to require it from a candidate, do so in a way that is both fair to the candidate, and helps you as the hiring manager understand if the candidate possesses the skills that really matter. Anybody (practically) can learn the tool given the right environment. But do they have the skills that will create the kind of video you are looking for? That’s what you have to determine.
March 18th, 2008 at 8:26 am
RE Tom and Siska -
I’ve got to take side with Siska here. I’m in the same boat as she is. See, I do participate actively in the community — I add to forums and wikis, I speak at local events, I also have several blogs, photo sharing sites, a web site, etc. However, I don’t use my full name (in many cases, I write under a pseudonym) in any of those contexts.
I work very hard to keep my name out of google. I love the power of communication and collaboration that the web gives me, but I also love my personal privacy. I don’t want people I know to read my stuff unless I’ve asked them to (by sharing a link, or my personal alias). Bloggers like Dare Obasanjo have had a lot of trouble with this kind of publicity.
Nor do I want people I don’t know to read my material and have access to my personal life. We all know how bad that can go after watching Kathy Sierra drop out of the blogosphere last year.
Being active in your community has nothing to do with having a public presence within that community. I can be as active as any other guy without sharing any personal details about myself. For years I’ve been a contributing member of the communities that I belong to on the web without leaving my name behind. However, the people in those circles do know me, and do know my work - they just don’t know my name, where I live, where I work, or even my gender.
Tom, you have a public presence, and that’s great. It’s part of your personal business model. It’s not a part of mine. I work to control the information that I share with others, and when an employer asks for information I will happily give it to them, including links to the sites I post to, or pseudonyms — but they have to ask. Searching for my name without asking and then making assumptions is asking for trouble (not to mention, kind of rude).
March 18th, 2008 at 8:39 am
RE Writing samples:
I’ve always wondered what other people do when handing in writing samples. All of my samples are created with pretty specific parameters, and if you took any three of them to compare you would find that they are all completely different and not representative of any particular style.
In the last year, I’ve written for:
- a ‘new and funky’ web 2.0 company
- a technology site for children
- two very large companies, each with their own stylistic requirements
- a wiki for a video game community
- a very large doc set that had been completely translated already. meaning that I can’t change what’s there in any meaningful way, but I have to take ownership of the entire work.
All of these have a very different writing style.
When presenting these to a potential employer, do people provide a synopsis of the parameters that they are working in? Or a summary of the client, the situation, and what you did for your writing?
I’ve seen this sort of thing done in portfolios for advertising companies or in some art portfolios but never in journalism or tech writing portfolios. However, I’m considering starting. More and more of the writing that I do is what I would consider horrible, unless it was presented in the context of the work.
i.e. If I were to submit a dita task to the children’s techology website I for sure wouldn’t get the job.
What are other people doing?
March 18th, 2008 at 8:46 am
There’s some great discussion going on here. I want to respond to some of the points you raised, but won’t get to it until later. In the meantime, my mother raised an excellent point that I want to insert here:
The point she raises is an important one. Maybe the candidate you’re interviewing won’t have all the skills you want/need for the position at the time. But perhaps the candidate is an exceptional self-learner, a highly dedicated employee who can learn everything he or she needs to know about single sourcing and structured authoring etc. on the job in a matter of weeks.
Some people may seem to know a lot, but after you hire them, you realize they aren’t motivated to keep learning. I would rather hire an under-experienced person who is a motivated self-learner and technology enthusiast than someone who has 4 years of experience and knows a thing or two, but is not passionate to keep learning.
March 18th, 2008 at 10:00 am
Comma Hater,
(Sorry it took so long to respond. I didn’t see your message above.)
I think we actually agree, even though you thought we disagree.
I actually think that you want to hire experts. I work for a company that creates text analytic software. If I could find a technical writer who was an expert in linguistics, and an expert Java, I’d take a very serious look at that candidate.
My point was more that it would be weird to ask a candidate to document tricks on speeding up Firefox if that has nothing to do with the work you are doing in your company. Just because a writer can hack Firefox to make it faster doesn’t mean they will be a good fit at my company. Even more important, even if they can’t figure out how to make Firefox work faster, they still might be a great fit because they already know how to do what my company wants them to do.
So I took issue with the Firefox example not because I don’t think we want to hire experts in our field, but because I don’t think that you should expect that every technical writer is an expert in tweaking open-source software, nor do I think that is a very good indicator of whether or not that writer will be a good fit in a given position. (Unless of course the writer is applying to work for the Mozilla Foundation. Then that would be a different story.)
March 19th, 2008 at 3:37 pm
Dave, to respond to your comment about how to handle varied items as writing samples in your portfolio, here’s what I’m doing. Like you suggest, I do an annotated portfolio. It has a one-page introduction and three major sections - for me, these are user documentation, technical/in-house documentation, and marketing/editing samples. Each section has an introductory page with a short paragraph about the section’s focus, and about each piece. I also brought around a flash drive with samples of online help projects. In interviews, if I’ve brought the whole binder, I point out relevant samples for them; if they’ve provided specifics, I bring or send those.
Also, not everything that writers create is destined to be a portfolio piece. I’ve nixed things because I didn’t like the format the final customer used for distribution. I used to do some medical editing, so I once decided not to include an item where the dramatic (and icky) subject matter would overshadow anything else about it.
March 25th, 2008 at 6:37 pm
[...] @mrinal_desai - Who is Your Chauffeur? @Rachelskirts - Best Egg Hunt Ever @tomjohnson1492 - 10 Alternate Tests for Evaluating Technical Writing Job Candidates — A List for Hiring Manager… @daveatkins - Marketing and Politics @rachelpulido01 - Talk about Tuesday - Goals @ScrapNancy - Why [...]
March 25th, 2008 at 7:03 pm
[...] @mrinal_desai - Who is Your Chauffeur? @Rachelskirts - Best Egg Hunt Ever @tomjohnson1492 - 10 Alternate Tests for Evaluating Technical Writing Job Candidates — A List for Hiring Manager… @daveatkins - Marketing and Politics @rachelpulido01 - Talk about Tuesday - Goals @ScrapNancy - Why [...]
March 25th, 2008 at 10:32 pm
[...] @mrinal_desai - Who is Your Chauffeur? @Rachelskirts - Best Egg Hunt Ever @tomjohnson1492 - 10 Alternate Tests for Evaluating Technical Writing Job Candidates — A List for Hiring Managers @daveatkins - Marketing and Politics @rachelpulido01 - Talk about Tuesday - Goals @ScrapNancy - Why [...]
March 26th, 2008 at 2:06 am
March 26th, 2008 at 2:40 am
March 26th, 2008 at 3:03 am
March 26th, 2008 at 3:05 pm
March 26th, 2008 at 4:55 pm
March 26th, 2008 at 5:40 pm
March 27th, 2008 at 7:17 pm
[...] @mrinal_desai - Who is Your Chauffeur? @Rachelskirts - Best Egg Hunt Ever @tomjohnson1492 - 10 Alternate Tests for Evaluating Technical Writing Job Candidates — A List for Hiring Managers @daveatkins - Marketing and Politics @rachelpulido01 - Talk about Tuesday - Goals @ScrapNancy - Why [...]
March 28th, 2008 at 5:40 am
March 30th, 2008 at 4:04 pm
[...] @mrinal_desai - Who is Your Chauffeur? @Rachelskirts - Best Egg Hunt Ever @tomjohnson1492 - 10 Alternate Tests for Evaluating Technical Writing Job Candidates — A List for Hiring Manager… @daveatkins - Marketing and Politics @rachelpulido01 - Talk about Tuesday - Goals @ScrapNancy - Why [...]
March 30th, 2008 at 11:41 pm
April 3rd, 2008 at 11:05 pm
April 6th, 2008 at 8:50 am
April 6, 2008 Update: I have officially changed my mind about writing tests. While I initially thought they were insulting, I now think they are essential. I guess I had to experience for myself an interaction with someone whose writing I felt to be subpar. It lacked thoroughness, wasn’t easy to follow, was poorly organized, sometimes unclear, and was overall not something I’d want my department name attached to.
Many candidates pose as technical writers but really lack the skills. Writing tests can help weed these candidates out. I guess I’ve come full circle on this. I now would also encourage a writing test, and require that candidates provide instructions on how to document a typical company widget. When you get that writing sample, here are some obvious signs that you shouldn’t hire them:
* The writer doesn’t use numbered steps.
* The procedure had 20+ steps without being broken into separate tasks.
* The writing is unclear.
* The writing is poorly organized.
* The formatting is sloppy.
* The writer doesn’t structure the content with styles.
* The steps are inaccurate.
* Field definitions aren’t illuminating.
* You can spot misspellings and grammar errors.
My alternate tests are still valid. I’m just now endorsing the standard writing test.
As an added bonus, requiring writing tests will drastically reduce the number of candidates who apply.
May 10th, 2008 at 9:40 pm