Write a Custom Task

Custom tasks are available on Growth and Enterprise. They let you assess against something closer to your actual system.

What a task is made of

A task references a versioned base runtime rather than defining its own environment:

• Runtime profile — language, version, and capabilities. See Runtime Profiles.
• Workspace artifact — the starter repository the candidate opens.
• Lifecycle commands — setup and start.
• Test commands — public tests, and separately, hidden tests.
• Brief — what the candidate reads.
• Rubric — what the reviewer scores against.

Write the brief as a requirement, not a spec

The most common mistake is writing the brief like a ticket for a junior developer, listing every technical concern to address. Do that and every candidate scores identically, because you told them the answers.

Write business requirements. Let the engineering concerns stay hidden in the rubric:

Weak brief: "Implement the reservation endpoint. Use a transaction, handle race conditions, add idempotency keys, validate input, and write integration tests."

Strong brief: "Customers can reserve a seat. A seat can only be reserved once."

The second one is the assessment.

Keep the codebase small

A candidate has 60 minutes. If it takes 25 to understand the repository, you have measured reading speed. Aim for a starter repo a competent engineer can orient in inside 10 minutes — a handful of files, an obvious entry point, a working test command.

Do not ship your production code

Strip secrets, customer data, and anything proprietary you would not want on a stranger's laptop. The workspace runs in the candidate's browser, and the starter repository is on their machine for the duration.

Validate before you use it

Run your own task end to end. If you cannot complete it in the time limit with the AI agent's help, neither can a candidate.