NewLive pair coding: one link for the candidate, one shared sandbox for everyone.See it ↓

Coding screens · async take-homes

Take-homes in a real IDE. Graded where nobody can touch the score.

Candidates get VS Code, a terminal, a running preview of their app and language servers, all in the browser. Grading re-runs the work on Kendor's own servers at pinned versions with the network cut, so the score belongs to the code.

01

Three question types, one time limit.

Combine full projects, single-file exercises and written questions in one screen. The time limit covers the whole screen, and candidates move between questions freely.

02

A clean re-run decides the score.

Results from the candidate's own terminal don't count. Grading rebuilds the workspace from your starter on Kendor's servers, lays only the files the candidate may edit on top, and runs your tests at the challenge's pinned versions. Hidden tests only run there.

  • The same versions for every candidate, so two submissions are graded alike.
  • No network while the tests run, so nothing outside the sandbox can change a result.
  • Tests, fixtures and install commands come from your starter, so editing them changes nothing.

03

Integrity signals, shown as evidence.

With proctoring on, tab switches, external pastes and fullscreen exits are logged with timestamps, and the Timeline tab plays the code back as it was written. Kendor doesn't turn them into a score. A reviewer reads them and decides what they mean.

04

Attach a screen to a job posting.

Applicants get the screen the moment they apply, as a link on the confirmation page and an invitation email, so nobody sends invites by hand. Choose No screen and applications wait for manual review instead.

05

Every reviewer gives their own verdict.

Reviewers read the code, the test results and the activity, then each records a recommendation from Strong no to Strong yes, with a note the others can read. Then someone on the team advances or rejects the candidate.

How it works

From repository to decision in three steps.

  1. Build the screen

    Import a repository or start from a single file, add tests (hidden ones too), and set the time limit.

  2. Send it, or attach it to a role

    Invite candidates directly, or let applicants receive it when they apply.

  3. Grade, review, decide

    Kendor grades a clean re-run, each reviewer records a recommendation, and you advance or reject.

Questions

Can candidates see the hidden tests?

No. Hidden tests never reach the candidate's browser: a single-file challenge's test file stays out of their workspace, and hidden tests only run when the submission is graded on Kendor's servers. Test files candidates can see are restored from your starter before grading.

What if the code needs the network?

Dependencies are installed before the network is cut. Anything that calls out while the tests run fails the same way for every candidate, so mock external services in the starter code.

Does Kendor reject candidates automatically?

No. Test results and integrity signals are inputs for reviewers. A person advances or rejects every candidate.

Do candidates need to install anything?

No. They open the link from their invitation in a browser and land in the IDE with the project's dependencies, terminal and preview ready. No webcam, no browser extension, no desktop app.

More of Kendor

All features

Run your next screen on Kendor. Read what the code says.

Kendor works with engineering teams in the EU, the UK and the US. Tell us what you're hiring for and we'll set up your organization with you.