How to build a take-home from your company repository

To build a take-home from your company repository, copy a small slice of the real codebase into a separate repository, remove secrets, history and anything confidential, and make sure it installs and starts with one command. Then write one task that fits in about half the time limit, with tests that show the candidate what "done" means.

Why use your own code at all?

A task in your own codebase shows you how a candidate handles the code they'd actually work on: your conventions, your frameworks, your kind of mess. It also shows the candidate what the job is like, which helps good people say yes and lets poor fits drop out early.

The cost is preparation. A slice of a real system has to run on its own, without your VPN, staging database or internal package registry. Plan a few hours for the first one. Every later task built on the same slice is much cheaper.

Pick the right slice

Don't hand over the whole repository. Pick the smallest piece that still feels real.

• One service, not the platform. A single API with its own tests is ideal. If it calls three internal services, stub them with a few lines that return fixed data.
• Code people actually touch. The billing module that gets a change every sprint is a better choice than a framework layer nobody edits.
• Enough context to explore. A few thousand lines is fine. Candidates should be able to find their way in ten minutes.
• A real seam for the task. Look for a place where a bug fix or a small feature fits naturally, such as a missing validation, an endpoint without pagination or a slow query.

Use one folder of a monorepo

If your code lives in a monorepo, you often don't need to extract anything: point the take-home at the one folder that holds the service. Check that it doesn't import shared packages from elsewhere in the repository, or vendor the few it needs into that folder.

Strip secrets, history and anything confidential

Treat the slice like an open source release. Candidates will read every file.

• Start a fresh repository. Copy the files, don't fork. Git history can hold old keys, internal names and comments you'd rather not share.
• Remove secrets. Delete .env files and replace them with a .env.example that uses dummy values. Search for API keys, tokens, internal hostnames and connection strings.
• Remove customer data. Fixtures and seed files often hold copies of real records. Replace them with made-up data.
• Check comments and docs. TODOs that name customers, links to internal wikis and incident references all go.
• Mind licences. Third-party code with restrictive licences may not be shareable, even in an interview.

Make it run without you

The candidate shouldn't spend the first half hour installing things. Aim for one install command, one start command and one test command, and document them in the README.

• Pin language and dependency versions with a lockfile.
• Replace calls to internal services with small local fakes.
• If the service needs a database, use a real one with a small seed. See How to build a take-home with a real database.
• Run the tests once. If any are flaky, fix them or delete them before a candidate sees them.

Keep the task under the time limit

The most common take-home mistake is a task that takes twice as long as advertised. Candidates who have jobs and families pay for that, and you lose them.

• Time yourself on a clean copy, then make sure the task fits in half the limit.
• One clear goal. "Add pagination to GET /orders, with tests" is enough for 90 minutes in an unfamiliar codebase.
• Tell them what not to do. "No need to touch the UI" saves candidates from guessing at scope.
• Leave room for a short write-up of what they'd do next. It shows judgment and costs five minutes.

Doing this in Kendor

Kendor imports a repository straight into a challenge and runs it in a sandbox. Candidates don't clone anything or install anything locally. See Import from any Git host.

Import the repository

In a screen, paste the URL into Repository URL and choose Check. Kendor previews the import: the number of files, the size, the detected language, and whether the repository already has a kendor.yaml. Then set the Title, Language and any Databases, and choose Add challenge.

• Hosts: github.com, gitlab.com and bitbucket.org, plus your own GitHub Enterprise Server, GitLab, Gitea or Forgejo.
• Limits: up to 50 MB and 5,000 files, with no single file over 5 MB.
• Dependency folders such as node_modules, vendor and .venv are left out. The sandbox installs dependencies itself.

Private repositories

An organization owner adds a read-only token for the host under Integrations → Code hosts. Tokens are stored encrypted, and Kendor only ever shows their last four characters. Use a token scoped to just the repositories you'll import. See Private repositories.

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. See Monorepo folders.

A fixed snapshot

The import is a copy of the files at that commit, without the Git history. Later pushes to the repository don't change a screen that's already out, so every candidate gets the same code. See Snapshots and updates.

Make it run with kendor.yaml

A kendor.yaml at the root of the project tells Kendor how to install, start and test it. If the repository has one, Kendor uses it. If not, Kendor detects a setup from the project's files and adds a kendor.yaml for you to review in the editor's Runtime configuration.

version: 1
runtime:
  type: node
  version: "22"
databases:
  - type: postgres
    version: "18"
    init: db/seed.sql
install:
  commands:
    - npm ci
services:
  api:
    dev:
      command: npm run dev
      port: 3000
    test:
      command: node --test
preview:
  service: api

For a project with several services, each one gets its own entry under services, with a workDir for its folder. See the kendor.yaml reference and Multi-service apps.

Set the time limit and check it

In the screen's settings, pick a Time limit. 90 minutes is the default; presets go from 30 minutes to 4 hours, or you can enter a custom length. Then choose Preview as candidate, run the tests from the Tests tab, and work through the task yourself against the clock.