Technical Writer interview questions, with worked answers

How to use these questions

Most rounds include a writing test, such as rewriting a confusing page or documenting a small task from a demo, and a talk through your samples. Choose samples you may share and be ready to say who the reader was and what you changed after reviews. In the other questions, give a real document from your work, your part in it and what followed.

What a technical writer is expected to know

• The reader: technical documentationWrite manuals, guides and help that let a reader finish a task safely without asking anyone. built on audiences and tasks.
• The structure: topic-based writing in DITAWrite in topics with DITA and reuse them across products, versions and languages. or MarkdownWrite and structure pages in Markdown, the plain text format many docs-as-code teams use., and reuse.
• The product: enough to document it, including API documentationExplain what an interface does, how to start and what each part means, for developers who read fast. in software.
• The process: reviews, versions in GitKeep documents in Git like code: branches, reviews and a history of every change. and planning in JiraFollow the development work in Jira and plan documentation with each change..

The tools are named in ads side by side and none is a must everywhere: DITA editors, Markdown in Git, MadCap Flare, Confluence and SharePoint each have their place. A writer who learned one of them well picks up the next in weeks, and interviewers know it.

Readers, experts and reviews

How do you find out who your audience is and what they need from a document?

What they check: research before writing.

Short answer: "I ask support, sales and the product team who uses the product, what they try to do and where they get stuck, read support tickets and search terms, and if I can, watch a few users. Then I write a short list of readers and their main tasks."

The full answer: Different readers need different documents: an installer, a daily user and an administrator do not want the same page.

A weak answer: "I document every feature in order." Follow-up: "The product has beginners and experts." Say how you serve both.

A subject matter expert has no time for you. How do you get the information?

What they check: making it easy for busy experts.

Short answer: "A subject matter expert is the engineer or developer who knows the facts. I prepare by reading the requirements and trying the product, bring a short list of specific questions, and ask for fifteen minutes, not an hour. Then I send a draft they only need to correct."

The full answer: Join their meetings or demos where you can and thank them in public when the documentation helps.

A weak answer: "I wait until they answer my email." Follow-up: "The expert leaves the company next week." Say what you do now.

How do you run a review so that it improves the document and keeps the deadline?

What they check: a review process that works.

Short answer: "I tell reviewers what to check, technical facts for experts and clarity for an editor, give them a date, and collect comments in one place. I decide on conflicting comments with the owner and record why."

The full answer: A test by someone new to the product finds what experts no longer see.

A weak answer: "I send it to everyone and wait." Follow-up: "Two experts contradict each other." Say how you settle it.

Style, structure and reuse

Why does a team need a style guide, and what goes into one?

What they check: consistency as a service to readers.

Short answer: "A style guide sets how we write: voice, terms, how steps and warnings look, and words we avoid. It makes many writers sound like one, and it makes translation cheaper because the same thing is always said the same way."

The full answer: Keep it short, with examples, and add a terminology list. Many teams follow minimalism, writing only what the reader needs to act.

A weak answer: "Everyone writes in their own style." Follow-up: "Developers ignore the style guide in the texts they write." Say what you do.

What is topic-based writing, and how do you plan content reuse?

What they check: structure beyond single documents.

Short answer: "Topic-based writing means short topics that each answer one question: a task, a concept or a reference. Content reuse means writing a topic once and using it in several documents, which is single source publishing. I plan which topics are shared and keep their wording neutral so they fit everywhere."

The full answer: DITA supports this with its topic types; other tools do it with snippets or variables. Too much reuse makes pages hard to follow, so keep it where it saves real work.

A weak answer: "I copy and paste between manuals." Follow-up: "A shared topic is wrong for one product." Say how you handle it.

How do you organise a large help site so readers find answers through search and navigation?

What they check: information architecture in plain words.

Short answer: "Information architecture is how content is grouped and found. I group pages by the reader's tasks, keep the navigation shallow, write titles in the words readers search for, and check search logs for terms that find nothing."

The full answer: Test with real readers: give them a task and watch where they look.

A weak answer: "I mirror the product's menus." Follow-up: "The most visited page is the search page." Say what that tells you.

Docs-as-code, APIs and release notes

What is docs-as-code, and when would you use it?

