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.
Mine is also similar to others mentioned previously. Though I give myself
no length restrictions, it always comes to 3 pages. I've never had any
problem with that length.
Short statement of objective
Summary of experience (bullet list of specific tech writing skills and
types of deliverables I have/can produce, such as diagrams, flowcharts,
technical proposals, word macros, etc.)
Work history, in format:
Employer, location, dates
Paragraph of description. The first sentence describes my job function and
the project environment (tech writing...client-server application
development team), the rest describes the deliverables and tasks I
performed as part of the job (user manuals, informational interviews,
informal QA testing and results compilation, etc.).
End / page 3
Education (in this location to downplay my lack of a degree)
Associations (STC, HWG, etc.)
Applications experience table (tools I use, such as Word, Visio, etc.) I
have also put this table on page 1 with success.
My contracting companies usually cut and paste parts of my resume into
their standard format, then send my original along with it. That works the
best, IMO, since the visual format of the resume is an example of my work
that I want the client-employer to see.
Originally I described my jobs in the way that resume writing books tell
you to: in terms of accomplishments and concrete benefits (423-pg user
manual, $x cost savings produced, cut 3 weeks from timeline, etc.) but I
found that didn't work very well for my varied TW contracting experience.
On most contracts I do a bit of everything, with several short, unrelated
projects, rather than a large, significant project. This is just the kind
of work I like, so I prefer to emphasize the variety of skills I use and
the multi-tasking I do, rather than focusing on a single deliverable and
There seems to be lots of variety out there; that's interesting.