Technical writers face a strange irony in hiring: you get paid to make complex information clear, and then a recruiter gives your own document about seven seconds on the first pass. If your resume buries the docs you shipped under vague duty statements, you fail the exact test the job exists to solve.

The fix is specific. A technical writer resume wins on three things: the documentation types you own (API references, user guides, release notes), the toolchain you work in (Markdown, Git, MadCap Flare, DITA), and evidence that your writing changed a number somewhere, usually support tickets, onboarding time, or developer adoption. This guide walks through a complete technical writer resume example, then breaks down every section, including the applicant tracking system (ATS) keywords that recruiter filters actually scan for in technical writing postings.

The strongest technical writer resumes read like good documentation: front-loaded, scannable, and specific about scope. Hiring managers for these roles are often documentation leads or engineering managers, and they screen for three signals in order.

First, documentation types by name. "Wrote technical documentation" tells a reviewer nothing. "Wrote and maintained REST API reference documentation for 40+ endpoints" tells them exactly where you fit. Postings ask for specific deliverables, so your resume should name them: API documentation, user guides, admin guides, release notes, knowledge base articles, SDK documentation, runbooks, or installation manuals.

Second, the toolchain. Technical writing has split into camps. Docs-as-code teams live in Markdown, Git, and static site generators. Enterprise and hardware teams run structured authoring in MadCap Flare, DITA, or Oxygen XML. A recruiter filtering applications is checking whether your tools match theirs, and a resume that lists "Microsoft Word" as its headline tool signals you haven't worked in a modern docs team.

Third, outcomes. Documentation exists to reduce something: support tickets, time-to-first-call for an API, onboarding time for new users. The writers who get interviews connect their docs to one of those reductions, even roughly. "Cut ticket volume for the billing module after rewriting the self-serve help center" beats a paragraph about your attention to detail.

One more thing that separates technical writers from every other role: the portfolio. Your resume's job is partly to get someone to click your portfolio link, so that link needs to be in the header, working, and pointed at samples you're allowed to share. More on that below.

Here is a complete example for a mid-level technical writer in software. Notice how it names documentation types in the first line of the summary, puts the toolchain where a filter will find it, and ties bullets to measurable outcomes rather than responsibilities.

Treat this as a pattern, not a template to copy word for word. The structure transfers: niche in the summary, deliverables named in every role, tools in a dedicated skills section, portfolio in the header. The content has to be yours, because every claim on it is something an interviewer can probe.

Use reverse-chronological format. Technical writing is an experience-driven hire, and reviewers want to trace your progression: what you documented, for whom, with which tools, and how the scope grew. A functional (skills-first) format hides that progression and reads as if you're hiding something, which recruiters have learned to assume you are.

Two situations justify a variation. Career changers coming from engineering, support, QA, or teaching can use a hybrid format: a short skills-and-tools block up top, then reverse-chronological experience with the writing-adjacent work pulled forward in each role's bullets. And freelancers should group client work under a single "Freelance Technical Writer" entry with per-client sub-bullets, rather than listing eight three-month engagements that look like job-hopping.

On length: one page for under roughly five years of experience, two pages once your project list genuinely earns it. Senior writers with a decade across API docs, localization, and docs tooling should not compress that into one page and lose the keywords a filter needs. The one page vs. two pages question has a real answer by experience level, and for technical writers it leans two pages earlier than most roles because deliverables and tools take space to name.

Keep the layout clean for parsing: standard section headings, no text boxes, no multi-column skill grids that scramble in an ATS. If you want the mechanics, the guide to ATS-friendly resume formatting covers what breaks parsers and what doesn't. Export and submit as PDF, which preserves your formatting exactly as you built it.

The summary's one job is to name your niche in the first sentence. "Technical writer with 6 years of experience" is a wasted line. "Technical writer specializing in developer documentation for SaaS APIs" tells the reviewer in three seconds whether to keep reading, and for the right role, the answer is yes.

A working formula for technical writers: niche + years + primary deliverables + toolchain + one outcome. Three sentences, no adjectives about yourself. Compare:

• Weak: "Detail-oriented technical writer with excellent communication skills and a passion for making complex topics simple."
• Strong: "Technical writer with 6 years documenting REST APIs and SDKs for B2B SaaS products. Own end-to-end docs in a docs-as-code workflow (Markdown, Git, Docusaurus), from SME interviews to publication. Rewrote the developer onboarding guide at my last role, which cut time-to-first-API-call for new integrators."

The weak version could belong to any of a thousand applicants. The strong version could only belong to one kind of writer, and it repeats the exact terms a filter scans for. If you're targeting a different niche, swap the nouns: "documenting medical devices to FDA and IEC 62304 requirements" or "hardware installation and service manuals in MadCap Flare" do the same work. For more patterns, see how to write a professional summary.

Most technical writer bullets fail the same way: they describe the activity instead of the artifact and its effect. "Responsible for creating documentation" is an activity. A hiring manager wants the artifact (what you shipped), the scope (how big, for whom), and the effect (what changed because it exists).

Structure each bullet as deliverable + scope + method + outcome. You won't always have all four, but aim for three. Examples across common deliverables:

• API documentation: "Wrote and maintained OpenAPI-based reference docs for 60+ REST endpoints, working from engineer interviews and source code; support tickets tagged 'API confusion' dropped by roughly a third in the following two quarters."
• User guides: "Rebuilt the admin user guide (120+ topics) in MadCap Flare with task-based structure, replacing a monolithic PDF; the guide became the top self-serve resolution path in support analytics."
• Release notes: "Owned release notes for a biweekly release cycle, coordinating with 4 product teams to translate Jira tickets into customer-facing language before each ship date."
• Knowledge base: "Audited and rewrote 200+ knowledge base articles against a new style guide, retiring duplicates and adding search-optimized titles based on failed-search reports."

Only use numbers you can defend. If you don't know the ticket reduction, say what you can verify: "cited by the support team as the main driver of falling ticket volume for that module." Qualitative but concrete beats a number you made up, because interviewers ask follow-up questions and a hollow metric collapses fast.

Documentation managers hire for process as much as writing. Weave in the parts of the job that juniors don't know exist: interviewing subject-matter experts (SMEs), running docs through review cycles, testing procedures against the actual product, managing docs in version control, and maintaining a style guide. A bullet like "Established a docs review workflow in GitHub pull requests, getting engineering sign-off on technical accuracy before publication" signals seniority in one line.

Keep it to three to five bullets per role, strongest first. The bullet count guidance applies here as everywhere: recent roles get more, older roles compress.

When Roleframe's job-analysis engine reads a technical writing posting, the requirements cluster into a predictable set: documentation types, authoring tools, and process terms. Recruiters filter on these because they're the fastest proxy for fit. The pattern across software documentation roles is consistent: API documentation and Markdown-based, docs-as-code workflows dominate the software side, while structured authoring terms (DITA, MadCap Flare, XML) dominate enterprise and hardware postings.

Here are the keywords that come up again and again, grouped by how they're used in postings. Match the exact phrasing of the posting you're applying to, because a filter searching "API documentation" won't credit "documented APIs" split across a sentence.

Don't stuff all of these into your resume. A filter match gets you read by a human, and a human spots keyword salad instantly. Include the terms you can back with a story, in the exact phrasing the posting uses. For the general method, this guide to ATS resume keywords covers how matching actually works and where writers overdo it.

This is also the tedious part of applying that's worth automating the honest way: paste a specific posting into Roleframe and the fit report shows which of that job's keywords your resume already covers and which are gaps, so you're editing against the real posting instead of a generic list like the one above.

Your skills section should read like a docs team's actual stack, organized so a reviewer can find their tools in two seconds. Group by function rather than dumping an alphabetical list:

Three judgment calls worth making deliberately. Skip Microsoft Word as a headline skill. Every applicant has it, no filter screens for it in software roles, and leading with it dates you. If a government or defense posting explicitly requires Word-based deliverables, list it there and only there. List Git even at basic proficiency if you're targeting software, because docs-as-code teams treat it as table stakes; be honest about depth ("Git for docs workflows: branching, PRs, merge reviews") rather than implying you administer repos. Don't list both DITA and docs-as-code as your core stack unless you've genuinely worked in both, since they imply different careers and an interviewer will test the one you're weaker in.

For deciding what makes the cut and what gets swapped per application, these skills section examples show the keep-vs-swap logic in practice.

A technical writer resume without a portfolio link is a menu without prices. Put the link in your header, next to your email and LinkedIn, as a clean clickable URL. Not buried in the summary, not "portfolio available upon request," which reads as "I don't have one" (the same reason 'references available upon request' died).

What the link should point to, in order of preference: a personal site with three to five curated samples, a GitHub profile if your docs live in public repos, or a Google Drive folder with clearly named PDFs as a fallback. Curate hard. Five strong samples spanning your claimed deliverables (one API reference, one user guide, one conceptual piece) beat twenty screenshots.

Two problems every working writer hits. NDA'd work: never post proprietary docs. Instead, write a sanitized sample that demonstrates the same skill, or describe the project in a case-study format ("documented an internal billing API; here's a redacted excerpt of the structure") with your employer's permission, or document an open-source project's API to show the skill on public material. Public docs without attribution: if your published docs don't carry your byline, link them anyway and state your role precisely: "sole writer for sections X and Y." Interviewers verify this in conversation, and precision here builds trust.

Test the link from an incognito window before every application. A permissions-locked Drive folder has ended more technical writer candidacies than any typo.

Software and hardware documentation roles filter on different vocabularies, and one generic resume serves neither. This is the strongest argument for keeping a base resume and tailoring a version per application, which the base-and-variants approach makes routine instead of painful.

Lead with developer-facing deliverables and the docs-as-code stack: API documentation, SDK guides, release notes, Markdown, Git, static site generators, Confluence, Jira. Emphasize working inside agile sprints and reading code well enough to verify samples. If you've contributed docs to open source, that's a first-page bullet: it's verifiable, public proof of both writing and Git fluency.

Lead with structured authoring and compliance: installation and service manuals, DITA, MadCap Flare, XML, single-sourcing, illustrated parts documentation, and any standards you've written to (ISO documentation requirements, FDA submissions for medical devices, MIL-STD formats for defense). These employers also weigh hands-on verification, so bullets about testing procedures against physical products, working with CAD-derived illustrations, or coordinating with field engineers land hard. Defense-adjacent roles may mention clearance eligibility; if you hold or held one, state it in the header line.

Between the two, you're typically swapping: the summary's niche sentence, the order of your skills groups, which two bullets lead each role, and the samples your portfolio link highlights. That's a twenty-minute edit per application, not a rewrite. Keep the master untouched and edit the copy, so a hardware-flavored edit never bleeds into your next SaaS application.