HeroApply
Auto Apply to hundreds of jobs in a few hours
English (US)EspañolItalianoPortuguêsFrançaisDeutsch日本語한국어
Sign up

Technical Writer interview questions, and what they're really testing

A technical writer interview is mostly a test of how you think about readers. Expect to walk through your samples line by line, explain how you got information out of busy engineers, and probably do a writing exercise. The candidates who do well talk about decisions they made, not just documents they produced.

11 questions6 minute read

Part 1

1.Walk me through one piece in your portfolio. Who was it for, and what did you decide to leave out?

Why they ask

Anyone can show a clean page. They want to hear the judgment behind it, and cutting is where judgment shows most clearly.

How to answer

  • Name the reader precisely, like a new admin setting up single sign-on, not just users
  • Explain what the source material looked like before you touched it
  • Point to something you cut or moved to another page, and why
  • Say how you checked it worked, such as testing the steps or watching support tickets

2.An engineer hasn't answered your questions and the release is close. What do you do?

Why they ask

Chasing subject matter experts is a big share of the job. They want to know you won't stall or quietly ship guesses.

How to answer

  • Test the feature yourself in a staging build to answer what you can alone
  • Send a short list of specific yes or no questions instead of an open request
  • Try another route, like the product manager, the pull request or the Jira ticket
  • Flag the risk to your manager early with what's blocked and what you'll ship without it

3.How do you decide whether something is a task, a concept or a reference topic?

Why they ask

This checks whether you understand topic-based writing, which structured authoring and most modern help sites rely on.

How to answer

  • A task answers how do I, with numbered steps and one goal
  • A concept explains what something is or why it works that way
  • Reference is for lookup, like parameters, error codes or settings tables
  • Give an example of a page you split because it mixed all three
4.How would you document a REST API you've never seen before?

Why they ask

For developer-facing roles this is the core of the job. They want to know you can learn a system by using it.

How to answer

  • Start from the OpenAPI spec if one exists, and check it against real behavior
  • Make actual calls with Postman or curl, including ones that fail
  • Write a quickstart that gets a developer to a first successful call
  • Cover authentication, errors and pagination, which is where developers get stuck
5.Tell me about a time a reviewer rewrote your draft in a way you disagreed with.

Why they ask

Reviews from engineers, legal and product are constant. They're checking whether you can defend the reader without becoming precious about your words.

How to answer

  • Separate accuracy fixes, which you accept, from style changes, which you discuss
  • Explain how you pointed to the style guide or to the reader's task
  • Show you found a version both of you could live with
  • Mention anything you changed in your process afterward

Part 2

6.What does a docs-as-code workflow look like to you?

Why they ask

Many software teams keep docs in Git next to the code. They want to know if you'll need hand-holding on branches and pull requests.

How to answer

  • Docs written in Markdown or reStructuredText in the same repo as the code
  • Changes go through branches and pull requests, reviewed like code
  • A static site generator builds and publishes the site automatically
  • Be honest about which parts you've done and which you've only read about
7.How do you know if your documentation is working?

Why they ask

Good writers look past publishing. This shows whether you think about outcomes.

How to answer

  • Watch support tickets and which questions keep repeating
  • Check help site search terms, especially searches that return nothing
  • Read page feedback and comments from users
  • Sit with a new user or teammate and watch them follow the steps
8.The product team wants a feature documented, but it's confusing to use. What do you do?

Why they ask

Writers are often the first person to use a feature the way a customer will. They want to see if you'll speak up.

How to answer

  • Document it clearly as it is, so users aren't left stuck
  • Log the usability problem in Jira or wherever product tracks it
  • Suggest a concrete fix, like clearer button text or a better default
  • Keep it collaborative, since designers don't like surprise criticism
9.Tell me about a time you had to learn something technical quickly.

Why they ask

You'll be handed unfamiliar systems constantly. They want to hear how you learn, not just that you can.

How to answer

  • Pick a real example with a clear deadline
  • Describe the specific steps: reading the code, the spec, the ticket history
  • Mention who you asked and what you asked them
  • Show what you produced and how accurate it turned out to be
10.How do you handle several projects competing for your time?

Why they ask

Writers are often shared across teams, and every team thinks its release is the priority.

How to answer

  • Explain how you track work, whether that's a Jira board or a plain list
  • Say how you rank by release date and customer impact
  • Describe telling a team early when their docs will slip
  • Give one example where you negotiated scope, like shipping a minimal page first

Part 3

11.What's your approach to the writing test?

Why they ask

Some interviewers ask this before or after the exercise to hear how you'd plan it.

How to answer

  • Read the source material and decide who the reader is first
  • Outline before writing so the structure is right
  • Test any steps you can and note assumptions you couldn't check
  • Leave time to cut and proofread

Questions to ask them

Ask at least two. It shows you're picking them too.

  • Where do the docs live, and who owns the publishing pipeline?
  • How do writers find out about new features, and how early are they involved?
  • Who reviews documentation, and how long does a typical review take?
  • What's the biggest gap in the current docs, and what would you want fixed first?
  • How many product teams would I be supporting?

Related interview guides

EditorInstructional Designer