What they check: knowing the workflow, without code on the page.

Short answer: "Docs-as-code means writing documentation in plain text, often Markdown, keeping it in Git next to the product, reviewing changes like developers review code and publishing automatically. It suits software teams where developers also edit the documents."

The full answer: It needs some setup and help from developers; for heavily translated manuals of machines, a structured tool may suit better.

A weak answer: "It means developers write the docs." Follow-up: "Reviewers outside the team do not use Git." Say how you include them.

How do you document an API for developers who will not read much?

What they check: writing for developers' tasks.

Short answer: "API documentation explains what an interface does, how to start and what each part means. I write a short getting-started guide that leads to a first working call, task guides for common jobs, and a complete reference, often generated from the API description and edited for clarity."

The full answer: Test the getting-started guide yourself on a clean setup, and keep the reference in step with each version.

A weak answer: "The reference is enough." Follow-up: "Developers keep asking support the same question." Say what you add.

How do you write release notes that customers actually read?

What they check: knowing what matters to readers.

Short answer: "I lead with what changes for the reader, new things they can do and anything they must act on, in plain words, grouped by importance. Internal ticket titles do not go in unedited."

The full answer: Link each item to the updated help page and mark changes that break something clearly.

A weak answer: "I export the ticket list." Follow-up: "A change removes a feature customers use." Say how you write it.

Safety, translation and feedback

How do you write safety warnings in a manual for a machine?

What they check: safety information that protects people.

Short answer: "Warnings come from the risk assessment, not from imagination. Each one says the hazard, what happens if it is ignored and how to avoid it, with a signal word that matches the risk, and stands where the reader needs it, right before the step."

The full answer: IEC/IEEE 82079-1, the international standard for information for use, sets out how to plan and check such information. Too many warnings hide the important ones. This is not legal advice.

A weak answer: "I put all warnings on the first page." Follow-up: "Engineering wants to add a warning to every step." Say what you advise.

How do you prepare documentation for translation into many languages?

What they check: writing that translates well.

Short answer: "Short sentences, one term for one thing, no jokes or idioms, and text kept out of images and screenshots. I give translators the terminology list and answer their questions fast, and reuse topics so the same sentence is only translated once."

The full answer: Plan the translation dates in the release plan; late changes are expensive in every language.

A weak answer: "Translators will fix the style." Follow-up: "A translation is wrong in a safety warning." Say what you do.

How do you know whether documentation works, using feedback and data?

What they check: measuring readers' success.

Short answer: "I look at support tickets on documented topics, page feedback, search terms with no results and, for software, where people stop in a getting-started guide. Then I fix the pages that cause the most trouble first."

The full answer: Agree a few measures with support and product, and report what changed.

A weak answer: "Page views went up." Follow-up: "Readers rate a page badly but nobody says why." Say how you find out.

Senior rounds

As a senior technical writer or lead technical writer, how would you use AI tools in a documentation team, and what would you never let them do?

What they check: useful and careful use, and leading others.

Short answer: "AI tools can draft first versions from specifications, suggest clearer sentences and check terms against the style guide. A person checks every fact, every step and every warning, and confidential product information goes only into tools the company has approved."

The full answer: Set team rules, measure whether the tools save time, and keep the experts' review. Associations such as tekom in Germany and the ISTC in the UK share methods and training that help a team agree its rules.

A weak answer: "AI writes the manuals now." Follow-up: "A generated step is wrong and a customer is hurt." Say what that shows about your process.

The release is in two days and the documentation is not finished. What do you do about the deadline?

What they check: priorities under pressure.

Short answer: "I list what readers must have on day one: new tasks, changed steps, warnings and release notes. Those get finished and reviewed; the rest follows in an agreed update, and I tell product and support what is still missing."

The full answer: Afterwards, agree with the product team to involve documentation earlier, with the version plan.

A weak answer: "I skip the review." Follow-up: "The product manager wants everything by the date anyway." Say what you say.

Your CV for these questions

Each job on your CV invites the questions above: which readers, which documents, which improvements. Give those stories a line each, written so a documentation lead wants to hear more:

Check your CV against a technical writer job you want with the free score; any area it finds thin is the one to rehearse first, with a real document and a sample you may share.