テックライター採用試験が情報不足となる理由

Five interviews. A screening call, a conversation with the peer technical writer, a session with the engineering manager, a round with the hiring manager, and a final pass with HR. Each one scheduled days apart, each one requiring preparation, each one asking me to demonstrate — again — that I know how to do this work I’ve been doing for most of my career.Then the email arrived. Would I be willing to complete a writing exercise?I stared at it for a while. Not because the request was unusual. It happens all the time in tech writing hiring. But because of the timing. After five conversations, what could a take-home assignment possibly reveal that hadn’t already surfaced?The typical tech writer test assignment comes in a few flavors. Rewrite an existing topic. Produce a writing sample from scratch. Draft the questions you’d ask an SME before writing a procedure. Suggest improvements to a page of documentation. Sometimes all four.Each of these is a reasonable thing to evaluate. The problem is that five rounds of interviews have already covered them. A peer technical writer who spent 45 minutes talking through my process, my toolchain, and my approach to information architecture knows more about how I work than any timed exercise will show. The engineering manager who asked how I handle conflicting feedback from reviewers got a real answer, not a rehearsed one.The test assignment doesn’t add signal. It duplicates it. And duplication has a cost that companies rarely acknowledge. It tells the candidate that the interviews didn’t really matter.For someone with a few years of experience, the sting is mild. Someone at the senior or principal level is someone who has shipped documentation across multiple industries, reorganized information architectures, built style guides, and managed stakeholder workflows. These exercises feel like being asked to prove you can drive after you’ve already parallel-parked on a busy city street or merged onto the interstate during rush hour.Even if you believe test assignments once provided useful data, that argument has a new problem. The assignments can be gamed, and they are being gamed, at scale.Fabric, a hiring platform, tracked candidate behavior on take-home assignments and found that cheating with AI tools more than doubled in six months — from 15% in June 2025 to 35% by December. (A caveat: Fabric sells cheating-detection services, so they have a commercial interest in the problem being large. Their data comes from 50,000+ candidate evaluations on their own platform, not an independent study.) While that’s specifically coding assignments, the dynamic applies to technical writing. A candidate can paste a rewriting exercise into ChatGPT, clean up the output in Grammarly, and return something polished in twenty minutes. The assignment that was supposed to take two hours now takes less time than walking the dog.A Talogy survey found that sixty-five percent of hiring managers say they’re worried about candidates using generative AI to cheat on assessments. They should be. But the worry points in the wrong direction. The problem isn’t that candidates cheat. The problem is that the format invites it. Take-home assignments happen in an unobserved environment. There is no way to verify that the person who submitted the work is the person who did the work. And the better AI gets, the harder detection becomes. AI detectors flag false positives. It’s the nervous candidates who write clean prose getting flagged while sophisticated users introducing deliberate imperfections will pass.The tech writing version of this arms race is arguably worse than the coding version. Code can be tested: does it compile, does it pass, does the candidate understand it when questioned? A writing sample that reads well is just... a writing sample that reads well. You can’t run it and see if it breaks.Companies are spending their candidates’ time and their own evaluation effort on a signal that no longer reliably means what they think it means.Here’s an alternative that actually reveals how a candidate thinks: the portfolio walkthrough.Instead of assigning new work, ask the candidate to present an existing sample of something they wrote, shipped, and can speak to. Have the interview panel ask questions about it. Not “tell me about this document.” Real, hard questions that open a discussion.How did you get the information? Who was the SME, and what was the relationship like? Where did you have to make tradeoffs between completeness and deadline, between technical accuracy and readability, between what engineering wanted and what users needed? What changed after user feedback? What would you do differently now?This approach tests everything a writing exercise claims to test, plus the things it can’t. A take-home assignment shows whether someone can produce clean prose. A portfolio walkthrough shows whether they can explain their decisions, navigate organizational friction, respond to critique, and learn from outcomes. Those are the skills that determine whether a senior tech writer succeeds on your team.It also has a practical advantage the test assignment doesn’t: it’s resistant to AI. You can’t ChatGPT your way through a live conversation about your own work. Either you did it and can talk about it, or you didn’t and you can’t. The format self-authenticates.An obvious objection: what about candidates whose work is locked behind NDAs or internal tools? That’s a fair point. But there are workarounds, such as using redacted samples with proprietary details removed, contributions to open-source documentation, or even a personal project written specifically for the portfolio. A candidate who can’t show you a single piece of work they can discuss has a different problem, and a take-home assignment won’t solve it either.The portfolio walkthrough respects the candidate’s time. They’ve already done the work. You’re not asking them to produce something disposable on spec. You’re asking them to show you something real and defend it.If you’re on the other side of this — a senior tech writer staring at a test assignment request after your fourth or fifth interview — you have more room to push back than you might think, but not unlimited room. In a market where job postings draw 250 applications and 2-3% of candidates reach the interview stage, any friction carries risk. You have to weigh that for yourself. But silence isn’t the only option.First, ask what the assignment is designed to evaluate. This is a reasonable, professional question, and the answer tells you a lot. If the hiring manager can articulate a specific gap the interviews didn’t cover, that’s worth considering. If the answer is vague — “we just want to see your writing” — that’s a signal that the process isn’t well-designed.Second, offer an alternative. Propose a portfolio walkthrough. Say something like: “I’d be happy to walk your team through a sample from my portfolio and discuss the decisions behind it. I think that would give you a better picture of how I work than a timed exercise.” Most reasonable hiring managers will take that deal. The ones who won’t are telling you something about how the organization values its people’s time.Third, if you do the assignment, set boundaries. Ask how long it should take. If they say two hours, spend two hours. Don’t spend a weekend polishing something to perfection for a company that hasn’t made you an offer. Respect your own time even when the process doesn’t.And if they can’t explain what they’re testing, won’t accept an alternative, and expect unbounded effort? That’s data too. You’re learning what working there will be like.You’re not trying to test-drive a car. You’re trying to hire a contributor who will work with your engineering team, navigate your review processes, and make your product’s documentation better. The person who can do that well is not necessarily the person who writes the cleanest two-page sample under artificial conditions on a Tuesday night.Forty-two percent of candidates drop out of hiring processes that take too long. A third withdraw specifically because their time was disrespected. After four or five interviews, a surprise test assignment is exactly the kind of friction that loses you the person you probably want to hire.Look at their portfolio. Talk to them about their work. Ask them the hard questions in a room where you can see how they think. That’s how you find out if they belong on your team. Not by handing them homework.Steve Arrants is the principal of Green Mountain Docs, specializing in documentation strategy, docs-as-code workflows, and AI-augmented documentation systems.No posts

※ 著作権に配慮し、引用は冒頭3段落までです。続きは元記事をご覧ください。