Technical writer, engineering behavioural interview questions

As asked

Tell me about a time you delivered documentation later than expected. What caused the delay, how did you communicate about it, and what did you change afterward?

Sample answer outline

Strong answers admit to a real delay with a specific cause (engineering spec changed mid-sprint, missed that a dependency existed), describe proactive communication as soon as the delay was apparent rather than at the deadline, and describe a concrete process change (earlier spec review, buffer in estimation). Candidates who claim they have never missed a deadline are not credible.

Expect these follow-ups

• How early did you communicate the slip and to whom?

As asked

Tell me about a time you had to document a technology you knew nothing about. How did you learn enough to write about it accurately?

Sample answer outline

Strong answers describe a structured approach: reading the RFC or spec first, then an existing implementation's source code, then building a toy project, then interviewing the expert who built it with very specific questions based on what they learned. Candidates should show the balance between enough self-study to ask good questions and not spending so long on self-study that they miss the deadline.

Expect these follow-ups

• How do you know when you understand something well enough to write about it confidently?

As asked

Tell me about a time you were pulled in multiple directions by different engineering teams that all believed their documentation request was the most urgent. How did you prioritize and what was the outcome?

Sample answer outline

Strong answers describe a transparent prioritization framework (revenue impact, customer-facing launch date, support ticket volume) rather than first-come-first-served, communication to each team about estimated timing, and a habit of surfacing the tradeoff to a manager when two requests truly cannot both be met. They should note what they delegate or deprioritize and why.

Expect these follow-ups

• How do you handle a team that keeps escalating and going around your prioritization?

As asked

Describe a situation where you found that existing documentation was technically incorrect. How did you verify it, report it, and fix it?

Sample answer outline

Strong answers show the writer tested the claim themselves (ran the API call, checked the source) before escalating, communicated the discrepancy to the owning engineer with specific evidence, prioritized the fix based on how many developers the error could mislead, and added a regression test or review trigger to prevent recurrence. They should mention balancing urgency (security implications vs cosmetic error).

Expect these follow-ups

• How did you handle a situation where the engineer disagreed and said the docs were right and the code had a bug?

As asked

Tell me about a time you worked with a product manager, designer, or support team member on a documentation project. What did they contribute that made the docs better?

Sample answer outline

Strong answers describe a concrete collaboration where the non-engineering stakeholder brought a different perspective (support team surfacing the most common user confusion, designer identifying inconsistent terminology in UI vs docs, PM clarifying the primary user persona). The writer should show they actively solicited input rather than treating doc as a solo activity.

Expect these follow-ups

• How did you handle conflicting input from two different stakeholders?

As asked

Describe a time a reviewer gave you substantial critical feedback on something you had written. How did you respond, and what did you change?

Sample answer outline

Strong answers show the writer separated feedback on the writing from feedback on the writer, asked clarifying questions to understand what was not working rather than defending, made changes based on the underlying problem rather than just accepting line edits, and thanked the reviewer. Candidates should give a specific example of feedback that changed their writing approach.

Expect these follow-ups

• Have you ever pushed back on critical feedback? Tell me about that.

As asked

Describe a situation where you were asked to document something but the brief was vague or the requirements kept changing. How did you move forward?

Sample answer outline

Strong answers describe making explicit the assumptions they were going to write to, documenting those assumptions and sending them to the stakeholder for quick validation before writing, and building in a review checkpoint early (a skeleton or outline before prose). They should note what happened when an assumption was wrong and how much rework that caused.

Expect these follow-ups

• How do you decide when to wait for clarity versus when to proceed on assumptions?

As asked

Tell me about a time you inherited or discovered a significant documentation backlog. How did you approach it and what did you actually accomplish?

Sample answer outline

Strong answers describe categorizing the backlog (critical errors, outdated but functional, missing entirely), getting buy-in for dedicated time rather than doing it in parallel to everything else, making the backlog visible to stakeholders as a resource risk, and picking the highest-user-impact items first rather than oldest items first. They should note what remained and why that was an acceptable tradeoff.

Expect these follow-ups

• How did you prevent the backlog from growing again once you had reduced it?

As asked

Walk me through how you coordinated documentation across multiple teams or contributors for a significant product release. What did you learn about the process?

Sample answer outline

Strong answers describe a pre-launch checklist (what must be published, what can be added post-launch), clear owners per section, a staging review where cross-functional stakeholders sign off, a publish cutoff time that allows for emergency fixes, and a post-launch retrospective on what went wrong. They should note at least one thing that nearly derailed the docs launch.

Expect these follow-ups

• How do you handle a situation where engineering ships a feature change two days before launch that invalidates two pages you already wrote?

As asked

Describe a situation where you made a case to leadership or engineering for more time, headcount, or tooling investment in documentation. What was your argument and what happened?

Sample answer outline

Strong answers tie the advocacy to business impact: support ticket reduction, developer onboarding time, or churn in developer API users. They describe framing the request in terms a non-writing audience cares about (cost per support ticket vs. cost per doc page), using data wherever possible, and showing a specific win to build credibility before asking for more. Candidates should describe both successful and unsuccessful advocacy attempts honestly.

Expect these follow-ups

• What would you do differently if the request was denied?

As asked

Have you ever seen criticism of docs you wrote posted publicly, in a forum, social media, or a GitHub issue? How did you respond and what did you take from it?

Sample answer outline

Strong answers show the writer read the criticism without defensiveness, investigated whether it was valid, responded publicly with acknowledgment and a fix timeline, made the fix visible in the response, and used it as a signal to audit related documentation. They should also describe what internal process broke down that let the issue get to the public.

Expect these follow-ups

• How do you decide when to respond publicly versus fix silently?