Time Limits and the Timer
The timer is server-authoritative. It is not running in the candidate's browser where a refresh or a closed laptop could change it.
When the clock starts
Not when the candidate opens the invitation. The sequence is:
- Candidate opens the invitation
- The device check runs
- The generic runtime downloads and caches
- The candidate sees Ready to Start
- The candidate clicks Start
- The task is authorised and downloaded, the workspace mounts, setup runs
- The runtime reports READY
- Only then does the clock start
A candidate never loses time to a slow download or a setup script. If our setup fails, the timer does not start at all.
Choosing a limit
Library tasks are built for 30 to 90 minutes and carry a recommended limit. Some guidance:
- Under 45 minutes rewards speed over judgement. Good for a screening filter, weak for seniority.
- 60 to 90 minutes is the sweet spot. Enough room to build something, review it, and improve it — which is exactly the behaviour you want to observe.
- Over 2 hours costs you completion rate more than it buys you signal.
Extending the limit does not make a task harder. It makes it more forgiving.
If a candidate disconnects
Work in the workspace is preserved locally. If the tab closes or the network drops, the candidate reopens the link and continues — the clock kept running, because it is measured on the server.
If something went genuinely wrong, you can reset an attempt. See An Assessment Was Interrupted.
Accommodations
Some candidates need more time as a reasonable accommodation. Extend the limit on a per-candidate basis when you invite them, or afterwards from the attempt. Providing accommodations is your responsibility as the employer.