TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
-----Original Message-----
From: Kim Bieler
Sent: Wednesday, April 11, 2012 10:33 AM
To: techwr-l -at- lists -dot- techwr-l -dot- com
Subject: Interviewing technical writers
I'm evaluating resumes for a technical writing & content strategy position at our company. I'm pretty clear on what I would ask candidates in an interview, but I'm not sure how to decide based on their resume who I should follow up with.
Is it appropriate to ask for writing samples before an interview? Are there particular assets or red flags I should be looking for in a resume? Any background research I should conduct?
Thanks!
Kim Bieler
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The most useful interviews I've been in/been an interviewer on are usually resume submission, phone screen (sometimes with multiple people such as HR and the hiring decision maker), and then one or two rounds of interviews. I'm personally not a fan of two rounds of interviews unless it is impossible because of scheduling and you can't get all the interviewers in a back-to-back timeframe.
As far as samples - as mentioned in a previous comment, it's pretty easy for a bad writer to fudge good samples. As long as it looks professional I usually don't pay too much attention to actual samples (although I do try to make sure they understand the concepts of working with styles and not in-line formatting everything) - what I find to be the most important is the tools skillset (including industry knowledge, if applicable), if they have an understanding of any particular concepts you use in producing your work (do you single source, etc.) and a general idea of how they might deal with the particular chaos that is your own workplace (can they deal with changing deadlines, late reviews, how they deal with tight-lipped SMEs, etc.). Plenty of people can write. But that doesn't mean they are the right technical writer for your workplace.
- V
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create and publish documentation through multiple channels with Doc-To-Help. Choose your authoring formats and get any output you may need.
Try Doc-To-Help, now with MS SharePoint integration, free for 30-days.
