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.
The resume/cover letter can provide hints as to the person's talents and abilities. If the cover letter is rambling, repetitive, and full of $10 words that sound fancy but don't say much, then its pretty much guaranteed that they don't know how to write in the clear and concise manner required of a tech writer.
If the resume is a crowded, hectic jumble overstuffed with details, then they don't know how to structure and filter information, and have no sense of design/how to optimize content delivery.
If there are formatting errors, or problems with grammar and spelling, forget it. They deserve no mercy.
I always insist on seeing writing samples up front. Even though, as Peter pointed out, people may cheat by submitting stuff they haven't written, seeing what they consider worthy of submission can tell you a lot, in terms of what their standards are.
Anybody who makes it to the interview stage is told prior to the meeting that they will be asked to complete short writing and editing tests.
For the writing test, I give them some jumbled point-form notes about a software function and ask them to write a brief overview, and include any questions they'd put to a subject expert. This tests their ability to analyze information, think creatively, extract what is pertinent, organize it, and write coherently in plain English.
The editing test is a simple one-page procedure with built-in errors -- devious stuff like using "affect" instead of "effect"; a glaring syntax error in the section head (which Nobody ever catches); a screen shot that doesn't quite show what the text says; a step sequence that doesn't quite make logical sense; inconsistencies in style, etc. This tests their analytical and language skills, and indicates whether they have the focus to be finicky about all the details you need to get right when producing accurate documentation.
In the end though, it's a real crap shoot. Some of the worst writers I worked with were those with several decades of experience; they tended to write in an academic style, rather than in plain English, and were so convinced of their eminent magnificence that they refused to accept legitimate editorial feedback -- they cared more about protecting their egos than nailing the content. Newer writers tended to be more open to learning and improving their skills and in going the extra mile to ensure that what they produced was as comprehensive, accurate and professional as possible... But then they need somebody who can mentor them/give them the informed feedback they need to evolve.
-----Original Message-----
From: techwr-l-bounces+lynne -dot- wright=tiburoninc -dot- com -at- lists -dot- techwr-l -dot- com [mailto:techwr-l-bounces+lynne -dot- wright=tiburoninc -dot- com -at- lists -dot- techwr-l -dot- com] On Behalf Of Kim Bieler
Sent: Wednesday, April 11, 2012 11: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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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.
Looking for articles on Technical Communications? Head over to our online magazine at http://techwhirl.com
Looking for the archived Techwr-l email discussions? Search our public email archives @ http://techwr-l.com/archives
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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.
