Cohesyve · Practice for candidates
Preparing for a Technical Writer role? Start by finding out where you stand.
Import the actual job you're going for, run a simulation built from it, and get a scored report showing which of these areas you're weakest in — before you spend weeks studying the wrong thing.
3
free assessments
$0
no card required
Full
scored report every run
Every
question type included
3 free assessments · No card required · Pro from $16/mo
Overview
Technical writing processes are portfolio-led and evidence-driven, and almost all of them include a writing exercise. Employers are trying to establish three things: whether you can understand something technical quickly, whether you can structure information for a reader with a task, and whether you can work inside an engineering workflow rather than beside it. The process usually runs CV and portfolio screen, recruiter call, a writing test or edit exercise, interviews with writers and engineers, and a final conversation about how you gather information. This page covers what each stage looks for.
The hiring process, stage by stage
Application and portfolio screen
Your samples do most of the work here. Reviewers look for the type of documentation you have written — API reference, tutorials, conceptual guides, release notes — and whether the audience and purpose are evident from the writing itself.
How to prepare: Choose three or four samples that match the target audience, and put a short note above each explaining the reader, the goal and what you were given to start from. If your best work is behind a login, write a comparable public piece rather than describing it.
Recruiter or hiring manager screen
A conversation about the products you have documented, the tools you have used, how you work with engineers, and whether you write in a docs-as-code workflow.
How to prepare: Prepare a short account of one documentation set you owned, including how you got the information. Be specific about your toolchain and version control comfort. Ask who the readers are and whether documentation ships with the release.
Writing exercise
Usually one of: document a small API or feature from a specification, rewrite a badly written page, or produce a short tutorial. Reviewers assess structure, accuracy, and whether you identified the reader's actual task.
How to prepare: Practise the two common formats under a timer. Before writing, state the audience and scope in a line at the top — reviewers look for it. Test any procedure you write by following it literally, since untested steps are the fastest way to fail.
Interviews with writers and engineers
A writer will discuss information architecture, style and your exercise. An engineer will check whether you can understand a system quickly and ask useful questions without consuming their time.
How to prepare: Rehearse asking sharp technical questions rather than open ones. Practise summarising a system you have documented in two minutes at two different levels of depth. Be ready to defend structural choices in your exercise.
Final interview with the documentation or product lead
Covers prioritisation across competing teams, how you keep documentation current, and how you handle an engineer who will not review your draft.
How to prepare: Prepare a story about deciding what not to document, one about chasing information from an unresponsive source, and one about documentation you retired or rewrote wholesale.
What to study
Audience and information architecture
Most weak documentation fails at the structure level, and reviewers can see it in a single sample.
Technical comprehension
The engineering interview tests whether you can learn a system fast enough to document it without a translator.
Writing craft under constraint
The exercise stage rewards precision, ordering and restraint far more than expressive prose.
Docs-as-code workflow
Many teams keep documentation in version control alongside the product, and inability to work there is a practical blocker.
Working with engineers and measuring value
Senior technical writing roles are judged on getting accurate information out of busy people and showing the documentation worked.
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.
Your preparation plan
Four weeks out
Rebuild the portfolio so it argues for you before you speak.
- •Select three or four samples matched to the audience the employer serves
- •Write one new public sample if your strongest work cannot be shared
- •Add a short context note to each sample naming the reader and the goal
- •Review a documentation set you admire and note what its structure does well
Two weeks out
Practise the exercise formats and sharpen technical comprehension.
- •Document a small public API from its specification under a timer
- •Rewrite a poorly written page and note the reasoning behind each change
- •Practise following your own procedures literally to catch missing steps
- •Prepare five specific questions you would ask an engineer about an unfamiliar feature
The final week
Rehearse the whole format and prepare to defend your choices.
- •Complete one full timed writing exercise from a cold start
- •Prepare a two-minute explanation of a system you documented at two depths
- •Re-read your submitted exercise and list the structural decisions you would justify
- •Draft your questions about ownership, review cycles and how documentation ships
The day before and the day of
Remove friction and settle your opening approach.
- •Check your samples all load and are not behind an expired link
- •Test screen share and any documentation tooling the company may ask you to use
- •Plan your first step in any exercise: state the audience, scope and assumptions in writing
- •Re-read the job advert and note the documentation types it emphasises
Questions to expect
“How would you document an API endpoint you have never seen before?”
What they're really asking: Do you have a repeatable process, and do you verify rather than transcribe?
How to answer: Describe your sequence: read the specification, call the endpoint yourself with valid and invalid input, note the gaps between documented and actual behaviour, then draft reference plus one task-based example. Say which questions you would take to an engineer and why those specifically.
“An engineer will not review your draft. What do you do?”
What they're really asking: Can you get information from busy people without escalating everything or blocking?
How to answer: Explain how you make review cheap: specific questions instead of a whole document, a marked list of claims to confirm, a short deadline and a stated default. Give a real example, including what you did when it still did not happen — publishing with explicit caveats or going to the manager as a last step.
“How do you decide what not to document?”
What they're really asking: Do you prioritise by reader need, or try to cover everything and let it rot?
How to answer: Give the signals you use: support volume, search queries with no result, onboarding friction, and how often a feature changes. Explain that unmaintainable documentation is worse than none, and describe a case where you deliberately left something undocumented or retired a page.
“Walk me through a page you rewrote and why.”
What they're really asking: Can you explain editorial reasoning, or do you work on instinct alone?
How to answer: State the reader problem first — people could not complete the task, or arrived at the wrong page. Then describe the structural change, not just the sentence-level edits. Finish with how you knew it was better: fewer tickets, task completion, or direct feedback.
“How do you keep documentation accurate as the product changes?”
What they're really asking: Do you have a system, or do you rely on being told when something changes?
How to answer: Describe the mechanisms you have used: documentation in the same repository as the code, doc changes required in the pull request, release note review, scheduled audits of high-traffic pages, and automated link checking. Name which of these you introduced yourself.
“Explain a technical concept to me as if I were a new user.”
What they're really asking: Can you pitch to an audience and resist explaining the implementation instead of the purpose?
How to answer: Lead with what the reader can do with it and why they would want to, then one concrete example, then the mechanism only if it helps them make a decision. Check your assumptions aloud as you go. Avoid opening with an architectural description.
What to bring as evidence
Three or four writing samples matched to the employer's audience and product type
A short context note for each sample naming the reader, goal and starting material
A before-and-after rewrite showing the structural change, not only the wording
Evidence a documentation change worked: ticket volume, search data or direct feedback
A public repository or merged pull requests if you have worked docs-as-code
Two references, ideally including an engineer whose work you documented
Common mistakes
Submitting samples without saying who the reader was or what you were given to start with
Writing a procedure without following it literally and discovering the missing step
Describing implementation detail when the reader needed to complete a task
Producing polished prose that ignores the structural problem the exercise was testing
Claiming docs-as-code experience without being able to discuss branching and review
Treating accuracy as the engineer's responsibility rather than verifying claims yourself
Questions to ask them
- ?
Who currently writes documentation when there is no writer available, and what does it look like?
- ?
Does a documentation change ship with the code change, or afterwards?
- ?
How do you find out when documentation is wrong?
- ?
Which part of the documentation set generates the most support tickets?
- ?
Who has final say on structure and style when an engineer disagrees with you?
- ?
What would you want documented first if you could only fix one area this year?
Frequently Asked Questions
How technical do I actually need to be?
Technical enough to verify what you write without a translator: call an API, read a specification, follow a build procedure and read code well enough to check a claim. You are not expected to write production code. The interview with an engineer is largely testing whether working with you will cost them time or save it.
What if my best samples are confidential?
Write a public equivalent rather than describing what you cannot show. Documenting a small open API or rewriting a poor public page demonstrates the same skills and gives reviewers something concrete. A short redacted excerpt with permission can supplement it, but it should not be your only evidence.
Do writing tests usually come with feedback?
Often not, which makes it worth building your own check. Ask a peer to follow your procedure literally and note where they hesitate. If you are given a brief with an unclear audience, state your assumption at the top of the piece — reviewers frequently include the ambiguity deliberately.
How important is the specific toolchain?
Less important than working comfortably in version control and understanding structured authoring. Teams accept transferable experience across static site generators and markup languages readily. If you have never used pull requests for documentation, spend an evening doing so, because that gap is more likely to be a blocker than the generator itself.
Should I practise the exercise stage in advance?
Yes, because the writing exercise is where most technical writing decisions are made and it rewards a clear process under time pressure. Cohesyve lets you import the specific job, run a simulation shaped around the role, and get a scored report with a learning pathway showing where your structure or scoping was weak. Your first three scored assessments are included free, with no card needed.
Practice
What a Technical Writer assessment tests, and how it's scored →
Career guide
What a Technical Writer actually does, and where the path leads →
Prepare for another role
Cohesyve · Practice for candidates
Don't walk in guessing. Find out where you stand first.
Three free scored practice runs, a full report on every one, and a learning pathway built from what you actually got wrong. No card required.
3
free assessments
$0
no card required
Full
scored report every run
Every
question type included
3 free assessments · No card required · Pro from $16/mo
For hiring teams
Hiring for a Technical Writer role? See how your applicants perform before you spend interview time.