Free Technical Writer Practice Assessment (2026)

Cohesyve · Practice for candidates

Going for a Technical Writer role? Find out how you'd actually score.

Run a Technical Writer simulation built the same way employers build theirs, and get a full report showing exactly where you lost marks — before it counts.

free assessments a month

no card required

Full

scored report every run

Every

question type included

5 free assessments a month · No card required · Pro from $16/mo

Overview

Technical writing assessments hand you the raw material and ask for the document. That usually means messy source — an engineer's notes, a Slack thread, an API response, an outdated page — and a brief naming the audience. You may also be asked to restructure something that is accurate but unusable. This page covers what those exercises involve, how they are marked, and how to practise the parts that are hardest to fake.

Why employers assess this role

Writing samples in a portfolio are almost impossible to attribute — you cannot tell who wrote the first draft, who restructured it, or how much an editor rescued. A timed exercise from supplied source material shows how you handle ambiguity, what questions you ask, and whether you can impose structure on something incoherent.

What gets tested

Turning messy source material into a usable documentAudience analysis and pitching detail correctlyInformation architecture and restructuringPlain-language editing and concisionWriting accurate procedures and stepsAPI and reference documentation conventionsAsking the right clarifying questions of a subject expertApplying a style guide consistently

The format

Duration

45–90 minutes

Question types

Write a document from supplied raw source material
Restructure or rewrite an existing poor document
Edit for style, clarity and consistency
Short written explanation of your structural choices

Levels

Entry · Mid · Senior

What you'll be asked to do

Write from messy source

You are given an engineer's rough notes, a transcript, or a bug thread, plus a stated audience. The gaps in the source are usually deliberate, and what you do about them is part of the mark.

•Turn an engineer's bullet-point notes into a step-by-step setup guide
•Write a release note from a changelog entry and a support thread
•Produce a troubleshooting page from a set of recurring support tickets

Restructure something unusable

An existing page that is accurate but badly organised — everything in one wall of text, or steps interleaved with background. You are marked on the structure you impose, not on how much you rewrite.

•Reorganise a 2,000-word page so a reader can complete the task without reading it all
•Split a document that is serving three different audiences at once
•Convert a narrative explanation into a procedure with prerequisites and steps

Document a technical interface

An API endpoint, a configuration file, or a CLI command, usually with an incomplete specification. Assessors check parameter accuracy, error coverage and whether the example actually works.

•Document an endpoint given only a sample request and response
•Write the reference entry for a configuration option, including defaults and constraints
•Document the error cases a developer will hit first, not just the success path

Edit and apply a style guide

A supplied style guide and a document that violates it in several ways. Consistency is measured directly, and so is the judgement not to change things that were fine.

•Edit a page to the supplied style guide and list the changes you made
•Cut a page by a third without losing any necessary information
•Make voice and terminology consistent across three pages written by different people

Cohesyve for candidates

Practise a Technical Writer assessment before the real one

Run the same AI job simulations companies use to evaluate applicants. You get a scored report showing where you're strong and where you're not, plus what to work on.

Sample tasks — and what strong looks like

Turn an engineer's raw notes into a setup guide for a developer who has never used the product.

Entry

What strong looks like: Establishes prerequisites before step one, sequences the steps in the order a real person performs them, tells the reader how to confirm each stage worked, and flags the gaps in the source rather than inventing content. Weak submissions reorder the notes into prose, assume knowledge the stated audience does not have, and quietly guess at the missing steps.

Restructure a long, accurate, unusable page so a reader can complete the task without reading it end to end.

Mid

What strong looks like: Separates conceptual background from the procedure, makes headings answer the reader's question rather than name the feature, and puts the task first with the explanation available but out of the way. Weak answers add subheadings to the existing wall of text and change nothing about the order.

Document an API endpoint given only a sample request, a sample response and a short description.

Mid

What strong looks like: Covers parameters with types, whether each is required, and defaults; documents the error responses a caller will realistically hit; and includes a copyable example that would actually run. Weak submissions describe only the happy path and reproduce the sample without explaining any field.

Propose how you would structure documentation for a product that currently has none, and explain the choices.

Senior

What strong looks like: Starts from what readers are trying to do rather than from the product's internal architecture, separates tasks, concepts and reference, and names what will be written first and why. Weak answers reproduce the engineering team's module names as a navigation tree.

How to prepare

#1
Practise writing a short guide from deliberately incomplete source, and note your assumptions explicitly instead of filling gaps silently.
#2
Take a badly organised page you have used and restructure it under a timer, changing only the order and the headings.
#3
Write documentation for an unfamiliar public API from its sample responses, then check how much you had to guess.
#4
Practise cutting your own drafts by a third, because concision is measured directly and almost every first draft is too long.
#5
Prepare the three clarifying questions you would ask a subject expert about any procedure, since asking well is explicitly rewarded.
#6
Do a timed mock with a supplied style guide and apply it consistently, as consistency errors are the easiest marks to lose.

Common mistakes

Filling gaps in the source with invented detail rather than flagging the assumption.
Writing for the engineer who supplied the notes instead of the audience named in the brief.
Documenting only the success path and omitting errors and prerequisites.
Rewriting a document when the actual problem was its structure.
Producing an example that has never been run and does not work as written.
Ignoring the supplied style guide on terminology, capitalisation or voice.

How it's scored

Criterion	What strong looks like
Accuracy	Nothing is asserted that the source does not support, examples are correct, and uncertainty is marked rather than smoothed over.
Audience fit	Detail, vocabulary and assumed knowledge match the reader named in the brief, with nothing left implicit that they would not know.
Structure	Findable headings, prerequisites first, one task per procedure, and background separated from steps.
Clarity and concision	Plain language, active voice, short sentences, and no paragraph that exists only to sound thorough.
Handling ambiguity	Gaps in the source are identified, assumptions are stated, and the questions that would resolve them are listed.

Frequently Asked Questions

Do I need to be able to code?

For developer-facing roles you usually need to read code and run an example, not write production software. Many assessments include a snippet you must understand well enough to document accurately, which is a different skill from building it.

Will the source material be incomplete on purpose?

Almost always. The gaps are the exercise. Assessors want to see which questions you would ask and whether you flag an assumption rather than inventing a plausible-sounding step.

How much does the writing itself matter versus the structure?

Structure usually carries more weight. Clear prose in the wrong order still leaves the reader unable to finish the task, and restructuring is the harder skill to teach.

Should I submit something polished or something complete?

Complete and correct beats polished and partial. If time runs short, finish the structure, note what remains, and list the questions you would put to the engineer.

How do I practise for a documentation exercise?

Do a timed one and get it marked. Cohesyve runs the same kind of source-to-document task and returns a report on accuracy, structure and audience fit, with five free assessments a month.

Practise another role

Cohesyve · Practice for candidates

Practise a Technical Writer assessment now — free.

Five scored assessments a month, a full report on every run, and a learning pathway built from what you got wrong. No card required.