What a writing
portfolio should include.
A technical writer portfolio is the writing sample, so it should lead with a few pieces you can show in full, an API reference, a user guide, a tutorial, or a set of release notes, each with a line on the audience, the product, and your role. Name the tools and the workflow you run, from Markdown and a docs-as-code pipeline in Git to Confluence, MadCap Flare, or a structured authoring setup in DITA. Below is the full list of what to put in, the terms a documentation manager searches, and which of the Portfolio designs suit a writing sample.
The sections a writing portfolio needs.
A technical writer is hired on the quality of the writing and the clarity of the thinking behind it, so the portfolio is the work itself, framed well.
Writing samples, shown in full
Lead with three to five pieces a hiring manager can read end to end, not just link to. Show a range of document types and include a short frame for each: the audience, the product area, what you were solving, and what you personally wrote versus edited. The sample is the interview.
Document types you cover
Name the kinds of docs you write, API reference, developer guides, tutorials and quickstarts, conceptual overviews, release notes, how-to guides, and knowledge-base articles. Breadth signals you can own a doc set, and depth in one type signals you can go deep where it counts.
Tools and the docs pipeline
State the toolchain you run, Markdown or reStructuredText, a static site generator, a docs-as-code workflow in Git with pull requests and CI, and authoring tools like MadCap Flare, Oxygen, or a DITA setup. Add Confluence and any API-doc tooling such as Swagger or an OpenAPI-driven reference.
Information architecture
Show how you structure a doc set, not just how you write a page. A navigation map, a content model, or a before-and-after of a reorganised set demonstrates the systems thinking a senior writer is paid for. Explain the reasoning behind the structure.
Style and process
Name the style guide you write to, the Microsoft or Google developer style guide or a house guide you maintained, and describe your process, working from source, interviewing engineers, and reviewing with subject matter experts. Add any docs metric you moved, such as fewer support tickets or a higher docs satisfaction score.
Collaboration and tooling context
Describe how you work with engineering and product, where you sit in the release process, and how you keep docs current. A short note on reviewing docs in pull requests or shipping documentation alongside a release shows you can operate inside an engineering team, not beside it.
Never include: internal or unreleased documentation
No internal-only docs, no content for an unreleased feature, no material under an embargo, and nothing that carries a former employer's confidential information. Publishing internal documentation can breach a confidentiality agreement even when the writing is entirely your own.
Use samples that are already public, or write fresh ones for the portfolio. Documenting a public API or a well-known open-source tool is a strong, safe way to show your skill without exposing anything you were not free to share.
Terms a docs manager searches.
Applicant tracking systems index the words you wrote. If these are true of you, use the exact term a documentation manager filters on.
Paste your resume into the free ATS score checker with a real technical writing posting to see which of these terms the posting uses and your resume is missing.
Which designs suit a writing sample.
For a technical writer the design is part of the sample, so it should read beautifully and prove you understand typography and structure. Of the 60 Portfolio designs and 48 resume layouts, these fit.
Choose a design with excellent body typography, generous measure, and clear headings, because a documentation manager reads your page as a demonstration of your craft. The design itself should show that you know how to make text scannable.
Of the 48 layouts, pick a single-column one. Two-column resumes can serialise into a scrambled order in an employer's system, which is a poor first impression for a role about clear structure.
Order the page so the writing samples come first, with the tools, process, and about below. A hiring manager wants to read your work before they read about it, so put the proof at the top.
Use one accent colour and let the type carry the page. A technical writing reviewer notices spacing, hierarchy, and line length, so a calm, well-set page signals the exact skills you are being hired for.
Who a writing portfolio is not for.
A portfolio is close to mandatory for a technical writer, but the effort is not always the best use of your next hour. Read this first.
Worth building if you
- +Have public or freshly written samples that show a range of document types and your best craft.
- +Apply to product and developer documentation roles, where a portfolio is expected and often required.
- +Freelance or contract on documentation and want one link that shows samples, tools, and process.
- +Want to demonstrate information architecture and structure, not just individual pages.
Skip it, for now, if you
- −Have only internal or confidential samples you cannot show. Write a fresh public sample first.
- −Are applying to a role that reviews a take-home writing exercise instead. Focus there first.
- −Have a resume that does not yet clear the ATS. Fix the machine-readability before the site.
- −Have a deadline this week and no ready samples. Draft one strong piece before you build.
Questions writers ask.
Straight answers on samples, confidentiality, and what a docs manager actually reads.
What samples should a technical writer show?
Three to five pieces across different document types, an API reference, a user guide, a tutorial, and a set of release notes, each shown in full rather than linked. Frame every sample with the audience, the product area, and what you personally wrote versus edited, so a hiring manager can judge both the craft and your specific contribution.
Can I use documentation I wrote at work?
Only if it is already public. Never post internal-only docs, unreleased feature content, or anything under embargo, because publishing it can breach a confidentiality agreement even when the writing is yours. If your best work is internal, write a fresh sample for a public API or an open-source tool to show the same skill safely.
Which tools should I list?
Name the toolchain you actually run, Markdown or reStructuredText, a docs-as-code workflow in Git, a static site generator, and authoring tools like MadCap Flare or a DITA setup, plus Confluence and any OpenAPI or Swagger-driven API tooling. Employers screen for the exact stack they use, so the precise names matter more than a generic label.
Do technical writers need a portfolio to get hired?
Close to always, yes. Technical writing is one of the few fields where a portfolio is expected and often required, because the work is the evidence. Even when a role runs a take-home exercise, a portfolio of strong, well-framed samples gets you to that stage and shortens the case a hiring manager has to make for you.
Should I show information architecture, not just pages?
Yes, because structure is what a senior writer is paid for. A navigation map, a content model, or a before-and-after of a doc set you reorganised shows systems thinking that a single well-written page cannot. Explain the reasoning behind the structure so a reviewer sees how you decide, not just what you produced.
Where to go next.
Build the site, test your resume, or read how the paste-a-resume flow works.
Turn your writing
resume into a site.
Paste your resume and Portfolio drafts a clean, samples-first website in about a minute. Your best writing up top, internal docs left out, published to your own domain with TLS handled for you.