How to get hired as a technical writer in 2026-27

Five technical writing markets, and the tool list tells you which one a posting is

Technical writer is one job title covering at least five hiring markets that assess different evidence, use incompatible toolchains and sit in different parts of a company. The applicant who does not know this spends months sending a Docusaurus site to an aerospace publications manager and a service manual extract to a developer platform team, and gets silence from both. Decide which market you are entering for the next two years, build the evidence that market reads, and keep a second sample set for the market you want next.

Developer documentation is the market most people picture and the most competitive one. You write quickstarts, conceptual guides, API and SDK reference, CLI documentation, tutorials, migration guides, release notes and error message catalogues, usually in Markdown inside the same repository as the code, shipped through pull requests and a continuous integration pipeline. You are assessed on whether a developer can get to a working call using only your page, on whether you understand the product well enough to say which path is the recommended one, and on whether you can read a specification, a diff or a pull request without needing an engineer to translate it. The toolchain is the giveaway: if a posting names Git, OpenAPI, Docusaurus, MkDocs or Vale, this is the market.

Software end-user documentation and knowledge base work is the largest market by headcount and the least discussed. You write help centre articles, in-product help, onboarding content, admin guides, troubleshooting trees and release notes, usually in Zendesk, Salesforce Knowledge, Document360 or a help authoring tool rather than in Git. You sit near support rather than near engineering, your success is measured in tickets that did not get raised, and the single most valuable thing you can show is that you know which fifty articles carry most of the volume and why. Technical support agents are the natural recruits here, and the move is often internal.

Structured authoring for hardware, aerospace, defence and heavy industry is the market with the steadiest demand and the thinnest supply of qualified writers. You write operation and maintenance manuals, installation instructions, wiring and schematic documentation, illustrated parts catalogues, service bulletins and interactive electronic technical manuals, in DITA or S1000D, inside a content management system with a formal review and approval cycle, often in Simplified Technical English so that a non-native-speaking technician in another country reads it the same way you wrote it. The content is reused across variants and configurations rather than rewritten, which means you are really doing information architecture with words attached. These jobs pay above the generalist market, they are frequently clearance-gated, and a large share of them are filled through staffing agencies.

Regulated and quality documentation is a related corner with a different centre of gravity. Medical device instructions for use, labelling, user interface text that forms part of a usability engineering file, design history file documents, standard operating procedures, work instructions, validation protocols and reports, batch records, policy and controls documentation inside a bank. The content is an accountability artefact: it is audited, it is signed, it is version controlled in a document management system, and a wrong step is a safety and legal problem rather than a bad reading experience. People get hired here on familiarity with the quality system rather than on writing flourish, which is why writers who learn one regulated domain tend to stay employed in it for a decade.

The fifth market is the adjacent band that technical writers move into and out of, and it is worth naming so you do not mistake it for the same job. Instructional design and training content development. Technical marketing: whitepapers, solution briefs, reference architectures. Proposal and bid writing, which is compliance and deadline work with its own certification ladder. Content design and UX writing, which is interface text inside a design tool. Medical and regulatory writing for pharmaceutical submissions, which is a separate profession with its own credential culture and usually wants a life sciences background. Each one hires on different evidence from documentation work, and applying to all five with one resume is how a good writer ends up with no interviews.

• Read the tool list first. Git and OpenAPI mean developer docs; Zendesk means support content; DITA or S1000D means structured authoring; a quality management system means regulated work.
• Developer docs: assessed on whether a developer reaches a working result from your page alone.
• Help centre: assessed on whether you know which articles carry the ticket volume.
• Structured authoring: assessed on reuse, standards fluency and whether you can survive a formal review cycle.
• Regulated: assessed on the quality system, document control and traceability, not on prose style.
• Pick one for now. A second sample set exists for the market you want next, and you send it only in the right room.

What shrank, what grew, and what just got renamed

