Roles where writing is the work: screen with the work itself

Support, docs, content, product and customer success run on written words. Why portfolios stopped separating people, and what to ask instead.

For some roles a written screen is not a proxy for the job. It is the job, performed once, in front of you.

Support agents write to customers all day. Technical writers write. Content and marketing people write. Product managers write specs, decisions and the uncomfortable message that says no. Customer success writes the renewal email that has to be honest and warm at the same time. In a distributed team, most of what everyone does arrives as text in somebody else's window.

And yet these roles are usually screened the way every other role is screened: a CV, a portfolio link, a call where the candidate describes their writing out loud.

The portfolio stopped separating people

Asking for samples was always the reasonable move here, and it worked for a long time. It works much less well now, for three reasons that have nothing to do with candidate honesty.

Samples are edited by other people. A published article went through an editor. A help centre page went through a review. A launch email had four opinions on it. You are looking at the output of a process, not at the person.

Samples are not about your context. Someone who writes beautifully about consumer fintech has not shown you how they explain a rate limit to an irritated developer, which may be exactly what the job is.

And now, samples can be produced on demand. ZipRecruiter's 2026 AI Employer Report found that just under half of surveyed employers say AI has increased application volume per role, while only about a quarter believe they can almost always tell when AI was used in an application. For writing roles that lands harder than anywhere else, because the artifact you were using to evaluate is made of exactly the material these tools produce most convincingly.

The result is a screening step that feels rigorous and separates people mostly by how much editorial support they have had.

What you actually need to know

Strip the role down and the questions are usually these.

Can they explain something complicated to a specific audience, and do they change their approach when the audience changes? Can they say no, or deliver bad news, without either grovelling or picking a fight? Can they structure an argument, so that the reader knows by the second sentence what this is about? Do they know what to leave out? And when the brief is vague, do they ask, or do they produce two thousand confident words about the wrong thing?

None of those are visible in a polished sample. All of them are visible in an answer to a question you chose.

The move: give them the work, once, small

One scenario from the actual job. Their words, their time, no editor, everyone gets the same one.

This is the case where written pre-screening is least of a compromise, because the format and the job are the same activity. You are not inferring competence from a proxy. You are watching the thing happen at small scale.

The reading budget, with the numbers made up

Say a support role draws 90 applications. Reading 90 CVs and clicking 90 portfolio links properly is a day of work, and it ends with a shortlist sorted by presentation.

Now say the same 90 people each answer two short scenario questions. Reading one answer properly takes two or three minutes, because you are reading for judgement rather than scanning for keywords. That is around four hours if you read all of them, and much less if you read in a scored order and stop when the quality drops off.

The number that matters is not the four hours. It is that at the end of it you have read 90 people writing to a customer, which is the thing you were hiring for, and you did not read a single cover letter.

See what a written screen looks like

A new account opens with a filled-in example questionnaire and five candidates, so you can read a real report before writing a single question of your own.

Start free

Questions that do the work

The pattern is the same across these roles: a real situation, a real constraint, and something that can be got wrong.

Support. "A customer writes that the export is broken and they are losing money. It is not broken, they are looking at the wrong report, and this is the third time this week someone has made that mistake. Write your reply." This one question surfaces tone, accuracy, whether they fix the customer or the sentence, and whether they notice the pattern worth reporting internally.

Technical writing. "Explain what a webhook is, twice. Once for a developer integrating one this afternoon, once for a support agent who needs to know what to tell customers." The second version is where people separate.

Content and marketing. "Here is a claim from our marketing page that we can no longer support with data. Rewrite the section so it is still persuasive and no longer says it." Nothing reveals a writer's relationship with truth faster than taking away the number.

Product. "A stakeholder asks for a feature by Friday. You believe it is the wrong thing to build. Write the message you would send them." You will see, in one paragraph, whether this person can disagree in writing and stay in the relationship.

Customer success. "An account is coming up for renewal, adoption is low, and the champion who bought it has left. Write the first email." Optimism, honesty and next steps, or two of the three.

Two or three of these, not ten. Say roughly how long it should take. The point is not endurance.

The three things a scenario answer shows that a sample cannot

It is worth being precise about why a small piece of work beats a large portfolio, because the portfolio looks like more evidence and is not.

Constraint handling. A published article had no constraint you can see. A scenario has one you wrote: the customer is wrong, the deadline is bad, the claim is unsupportable. Watching someone work inside a constraint is most of what you need, and it is the part that never survives into a finished sample.

What they leave out. Skilled writing in a working context is mostly deletion, and you cannot see deletion in a portfolio. You can see it immediately when two people answer the same question and one of them is four paragraphs shorter without being less complete.

The first sentence. In real work, the first sentence carries the load: it tells the reader what this is and whether they need to act. Marketing copy and essays are allowed to warm up. A support reply, an internal decision memo and a handover note are not. A scenario question tests the version of writing the job actually uses.

There is a fourth thing, harder to name. Everyone answers the same prompt, so you are finally comparing people rather than comparing the situations they happened to be in. Two portfolios never have that property.

The distributed team version of this

If the team is spread across time zones, written communication is not one of the skills, it is the medium everything else travels through. Buffer's 2023 State of Remote Work, based on responses from around three thousand remote workers, found that most respondents had immediate teammates in more than one time zone. A decision that is not written down in that setting does not exist.

That changes what you are screening for. Not elegance. Whether the message would still be unambiguous when it is read eleven hours later by someone who cannot ask a follow-up question until tomorrow. That is a specific skill, it is rarer than it sounds, and it is invisible in a portfolio of published work, which was written to be read immediately by a friendly audience.

If the role is remote, it is worth asking one question in that exact shape: "Write the handover message for something you are leaving half finished." What comes back tells you how the person's colleagues will experience them on a Tuesday.

