Re: samples again

[Roger Mallett <roger -at- CSICAL -dot- COM>]

I've done a bit of hiring in my days and you are right on target.  In
fact, I use your exact same method when I sell myself on a job.  I also
like to include marketing literature for products from competing
companies and redline those to death (especially picking on look and
feel), demonstrating to my potential clients that they will not have to
worry about such common problems when my eagle eye is assigned to the
task.

With respect to interviewing others, I have never seen anyone as
prepared as we are (I wish they were).  However, I know what to ask, so
it is easy to ferret out those who really don't know the overall
processes of our profession.

The solution you describe enables a potential buyer of your services to
examine if you really understand the nitty gritty details of technical
manual development.

A+ to you for this answer!


---------------------
Roger Mallett
Control Systems
(714) 458-5040 x 239

>----------
>From:  Miki Magyar[SMTP:MDM0857 -at- MCDATA -dot- COM]
>Sent:  Wednesday, March 25, 1998 12:14 PM
>To:    TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
>Subject:       samples again
>
>
>The best samples/portfolio solution I've found is the before-and-after
>format. I save the raw, crude, red-lined, hashed-over starting stuff,
>and the final version. I put them side by side in a 3-ring presentation
>binder (which is itself something I designed) so that anyone looking at
>it can see what I started with and what I did with it. I have one- and
>two-page selections from as many different kinds of stuff as I can
>collect. It's been easy to find non-confidential pages that I can use
>to demonstrate skill in editing, page layout, specific technical
>domains, graphics, etc. I can pick examples from my collection to
>target the people I'm talking to.
>
>I've shown this to tech pubs managers and HR people who weren't quite
>sure what a tech writer is. Both seem to understand what's being shown.
>In fact, for some contracting clients, it's been an excellent tool for
>teaching them just what they're asking for.
>
>All the examples don't have to be from paid jobs. That's the beauty of
>it. You can re-write your VCR instructions and impress a potential
>employer (assuming you do it well!).
>
>When you start looking for things to collect, look for the ugliest
>stuff. Look for examples that clearly demonstrate a particular skill.
>For instance, I have a page of code overlaid with the programmer's
>cryptic notes and sketches of how the system displays data. The
>finished page is clean, well organized, has a table showing the
>options, and so on. Yes, this person can talk to programmers and
>translate their stuff into clear English.
>
>Be prepared to explain how and why you made the changes and choices you
>did. Cite research and talk about the audience you were writing for. If
>you sound confident about the process, you'll come across as
>knowledgeable and competent.
>
>If all this sounds like a reprise of what I've said about how to break
>into tech writing, it is. I'd like to hear from some of the people who
>hire; am I right on this? Would this type of portfolio/samples be
>sufficient? Can we extrapolate from my experience to a general
>statement of usefulness?
>
>Miki
>mikim -at- mcdata -dot- com
>
>
>~~~
>Find contractor info at
>http://www.raycomm.com/techwhirl/contractors.htm
>
>