The honest picture of this market in 2026 is neither collapse nor boom, and candidates lose interviews by arriving with the wrong one. Documentation headcount at small and mid-size software companies has genuinely thinned, because the cheap half of the work (restating the interface, writing a how-to for every button, keeping a help centre superficially current) is the half a product manager with an assistant can now do badly enough to defer hiring. At the same time, demand at the top of the field went up, because documentation stopped being a cost centre at the end of the release and became the surface that both customers and machines read a product through. Fewer, more senior writers who own a system, and more writers in regulated and hardware industries where nothing about the obligation changed.

The clearest growth is in documentation that is treated as infrastructure. Companies whose product is an API now staff documentation like they staff a service: an owner, a build pipeline, automated link and style checks, a review gate in the definition of done, an analytics loop, and increasingly a retrieval layer that answers questions from the docs. The title that carries this work is often documentation engineer or docs engineer rather than technical writer, and it is a real distinction rather than inflation: the posting expects you to work in the repository, fix the build, write a script, read the specification and own the information architecture, and it usually pays on an engineering band. If you can do that, apply under that title, because fewer writers do and the postings get less traffic.

The second area of growth is the oldest part of the field. Aerospace, defence, medical devices, energy, rail and industrial equipment have not reduced their documentation obligations by a single page, and in several of those sectors the obligation grew. A technician still needs a maintenance procedure that is correct at the torque value. A device still ships with instructions for use that are part of its regulatory file. A plant still runs on standard operating procedures that an auditor will read. This work is less visible than software documentation because it is not published on the open internet, it is advertised through staffing firms as often as through careers pages, and it is where a writer who wants a decade of steady employment should be looking.

What got renamed is worth tracking because it changes how you search. A lot of end-user documentation work is now posted as knowledge management, content operations, support content or customer education. A lot of interface text work is posted as content design or UX writing. A lot of internal documentation work is posted as enablement, developer experience or platform documentation. And a growing number of postings fold documentation into a hybrid role: developer advocate, solutions engineer, support engineer, product operations. Those hybrids are real jobs and often the way in, but read the split honestly before accepting, because a job that is twenty percent documentation and eighty percent something else will not build the portfolio you need next.

One structural feature of this field surprises people arriving from software: a large share of good technical writing jobs are contracts, and that is not a signal of a weak employer. Aerospace, defence, medical device and industrial employers staff documentation against programme milestones, so they hire six, twelve and eighteen month contracts through staffing firms, and experienced writers in those sectors spend much of their career on them, often converting to permanent at one employer and then contracting again. The practical implication is that you should be registered with the staffing firms that actually serve your sector, because a meaningful number of these roles never appear on a public job board at all.

• Shrank: generalist documentation headcount at small software companies, and basic how-to libraries.
• Grew: documentation treated as infrastructure at API-first companies, and everything in regulated and hardware industries.
• Renamed: documentation engineer, knowledge management, customer education, content design, developer experience, platform documentation.
• Contract work is normal in this field, especially in aerospace, defence and medical devices. Register with the staffing firms that serve your sector.
• If you can work in a repository and fix a build, apply under documentation engineer. Fewer writers do, and the band is higher.

Who hires steadily, and how to find the postings that are not on a job board

The searcher question that matters most for a long career is which industries still hire technical writers reliably through a soft market, and the answer is consistent: the ones where documentation is required by somebody other than the marketing department. Where a regulator, a standard, a safety case, a maintenance programme, a contract clause or a certification audit requires the document, the writing job survives downturns, because the document is a deliverable rather than a nice-to-have. Where documentation exists to help customers feel supported, the job is discretionary and it moves with the budget.

Aerospace and defence is first on that list. The primes hire directly and continuously, and the larger market is the tier-one and tier-two supply chain: avionics, engines, landing gear, actuation, radar, sensors, munitions, ground support equipment, simulation and training. Work is organised around publication specifications and configuration control, and entry is usually either a staffing contract or a junior technical publications role at a supplier. The two gates are export control eligibility and clearance. If you are a US person without a clearance, say so clearly and apply anyway, because sponsorship for a secret clearance is routine at this level and the posting language often reads as if it is not.

