Technical Writer Resume
Skills & ATS Keywords

Aim for 28 to 38 specific authoring tools, doc formats, linters, static-site generators, version-control workflows, and IA frameworks grouped into 6 or 7 labeled rows. Under 22 reads thin for any Technical Writer seat above Mid; over 45 reads like a feature dump. Every line in the Skills row should resurface inside at least one API reference, guide, tutorial, release note, or docs-as-code PR bullet.

Developer documentation authoring, API references, guides and tutorials, release notes, Markdown, MDX, docs-as-code in Git, information architecture, style guides, Diataxis, Vale, code-sample verification, audience modeling, and cross-functional partnership with PM and Eng are the non-negotiables. Static-site generators (Docusaurus, MkDocs, Nextra, Mintlify), OpenAPI, GitHub PR reviews, link checkers, glossary management, and deflection metrics split Senior and Staff files.

Technical Writer (this page) is the writing-first specialist on the Docs team: owns developer-facing docs content (API references, guides, tutorials, release notes, conceptual docs), reads code, runs the snippets, files PRs in Markdown and MDX, and works inside Git. Docs Engineer owns the docs platform itself (static-site generators, search, CI pipelines, build tooling) and is code-heavy on infrastructure, not on content. Developer Advocate is community-first (stage, livestream, conference talks), with less docs scope. DevRel Engineer ships production SDKs and sample apps as the headline output. Content Designer and UX Writer own in-product copy (button labels, empty states, error messages), not developer docs. Marketing Writer covers campaigns and landing pages, no API references. If your week is an API reference revision on Monday, a tutorial walkthrough on Tuesday, a release note on Wednesday, a Vale lint pass on Thursday, and a docs PR review on Friday, you are on the right page.

Enough to read the code, run the snippet locally, spot when an example is broken, and file the PR to fix it. The bar is lower than DevRel Engineer or Docs Engineer (you do not ship product features or own the docs platform), but a Technical Writer file with zero Git activity, no Markdown or MDX fluency, and no record of running the code reads as a Marketing Writer reaching for a developer-docs label. Surface 3 or 4 concrete code-side artifacts inside your bullets (a broken-snippet PR you opened, an OpenAPI spec you reconciled with the docs, a tutorial you tested against staging, a release note you wrote from the diff).

Quote the page-view growth on revised content (rewrote the OAuth flow guide, lifted monthly page views from 4,200 to 18,400 inside one quarter), the support deflection you drove (cut inbound support tickets on the billing API by 38 percent after a fresh quickstart), the release-aligned publish cadence you carried (shipped release notes the same day as 14 of 14 minor releases), the docs-driven activation lift (raised first-API-call rate on new signups from 41 to 67 percent after a redesigned getting-started), and the broken-snippet throughput (filed 62 PRs to fix code examples across the SDK reference). A line like "Rewrote the OAuth flow guide, lifted monthly page views from 4,200 to 18,400 inside one quarter, cut inbound OAuth support tickets by 38 percent" reads at the Senior band.

Yes, more than DevRel Engineer or Docs Engineer. Technical Writer has the widest entry door on the Docs team. Common paths in are a journalism or English background plus a self-taught Markdown and Git habit, a CS new-grad who pivoted to docs after a tech internship, a support engineer who started owning the knowledge base, or an in-product UX writer who moved up the stack into developer docs. Junior seats land at Stripe, Vercel, MongoDB, HashiCorp, GitLab, Supabase, Twilio, and frontier-model vendors, and they expect Markdown fluency, Git basics, and one or two writing samples on a real product, not Staff-level scope. Run the file through an ATS Checker to confirm the parse.

No. Site ownership is the Docs Engineer plane (Docusaurus, MkDocs, Nextra, Mintlify, custom Next.js or Astro docs sites, search, CI, versioning, redirects). A Technical Writer should know enough to author inside the generator, fix a broken sidebar entry, and read the build error when a PR fails, but the docs platform itself reports to a Docs Engineer or to a DevRel Engineer wearing that hat. A Technical Writer file that leads with site-generator migrations and CI work reads as a misclassified Docs Engineer; flip it so authoring and IA carry the top 70 percent and the platform familiarity sits as a closing row.