Technical Writer Resume and Portfolio: Show Documentation Decisions You Can Defend

A technical writer resume and portfolio should let a reviewer trace one claim to the document, the decision you made, and the evidence you checked. “Created developer documentation” leaves that chain hidden. A short sample with an attributable revision, a defined audience, and a clear testing boundary gives the interviewer something concrete to examine.

This guide uses primary documentation guidance and original fictional examples. They illustrate application choices, not successful applicants or universal hiring rules. Use PracHub’s Behavioral & Leadership questions to rehearse explaining your contribution after you have assembled the evidence. A polished sentence becomes more useful when you can answer, “What changed, why, and how do you know?”

Choose samples for the writing job you want

Write the Docs’ portfolio guidance recommends targeted samples with a short account of the creation process. It also distinguishes examples suitable for editing, information architecture, API documentation, and leadership roles. That is practitioner guidance from a documentation community; it does not establish a required number of samples or a particular employer’s scoring system.

Our recommendation is to start with the reader problem in the job description. For a developer-documentation role, show how a developer reaches a working outcome and recovers from a relevant error. For information architecture, show how you separated competing reader needs and preserved findability. For an editing role, show a meaningful before-and-after passage with reasons. Pick the smallest excerpt that makes your judgment visible.

A portfolio landing page can introduce three selected pieces rather than display every document you have written. Give each a descriptive title, intended reader, your contribution, and an obvious sample link. A hiring reviewer should not need to guess which part you authored or open a large manual to find the changed paragraph. The number three is an editorial starting point here, not an industry requirement.

Write resume bullets that resolve to evidence

Build each bullet around evidence: reader task, your action, artifact scope, and observed result. A result may be a verified documentation change. Use a business percentage only when records support it. The following excerpts are fictional and should be replaced with your own work and records.

Early-career example: “Reorganized a personal project’s setup guide into prerequisites, first-run steps, and troubleshooting; checked the documented path on a clean local environment and recorded the tested version.” The corresponding sample would include the original guide, revised excerpt, environment record, and limitations. If you have only reviewed the commands on paper, replace “checked” with that narrower description.

Experienced writer example: “Owned the migration-guide revision for one SDK release; separated compatibility checks from upgrade steps and documented unresolved rollback questions for engineering review.” Evidence would include an authorized diff, release scope, and the questions you raised. Do not claim ownership of the SDK migration itself if engineering implemented it.

Lead example: “Defined review ownership and release checks for a documentation collection; introduced a named owner and version field on each maintained page.” Support that claim with a governance excerpt and examples of adopted records. Keep the decision owner and review status next to that excerpt. An interviewer can then distinguish a policy you drafted from one that colleagues actually adopted. A proposed template alone supports “designed” or “proposed,” not “rolled out across the organization.”

Notice how the verb changes with the evidence. Drafting, reviewing, testing, approving, and publishing are different contributions. If a team produced a guide, identify the sections or decisions you owned and describe the collaboration without taking credit for the whole release. Tool names belong where they explain the workflow, not where a reader consequence should appear.

Build a sample wrapper that survives scrutiny

A screenshot hides the document’s navigation, version, and revision history. Put a short evidence wrapper before the sample so the reviewer knows what it represents. Include its audience, task, source version, authorship, sharing status, and verification scope. Use meaningful filenames or page titles so the link still makes sense outside your portfolio navigation.

For a fictional “Export job results” guide, the wrapper might say: “Self-authored demonstration for an administrator who has already generated an export. Revised the procedure and navigation labels; product behavior is an invented specification. No live export service was executed.” That sets an honest boundary before the reader encounters product instructions.

For real work, distinguish a frozen authorized excerpt from a live page maintained by others. Record when you captured or last checked the sample. If later contributors changed the page, say which revision shows your contribution. Where permission allows it, a focused diff makes authorship easier to inspect than a current URL alone.

GitLab’s official technical writer role description includes planning, editing, information architecture, docs-as-code work, and collaboration with product and engineering. This supports showing those capabilities. It does not mean every technical-writing role requires GitLab’s tools, AI workflow, or organization structure.

Show a consequential edit, not a longer sentence

Consider this original fictional source paragraph: “After the export finishes, download the file and retry if there is a problem. Older exports may not work.” The ambiguity affects the reader’s next action. “Finishes,” “problem,” and “older” hide state, recovery, and compatibility decisions.