Medical devices, diagnostics and life science instruments hire steadily and churn less. The work is instructions for use, labelling, user interface text that is part of the usability file, service manuals for field engineers, training material and the procedures that run the quality system itself. Employers screen on whether you have worked inside a controlled document process, so if you have ever had a document routed for electronic signature in a system such as Veeva, MasterControl, Windchill or an equivalent, name the system. Expect translation to be central, because a device sold across the European Union ships documentation in many languages and that drives everything about how you write.

Enterprise infrastructure and developer platforms are the healthiest part of the software side: cloud providers, databases, data platforms, security, identity, payments, observability, developer tooling and API-first companies. Documentation there is competitive surface area, and the budget holder is often engineering rather than marketing, which is why the roles survive marketing cuts. Semiconductors, test and measurement, industrial automation, robotics, energy and grid, nuclear, rail, automotive service information, telecommunications and network equipment all hire continuously and quietly, usually against programme need. Financial services and insurance hire procedure, policy, controls and model documentation writers, often inside risk or operations rather than inside a content team. Government agencies and their contractors hire against contract vehicles and are worth monitoring directly.

Finding these postings takes a different search habit from software job hunting. Set alerts on the artefact rather than the title: search for S1000D, DITA, instructions for use, service manual, standard operating procedure, technical publications, OpenAPI and knowledge base as keywords, with and without the word writer. Read the careers pages of the ten largest employers in your metropolitan area regardless of industry, because a writer job at a pump manufacturer is invisible on a tech job board. Register with the staffing firms that actually place in your sector, which in US engineering and life sciences means firms such as Actalent, Aerotek, Kelly, Yoh, Belcan, Insight Global, TEKsystems, Aquent and Robert Half, and tell the recruiter precisely which document types you can produce. Join the communities where these jobs get mentioned before they are posted: Write the Docs, the Society for Technical Communication chapters, the DITA and S1000D user groups, and the developer community of whatever product you want to document.

One more route that works and is underused: document the product before they hire you. Pick an employer you want, find the page in their public documentation that is visibly wrong, incomplete or three releases out of date, rewrite it properly, and send it to the person who owns documentation with one paragraph saying what was wrong and what you changed. This converts at a rate that no amount of applying does, it is legitimate rather than a gimmick, and in open-source-adjacent companies you can simply open the pull request.

• The reliable rule: if a regulator, standard, contract or audit requires the document, the writing job survives downturns.
• Aerospace and defence: apply even without a clearance if you are export-control eligible. Sponsorship at secret level is routine.
• Medical devices: name the controlled document system you have worked in, by name.
• Search for artefacts and standards, not titles: S1000D, DITA, instructions for use, service manual, SOP, OpenAPI, knowledge base.
• Register with sector staffing firms and tell them the document types you can produce.
• Rewrite a broken page in a target employer's public docs and send it to whoever owns docs. It converts.

How hiring actually works, who screens, and what each stage is really testing

Technical writing is screened by fewer people than a software job and by different people than most applicants expect. At a software company the first human read is usually a recruiter who checks for the toolchain keywords and the presence of samples, then the hiring manager, who may be a documentation lead but at smaller companies is a head of product, engineering, support or developer relations with no writing background. At an aerospace or industrial employer it is HR against a requisition that was written from a contract requirement, then a technical publications manager who has been doing this for twenty years and will test you on the specification. At a medical device company the decisive voice is often quality or regulatory affairs rather than a writing manager. At a staffing firm it is a recruiter who has a live requirement and will submit you within hours if your resume matches the document types.

Stage one is the samples screen and it is where most applications die. Two or three pages get read, quickly, for a small number of things: is this the kind of document the job requires, is it correct, is it organised so a reader can find one thing without reading all of it, and did this person write it. A beautiful conceptual essay loses to a plain procedure when the job is procedures. A link that is broken, gated, or made of screenshots from a product the reviewer cannot see is a rejection without a reply.

