---
title: "Send your first coding screen"
description: "Build a coding screen from your own repository, check that it runs, and invite a candidate. About 15 minutes."
updated: 2026-10-06
canonical: https://kendor.io/docs/getting-started/send-your-first-coding-screen
---

# Send your first coding screen
> **Before you start**
>
> - A Kendor organization. Access is by request: ask on the [contact form](/#contact) and you'll get a link to set it up.
> - The **Owner** or **Editor** role. Viewers can read screens but can't create them.
> - A repository for the candidate to work in, on any Git host. No repository yet? Start from a blank project instead (step 2).

## Create a screen

Open **Screens** in the sidebar and choose **New screen**. Give it the name candidates will see, such as `Rate limiter`, in the **Name this screen** field.

In the settings on the right, pick a **Time limit**. 90 minutes is the default and suits most backend tasks; you can also choose 30 minutes to 4 hours, or a custom length. Once the draft exists, your changes save as you go.

## Add a challenge from your repository

Paste the repository URL into **Repository URL** and choose **Check**. Kendor previews the import: the number of files, its size, and whether the repository already has a `kendor.yaml`.

- **Hosts:** github.com, gitlab.com and bitbucket.org, plus your own GitHub Enterprise Server, GitLab, Gitea or Forgejo.
- **Private repositories:** an organization owner adds a read-only token under **Integrations → Code hosts** first. Tokens are stored encrypted, and Kendor only ever shows their last four characters.
- **One folder of a monorepo:** paste a link to a branch or folder (for example `github.com/acme/platform/tree/main/services/billing`) and only that part is imported.

Set the **Title**, **Language**, and any **Databases** the project needs, then choose **Add challenge**. The import is a copy of that commit: later pushes to the repository don't change a screen that's already out.

No repository? Under **Or add:**, choose **Blank project** to start from one of Kendor's starters, or **Single file** for an algorithm-style question.

## Check how it runs

A `kendor.yaml` at the root of the project tells Kendor how to install, start and test it. When the repository doesn't have one, the editor opens **Runtime configuration** for you. Fill in the form, or switch to **Raw YAML**, and save: Kendor writes `kendor.yaml` and restarts the sandbox with it.

A small project with a PostgreSQL database looks like this:

```yaml title="Python" file="kendor.yaml"
version: 1
runtime:
  type: python
  version: "3.12"
databases:
  - type: postgres
    version: "18"
    init: db/schema.sql
install:
  commands:
    - pip install --user -r requirements.txt
services:
  app:
    dev:
      command: uvicorn main:app --host $HOST --port $PORT --reload
      port: 8000
    test:
      command: pytest --tap-stream
preview:
  service: app
```

```yaml title="Node.js" file="kendor.yaml"
version: 1
runtime:
  type: node
  version: "22"
databases:
  - type: postgres
    version: "18"
    init: db/schema.sql
install:
  commands:
    - npm ci
services:
  app:
    dev:
      command: node --watch src/server.js
      port: 3000
    test:
      command: node --test
preview:
  service: app
```

Kendor starts the database inside the sandbox and passes its connection string to your app as `DATABASE_URL`. Choose **Preview as candidate** to see the running app exactly as a candidate will.

## Make sure the tests run

Candidates run the project's tests themselves, from the **Tests** tab in the editor or from the terminal, as often as they like. The tests are ordinary files in the project, so candidates can read them too.

The **Tests** tab runs the `test` command from `kendor.yaml`. To get one row per test instead of a single pass or fail, have the command print TAP: `pytest --tap-stream` (Kendor's Python ships with `pytest-tap`) or Node's built-in `node --test` both do. Run the suite once in the preview to check it.

## Launch the screen

Back in the screen's settings, add **Default reviewers** and check the **Invite expiry** (7 days unless you change it). To let candidates use Claude Code or Codex in the terminal, turn on **AI assistants in the terminal**; it runs on your organization's own API keys.

The **Launch checklist** shows what's missing. A screen needs a title, at least one challenge, and a valid runtime configuration. Choose **Launch** and the screen goes **Live**.

## Invite a candidate

Open **Candidates** and choose **Invite candidate**. Enter one or more emails, pick the screen (only live screens are listed), and choose **Send invite**.

Each candidate gets their own link by email. They don't need an account: they enter their name, and the timer starts when they choose **Begin screen**. If you'd rather send the link yourself, use **Copy invite link** in the candidate's row.

> **Tip.** Send the first invite to yourself to see exactly what candidates see.

## Review the submission

When the candidate submits, open them from **Candidates** and choose **Open review**. You'll find their code and its diff under **Solution**, plus the **Timeline**, **Terminal**, **AI agents** and **Activity** tabs.

Each reviewer records a recommendation, from **Strong yes** to **Strong no**, with an optional note. Then someone makes the call: **Advance** or **Reject**. Neither emails the candidate, so you decide when and how they hear back. **Mark passed** and **Mark did not pass** are different: they email the candidate their result straight away. See [Review a submission](/docs/coding-screens/review-a-submission).