How to Write a Code Challenge Brief That Actually Tests What Matters

You have probably seen briefs like this one:

This brief tests nothing useful. It will produce twenty submissions that look roughly the same, and your engineering team will spend hours trying to rank them based on vibes. The candidate who happened to have a free weekend will outperform the one with two kids and a side project, and neither outcome tells you anything about who would be better at the actual job.

Let us fix that.

Why Most Briefs Fail

The root cause of bad briefs is working backwards from the test rather than forwards from the role. Someone thinks "we should give them a React challenge" without first asking "what does this person actually need to be good at on day one?"

That number should bother you. It means the majority of candidates filtered out by your coding challenge were false negatives: people who could do the work but whose take-home submission did not demonstrate it, because the brief was testing the wrong things.

Common failure modes include:

• Testing framework fluency instead of problem-solving. A candidate who has not used your exact stack but can think clearly about architecture might be your best hire.
• Testing speed instead of quality. One-week deadlines with extensive requirements reward candidates who have free time, not candidates who write careful code.
• Testing nothing specific. "Build a web app" is so broad that candidates have to guess what you value, and most will guess wrong.

Start With the Role, Not the Test

Before you write a single line of the brief, answer these three questions:

These questions force you to think about the actual job rather than a generic assessment of "coding ability." A frontend developer who will be building complex forms needs a different challenge than one who will be building data visualisation dashboards, even though both roles might have "React" in the job description.

The best briefs test the weakest skill that would cause a new hire to fail in their first 90 days.

If your last three hires all struggled with state management in complex UIs, your brief should test state management in complex UIs. Not routing, not styling, not API integration. The specific thing that predicts failure.

The Anatomy of a Great Brief

Every effective brief has five sections. Here is what each one should contain.

1. Context

Give the candidate enough background to make realistic decisions. They should understand not just what to build, but why it matters.

2. Core Requirements

List 3-5 specific, testable requirements. Each one should map to a skill you identified as important for the role.

Notice that these requirements are specific and testable. "Handle concurrent edits gracefully" is evaluable. "Write clean code" is not.

3. Evaluation Criteria

This is where most briefs fall short. Tell the candidate exactly what you are going to evaluate and how you weight it.

4. Constraints and Scope

Be explicit about what is in scope and what is not. This prevents candidates from spending time on things you do not care about.

5. Submission Instructions

Make submission frictionless. Every unnecessary step is a place where candidates drop off.

Scoping and Time Constraints

The single most impactful change you can make to your brief is reducing the scope.

A well-scoped 3-4 hour challenge produces better signal than a sprawling week-long project. Here is why:

• It forces you to prioritise. If you only have 3-4 hours of candidate time, you must decide which skills actually matter. This constraint improves the brief.
• It levels the playing field. A parent with limited free time can find 4 hours. They cannot find 20.
• It produces more comparable submissions. When scope is tight, solutions converge enough to be meaningfully compared, while still leaving room for individual approaches.

Defining Evaluation Criteria

The evaluation criteria section is the most important part of the brief, and it is the part most teams skip entirely.

Explicit criteria serve three purposes:

1. They tell candidates what you value. A candidate who knows you care about error handling will handle errors. A candidate guessing what you value might spend their time on pixel-perfect CSS instead.
2. They create scoring consistency. When your team reviews submissions, they know what to look for. No more reviewer lottery.
3. They make automated scoring possible. Brief-driven scoring tools evaluate code against stated criteria. Without criteria, there is nothing to score against.

A brief that says "build a REST API" tests nothing. A brief that says "build a REST API that handles concurrent updates to shared resources" tests something specific.

Example: Before and After

Let us take a real brief and rewrite it.

Before:

After:

The second brief is longer, but it will produce dramatically better submissions. Candidates know exactly what to focus on, reviewers know exactly what to evaluate, and the entire process respects everyone's time.