Stage two is a recruiter or hiring manager call, usually thirty minutes, and the real content is fit to the market rather than your writing. Expect to be asked what you have documented, who read it, where it lived, how it got reviewed, how you got information out of engineers, and how much of the product you used yourself. Have a two-sentence answer ready for the question that trips up experienced writers: what was the hardest thing you had to understand, and how did you work it out. A candidate who answers that with a real mechanism, in the product's own vocabulary, has effectively passed.

Stage three is the exercise and it decides the offer. The five common forms are worth practising in advance because they are predictable. First, the edit test: a page deliberately full of passive constructions, undefined terms, buried steps, missing prerequisites and inconsistent naming, with an instruction to improve it and list your changes. The list is what is being graded, not the prose. Second, the subject matter expert interview: twenty to thirty minutes with an engineer, then a write-up, which tests whether you ask about failure modes, prerequisites and the parts users get wrong rather than taking dictation. Third, write one reference page from a specification, a changelog or a pull request, which tests whether you can read source material. Fourth, restructure a sprawling page into task, reference and concept, which tests information architecture. Fifth, and increasingly common, review a machine-generated draft and mark what you would not publish, which tests judgment about correctness. Capped take-home exercises in this field are usually two to four hours; if one is open-ended and large, ask what the cap is, because a good employer has one.

Stage four is a panel, which exists in software hiring and rarely elsewhere. The engineer on the panel is checking whether talking to you will cost them time, so answer technical questions with the mechanism rather than the metaphor, and say clearly when you do not know something and what you would do to find out. The product manager is checking whether you will fight the right battles and ship on the release date. A support lead, if present, is checking whether you will fix the pages their tickets come from. In aerospace, defence and industrial work the equivalent stage is a practical review with the publications manager, often with a real manual extract in front of you, and the test is specification compliance and reuse rather than opinion about style.

Two practical notes on the process. Contract roles move in days rather than weeks, so if you want that part of the market, answer recruiters the same day and have your resume tailored per document type ready to send. And clearance processing in defence work can add months after the offer, during which you may be put on unclassified work; ask early what you will be doing while the clearance is in process, because the answer varies enormously between employers.

• The samples screen is the gate. Send the document type the job requires, not your best-written piece.
• Prepare the question nobody prepares for: the hardest thing you had to understand, and how you worked it out.
• For an edit test, the list of changes with reasons is what is graded. Write it even if they do not ask.
• For a subject matter expert interview, ask about failure modes, prerequisites and what users get wrong.
• Ask for the time cap on a take-home. A good employer has one, usually two to four hours.
• Contract roles close in days. Permanent defence roles can take months after the offer because of clearance.

Writing samples: what to send, and what to do when everything you wrote is behind a login

Almost every technical writer hits the same wall: the work that proves you can do this job belongs to an employer, sits behind a customer login or a firewall, and is covered by a confidentiality agreement. That wall is not an excuse that hiring managers accept, because other candidates solved it, so solve it deliberately rather than apologising for it in a cover letter.

Send three to five samples, not twenty, and choose for coverage rather than for polish. The set that passes in most markets is: one procedure with prerequisites, numbered steps and a verification step at the end; one reference page, ideally API, parameter, error code or parts reference, where the test is completeness and consistency; one conceptual or explanatory piece that shows you can describe a system's model rather than its buttons; one before-and-after edit with margin notes on what you changed and why; and one piece that shows you structured content for retrieval, which in 2026 is the sample almost nobody sends and the one that gets remembered. Add a single page in front of the set with one line per sample: audience, what the document had to achieve, what constraint you worked inside, and what you wrote versus what you edited. Reviewers read that page.

If your work is public, link it and be precise about authorship, because reviewers assume the worst about unattributed documentation. Say "I wrote the installation and upgrade sections of this guide and rewrote the troubleshooting tree; the API reference is generated from source" rather than linking a documentation set and hoping. If a page has a Git history with your commits in it, say so and link the history, because provenance is now a real asset.