A practical note on volume in these roles. Writing jobs attract more applicants than most, partly because the barrier to applying looks low and partly because these are the roles people are most often trying to move into from adjacent work. That combination is exactly where a written screen changes who gets seen: career changers with no portfolio and no recognisable company names are invisible under the old filter and perfectly visible under this one. If you have ever hired a great support person who came from teaching or hospitality, you already know that the CV was not what told you.

The AI question is different for these roles

Everywhere else, the worry is that a candidate used a model to answer. For writing roles that framing is wrong from the start, because most of these jobs now include using the tool. A support team drafts with it. A content team outlines with it. Pretending otherwise in the screen produces a hire who cannot work the way the team works.

So the question is not whether they used it. It is whether they can tell when the output is wrong, and whether they take responsibility for what goes out under their name.

Stack Overflow's 2025 Developer Survey captured this pattern precisely in a neighbouring profession: 84% of respondents use or plan to use AI tools while 46% actively distrust the accuracy of the output. Use the thing, verify the thing. That is professional practice, not a compromise, and it is what you want to hire for.

Three practical consequences for the screen.

Ask about judgement, not authorship. "Where would you use a model in this task, and where would you not, and what would you check before sending?" An honest, specific answer to that is more informative than any detection.

Design at least one question a model cannot carry. Anything that requires a specific fact about their own experience, or a decision inside your context, degrades gracefully into vagueness when it is generated.

And keep the signal advisory. Eneya reports whether the answers name anything you could verify, as a High or Medium reading shown next to the score with the fragments that gave it. For these roles especially, Medium is not a verdict. It is a prompt to ask one more question on the call, usually the same one: which piece was this, and walk me through what you changed and why.

One more distinction worth making explicit, because it changes what you ask. There is writing that persuades a stranger, and there is writing that keeps a team coordinated. Marketing hires are usually screened for the first and then spend most of their week doing the second. If the role involves briefs, status updates and handovers, at least one of your questions should be an internal message, not a customer-facing one. The two skills correlate less than people expect, and the gap is where a lot of unhappy first quarters come from.

What the score is doing here

For writing roles the scored report earns its place in a specific way: it separates reading order from judgement.

The model assesses each answer against the competencies you defined and reports what it found, with the part of the answer it based that on. The final number is computed from those assessments by fixed code in the product, not by the model, and every report shows the breakdown, so a number is always traceable to something a person can read and disagree with.

Which you will, more often than in other roles, and that is fine. Tone is a judgement call. Whether a reply to an angry customer is warm or servile is a judgement call, and it depends on your product and your customers. The score gets you an order to read in. The decision about voice is yours and should never be delegated, which is why your decision is stored separately from the model's verdict rather than being blended with it.

One habit that matters more here than anywhere else: read the answer and form your view before you look at the number. Prose is exactly the kind of material where a number will retune your reading without you noticing.

How the step fits into the rest of the process

The usual sequence for these roles is CV, call, test task, interview, and the test task is where everybody stalls: it is expensive to set, expensive to review, and candidates increasingly refuse to do unpaid ones at the shortlist stage.

Putting a two-question written screen before the call changes the shape of the whole thing. The first call stops being an audition and becomes a conversation about the work, because you both already have something concrete to talk about. The test task, if you still want one, goes to fewer people and can therefore be paid without an argument. And the candidates who never get to a call at least did something related to the job instead of disappearing into a queue.

There is one sequencing rule worth keeping. Do not ask for both a portfolio and a scenario answer up front. Pick the scenario. The portfolio can come later from the people you are seriously considering, at which point it is context rather than a filter, and you will read it very differently once you already know how the person writes when nobody edited them.

What this does not replace

A paid test task, where you can afford one. For senior content or docs roles, a real piece of work with real feedback is a stronger signal than any screen. Written screening is what you use before you are willing to pay for that, or when you have too many candidates to pay them all.

The interview. You still need to know how someone takes editorial feedback, which is a conversation, not a document.

Your own standards. A written screen tells you who can write. It does not tell you which voice your product should have. That decision has to exist before the screen, or every candidate will be measured against a moving target.

Where this breaks down

Second-language roles. If the role runs in English but the customer base does not, be explicit about which language you are screening in and why. Otherwise you will filter out people who write perfectly well in the language the job actually needs.

Voice-first roles. Sales, phone support, community moderation in live channels. Written answers still tell you something, but the job happens in real time and the screen should be weighted accordingly.

Very small candidate pools. If four people applied, read their samples and talk to them. Structure pays off when there is a pile.

Roles where speed of writing is the constraint. A screen taken in the candidate's own time measures quality, not throughput. If the job is forty tickets a day, throughput is a separate question and belongs in the trial period.

Starting this week

  1. Pick the role where you have the least confidence in your current filter. For most teams that is support or content.
  2. Write two scenario questions from real situations that happened in the last month. Change the names. This takes twenty minutes and the questions will be better than anything generic.
  3. Map each question to the competencies you care about, so the report is about your criteria rather than about writing in general.
  4. Send it to everyone still in the running, including the ones with no portfolio. That group is where this method finds people the old one missed.
  5. Read for judgement, not for polish. Then look at the score, and notice where you disagree with it.

For roles where the work is writing, this is the least artificial screening step available: the candidate does a small piece of the job, everyone does the same one, and you keep what they wrote.

If the size of the pile is your problem rather than the format, see high-volume roles. If you are weighing this against recorded video answers, the longer argument is in written pre-screening or one-way video.

Try it on a role you are hiring for

Written answers, scored against the competencies you defined, with the working shown. No video to record or sit through, and no annual contract.

Start free