Technical Writer Interview Questions and Scorecard

The first technical writer I helped a company hire interviewed beautifully. She talked about clarity, about respecting the reader, about the elegance of a well-structured guide. Nobody asked her how she would find out whether a procedure actually worked. Two months later the install guide she shipped was lovely, and it skipped a prerequisite because the engineer who reviewed it already had that component installed and never noticed it was missing.

That is the failure mode of this hire. A technical writer is not a writer who happens to work near engineers. The job is getting accurate information out of busy people, verifying it by doing the thing, and deciding what a reader does not need. Prose quality is the easy part to judge and the least likely to be the problem. At FirstHR, we build for the small companies making this hire without a documentation team or an HR department, usually with a founder or a product lead running the interview alone.

This page gives you six question sets written for the employer side of the table. Every question states why it is worth asking and what a good answer sounds like, so you can evaluate the craft without being a writer. There is also a paid writing test brief and a 1-to-5 scorecard. If you still need the posting, the technical writer job description comes first, and the rest of the hiring templates cover the offer and the paperwork.

What a Technical Writer Is Actually For

A technical writer exists to make a reader able to do something correctly on the first try, which makes accuracy and structure the job and prose the delivery mechanism. Federal occupational data describes the work as preparing instruction manuals, how-to guides, journal articles, and other supporting documents that communicate complex information more easily. What that summary leaves out is where the time goes.

Most of it goes to research. A working technical writer spends more hours extracting information from engineers, running procedures to see what breaks, and reading support tickets than typing finished sentences. That is why an interview that only compares writing samples measures the smallest part of the role, and why the questions on this page push hard on how a candidate gets to the facts.

The second half of the job at a small company is deciding what not to write. Documenting everything is the default failure, because it buries the three articles customers actually search for. A candidate who has a real filter for that, usually reader tasks, support volume, or risk, is worth more than one with a longer portfolio. Probe it alongside the attention to detail the craft itself demands.

The Competencies Worth Testing

Test six areas, and expect a strong candidate to hold up across all of them rather than dominating one. Candidates rehearse craft answers most, so the areas that separate people in practice are research and impact awareness, where vague answers are common and revealing.

Weight these to your reader. Developer-facing documentation puts research, tooling, and technical depth first. Customer-facing product documentation puts audience and structure first. Regulated or safety-critical content puts verification above everything, because the cost of a wrong instruction is not a support ticket. Accessibility belongs in the tooling conversation for anyone publishing to the public, and the federal Section 508 guidance on accessible documents is a compact standard to ask a candidate about.

Which Question Set Should You Use?

Start with the core set for every candidate, then add two or three questions from the sets that match your readers and your stack. The sixth file is not a question set: it is the paid writing test brief and the scorecard, and it is the piece most interview lists leave out entirely.

6 Free Question Sets to Download

Download all six as a single Word document, or copy the sets you need. Each follows the same structure: when to use it, the questions with good-answer notes, what to listen for, and space for notes. The final file adds the writing test brief, the rubric, and a red-flag checklist.

Set 1: Core Technical Writer Questions

The starting set for every opening: naming the reader, documenting a feature with no spec, deciding what not to write, fixing a help center nobody can search, and how they know a document worked.

Set 2: Research and Subject-Matter Expert Questions

The set that separates a technical writer from a general writer: preparing for a 30 minute engineer interview, verifying a procedure by running it, and escalating a review that has stalled two weeks before release.

Set 3: Developer and API Documentation Questions

Use only if your reader writes code: reference versus tutorial, documenting an endpoint from scratch, error messages that say what to do next, quickstarts, and keeping reference accurate on a weekly release.

Set 4: Tools, Docs-as-Code, and Publishing Questions

Ask these against the stack you actually run: Markdown in a repository, structured authoring, single sourcing, versioning for customers on older releases, screenshots as a maintenance cost, and accessibility.

Set 5: Behavioral and Collaboration Questions

Past behavior on the parts of the job that hurt: a release date that moved, an expert who disagreed, the hardest feedback they ever received, a document that failed its readers, and three teams asking for one writer.

Set 6: Writing Test Brief, Scoring Rubric, and Red Flags

A ready-to-send paid writing test brief with deliberate gaps planted in it, a 1-to-5 rubric across six areas, and a red-flag checklist, so the decision rests on written evidence rather than on the conversation that felt best.

What a Strong Answer Sounds Like

You do not need to grade the writing yourself; you need to hear whether a candidate reasons from the reader or from preference. Strong technical writers tie decisions to something outside themselves: a task, a support ticket, a specification, or a measurable signal. Weak ones describe what they did without saying why it was the right call.