If your work is not public, there are five legitimate routes and all of them beat a sample you cannot show. First, open-source documentation contributions: find a project you actually use, fix the documentation issue nobody wants, get it merged, and you have a public, dated, attributable artefact with a review trail. This is the single best investment for a developer documentation candidate, and projects with a documentation label on their issue tracker are abundant. Second, write a complete quickstart for a public API that has a bad one, end to end, and include the working code and the error you hit on the way. Third, sanitise: rebuild a document you wrote with a fictional product name, scrubbed numbers and no customer identifiers, and label it clearly as a sanitised rewrite, which is accepted practice when it is declared. Fourth, document something physical: write the maintenance procedure for a bicycle hub, an espresso machine or a 3D printer, with real torque values and real part numbers from the real service documentation, because that sample proves more about hardware writing than an essay does. Fifth, if you are moving from support, ask your employer for permission to use two knowledge base articles you wrote; many say yes for customer-facing content that is already public.

Do not send: anything confidential, anything you cannot discuss in detail, a resume disguised as a sample, marketing copy when the job wants procedures, a sample that is mostly screenshots of a product the reviewer cannot see, a document with somebody else's template and no indication of what you contributed, or a PDF that has been exported from a help authoring tool and lost its structure. And do not send a twenty-page document when a reviewer will read two pages: send the two best pages with a note saying where they sit in the whole.

One format decision matters more than it looks. If the job is docs-as-code, your samples should look like they came from a repository: Markdown or AsciiDoc rendered on a real site, a visible Git history, a build. If the job is structured authoring at an industrial employer, a clean PDF extract that follows a specification is exactly right and a GitHub link reads as irrelevant. Sending the wrong format is the most common self-inflicted rejection in this field, and it is the easiest to avoid.

• Three to five samples: procedure, reference, concept, before-and-after edit, and one that shows retrieval-aware structure.
• Put a one-page index in front: audience, purpose, constraint, and what you wrote versus edited, per sample.
• State authorship precisely. Unattributed documentation is assumed to be someone else's or generated.
• No public work: merged open-source documentation pull requests, a real quickstart for a public API, a declared sanitised rewrite, or a hardware maintenance procedure.
• Match the format to the market: a repository and a rendered site for docs-as-code, a specification-compliant extract for industrial work.
• Never send anything you cannot discuss line by line in the interview.

The resume, the cover letter and the application: what gets read and what gets skipped

A technical writing resume is read for evidence of four things, in this order: what you documented, who read it, where it lived and how it shipped, and what changed because of it. Everything else is skipped. The adjectives at the top (excellent communicator, detail-oriented, passionate about clarity) are the first thing a documentation lead's eye slides past, partly because every applicant has them and partly because a writer who describes themselves as an excellent communicator in a resume summary has already failed a small test.

Write the products, not the duties. "Documented a payments API: 40 endpoints, three SDKs, quickstart plus migration guide, in Markdown in the service repository, shipped through pull request review in the same release train as the code" tells a hiring manager more than a paragraph of responsibilities. For hardware, the equivalent is "authored and maintained operation and maintenance manuals for a line of industrial pumps in DITA, 1,200 topics, reused across nine configurations, translated into eleven languages". Scale, document type, toolchain and delivery mechanism are the four facts a reviewer is hunting for, and most resumes omit three of them.

Put numbers where you genuinely have them and describe the shape where you do not. Real and checkable numbers in this field: topic or page counts, number of releases shipped into, number of languages, number of products or configurations, support ticket volume on the area you rewrote before and after, search success rate inside the docs site, time for a new developer to reach a first successful API call, reduction in translation cost after a terminology or reuse project, audit findings closed. If you do not have the number, say the shape honestly: "rewrote the top twenty troubleshooting articles, which were the source of most password-reset tickets" is credible; an invented percentage is not, and a documentation lead who has run the same analytics will spot it.

