Technical writer job description

Documentation gets hired for late, usually once support has answered the same question every week for a quarter. The instinct at that point is to screen on writing, which is the wrong constraint. Most of this job happens before any writing: getting an accurate account of how something works out of an engineer who has ten minutes and assumes you already know. Below is a description you can post, and the four signals teams overweight when they hire their first writer.

The job description

We are looking for a technical writer who can find out how something works and explain it to somebody who is stuck. You will own the documentation set, including the decisions about what gets removed from it.

What you will own

Documentation for your areas: concepts, tasks, reference, and the errors people actually hit
Interviewing engineers and product people, then testing what they told you against the real thing
Information architecture: what exists, where it lives, and what should no longer exist
Keeping pages aligned with releases, which means being inside the release process rather than downstream of it
A feedback loop with support, so the pages people need get written first

What the job needs

The ability to use the product yourself, including the technical parts of it
Editing discipline: halving your own draft without losing the substance
Comfort asking an expert the question that exposes what you do not know

Signals we weight heavily

You have deleted documentation
You can describe how you found out that something had shipped
You have argued that a confusing page was really a product problem

What a technical writer is actually accountable for

The output is pages. The outcome is that somebody gets unstuck without contacting a human, and that the page they read is still true after the most recent release.

Questions that stop reaching support because the answer is findable
Documentation that survives the next release, because the writer knew it was coming
Getting a precise explanation out of an engineer who is busy and assumes too much
Structure, so somebody in a hurry lands on the right page rather than the longest one
Deleting and merging, so the set stays smaller than the product

Four ways a technical writer hire looks right and is not

Every one of these passes a resume screen. Ladders eye-tracking study timed the average initial scan at just 7.4 seconds, which is long enough to check the four signals below and not long enough to check anything that would contradict them.

Looks right

Excellent writing samples

Samples are edited, sometimes heavily, and prose quality is the last constraint in this job rather than the first. The difficult part happens before the writing: getting a busy engineer to explain a mechanism precisely, and spotting which of their assumptions the reader does not share.

Looks right

Documentation experience at a large software company

In a mature documentation team the architecture, the style guide, the publishing pipeline and often the source material already exist, each with a specialist behind it. Being handed a feature, a chat thread and a release date is a different job, and it is the one you are hiring for.

Looks right

A journalism or literature background with strong published work

Journalism is written for a reader who wants to keep reading. Documentation is written for a reader who is stuck, irritated and scanning for one line. The instincts point in opposite directions. The tell is whether the candidate can cut their own paragraph in half without defending it first.

Looks right

Fluent in the documentation toolchain

The toolchain is a weekend of work. What keeps documentation from becoming a liability is whether they notice that the example response no longer matches what the product returns. Stale pages are worse than missing ones, because support answers from them with total confidence.

What to ask for evidence of instead

Four questions, and what the answer actually tells you. Take these into your own process whether or not you ever talk to us.

Tell me about documentation you deleted or merged.: What it tells you: Nearly every documentation set is too large, and the instinct is to add. Writers who have pruned can explain how they knew a page was unread, which means they had access to analytics or to support and cared enough to go looking.
How did you find out that something had shipped?: What it tells you: The most diagnostic question in the interview. Writers embedded in the release process describe a mechanism. Writers waiting to be told describe being told late, which is exactly how a documentation set ends up describing last quarter.
Here is a feature, described badly, in two minutes. What would you ask an engineer next?: What it tells you: Cheap, live, and almost impossible to fake. Strong candidates ask about failure cases and about who the reader is. Weaker ones ask what it should be called.
Which page did support send most often, and what did you change once you knew?: What it tells you: Whether documentation is treated as a product with users. It also establishes whether they had any working relationship with support, which is where the demand signal for the whole set lives.

How Continuity1 runs this funnel

The screening above is the job. These are the numbers it produces when a function owns it end to end, set against the published benchmarks for the same market.

1 in 3: Shortlisted candidates you meet who become the hire; Aligned engagements run nearer 1 in 2, distant ones nearer 1 in 10. The market takes about 180 applicants to make one hire, and that sifting lands on your team rather than ours.; Continuity1 tracked engagements
~3: Interviews your team sits in, per hire; Ashby puts technical roles at 17.6 interviews per hire across the whole process, up 52% since 2021. The rest of that load sits with the function, not with you.; Ashby talent-trends report
1 in 9: Accepted offers that ghost before joining; Indian employers report nearly 4 in 10 offers dropped. We lose 1 in 9.; nasscom community
95%: Offers that close inside your stated band; 20 of the last 21. A flat fee earns nothing from an inflated offer; a percentage of CTC earns more.; Continuity1 tracked engagements

Every brief becomes a success profile before sourcing starts, calibrated with the people who will manage the role. That calibration is the step most hiring skips, and it is why a shortlist either matches the job or matches the job advert.

You review a scored shortlist and make the calls. The filtering never lands on your calendar.

Share a role See the workings and the citations

Questions teams ask

Should the technical writer be able to code?

They need to use the product the way a technical user does, and for developer-facing documentation that means running the code in their own examples. Insisting on a professional engineering background narrows the pool sharply and buys less than the ability to ask precise questions and verify the answers.

Technical writer or developer advocate?

A writer owns the documentation set and its accuracy. An advocate owns audience and reach, and writes as one of several activities. Hiring an advocate to fix documentation is common and disappointing, because the talks and demos are more visible and the reference pages stay stale.

Contractor or in-house?

A contractor works well for a bounded set of documentation with a stable product behind it. Once the product changes weekly, the value sits with somebody who knows what shipped last month and notices when a page has quietly gone wrong, and that requires being inside the release process rather than beside it.

How do we test for this in an interview?

Give them access to something in your product and one real user question, and ask for the page. Keep it to an hour, then read it the way a stuck user would. Judge structure and accuracy before style, because style is the part an editor can fix later.