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.
Geoff Hart requested these comments be forwarded to the list:
> I'm in full agreement with those who have said that writers should
> always have writing samples available. That's not to say that you
> should ram them down the interviewer's throat; far from it. Make it
> known that they're available and you're willing to discuss them, and
> leave it at that. Those who have expressed vehement dislike of
> writers bearing samples will experience a brief moment of
> annoyance and proceed to ignore them; those who want to dig a bit
> deeper into your skills will appreciate them and will take the time
> to do so. Win-win situation, as I read it.
>
> Issues of confidentiality and what to include become somewhat moot if
> you think of the samples from the interviewer's side of the table:
> "What do I want to learn about the candidate? I certainly don't want
> to try to skim a 500-page manual in the 5 minutes we have left and
> try to infer this information." The answer to the question is that
> the interviewer wants to know that you can think a problem through
> and arrive at a logical, reader-friendly solution. So pick example
> text that shows your solution to several common problems: how to
> chunk text, how to work with white space and levels of heading, how
> to create and proof hyperlinks, etc. etc. etc. Then, rather than
> requiring the interviewer to read each one, simply lay it on the
> table, explain what the problem was that you tried to solve, how you
> solved it, and whether you're satisfied with the solution.
>
> Confidentiality is also moot. You're bound to get in trouble
> eventually if you display confidential documents, even with the
> company name bleeped out somehow. The solution is simple, but
> time-consuming: take the same format you used for the company in the
> confidential document, and build a (say) 2-page sample based on that
> format for some hypothetical product (e.g., Spacely Sprockets).
> Again, emphasize the problem and the solution, not the specific
> details of some confidential product.
> --Geoff Hart @8^{)}
> geoff-h -at- mtl -dot- feric -dot- ca
