Maya was on round four for a senior technical writer role when the hiring manager sent the “small exercise.”
Small, in hiring language, is a cursed unit of measurement. It means anything from “15 minutes” to “please restructure our knowledge base while we go to lunch.”
The prompt looked harmless:
Spend no more than 90 minutes improving this onboarding article. We’re interested in how you think.
Attached: a live help center article, three customer complaint snippets, a screenshot of activation drop-off, and a note that the team was “still deciding whether the issue is docs, product UX, or enablement.”
So, not a writing sample. Not even a technical communication interview. This was a cross-functional collaboration problem with product, support, customer success, and analytics braided into a little unpaid take-home assignment burrito.
Maya did what good candidates do when they want the job. She over-delivered. She rewrote the page, built a content model, added a glossary, flagged product friction, proposed a measurement plan, and sent an editable Google Doc because she is a helpful adult and hiring processes punish helpful adults like it’s a sport.
Two days later: “Could you make one quick revision before the panel?”
There it is. The ritual coughs up the truth.
A documentation take-home can be a fair assessment. But when it uses real company material, asks for publishable work, hides the hidden interview scorecard, and keeps expanding, it stops being evaluation. It becomes a free consulting interview task with better grammar.
Let’s build the playbook Maya needed before the doc opened.
Diagnosis: Is This an Assessment or a Tiny Unpaid Content Sprint?
A legitimate docs exercise tests judgment under a bounded, artificial scenario.
A dignity-tax exercise extracts usable candidate work product under the cover of “seeing how you think.”
The difference is not whether the company is evil. Plenty of teams stumble into exploitative hiring because nobody owns the process and everyone is allergic to defining done. Intent matters morally. Structure matters practically.
You need to diagnose the structure.
Green-ish signs
The assignment is probably reasonable if:
- It uses a fictional product, sanitized excerpt, or outdated sample.
- The time cap is believable and enforced.
- The deliverable is small: one page audit, one short rewrite, one explanation of tradeoffs.
- The work trial evaluation criteria are stated before you begin.
- They explain who will review it and what decision it informs.
- They do not ask for editable files, implementation-ready copy, or a full taxonomy.
- There is no “quick revision” loop unless it is paid or explicitly part of the evaluation.
This can actually be useful. A good technical communication interview should show how you handle audience, ambiguity, constraints, stakeholder management, and clarity.
Red flags with a little red flag wearing a hat
Start setting boundaries if the exercise includes:
- Real help center pages, support macros, API docs, sales enablement, onboarding flows, or internal docs.
- Real customer complaints, analytics, Zendesk tags, call transcripts, churn reasons, or product backlog notes.
- A request to “identify all content gaps” or “propose a content strategy.”
- A broad audit of the whole doc set.
- A “Loom walkthrough” plus a written deliverable plus a panel presentation.
- Editable deck files, Google Docs with comment access, or source files.
- Multiple rounds before anyone has discussed salary, level, decision timeline, or paid work trial options.
- Vague praise followed by “one quick revision.”
The phrase “we just want to see how you think” is not automatically sinister. But when the deliverable can be copied into their roadmap, “how you think” becomes “please leave your brain in this shared folder.”
The Prep Workflow: Build a Documentation Boundary Brief
Before you touch their messy docs, build a one-page boundary brief. Not a manifesto. Not a courtroom filing. Just enough structure to keep the task from eating your night.
1. Ask for the scorecard before the work starts
Send this before opening the assignment:
Thanks — happy to take a look. Before I begin, can you confirm the evaluation criteria for this exercise? For example, are you primarily assessing audience analysis, technical accuracy, structure, concision, prioritization, stakeholder communication, or final polish? Also, is the expected time box 90 minutes total including review, writing, and presentation prep?
This does two things.
First, it makes the hidden interview scorecard less hidden. Second, it forces the company to admit whether the “small exercise” is actually three jobs in a trench coat.
If they cannot explain what they are evaluating, that is data. Not necessarily a rejection. But definitely data.
2. Convert the task from “deliverable” to “diagnostic”
Your goal is to prove judgment, not donate production-ready work.
Bad version:
I rewrote your onboarding article and rebuilt the information architecture.
Better version:
I spent 75 minutes on a diagnostic pass. I identified the top three reader risks, rewrote one representative section, and included the assumptions I would validate with PM, support, and analytics before making broader changes.
That second version shows more seniority. It proves you know documentation is not just word sweeping. It is product understanding, user empathy, technical accuracy, and cross-functional collaboration — all without handing them a finished content sprint.
3. Cap the scope in writing
Use a simple scope box at the top of your submission:
Scope: 75-minute assessment. Reviewed one article and supporting context. Deliverables: top 5 issues, 1 sample rewrite, assumptions, follow-up questions, measurement suggestion. Excluded: full rewrite, taxonomy redesign, content roadmap, implementation copy.
This is not being difficult. This is being literate about labor.
If they wanted a full rewrite, they can buy one. Radical concept: money in exchange for work.
4. Bring your own proof blocks
Do not let the take-home become your only evidence.
Prepare two or three proof blocks from past work:
- A confusing onboarding flow you clarified.
- A support-ticket pattern you turned into self-serve content.
- A technical subject you translated for non-experts.
- A docs project where you negotiated accuracy with engineering and usability with customers.
Map each proof block to the role using a tiny role-evidence map:
| Role need | Your proof | Metric or outcome |
|---|---|---|
| Improve onboarding docs | Reworked setup guide for API users | Reduced repeated setup tickets 22% |
| Partner with engineering | Built review process with two backend teams | Cut doc review cycle from 10 days to 4 |
| Handle ambiguity | Prioritized docs fixes from support tags | Raised self-serve success on top workflow |
This matters because some companies will judge your free exercise more than your actual record. Do not let their sample task erase your experience.
If there’s an AI interview screen in the process too, tools like NoSweatKing can help decode the questions and turn those proof blocks into bot-readable answers in your own voice.
5. Decide your boundary before they test it
Write your limit before the company asks for more:
- Maximum unpaid time: 60–90 minutes.
- Maximum deliverable: audit plus small sample.
- File format: PDF or view-only doc.
- Revisions: none unpaid, or one clarification round capped at 15 minutes.
- Real company data: diagnostic only, no implementation-ready output.
- Larger request: convert to paid work trial.
This is how you avoid negotiating with your anxiety at 11:42 p.m. while naming a Google Doc “final_final_REALLYFINAL.”
What to Send Instead of the Whole Roadmap
Here is a safer structure for a documentation assignment using real company material.
The bounded submission
Time box: 75 minutes
Goal: Assess clarity and reader success for one onboarding article
Audience assumption: New admin user with moderate technical comfort
Top risks: Missing prerequisite, unclear success state, overloaded steps
Sample rewrite: One section, 180 words
Questions before implementation: 5 questions for PM/support/engineering
Measurement suggestion: Track setup completion, article deflection, and repeated ticket categories
Excluded: Full article rewrite, IA redesign, final publish-ready copy
Notice what this does. It gives them signal without surrendering the whole artifact.
You are not refusing to demonstrate skill. You are refusing to become the temp documentation department for zero dollars and a vague promise of “next steps.”
A sample rewrite that proves skill without giving away the store
Instead of rewriting the whole article, choose one representative section.
Frame it like this:
I selected the “Connect your workspace” section because it carries the highest reader risk: if users miss this step, the rest of onboarding fails. I rewrote only this section to show my approach to sequencing, prerequisite labeling, and success-state confirmation.
Then include:
- Original issue: “The article starts with configuration before defining required permissions.”
- Rewrite principle: “Put prerequisites before action steps.”
- Sample rewrite: 150–200 words.
- Tradeoff: “I kept product terminology but added a plain-language parenthetical on first use.”
This is technical communication with receipts. It shows decision-making, not just sentence grooming.
Scripts for the Awkward Parts
You do not need to sound combative. You need to sound clear.
When they send a broad real-docs assignment
Thanks for sending this over. Since this uses real company material, I’ll treat it as a diagnostic exercise rather than implementation work. I can provide a time-boxed audit, one representative rewrite, and the assumptions I’d validate before making broader changes. If you’re looking for a full rewrite or content strategy, I’d be happy to discuss a paid work trial.
When they ask for editable files
I’ll submit the exercise as a PDF or view-only document so the evaluation stays focused on approach and judgment. If the team wants editable implementation-ready work, I’d treat that as paid work product.
When they ask for “one quick revision”
Happy to clarify my thinking or answer questions in the interview. Since I’ve completed the agreed time-boxed exercise, I’d prefer not to do additional unpaid revisions. If revision quality is part of the assessment, could we structure that as a short paid trial or a live working session with a defined scope?
When they want a full presentation after the take-home
I can walk through my approach for 15–20 minutes, focusing on assumptions, tradeoffs, and how I’d collaborate with PM/support/engineering. To keep the process proportional, I won’t prepare a separate deck unless that is part of a paid stage.
When they say other candidates completed it
I understand. My goal is to give you enough signal to evaluate fit while keeping the process fair and bounded. The proposed format should show audience analysis, prioritization, technical clarity, and collaboration style without turning the exercise into production work.
That line is doing a lot. It says: I am cooperative, not compliant wallpaper.
Mistakes to Avoid When You Actually Want the Job
Mistake 1: Treating “quick” as a time estimate
“Quick” is not a scope. “Quick” is a feeling the requester has because they are not doing the work.
Translate it into hours, deliverables, and exclusions.
Mistake 2: Making the work too useful
This sounds backwards, because competent people like doing useful work. But your interview artifact should be useful as evidence, not useful as free implementation.
Give them a slice. Not the bakery.
Mistake 3: Forgetting your past work exists
A take-home is not the only proof you have. Pair the exercise with proof blocks from real projects. Hiring teams love to over-index on artificial tasks because those tasks are easy to compare. You need to make your real experience easy to compare too.
Mistake 4: Sending editable work product
If they can paste it into production, they may. Maybe not maliciously. Maybe because the team is drowning and your file is sitting right there, looking helpful.
View-only is your friend. PDF is your friend. Clear ownership language is your friend.
Mistake 5: Letting the revision loop become round five
A revision request can be legitimate if the job involves feedback cycles. But unpaid revision loops are how endless interview rounds learn to crawl.
One clarification conversation? Fine.
A second pass, new stakeholder comments, and “can you also think about onboarding emails?” Congratulations, you are now doing lifecycle content strategy for vibes.
The Short Checklist Before You Submit
Before sending a documentation take-home, make sure you can answer yes to these:
- Do I know what they are evaluating?
- Did I cap the time box in writing?
- Did I limit the deliverable to a diagnostic plus small sample?
- Did I avoid full rewrites, roadmaps, taxonomies, or implementation-ready copy?
- Did I include assumptions and questions instead of pretending I have full context?
- Did I protect editable files or source material?
- Did I bring proof blocks from past work to support the sample?
- Did I define what happens if they ask for revisions?
- Did I ask for a paid work trial if the scope is bigger than an assessment?
- Did this process increase signal — or just ask me to donate labor?
If the assignment is fair, your boundaries will make you look senior.
If the assignment is exploitative, your boundaries will make them uncomfortable.
Both outcomes are useful.
Because the goal is not to be the most generous unpaid candidate in the pile. The goal is to prove you can do the job without letting a broken candidate screening process quietly invoice your dignity.
