Questions to Ask a Technical Writer

The questions

Open any question to see why it works.

1. 1

   What do you actually write, and who reads it?

   The title covers API references, task-based user guides, internal runbooks, hardware manuals, release notes, error messages and onboarding material. The audience decides the tools, the tone and the review process, so this answer frames everything else.

2. 2

   Where does the documentation live, and how does it get published?

   Documentation kept in a repository and reviewed through pull requests is a different job from documentation in a content management system or a help desk tool. This single answer tells you most of what their day looks like and who has to approve their work.

3. 3

   How did you end up doing this?

   The routes cluster: from support, from engineering, from journalism or English, from teaching, from quality assurance. Which one they came through predicts their strengths, since a former support agent and a former developer notice completely different gaps.

4. 4

   Do you need to be able to code, and how much?

   The honest answer is usually enough to install the thing, run it, read the code, and tell when an example is wrong. Ask what they had to learn on the job rather than what they knew when hired, because that gap is what a career changer would face.

5. 5

   How do you learn a product well enough to write about it?

   This is the core skill of the job. Strong answers are concrete: use it as a new user would, break it deliberately, read the tests, sit with support tickets, follow the pull requests. A vague answer here is the clearest signal you will get.

6. 6

   Who do you get information from, and how do you get them to give it to you?

   Extracting knowledge from busy engineers is most of the work, and everyone who is good at it has a technique: a draft with deliberate errors in it, a fifteen minute screen share, a comment on the pull request. Push past the word collaboration to the actual method.

7. 7

   What do you do when the explanation you are given does not make sense?

   Good writers keep asking until they understand, because documentation that reads as confusing is often describing something that genuinely is. Ask whether they have ever pushed back on a feature's design as a result.

8. 8

   Have you ever found a bug by writing the documentation?

   Very common, and the answer comes as a story. It also shows how documentation functions as a late design review, which is the argument you would need if you were making the case for hiring a writer earlier.

9. 9

   How do you decide what not to document?

   Everything cannot be written and maintained, so the interesting decisions are the omissions. Ask what gets cut, what gets archived, and who complains when it does.

10. 10

    How do you know whether a page is any good?

    Possible answers include support ticket volume on that topic, site search queries that return nothing, user testing, and asking someone to complete the task while watching. If the answer is that nobody measures it, ask what they would measure given the chance.

11. 11

    What happens to the documentation when the product changes?

    Maintenance is the unglamorous half of the job and the reason documentation sets rot. Ask about the review cycle, how stale pages get flagged, and whether anything in the release process forces a docs update.

12. 12

    What is the worst documentation debt you have inherited?

    This reveals what they do with a mess, and the options are all defensible: rewrite from scratch, archive aggressively, or triage by traffic. Listen for whether they made a plan or simply started at the top of the list.

13. 13

    Do you own the style guide, the terminology and the structure, or does someone else?

    A shared term list and a settled structure are quiet leverage across a whole product, including the interface text. Ask whether one exists, who wrote it, and whether anyone outside the docs team follows it.

14. 14

    Where do you sit: engineering, product, support, or marketing?

    The reporting line determines whose priorities win, whether documentation is treated as part of a feature or as a favour, and how safe the role is in a difficult quarter. It is the most predictive organisational fact about the job.

15. 15

    How do you get documentation into the release process rather than after it?

    This is the structural fight of the profession. Look for a specific mechanism such as a documentation item in the definition of done, a required docs reviewer, or a release checklist, rather than an aspiration to be involved earlier.

16. 16

    Which tools do you use, and which of them do you actually like?

    The tooling landscape moves quickly and the answer dates fast, so the more useful version is what they would choose if they were starting a documentation set from nothing today, and what they would avoid repeating.

17. 17

    How has generated text changed your work?

    A live and unsettled question in this field. Ask what they use it for, where it makes things worse, and whether they now think about their documentation being read by machines as well as people, which changes how pages are structured.

18. 18

    What does progression look like from here?

    The paths include senior writer, lead, documentation manager, information architecture, content design, developer relations and product management. Ask which of those exist at their company rather than in the profession generally, since many teams are too small to have any.

19. 19

    What does a good portfolio need to show?

    Usually a small number of samples with an explanation of the constraints and the audience, rather than volume. Ask what they would cut from a portfolio they were reviewing, because that is more instructive than what they would keep.

20. 20

    What do people get wrong about this job?

    The two usual answers are that it is typing up what engineers say, and that the hard part is the writing. Whichever one they correct tells you where they think the skill actually sits, which is normally in understanding the system before anyone else has to.