Docs Engineer Resume
Skills & ATS Keywords

Aim for 30 to 40 specific site generators, front-end frameworks, reference pipeline tools, CI platforms, search and AI providers, analytics tools, i18n services, accessibility scanners, and performance tooling grouped into 6 or 7 labeled rows. Under 24 reads thin for any Docs Engineer seat above Mid; over 48 reads like a feature dump. Every line in the Skills row should resurface inside at least one shipped docs platform, OpenAPI pipeline, deploy workflow, search rollout, or Core Web Vitals bullet.

Docusaurus, MkDocs Material, Nextra, Astro Starlight, Mintlify, MDX, React, TypeScript, OpenAPI, GraphQL, GitHub Actions, Vercel, Algolia DocSearch, Core Web Vitals, and docs deflection rate are the non-negotiables. AI assist (Inkeep, kapa.ai), MeiliSearch, Crowdin, axe-core, WCAG 2.2, sitemap and canonical hygiene, and build time compression split Senior and Staff files.

Docs Engineer (this page) owns the docs platform itself: the site generator, the MDX runtime, the reference pipeline that turns OpenAPI or Protobuf into pages, the GitHub Actions that build and deploy on every PR, the search index, the AI assist box, the analytics, the i18n pipeline, the axe-core run on the docs site, and the Core Web Vitals budget. Technical Writer owns the content inside that platform (API references, guides, tutorials, release notes) and files PRs in Markdown or MDX, not infrastructure. DevRel Engineer ships SDKs and sample apps for the product, not the docs site. Developer Advocate is community-first (stage, livestream, conference talks), with no platform scope. Front-End Engineer owns the product UI, not the docs platform. Site Reliability Engineer keeps the production product running, not the docs site. If your week is a Docusaurus theme refactor on Monday, an OpenAPI to Mintlify pipeline on Tuesday, a Vercel preview deploy fix on Wednesday, an Algolia reindex on Thursday, and a Core Web Vitals audit on Friday, you are on the right page.

A real amount. Most Docs Engineer postings expect React or Astro fluency, TypeScript, MDX runtime work, custom theme code on Docusaurus, Mintlify, Nextra, or Astro Starlight, and the comfort to drop into a generator's source when the theme stops bending to what you need. A Docs Engineer file with zero front-end output, no MDX components shipped, and no custom theme work reads as a Technical Writer reaching for an infra label. Surface 3 or 4 concrete platform artifacts inside your bullets (a custom Docusaurus theme component you wrote, an MDX shortcode pack you shipped, an OpenAPI to docs build step you wired, a search reindex pipeline you owned).

Quote the build time you compressed (cut Docusaurus build from 14 minutes to 3 minutes by parallelising the OpenAPI generator), the Core Web Vitals you lifted (lifted LCP from 3.8s to 1.4s on the top 50 reference pages), the search outcomes you drove (raised in-docs search click-through from 31 to 58 percent after the Algolia DocSearch rebuild), the AI assist adoption you shipped (drove 22 percent of doc sessions through the kapa.ai chat inside one quarter), and the i18n rollout scope you owned (shipped 4 locales across 380 reference pages with Crowdin). A line like "Rebuilt the docs site on Astro Starlight, cut LCP from 3.8s to 1.4s, lifted organic docs traffic 34 percent" reads at the Senior band.

Rarely. Docs Engineer is one of the few Docs team seats that tends to start at Mid or above. You need real front-end engineering chops (React or Astro, TypeScript, MDX runtime), comfort with CI on GitHub Actions, and one or two docs platforms shipped end to end. The common paths in are a Front-End Engineer who got pulled toward developer experience, a Technical Writer who picked up enough React to maintain the theme and crossed the bar, or a DevRel Engineer who took on the docs platform after shipping SDKs. Junior writing seats land at most vendors; Junior Docs Engineer seats almost never appear in the wild. Run the file through an ATS Checker to confirm the parse.

No. Content authorship is the Technical Writer plane (API references, guides, tutorials, release notes, conceptual docs). A Docs Engineer should know enough to read a Markdown PR, fix a broken sidebar entry, and reason about how a new content type lands in the IA, but the writing itself reports to a Technical Writer. A Docs Engineer file that leads with reference page authorship and release-note copy reads as a misclassified Technical Writer; flip it so platform work (site generator, reference pipeline, CI, search, performance) carries the top 70 percent and the writing partnership sits as a closing row.