Name the toolchain specifically and keep it honest, because this is where the keyword filter actually bites. List the authoring format, the publishing system, the version control, the ticketing system, the standards and the localisation tooling. Distinguish what you have used in production from what you have tried, because a writer who claims S1000D and cannot explain a data module code will be found out in ten minutes. If the posting names a tool you do not know, say in one line what you do know that is adjacent: Flare if you know RoboHelp, DITA if you know AsciiDoc and content reuse, Oxygen if you know XML editing anywhere.

Formatting rules that matter in this field more than most: one page per decade of work, plain structure, real section headings, no two-column layout that a parser scrambles, no skills matrix with star ratings, no graphics that carry information. A technical writer whose resume is hard to skim has made an argument against themselves. Link your samples near the top rather than at the bottom, and make the link work without a password, because a reviewer will not email you for access.

The cover letter is worth writing in this field, which is not true everywhere, because documentation hiring managers read for judgment and a short letter can demonstrate it. Four sentences: which market you are in and why this posting is it, one specific observation about their documentation that proves you read it, the single most relevant thing you have done, and what you would look at first. The observation is the whole letter. "Your quickstart assumes an API key is already provisioned, and the provisioning steps are two pages away in the admin guide" gets a reply at a rate nothing else does.

Two application mechanics worth knowing. Government and defence applications are often routed through systems that require the resume to restate the requisition's language explicitly, and omitting a stated requirement means an automatic screen-out even if you clearly have it, so mirror the requirement wording in your own words. And in contract markets, the same role is frequently represented by multiple staffing firms, so track who submitted you where, because duplicate submissions to the same client get both withdrawn.

• Lead with products documented, audience, toolchain and delivery, not with adjectives.
• Real numbers in this field: topics, releases, languages, configurations, ticket volume on the area you rewrote, time to first successful API call, translation cost, audit findings closed.
• Separate production experience from exposure in the tool list. Overclaiming a standard gets caught in minutes.
• Plain single-column formatting, headings, working sample links near the top.
• Cover letter: one specific, accurate observation about their documentation beats three paragraphs about passion.
• In defence and government applications, mirror the stated requirement language or be screened out for something you have.

Pay: where to look instead of guessing, and what actually moves the number

Technical writing pay varies more by industry and specialism than by years of experience, which is unusual and exploitable. Two writers with eight years each can be a long way apart because one documents a consumer app and the other documents a flight control computer under clearance, and the gap is not about writing ability. Before you negotiate anything, read the authoritative series for your country rather than a forum consensus.

In the United States, start with the Bureau of Labor Statistics Occupational Employment and Wage Statistics data for SOC 27-3042, Technical Writers. It is one of the few writing occupations with its own code, which means the data is unusually clean, and it is published by state and metropolitan area with a full wage distribution rather than only a median. Read your own metro rather than the national figure, because the spread between metros in this occupation is large. Then read O*NET's 27-3042 entry, because a surprising number of employer job descriptions are assembled from it and knowing the task list tells you what the requisition means. If you are targeting documentation engineer roles inside engineering organisations, also read the software developer codes, because those roles are often reported and paid there instead.

Outside the US: the Office for National Statistics Annual Survey of Hours and Earnings covers the UK under the relevant writing and editorial occupation codes, Canada's National Occupational Classification has a dedicated technical writer code with provincial wage ranges published on Job Bank, and Australia's ANZSCO lists technical writer as its own occupation with pay data available through government labour market sources. In all of these, government data lags the market by a year or more, so use it to establish the shape and then calibrate against live postings.

Live postings are now a real source rather than a rumour. Pay transparency laws in a growing list of US states and cities require a band in the advertisement, and many UK and EU employers publish one voluntarily, so read fifty postings for your city, level, industry and document type and look at the distribution rather than the top of it. Recruiter salary guides from staffing firms are free, directional and published by the people who profit from the number, which is worth remembering but does not make them useless for relative comparisons between specialisms.

