Runtime Profiles and Databases
Assessments run inside the candidate's browser. The editor, terminal, test runner, and their code all execute locally, using WebAssembly and, for some profiles, an in-browser Linux environment.
This keeps assessments fast to start and cheap to run, and it means a candidate's code never has to touch our servers to execute.
Available profiles
| Profile | What it gives you |
|---|---|
node-basic | Node with npm. JavaScript and TypeScript tasks with no database. |
node-sqlite | Node plus embedded SQLite. |
node-pglite | Node plus PGlite, for PostgreSQL semantics. |
python-basic | Python with pip. |
python-sqlite | Python plus embedded SQLite. |
Profiles are versioned and immutable. A task pinned to a version keeps behaving the same way a year later, so scores stay comparable.
Choosing a database
SQLite is the default for good reason: embedded, deterministic, no setup, and sufficient for most data modelling, transaction, and constraint work.
PGlite when the task genuinely depends on PostgreSQL behaviour — advisory locks, SELECT … FOR UPDATE, specific isolation semantics, or Postgres-only types.
No database for pure logic, algorithms, frontend, and refactoring tasks.
What is not supported
There are no Docker-based candidate environments, and no arbitrary Docker Compose stacks. Redis, Kafka, MongoDB, and dedicated PostgreSQL instances are not available.
That is a deliberate limit. The assessment is about engineering ability, not infrastructure setup — and a candidate should not spend twelve of their sixty minutes waiting for containers.
Caching
The generic runtime downloads and caches in the candidate's browser before the assessment starts and before the clock runs. Task-specific files are authorised and fetched at the moment the candidate clicks Start.