patchgroundStar on GitHub

Open-source engineering practice

Real code.
Real problems.
Practice beyond
the puzzle.

Interviews and real jobs are not about inverting binary trees. They are about stepping into code you did not write, understanding what is broken and fixing it so it stays fixed. Patchground gives you a real repository, a real ticket, your own editor and AI, and checks that run in Docker.

Get Patchground Browse challenges
  • Local-first, no account
  • Bring your own editor and AI
  • Verified by tests, not scored
  • Apache-2.0
one practice sessionillustration
  1. pgnd start duplicate-charges-on-retry
  2. workspace ready · ticket: Duplicate charges after a payment retry · 45 min
  3. pgnd check
  4. ✗ 12 passed, 2 failed — hidden checks still red
  5. pgnd check
  6. ✓ 14 passed, 0 failed
  7. pgnd submit
  8. Verified outcomes
    Checks
    14 / 14
    Regression test
    fails before · passes after
    Diff scope
    inside src/payments/
    Time
    38 of 45 min
    No overall score. Facts your tests can back.

How it works

One ticket.
Four commands.

A session goes the way real work does: pick up a ticket, dig into a codebase you have never seen, prove the fix holds and get a record of what you actually did.
  1. 01 · pgnd start

    Pick up a ticket

    A real repository with a bug report or feature request, in a fresh workspace. The tests that decide the outcome stay hidden.

  2. 02 · your editor

    Find it and fix it

    Read code you did not write, reproduce the problem and change it. Use your own editor and AI agent, or work without one.

  3. 03 · pgnd check

    Check as you go

    Run the checks in Docker as often as you need. Red turns green only when the behaviour is actually right.

  4. 04 · pgnd submit

    Get verified outcomes

    Your work is frozen into a report: what passed, whether your test proves the fix and where your diff landed.

What you practise

The skills the job
actually asks for.

Puzzles train you to recall algorithms. Patchground trains the habits that matter on a team and in a practical interview, and gives you evidence to show for them.

Debugging unfamiliar code

Trace a symptom from a support ticket to its root cause in a codebase you have never opened.

Proving the fix

Write a regression test that fails before your change and passes after. Patchground runs it on both versions to check.

Working with your AI

Direct Claude Code, Codex, a local model or no tool at all. Then use the outcomes to check what it really changed.

Shipping a feature

Extend existing behaviour without breaking what already works, so the old tests stay green.

Keeping the change in scope

Fix the problem in the right place. The report shows exactly which files your diff touched.

Working to a timebox

Every challenge has a realistic timebox. See how long you really took and how many hints you used.

Who it's for

Preparing for a practical interview

Live debugging rounds and take-home feature tasks, rehearsed on real repositories against the clock.

Joining a new codebase

Read before changing, find the right place for a fix, leave the tests stronger than you found them.

Learning to lead an AI agent

Direct your agent on a realistic task, then check its work with tests, regression evidence and diff scope.

What you walk away with

Facts about your work,
not a score.

When you submit, Patchground freezes your workspace and computes a report from test runs alone. When it cannot prove something, it says so instead of guessing.
Verified outcomesduplicate-charges-on-retry · illustration
Checks
14 / 14 passed
Regression test
fails before · passes after
Test structure
0 tests removed · 0 assertions dropped
Diff scope
2 files inside src/payments/
Time & effort
38 of 45 min · 6 checks · 1 hint
No overall score. Missing evidence is reported as "not established".

  1. Does it work?

    Visible and hidden checks run fresh in Docker on your final code.

  2. Did you prove it?

    Your new test is run on the original code and on yours. It only counts if it catches the bug.

  3. Did you cut corners?

    It flags deleted test files or functions and fewer assertions, so a fix can't pass by weakening tests.

  4. Did you stay focused?

    It lists every file you changed and whether each one is in the area the ticket expects.

  5. How did it go?

    Elapsed time against the timebox, plus how many practice checks and hints you used.

Why it exists

The interview changed.
The practice did not.

The people who build the tools and run the hiring have been saying it for a decade: puzzles don't predict the job. Companies are now rebuilding their interviews around real codebases and real tools. The practice platforms mostly haven't.
In their own words · public statements, linked to the source · not endorsements of Patchground

  • Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard…

    Max HowellCreator of Homebrew, after a Google interview · June 2015X (archived)

  • Hello, my name is David. I would fail to write bubble sort on a whiteboard. I look code up on the internet all the time. I don't do riddles.

    David Heinemeier HanssonCreator of Ruby on Rails, CTO of Basecamp · February 2017The Outline

  • Engineers spend most of their time understanding existing codebases, reviewing pull requests and iterating on solutions, rather than implementing algorithms from scratch.

  • This is more representative of the developer environment that our future employees will work in, and also makes LLM-based cheating less effective.

    MetaInternal post on AI-enabled coding interviews · July 2025404 Media

  • The developer’s role has changed to be an orchestrator of agents, but LeetCode-style puzzles aren’t going to help you find them.

    HackerRankIts own homepage, to the companies it sells interviews to · checked 2 November 2026hackerrank.com

  • We found that brainteasers are a complete waste of time. … They don’t predict anything. They serve primarily to make the interviewer feel smart.

How Patchground compares

From each platform’s public pages · checked 2 November 2026

