If you’re like me, you can’t hire as many people as you need to do the work. But I’ve just had a writer take another opportunity, and now I have to back fill for him. The good news is there are lots of qualified writers out there right now. The bad news is there are also a lot of people applying for just anything. It can be make the hiring situation kind of overwhelming, but I have some tips that I, unfortunately, learned the hard way.
Tip #1: Recognize your job is hard
The biggest mistake I made in my first couple hires was to think that my job was standard fare that anyone could handle. I felt like I was being overdramatic to spend too much time vetting the candidates, when it seemed like it just couldn’t be that hard. Anyone would do.
The tricky thing here is that technical communicators have a very wide variety of skills and a broad spectrum of capabilities. A person can have the title “Technical Writer” and have it mean anything from “I know the source code inside and out, help customers directly with technical issues, and consult with the product manager on the direction and design of the product” to “I get a rough draft from an SME and add page breaks in the right places.”
Your job is hard, and not just anyone can do it. You can and should be picky.
Tip #2: It’s not just what’s in the résumé, but also how it’s in there
In our field, the résumé is the applicant’s first writing sample. Using “it’s” when you meant to use “its” doesn’t just demonstrate confusion about possessive pronouns; it also demonstrates a lack of carefulness. Myself, I probably wouldn’t automatically disqualify someone for that mistake alone, but if your position requires a high level of attention to grammatical detail, then this applicant has already shown you they’re not up to the challenge.
For example, one thing I care about is that my writers really consider the user’s needs. But saying “customer focused” on the résumé means a lot less than demonstrating that you considered my needs in reading it. Here are a few examples:
| My need as a user | How applicants can meet that need | How they often don’t |
|---|---|---|
| I’m swamped. I might like to hear your life story if we were chatting over coffee, but right now I need you to hit the high points. | Give me a brief, scanable résumé. | Filling a résumé with bumper-to-bumper words. Sure, it shows you can type, but it doesn’t prove you can write. |
| I’ve gotten a few dozen résumé this week and I am keeping them all in a folder. | Give your résumé a clear file name that includes the your name and the year. | Naming the file “resume.doc.” Not only does this make me think you send the same résumé to every random job, but it also gives me file name conflicts with the 20 other people who named their file the same thing. |
| I want to hire writers with diverse backgrounds to correspond with the diverse backgrounds of our customers. | Connect the dots for me about how your experience, which may not be directly related to tech comm, is relevant. I want to use your skills but I don’t have time to imagine all the ways your time as a sporting goods store manager might relate to my job requirements. | Listing a creative writing major and no other qualifications. While sometimes technical documentation feels like creative writing (read: vaporware), an applicant who thinks skill writing poetry translates directly to skill writing technical docs is in for a shock. |
Tip #3: A stitch in time saves nine
Firing people sucks. It sucks for you, it sucks for the company, and it sucks especially for the person being fired. It sucks so much that you owe it to everyone involved to put in the work to pick the right person in the first place. My interview process is a lengthy one, but I haven’t had to fire anyone since I started using it. It goes like this:
Résumé review
I look not just at the content of the career but also the care with which the résumé was put together. We’ve been over that. Let’s move on.
Writing test
This is my favorite part because it’s so very telling. Our writing test has three exercises:
- The first exercise is an editing test. I took a particularly dense paragraph from an old doc and pumped in a few typos and run on sentences. The test taker is challenged to correct and compress the information. The passage starts out at 294 words, and I see cutting the count as evidence of mastery of these tools we call words. A good candidate can get it down to 200. I can get it down to 95, but I’m really mean like that.
- The second exercise is the real challenge: I provide some cryptic notes I wrote while researching a feature and challenge the applicant to organize them into a feature guide. Writing an accurate feature guide isn’t the point; this exercise measures your enthusiasm for rolling up your sleeves and trying something you don’t already understand. My team isn’t often held by the hand, so my writers need to have the self-confidence to try even when there’s a chance they’ll be wrong.
- The final exercise is defining a list of web terms. I’d like to say this is about writing clear reference content, but actually I created this test in direct response to a former coworker who dug up the entirely wrong meaning of an acronym online somewhere and published it in a customer-facing document without questioning why a financial term was suddenly in the middle of a document about FTP. This is an easy exercise, but I guess I feel like I just have to have a reality check in there.
Phone interview
After subjecting the candidate to the test (which only takes a couple hours but people get really worked up about it) I’ll schedule a phone interview where I’ll go over the writing test with the applicant and talk about the choices they made in completing it.
You know, it’s funny: even though all tech writers are dedicated to improving the user experience, I have yet to meet one who didn’t have trouble, at least at first, receiving feedback, even though they know it makes their documents better. There’s something just so personal about putting words on paper, and having someone question you on them directly just hurts. But this is an enlightening discussion because it lets you see how thoughtful the candidate was about the writing in the first place and how well they can handle critique.
In-person interview
If the applicant makes it to the in-person interview, I pretty much already decided that I think they could do the job. This is the time for candidates to interview us, so I want to expose them to as many of the warts of working in this department as I can.
“I love working here, but it’s not for everyone,” is one of my favorite phrases. Then I go on to describe the super-fast pace, the changing priorities, and the frequent need to blaze your own trail. Many documentation departments are downright sedate, and a person who loves that environment is going to be horribly frustrated on my team. And if you’re one of those “I get a rough draft from an SME and add page breaks in the right places” writers, we might as well find out early that it’s not going to work out.
In summary
To sum up, taking pity on candidates during the selection process might seem kind, but it doesn’t really help anyone in the end. You don’t have to be cruel, but putting candidates through their paces will not only save you time and money in the long run, but will also help you find just that right person to fill your all-too-rare open headcount.
What are your tips for navigating the sea of résumés? Share them in the comments below.