Four things move the number materially. An active security clearance in defence work commands a visible premium, and it rises with level, which is why writers in that sector guard clearance continuity carefully. Regulated and structured authoring specialisms (DITA, S1000D, medical device labelling, validation documentation) pay above the generalist market because the supply of writers who can do them is thin. Engineering-adjacent documentation engineering roles pay on engineering bands. And industry pays more than function: the same writing skill is worth more at a semiconductor company than at a nonprofit, and moving industry is usually a faster raise than moving title.

On contract rates, do the arithmetic properly. An hourly rate through a staffing firm covers no unpaid holiday, often thinner benefits, and gaps between contracts, so compare it to a salary by estimating billable hours you will actually work in a year and adding the cost of the benefits you are replacing, not by multiplying by 2080. Ask whether the contract is W2 through the firm or incorporated, whether there is a conversion clause and at what point, and whether overtime on a programme crunch is paid. Experienced contract writers in aerospace and medical devices negotiate those terms as a matter of routine, and new entrants do not know they are negotiable.

• US: BLS OES SOC 27-3042, Technical Writers, read by metro area with the full distribution. Then O*NET 27-3042.
• UK, Canada, Australia: ONS ASHE, the NOC technical writer code with Job Bank wage ranges, and ANZSCO.
• Read fifty live postings with transparency bands for your city, level and industry. Look at the distribution.
• Premiums that are real: clearance level, structured authoring and regulated specialisms, engineering-band documentation roles.
• Changing industry usually pays better than changing title.
• On contract rates, ask about W2 versus incorporated, conversion terms and paid overtime, and never compare by multiplying the hourly rate by 2080.

The interview, the exercise, and your first ninety days

The interview for a technical writing job tests five things and only one of them is writing. Can you learn a complex thing fast and explain it at the altitude the audience needs. Can you get information out of a busy engineer, technician or clinician who does not want a meeting. Do you have judgment about structure, which means knowing when a reader needs a task, a reference, a concept or a tutorial, and not blending all four into one page. Will you actually verify what you wrote by doing it. And can you take and give editorial feedback without it becoming personal, because documentation review is relentless and a writer who flinches costs the team more than a slower writer who does not.

Prepare specific answers to the questions that come up in almost every loop. Walk me through how you documented something you did not understand at the start. How do you get time from an engineer who ignores you. Tell me about a document you were wrong about and what happened. How do you decide what not to document. What do you do when the product is bad and the documentation is being asked to cover for it. How do you keep documentation current through a fast release cycle. What would you look at in your first month here. Each of those wants a mechanism and an example, not a principle.

There is one answer that distinguishes senior candidates immediately, and it is about verification. Say that you run the procedure. Describe a time the documented steps did not work, what you found, and what you did about it, including filing the bug rather than writing around it. Writers who document from a specification without touching the product produce documentation that is plausible and wrong, which is the exact failure mode that machine generation also produces, and every experienced documentation manager is now screening for it harder than they used to.

Ask questions that reveal whether the job is doable, because a documentation role in a company that does not value documentation will exhaust you in a year. Who owns documentation, and who signs off. Is documentation in the definition of done, or does it arrive after release. Where does the content live and who can edit it. How do writers get access to the product, and will I have a licence, a test environment or a device. What happened to the last person in this role. How is documentation measured here, and what happens if the number moves. How much of the backlog is new content versus fixing existing content. The answers to those seven questions predict your experience better than the salary does.

For the first ninety days, resist the instinct to rewrite everything. The pattern that earns trust fastest is narrow and measurable. In the first two weeks, use the product as a new user would and keep a log of every place you got stuck, which is the most valuable document you will ever write at that company and has a shelf life of about a month. In weeks two to four, find the evidence: the ten pages with the most traffic, the ten questions that generate the most support tickets, the search queries inside the docs that return nothing, and if there is an assistant answering from your documentation, the questions it answers wrongly. In weeks four to eight, fix the top ten, properly, and show the before and after. In weeks eight to twelve, fix one piece of the system rather than the content: a style check in the build, a template, a terminology list, a review step that engineers will actually use, or a release note process that does not depend on you chasing people.