Patchground compared with LeetCode, HackerRank, CodeSignal, Exercism and CodeCrafters
AspectPatchgroundLeetCodeHackerRankCodeSignalExercismCodeCrafters
What you work onA real repository with a bug report or feature ticket4,100+ algorithm problemsInterview Preparation Kit: arrays, hashmaps, greedy, dynamic programming, trees…Courses with an AI tutor, and certified coding assessments8,700+ small exercises across 85 languagesBuild your own Redis, Git, SQLite…
Where you write codeYour editor, on your machine, with any AI or noneBrowser editor, with a built-in AI agent on Premium creditsBrowser editorBrowser IDEBrowser, or your editor through its CLIYour editor; you submit with git push or its CLI
Where checks runDocker, on your machineLeetCode’s judgeHackerRank’s serversCodeSignal’s serversYour machine, or Exercism’s test runnerCodeCrafters’ test runners
What you get backVerified outcomes: checks, regression proof, diff scope, time. No score.Accepted or not, with runtime and memory percentilesPass or fail per test caseAn assessment score from 200 to 600Passing tests, automated analysis, optional human mentoringStage-by-stage test results
Account neededNoYesYesYesYes; the CLI uses your API tokenYes
Source code publicYes, Apache-2.0NoNoNoYes, on GitHubIts test runners are, on GitHub

Sources: LeetCode problem list, Premium · HackerRank Interview Preparation Kit · CodeSignal Learn, assessment score · Exercism homepage, working locally · CodeCrafters how challenges work, CLI, redis-tester. Products change; if a cell is out of date, open an issue. Exercism and CodeCrafters are excellent—use them too. Patchground is narrower: unfamiliar codebases, your own tools, and outcomes your tests can back.

01

Local-first

No account, server or subscription. Image builds may use the network; checks run on an internal Docker network with resource limits.

02

AI optional, never required

Use Claude Code, Codex, a local model, or nothing—in your own editor. Patchground needs no API key and has no built-in AI; what your assistant sees is up to you.

03

Verified or it does not ship

Every published challenge must prove, in its container, that the broken state fails and a reference fix passes—deterministically.

Challenges

Small collection.
Real bugs.

Each one is a complete repository with a ticket, visible tests you can extend, hidden checks, and a reference fix—validated in Docker before it is published. A handful of excellent challenges beat fifty generated ones.

7 challenges in 1 pack · Python, Typescript · Debug, Refactor, Feature

Put a port between the order service and its storage and email — read the ticket

OrderService imports and constructs SQLite and SMTP adapters itself, so nothing can be swapped for SMS or for fast tests. Introduce ports, inject the adapters and keep behaviour identical.

patchground-examplesbuilt-inPython / Refactor · architecture, ports-and-adapters, dependency-inversion, refactoring

Intermediate · AI-generated40 MIN

Add unsubscribe and once to the in-process event bus — read the ticket

A synchronous exact-topic event bus cannot take a subscription back or listen once. Add unsubscribe and once with precise snapshot, re-entrancy and error-collection behavior.

patchground-examplesbuilt-inTypescript / Feature · events, reentrancy, error-handling

Intermediate · AI-generated45 MIN

Difficulty and realism are not yet human-rated. Challenges marked AI-generated were drafted with a coding agent and validated like any other. built-in means shipped with the CLI and validated in this repository's CI; verified means a community pack whose every challenge passed pgnd validate in Patchground's CI on the date shown. Installing packs by name from the CLI is planned; today the CLI runs challenges from a local path or a pack URL. How to run one · Registry status

Packs: collections, kept by their authors.

A pack is a git repository with a pack.yaml and one folder per challenge. It stays in its author's repo; Patchground only indexes it after re-validating every challenge in its own CI. Stars and forks come from the host.

1 pack · 0 community

patchground-examples

built-in

Curated examples shipped with the CLI; validated in this repository's CI on every push.

7 challengesDebug, Feature, Refactorvalidated in CI on every push

No community pack has been verified yet. Publish yours and it will appear here after the next registry run.

Install

From install
to first ticket.

Patchground is an early, working release on PyPI. The curated challenges ship with the CLI, so there is nothing else to download.

  • Python 3.12+ and uv
  • Git and a running Docker engine (or Podman)
  • macOS or Linux; Windows through WSL2
First-session guide README
get started
uv tool install patchground
pgnd doctor
pgnd list --builtin
pgnd start pagination-last-page

Then open the printed workspace in your editor and run pgnd check as you go. Finish with pgnd submit.

Publish your pack

Know a bug worth learning from? Publish it. No pull request.

Your challenges live in your own repository. Patchground discovers it, re-runs its validator on every challenge, and lists what passes. The validator is the gate: nothing else is reviewed by hand, and nothing that fails is listed.
  1. 01

    Author and validate locally

    pgnd new my-bug scaffolds a runnable challenge; pgnd validate my-bug proves the broken state fails, the reference passes, and the result is stable. Fix every step until it reads valid.

  2. 02

    Make it a pack

    Put each challenge folder at the root of a public repository next to a pack.yaml that names it. Declare a content_license and provenance in every challenge.yaml; keep services: [].

    spec_version: "0.1"
name: my-pack            # lowercase, hyphens; first publisher keeps the name
version: 0.1.0
description: Bugs from a payments team
challenges: [my-bug]
  3. 03

    Tag the repository

    Add the GitHub topic patchground-pack to the repository. On other hosts, add your https:// clone URL to registry/sources.yaml. That is the whole submission.

  4. 04

    Appear

    Every few hours the registry clones tagged repositories, runs the policy checks and pgnd validate on each challenge in Patchground's CI, and publishes the result. Passing packs show up in the catalog with a verified badge; anything else is explained on the status page with the failing step.

Planned: pgnd pack publish to validate and tag in one command, and pgnd pack add <name> to install by name from this index. Until then the steps above are the whole process. The registry never lists hidden checks, hints or reference solutions; only the public metadata you see in the catalog. Authoring guide

Built in the open

Improve the engine itself.

Patchground is Apache-2.0. Sharpen a ticket, extend the validator, add a language adapter, or report what confused you on your first session.

Contribute on GitHubOpen an issue