Discovering technical writers

When hiring a technical writer not everybody searches for the same skill set. Choosing the right candidate is often more complex than simply finding somebody to deliver the currently pressing tasks.

It's fine to look for the particular skill set for the specific task, but it does point to a lack of foresight. How the role might evolve in the future, if the scope will change, or whether it will shift more towards leading and hiring others.

I find it helpful to keep a mental model of specializations within the discipline of technical writing. This helps in getting the core capabilities that most or all of these sub-specializations need to possess, so you can then test for them during the hiring process.

What is a technical writer

To get started, check out my presentation on technical writing. There you can start from what technical writing is not and work your way towards a definition you find satisfactory.

Here, I want to focus on the general skills that you should be testing for. You should devise your testing framework and the interview process to unveil whether the candidate thinks as a technical writer.

Skills

In this sense, these are neither technical nor writing skills. Rather, these are thinking models that make up a successful technical writer. They apply across all the specializations below, and they are what your screening process should be designed to surface.

Specific technical capabilities certainly pertain to the job and your particular need at the time. Knowledge of content management systems, docs-as-code, documentation frameworks, and simplified technical English will all be relevant, but if you get the core skills wrong—you will end up with an unideal candidate.

Three thinking models matter most. None of them are unique to technical writing, which is precisely what makes them worth testing for.

Intellectual curiosity

A technical writer's job changes constantly. Products evolve, teams reorganize, toolchains get replaced, and the subject matter deepens without warning. Those who handle this well are not more disciplined—they are more curious. They find the new tools interesting rather than disruptive. They don't wait for scheduled knowledge-transfer meetings; they research because they want to.

Curiosity accelerates learning. A curious writer acquires context faster, recovers from the unknown without stress, and accumulates enough breadth over time to become a swiss army knife. This makes them comfortable changing domains and useful beyond the immediate task. That breadth also reinforces systems thinking.

Systems thinking

A technical writer who can only see the document in front of them will miss the gaps between documents, the assumptions baked into the onboarding flow, and the terminology drift that has been accumulating across teams for two years. Good writing fixes none of that. Seeing it does.

Systems thinking is the ability to zoom out. Not to become an expert in every adjacent discipline, but to hold enough context to understand how the parts connect—and to notice when they don't. A writer with systems thinking asks questions that expose product inconsistencies before they become documentation problems. They know which process is worth fixing and which is worth working around.

Think of it like an engineer who only knows one service in a large system. They can do their job, but they cannot see the failure that lives in the space between services. A technical writer with systems thinking operates across that space—and that is where the most valuable interventions happen.

Communication

Technical writers spend more time talking, reading, interviewing, reviewing, and aligning than they do writing. The output is text, but the work is almost entirely relational. A writer who communicates well moves faster, earns trust earlier, and produces more accurate documentation—because they get better information out of the people who have it.

This means being easy to work with: no ego about whose idea it was, no attachment to a draft that isn't serving the reader, no reluctance to say "I don't understand this yet." It also means being precise under pressure—able to take a complex technical concept, strip it to its essential structure, and hand it back in a form that a colleague, a user, or a community member can act on.

Spoken and written communication both matter. A writer who cannot hold their own in a meeting will struggle to represent documentation interests in product decisions. A writer who writes beautifully but cannot synthesize and relay what an engineer just explained will produce content that is structurally correct and factually wrong.

Specializations

Technical writing is not one role. The job title can refer to very different work depending on the company, the product, and where documentation sits in the organization. The roles below move roughly from pure writing craft toward technical depth and external reach.

Technical writer

The generalist. Covers product documentation, user guides, release notes, and whatever else needs writing. At smaller companies, this person owns the entire surface. The core expectation is clarity: take what engineers and product managers produce and turn it into something a user can act on.

Programmer writer

A technical writer with genuine programming ability. They document APIs, SDKs, and developer platforms, validate code samples by running them, and work directly from source rather than waiting for engineering handoffs. Comfort with OpenAPI or similar specification formats is common. The expectation is that you can read code, understand what it does, and write documentation that a developer will trust.

UX writer

Focuses on the words inside the product: button labels, error messages, empty states, onboarding flows, tooltips. The goal is to make the interface self-explanatory. At companies too small to have a dedicated UX writer, this work usually falls to the most senior technical writer on the team.

Documentation engineer

Takes ownership of the documentation platform rather than, or alongside, the content. Builds and maintains the documentation site, the publishing pipeline, the CI/CD workflow, the search integration. At companies without a dedicated headcount for this, a senior technical writer typically absorbs it.

Content strategist / architect

Operates at the information architecture level. Decides how documentation is structured across a product, how topics relate to each other, what content types to use, and how to maintain consistency at scale. More common at larger organizations where documentation has grown beyond what any single writer can govern by feel.

Developer advocate

The role furthest from traditional technical writing, but one that draws on the same foundations. Developer advocates produce tutorials, sample applications, blog posts, and conference talks. They gather feedback from real users and carry it back into the product and documentation. Where the programmer writer explains what exists, the developer advocate makes people want to use it.

How to test for the right skills

No two companies will test for technical writing skills the same way, nor should they. The framework needs to reflect the actual work: the tools, the audience, the product surface, and the level of ownership the role demands. What matters is that the process surfaces how the candidate thinks, not just what they can produce.

A few approaches that work across most specializations:

Give them a bad document. A procedure with a missing step, inconsistent terminology, and a structure that buries the most important information. Ask them to fix it. You are not testing whether they can write from scratch. You are testing whether they see what is wrong and why, and whether they document their decisions along the way.

Give them a real knowledge gap. Point them at a feature, a codebase, or an API without a handoff. Do they ask the right questions? Do they find the answers themselves? Do they know what they don't know?

Run a live session and stay quiet. A candidate who thinks out loud, flags contradictions, and asks clarifying questions before diving in is showing you more than one who produces clean output in silence. If something doesn't add up, the right candidate will say so directly.

Ask them to describe a process they improved. Not documented. Improved. If the answer is only about output, that tells you something. If it touches on why the process was flawed and what changed as a result, you have a different kind of candidate.

That last point is the crux of it. The best technical writers do not reach for documentation the moment something is unclear. They ask whether the thing should work differently. A confusing error message is not a documentation problem. A procedure that requires a workaround is not a documentation problem. Onboarding that consistently fails new users is not a documentation problem. A writer who thinks this way will push back on the product, ask uncomfortable questions in cross-functional meetings, and advocate for the end user at the point where it still costs less to fix things.

Documentation is most valuable when it is a definition of done, a signal that the product or process is coherent enough to explain. When it exists to compensate for a broken interface or an underdefined process, it creates maintenance debt and misleads the user. Find someone who knows the difference.

Closing

Find the right one. And witness a multitude of improvements across different disciplines—unveiling opportunities, improving processes, optimizing workflows, and documenting everything in the way the audience expects.

If you are on the other side of the table, take a look at how to prepare for the technical interview round and where a technical writing role can take you on the career ladder. And once you land it—work with people.