The most useful follow-up on this role is not why but how do you know. Ask it after any confident claim and you will find out quickly whether there is a method underneath or a habit. It works equally well on the writing test debrief, where the candidate has to defend what they chose to leave out.

The Writing Test Beats the Portfolio

A short paid writing test on your own product tells you more than any portfolio, because a portfolio shows what a document became after reviewers and a house template, not what this candidate contributed. Keep it to one page and 90 minutes, give every finalist the same brief and the same access to an expert, and pay for the time.

Three results matter. Did the candidate find the gaps you planted, which tells you whether they verify or assume. What did they ask the expert, which tells you how they will use scarce expert time for the next two years. And did they write one page, which tells you whether they can cut.

Keep the test small deliberately. An unpaid multi-hour assignment screens for candidates who can afford to work for free, and the strongest writers with current work will decline it. A tight, paid, well-briefed test gets a higher response rate and a cleaner comparison at the same time.

Scoring and Red Flags

Score each candidate on a rubric immediately after the interview, while the answers are still fresh, and anchor every score to something the candidate actually said or wrote. Rate the same six areas for everyone so you compare on evidence rather than on whichever conversation felt best.

If more than one person interviews, each should score independently before the group talks, so the most senior voice does not anchor everyone else. Written scores also make the feedback step fast and specific, and they give you something concrete to check against when you run a reference check.

The red flags worth weighting heavily are narrow. A candidate who names the tool or the format before ever naming the reader. One who cannot say how they would know a document worked. One who verifies accuracy only by asking someone. And one whose portfolio is polished but who cannot say which parts they wrote or what they argued to remove.

Fair, Legal, and Structured Interviewing

A fair interview and a useful interview are the same interview. Asking every candidate the same job-related questions, scored against the same rubric, keeps you inside the rules and reduces bias while producing a better decision. On writing roles this matters more than usual, because samples and portfolios invite subjective comparison and subjective comparison is where bias lives.

The full list of questions to avoid is worth reading before you sit down, and the two writing-specific traps are worth repeating: nothing about where someone learned English, and nothing that works as an age proxy. This is general information, not legal advice.

One standard worth borrowing rather than avoiding: the federal plain language guidelines published under the Plain Writing Act of 2010 are a compact statement of what good technical writing does. Asking a candidate where they agree and disagree with them is a fast read on whether they think about the reader or about rules.

Hiring a Technical Writer Without HR

At a large company this candidate meets a documentation manager, a peer writer, and a recruiter coordinating the scorecards. At a small business the founder or a product lead runs the interview alone, between everything else, and has usually never written a manual. Here is how to make that single conversation as rigorous as a full panel.

The simplest rule: if a wrong instruction costs you a support ticket, a returned product, or a safety incident, you need the technical writer and you should weight the research set heavily. If the goal is to attract and persuade readers, the content writer posting is the cheaper and correct hire. Teams whose real gap is product interface wording are usually looking at a UX writer instead.

Technical Writer Pay

Technical writing is its own federal occupation, so the benchmark is unusually clean for a writing role. Where a candidate falls in the range depends mostly on the reader they can serve: developer documentation, regulated content, and real subject-matter depth push toward the upper half, while general product help sits nearer the middle.

That median sits well above the editors classification, which reported $77,920 in the same survey, so a company weighing a writer against an editor is not choosing between equivalents. If your content already exists and the problem is consistency and correctness, the technical editor questions fit better than these.

Many small businesses start with a contract writer on an hourly or project basis and convert to full time once the volume justifies it. That path also gives you a real work sample before you commit, which is worth more than any interview. Write the scope down either way, in the posting and then in the offer letter.

From Interview to Onboarding

The interview is step one. Once you choose a writer, the work shifts to hiring well: a written offer, the new hire paperwork, access to a trial account and the publishing tool on day one, and a first 90 days with a stated goal at each 30 day mark. A writer with no product access cannot verify a single sentence, which is the most common way a good hire looks slow in month one.

Write down what the first 90 days should produce: using the product and reading tickets in the first 30, the highest-volume topic shipped by 60, and a documentation plan they own by 90. An onboarding template keeps that visible instead of living in your head. If the scope you actually need is broader than writing, closer to owning the whole knowledge base, the documentation specialist posting is the better description.

FirstHR connects the offer, the paperwork, the e-signatures, and the onboarding workflow in one place, and keeps the signed documents and interview scorecards on the employee profile, so a small business can run hiring through onboarding from a single system. FirstHR is an onboarding and HR platform, not a documentation tool or a content management system, so connect those separately. Applicant tracking is coming soon to FirstHR.

Frequently Asked Questions