For this demonstration, the supplied product specification says that only jobs marked Ready expose a download, completed files remain available for seven days, and an expired file requires creating a new export. It says nothing about which application versions can import those files. These are invented premises, not behavior of a named vendor.

A revised excerpt could read: “In Export history, open a job marked Ready and select Download. Files remain available for seven days after the job completes. If the file has expired, create a new export. Import compatibility has not been confirmed; check the receiving application’s supported format before proceeding.”

Each revision answers a different reader question. The status condition now precedes the action. Expiry has a specified recovery path. An unknown compatibility claim stays unknown instead of becoming a reassuring promise. A portfolio annotation should explain each choice and identify who would need to resolve the remaining question.

Google’s official procedure guidance recommends ordered actions, appropriate context, and useful results or explanations. Its style highlights also cover active voice, descriptive links, accessibility, and conditions before instructions. Use such guidance to explain an edit; do not cite a style rule as proof that the underlying product claim is correct.

Make information architecture visible without rebuilding a site

A second sample can demonstrate a different kind of judgment. Suppose one fictional page mixes first-time setup, export-field definitions, routine downloads, and reasons for retention limits. Its length is not the only problem: readers with different goals must keep passing through unrelated material.

Diátaxis’ documentation framework distinguishes tutorials, how-to guides, reference, and explanation by reader need. For this example, a guided first export belongs in a learning path, downloading an existing export is a task, field definitions are reference, and retention rationale is explanation. This is an application of the framework, not a mandate to create four pages for every feature.

Show the old navigation and your proposed labels beside a specific reader journey. An administrator returning to download a finished file should reach the task directly; a first-time reader still needs setup context. Keep links between the relevant pieces. Explain where you retained material together because splitting it would interrupt the task.

A useful portfolio artifact is an annotated navigation change with one findability question: “Where would a returning administrator look for an expired export?” A proposed structure is not a measured improvement. If you later run a study, record participants, tasks, and observations separately. Do not convert your own successful navigation into evidence that users find the new structure easier.

Handle confidential work and AI contributions explicitly

Write the Docs advises obtaining explicit written permission from an authorized owner before sharing employer-owned material. Removing a company name does not itself establish permission. Check diagrams, comments, sample data, screenshots, metadata, and revision history as well as the visible prose. Keep private credentials and customer information out of the sample.

If you cannot share the work, create an independent demonstration or describe your process at an authorized level of abstraction. Label the demonstration clearly. Do not reconstruct a confidential interface so closely that the “fictional” label hides the same disclosure. An original sample lets the reviewer examine your work without exposing restricted material.

If AI contributed, describe the actual contribution and your review. For example: “Used an approved assistant to suggest heading alternatives; selected the task-oriented labels and checked all product statements against the supplied specification.” Do not imply independent technical validation merely because a second model agreed. Responsibility for the final claims still needs a person and a source.

Explain verification without overstating the check

Separate checks by what they establish. A build can show that the documentation site compiles. A link check can show that a destination responds. A command run can show observed behavior in a particular environment. A subject-matter review can resolve a semantic question. None automatically proves reader success or a business outcome.

For the fictional export revision, a paper review can establish that Ready, seven-day expiry, and the new-export recovery path match the invented premises. It cannot establish a working service, correct authorization, or an actual usability benefit. That limited check is still worth documenting because the reviewer can see exactly what remains unverified.

When you have real results, preserve the denominator and attribution. “Six of eight participants completed the revised task in this moderated study” differs from “the guide improved completion by 75%.” The second statement requires a comparison and stronger evidence. Likewise, fewer support tickets after a release may reflect product fixes, traffic changes, or a different customer mix.

Rehearse the decisions behind the portfolio

These PracHub questions come from other technical and product roles. Use them as transferable communication practice, not as a technical-writer question bank or a prediction of your interview. Answer using your actual document and a visible revision.

For hands-on API task practice, the separate technical writer interview exercise focuses on specification and request validation. Your application portfolio has another job: selecting and explaining the evidence that represents you.

Before applying, open one resume bullet and its linked sample as a reviewer would. Confirm access, identify your exact contribution, and find the evidence behind its strongest claim. Then rehearse one follow-up from the Behavioral & Leadership collection. If the answer requires an unsupported result, narrow the bullet before sending it.

Sources and Further Reading

• Write the Docs: Maintaining a portfolio
• GitLab: Technical Writer role description
• Google developer documentation style guide: Procedures
• Google developer documentation style guide: Highlights
• Diátaxis documentation framework