What the work actually looks like

You will spend most of your time in two modes. The first is evaluation: reading model-generated documentation — an endpoint reference, a migration guide, a set of release notes — and judging it against the standards you would apply in a real docs review. That means catching invented parameters, missing error responses, prerequisites buried after step four, and prose that sounds authoritative but is quietly wrong. The second mode is demonstration: writing the version a competent senior writer would ship, so the model has a ground truth to learn from. Some batches ask you to rank two or three candidate responses and write a short rationale explaining which documentation principle decided it.

Tasks arrive in batches with a rubric. Rubrics change between projects — one week you may be scoring factual accuracy against a supplied API spec, the next you may be judging information architecture or audience fit for a developer-onboarding guide. Reviewers care much more about whether your written rationale is specific and reproducible than whether your score matches theirs exactly.

What the screening looks for

  • Verifiable ownership of docs. Not "contributed to," but documentation you scoped, structured, and maintained. Expect follow-ups on how you handled a spec that disagreed with the implementation.
  • Ability to name your standards. Strong candidates cite concrete conventions — how they treat optional parameters, when they use a table versus prose, how they version release notes — rather than talking about clarity in the abstract.
  • Calibration under a rubric. Screens probe whether you can suppress personal style preferences and score against the criteria you were given.
  • Tooling literacy. Markdown, Git, and static site generators come up because most demonstration tasks are authored in plain text with review-by-diff.

Logistics

Fully remote and fully async — no standing calls, no required overlap window. Most contributors report picking up work in blocks of a few hours, with weekly volume that fluctuates by project rather than being guaranteed. Pay is hourly within the observed $45–90 band; higher rates tend to attach to developer-facing API work and to reviewer or lead roles on longer-running projects. Onboarding typically involves a paid or unpaid calibration task before live batches open up.