Podcast: Play in new window | Download

The voices in this podcast belong to: Graham Campbell and Alistair Christie.

This time round, Graham and I discuss the best way of interviewing technical writers.

Skills/attributes we mention as being things we’d look for in a candidate for a technical writer position include:

1. Evidence of solid English language skills (particularly competency in written communication)

2. A genuine enthusiasm for technology (and preferably a fascination in software)

3. Signs that the candidate would fit into the team, provide effective peer review and would be able to interact with the developers

4. The ability to review the work of colleagues effectively – and to have your work reviewed

Podcast recommendations:

The Best of MySpace – http://www.bestofmyspace.uk.com/

Mostly Tunes – http://www.mostlytunes.com/

Note: The song I play at the end of this show is one I heard on a recent Mostly Tunes show:

Be OK by Ingrid Michaelson – played here by grace of the Podsafe Music Network.

Listen to more of Ingrid’s songs.

Application recommendations:

Adobe Buzzword – http://www.acrobat.com

Google Calendar – http://www.google.co.uk/intl/en/options/ 

Tips:

Press Q on Google Calendar for a quick, natural language way of adding an appointment.

What I’m listening to:

Graham is (still) listening to the music from the Transformers movie.

Oops! – a note about the sound quality

Despite a quarter century of podcasts (if you see what I mean) I still managed to make a couple of schoolboy errors with the recording of this podcast:

1. I didn’t check the levels properly, so Graham is too quite and my mic is maxing out

2. I accidentally recorded in mono. Usually I record with each mic into one side of a stereo recording so that I could remix the levels.

So apologies if I sound worse than usual in this recording and you’re struggling to hear Graham.   

The music I play at the beginning and end of the show is by Amplifico. You can hear more of their music at Podshow.

I’ve just started the challenging task of hiring a new technical writer.

As a result I’ve been reviewing our interview process, researching what other bloggers have had to say on the subject and generally thinking about the challenge of getting the right person.

As chance would have it, Writer River dropped an email in my inbox on Monday with a relevant article: 
The Interview Question You Should Always Ask

This is one of those blog posts where the comments are as interesting as the actual article. The question referred to in the title (you might want to stop reading here and go and read the article first … no?, okay let’s continue) is “What do you do in your spare time?” I’ve never asked this question but I thought it was a good one. If an applicant says he/she writes a blog, contributes to open source documentation projects and creates instructional videos and posts them on YouTube, then they probably immediately elevate themselves into the contender bracket.

However, some of the comments warned of potential HR headaches, or nightmares, arising from asking this question.

I would never ask this question.
1) It might take you somewhere where you do not want to go:

What do you do in your spare time? - I sing in the choir at my church.
or
I take care of a disabled husband.
or
I meet with the therapist that is helping me to battle my addiction.

Another commenter added the following grim warning:

Should this candidate reveal something in their answer that could be viewed through the lens of being "protected", and you elect not to hire the candidate, you may find yourself spending significant time with your legal counsel.

This also made me think that maybe I should consider getting our HR person involved in the interview. I’ve always preferred not to have the HR person sitting in through the whole interview, but maybe I should, I’m not sure. I tend to think that HR problems generated from interviews (other than for internal candidates, which is a more complicated situation) has got to be more something that happens in the more litigious US, not here in the UK. But maybe this is an accident waiting to happen and we should be less easy-going/conversational in our approach to interviews, which would be a shame.

Some good resources on interviewing are:

• The Guerrilla Guide to Interviewing (version 3.0) by Joel Spolsky
• Thoughts on Interviewing by Gordon McLean
• Interviewing by Gordon McLean
• 10 Alternate Tests for Evaluating Technical Writing Job Candidates — A List for Hiring Managers by Tom Johnson 
  This is another one where you really need to read through the comments.

Graham pointed out this scandalous slight on our profession:

Whenever I'm asked I usually say: "I work for a software company".

This is pretty much as good as conversation stopper as the above but it has the benefit of not building you up for a fall. If I say: "I'm a technical writer" or worse still: "I'm a technical author", the other person doesn't have a clue what I'm on about but they do catch the word "writer" or "author" which sounds quite interesting and they hopefully ask me to elaborate. This just leads to disappointment and antagonism, as if my first reply had been a deliberate trick to fool them into thinking their line of questioning could have led to an interesting conversation.

I always thought "wheel tapper" sounded an intriguing job.

Graham Campbell writes:

We had some listener feedback about the Podcast on being the sole TA in an organisation (Being the only tech writer - Podcast #13).

Paul Welsh, a Technical Writer from Nebraska, USA, raised the following point:

"One thing that I don't think you mentioned is that there's no one to talk to when it comes to
your job. Not a big deal, but I've noticed it a few times lately as I evaluate tools and there's no one else here who would really get it, or be interested in the discussion."

It's a good point, and one that I feel is actually a big deal despite what Paul suggests. Beyond the evaluation of tools and procedures - something that demands a peer for meaningful discourse - the actual discussion of work to be done and requisite peer review are just not there.

For someone as new to the vocation as me - I mentioned in the Podcast I've been a Tech Writer for 2 years now - the absence of peer review is a knock to both confidence and, inevitably, quality. The fear of not producing a meaningful piece of work is bad enough without the added burden of knowing that, without peer review, mistakes and bad habits aren't being identified and dealt with.

I've offered before that Tech Writers can feel like we're considered last and least in the list of priorities in an organisation, and this feeling is only emphasised when you're flying solo.

However, Geoff Hart's article on Why do I need a technical writer? makes a good job of listing the very specific reasons a skilled Tech Writer is an important addition to any organisation.

In particular, his first point in reducing support costs:

"Technical writers think of the task from the user's perspective, not the designer's perspective. Thus, they explain better how users can reach their goals."

Which brings me nicely to the solution I found for my dilemma - conscript one of the Testers as a pseudo-reviewer.

Any software house worth its salt will have an internal team of quality assurance testers. Testers, like Tech Writers, have an inherent eye for detail perfect for finding any error in that tricky procedure you wrote or with the delivery method you chose (broken links in a series of Online Help Web pages for example). More importantly, testers are also looking at the tasks in the software from a user's (and a usability) point of view which, as Geoff states in his article, is a vital Tech Writer trait.

While Testers and Tech Writers have different sets of skills, they nonetheless both share the same attention to detail required to perform their designated function as well as an interest in the tools and procedures needed to "get it right".

I'd never advocate this as a permanent solution of course, but if you find yourself missing a spare Tech Writer or two and are on good terms with your QA staff, relying on their keen eye is a good stop-gap.