Every five years or so, someone on the internet rediscovers that work-sample tests predict job performance better than résumés, interviews, and almost every other screening method. Frank Schmidt and John Hunter made the case clearly in their 1998 meta-analysis, and the field has been quietly confirming it ever since. And yet most organizations still run the same hiring pipeline they've always run: résumé screen, phone interview, onsite, offer. Work-samples show up, if at all, as a late-stage "take-home" that the candidate treats as homework and the hiring manager treats as a checkbox.
This piece is for the people trying to actually rebuild hiring around work-samples. It covers what a work-sample is and isn't, how to pick the right task for a role, how to write a rubric that discriminates, how to use AI scoring without making the process worse, and the three failure modes that turn a well-intentioned work-sample program into theater.
What a work-sample actually is
A work-sample is a task that mirrors what the candidate would actually do on the job, scored against criteria the hiring team has agreed on in advance. The key word is mirrors. It is not a puzzle, not a trivia quiz, not a personality inventory. A product manager's work-sample is a product brief. A data analyst's work-sample is a SQL query against a realistic schema followed by a short written interpretation. A customer success lead's work-sample is a response to a frustrated customer email.
The difference between a good work-sample and a bad one isn't difficulty. It's realism and rubric. Difficulty without realism tests irrelevant skills. Realism without a rubric produces scores that depend on which reviewer read the submission. You need both.
A work-sample is not a test of ability in the abstract. It's a slice of the actual job, evaluated against the actual criteria you care about. If it isn't that, it's theater.
Good work-samples are time-boxed — usually thirty to ninety minutes — scoped narrowly, and scored against a rubric that was written before any candidate submitted. The time-boxing matters because it reflects how real work happens. The scope matters because you are testing one or two high-leverage things, not everything the candidate might do on the job. The up-front rubric matters because it prevents post-hoc bias from deciding the outcome.
What to test, by role
You don't test "skills" in the abstract. You test a slice of the job. The design question that matters is: what is the most common, highest-leverage thing this person will do in their first ninety days? Build the work-sample around that.
For engineering roles, skip the whiteboard algorithm puzzle. It predicts job performance poorly because almost nobody solves dynamic programming problems cold under pressure in production. A better three-task sandbox runs something like: fix a failing test in a small codebase, write a function that returns data from a JSON blob in a specific shape, then write a short decision memo about a tradeoff relevant to the team's stack. The first two test the craft. The third tests judgement, which is the thing you're actually hiring for at senior levels.
For data roles, a SQL query over a realistic three-table schema, followed by a short interpretation of the results, followed by an exec-summary email to a non-technical stakeholder. In forty-five minutes you get a crisp read on whether the candidate can query data, think about it, and explain it to the CEO — which is the job.
For marketing, an email to a specific persona, a landing-page concept, or a response to a competitive attack. Score for tone, evidence of thinking about the reader, and specificity over generic marketing language. For sales and customer success, a discovery-call outline given a specific prospect brief, or a response to a churn-risk signal, or a structured objection-handling script. Video response works well here because how they say it matters as much as what they say. For operations and chief-of-staff roles, a prioritization memo: given this company state and these five initiatives, rank and justify.
How to write a rubric that discriminates
Most hiring rubrics fail one of two ways. Either they're so vague — "communication: excellent, good, or poor" — that two reviewers never agree. Or they're so granular — twelve subcriteria with five levels each — that scoring a single submission takes an hour and nobody wants to do it.
A useful rubric has three to five criteria, each with three to five levels, and concrete anchors for each level written as observable behavior. For a data analyst rubric, that looks something like: analytical depth (level 1: answers the literal question, misses underlying pattern; level 3: identifies one non-obvious pattern; level 5: identifies root cause and raises the question behind the question). Writing clarity (level 1: dense, unstructured; level 3: organized but jargon-heavy; level 5: an executive reads it in thirty seconds and can act). Stakeholder sensitivity (level 1: ignores audience; level 3: appropriate tone; level 5: anticipates pushback). Actionability (level 1: vague recommendations; level 3: specific but not assignable; level 5: every recommendation has an owner).
Four criteria. Five levels. Anchored to observable behaviors. Two reviewers scoring the same submission should converge within one level on each criterion. If they don't, the anchors aren't concrete enough, and the fix is to rewrite them, not to train the reviewers harder.
If your rubric fits on one screen and discriminates between two careful readers, you have a hiring tool. If it doesn't, you have theater.
The hardest part of rubric writing is the anchors. Every team I've worked with starts by writing levels that describe the candidate ("the candidate demonstrates strong analytical thinking"). Those don't work. The only useful anchors describe the artifact in front of you. "The memo identifies three root causes before proposing a solution." "The executive summary fits in the preview pane of Outlook." Anchors that describe the artifact, not the person, are the ones that let two reviewers converge.
AI scoring without making it worse
We run AI-assisted rubric scoring inside Chronos because the alternative — a hiring manager scoring forty rich-text submissions personally — is either impossible or produces drive-by scores that are worse than random. But AI scoring is only useful under two conditions.
The first is that the model has to use your rubric, not its own. Your scoring system prompt passes the rubric to the model verbatim, asks for a numeric score per criterion, and requires a written rationale that references specific quotes from the submission. Without that constraint, you get a score based on whatever the model thinks "good" is, which is not the same as what you think good is.
The second is that a human has to override, and the overrides have to be logged. AI scoring is a first pass. A reviewer reads the top-of-pile submissions, adjusts the AI score when the rationale doesn't hold up, and the override goes into the audit trail. Over time, you look at the delta between AI scores and human overrides to understand where the model and your team disagree. That gap tells you whether to update the rubric or to retrain the model.
AI rubric scoring is a drafting tool, not a decision tool. The moment it becomes the decision, you've automated the bias instead of correcting for it.
Teams that get this right treat AI scoring like a junior analyst: fast, cheap, useful for a first read, always reviewed by a senior person before a decision. Teams that get it wrong treat AI scoring like a final answer, and they hire worse than they would have without it.
The three failure modes
The first is testing the wrong thing. A startup hiring its first senior backend engineer gives candidates a frontend CSS task because the hiring manager knows CSS and is too busy to design a backend task. The best candidate bombs. The wrong candidate passes because she happened to have built a blog recently. This is a preventable self-own. If you cannot design a realistic task for the role, you are not ready to hire for the role.
The second is scoring after the fact. The rubric gets written after reading the first few submissions. Which means the rubric confirms the team's existing bias about which submissions looked good. Which means the work-sample is theater with extra steps. Rubrics are written first. Always. If you can't write a rubric before you've seen submissions, you don't know what you're looking for, and you're not ready to evaluate candidates on it.
Rubrics are written before any candidate submits. Always. If you cannot write it in advance, you don't know what you're hiring for.
The third is skipping calibration. Three reviewers score the same ten submissions independently, without seeing each other's scores, then compare. If they agree within one level on each criterion, the rubric is discriminating and you can use it in production. If they disagree widely, the rubric is unclear and needs a rewrite before a single candidate sees it. Most teams skip this step because it feels slow. They end up making hire decisions on reviewer luck.
What to do this week
Pick one role you are actively hiring for. Write the rubric first — three to five criteria, three to five levels, anchored to observable behaviors about the artifact, not the candidate. Have two colleagues score you on the rubric without showing them each other's scores. If they converge within one level per criterion, you have a usable rubric.
Send the work-sample to your next three candidates. Score their submissions against the rubric. Compare the scores to your gut read. If the rubric picked up things your gut missed, keep it. If your gut picked up things the rubric missed, rewrite the rubric to capture what you noticed. Iterate for one hiring cycle.
Work-samples change how hiring works, but only when they are designed with the same seriousness you would bring to a production system. Most organizations don't invest that seriousness and keep the bad hiring pipeline they've always had. The organizations that do invest hire better, hire faster, and do it for less money. It is not a hard bet.