Two habits to establish immediately because they are hard to add later. Keep a decision log of terminology and structure choices, with the reason, because you will be asked to re-litigate every one of them and the log ends the argument in thirty seconds. And build one relationship with an engineer or technician who will answer a question in a direct message, because in every documentation job the single biggest determinant of your output is how quickly you can get an answer from someone who knows.

• Five things tested: learning speed, extracting information from experts, structural judgment, verification, and handling review.
• Say that you run the procedure, and tell the story of the time the documented steps did not work.
• Ask the seven questions: ownership, definition of done, where content lives, product access, what happened to the last person, how documentation is measured, and the new-versus-fix split in the backlog.
• First two weeks: use the product as a new user and log every place you got stuck.
• Weeks four to twelve: fix the top ten pages by evidence, then fix one thing about the system rather than more content.
• Start a terminology and structure decision log on day one.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

• Technical writer
• Technical writing
• Senior technical writer
• Documentation specialist
• Documentation engineer
• Developer documentation
• API documentation
• OpenAPI
• Swagger
• REST API reference
• SDK documentation
• Docs as code
• Git
• GitHub
• GitLab
• Markdown
• MDX
• AsciiDoc
• reStructuredText
• Docusaurus
• MkDocs
• Sphinx
• Antora
• Mintlify
• ReadMe
• Redocly
• GitBook
• Vale
• markdownlint
• Static site generator
• DITA
• DITA XML
• S1000D
• Structured authoring
• Content reuse
• Information architecture
• Topic-based authoring
• MadCap Flare
• Adobe FrameMaker
• Oxygen XML Editor
• Arbortext
• RWS Tridion Docs
• Heretto
• Paligo
• Ixiasoft
• DITA Open Toolkit
• Simplified Technical English
• ASD-STE100
• Technical publications
• Illustrated parts catalogue
• Interactive electronic technical manual
• Service manual
• Operation and maintenance manual
• Installation guide
• Instructions for use
• IFU
• Labelling
• ISO 13485
• ISO 14971
• IEC 62366
• IEC 82079
• EU MDR
• Design history file
• Standard operating procedure
• SOP writing
• Work instruction
• Validation documentation
• Document control
• Quality management system
• Veeva
• MasterControl
• Windchill
• Change control
• Redlining
• Zendesk Guide
• Salesforce Knowledge
• Document360
• Confluence
• Knowledge base
• Knowledge management
• Help centre content
• Release notes
• Troubleshooting guide
• Admin guide
• User guide
• Quickstart
• Style guide
• Google developer documentation style guide
• Microsoft Writing Style Guide
• Chicago Manual of Style
• Diataxis
• Task-based writing
• Plain language
• WCAG
• Section 508
• Accessibility
• Subject matter expert interview
• SME interviews
• Technical editing
• Peer review
• Editorial review
• Content strategy
• Content operations
• Taxonomy
• Metadata
• Terminology management
• Glossary
• Controlled vocabulary
• Localization
• Localisation
• Trados
• memoQ
• Phrase
• Smartling
• Crowdin
• Machine translation post-editing
• Snagit
• Camtasia
• Figma
• Visio
• Lucidchart
• Mermaid
• PlantUML
• Technical illustration
• SolidWorks Composer
• Jira
• Azure DevOps
• Agile
• Scrum
• Sprint
• Release train
• Continuous integration
• Retrieval augmented generation
• RAG
• llms.txt
• Model Context Protocol
• MCP
• Docs for AI assistants
• AI-assisted documentation
• Prompt engineering
• Evaluation set
• Documentation analytics
• Support ticket deflection
• Security clearance
• ITAR
• Export control
• Aerospace documentation
• Defence documentation
• Medical device documentation

Mistakes that cost people this job

Questions people ask