Practice With Your Own AI Agent Using Public Exercise Context

Choose what you want to practice before choosing a tool. Writing a solution independently, delivering a change with an agent, and reviewing a plausible patch exercise different skills. You can practice all three without treating an agent's confidence as evidence that the code works.

Match the session to the interview

There is no single modern interview process. One round may require independent implementation, another may allow an AI coding agent, and another may focus on debugging or reviewing an existing patch. Permission to use AI during preparation does not establish permission during an interview. Follow the rules for the specific session.

Confirm the role, round, permitted tools and expected evidence with your recruiter. See Read the interview contract for a preparation checklist. Beyond Big O's exercises are original practice, not employer questions or a prediction of hiring success.

For your own session, declare one of these conditions:

• Independent implementation: write and debug the solution yourself. Decide whether language documentation or library lookup is allowed before starting.
• Agent-assisted engineering: let your chosen agent help, then inspect its changes, run checks and explain the result in your own words.
• Review and transfer: inspect a supplied patch, find a counterexample, preserve a failing check, repair the defect and handle a disclosed requirement change.

Self-directed practice cannot prove that outside assistance was absent. A passing run, an explanation and an assistance declaration are different kinds of evidence.

A useful loop with your own agent

Start with one practice problem. Record its version and selected part, state the behavior you expect, and write one small input with a hand-checked result. Ask your agent for a concrete claim about the code and a test that could disprove it. Run the test yourself rather than copying a statement that tests passed.

If the test exposes a defect, save that failure before repairing it. Keep the repair small, rerun the regression and explain the invariant it restores. Then change one stated requirement and try the variation independently. For a cache, fixed expiry and renewal after a successful read are different contracts; passing one does not establish the other.

The editor's optional autocomplete suggests words from the current document. It is not an AI agent, a Go/Python language server or an MCP connection.

What MCP support exists today?

Beyond Big O now has a local read-only MCP stdio adapter for supplying public exercise and feedback context to your own client. The adapter runs from a local checkout; there is no hosted MCP endpoint. You do not need an MCP client to use the browser practice set.

The Rust adapter uses the official SDK and the same public-content contract as the browser and local JSON command-line tool. Its tools are search_problems, get_problem and get_review_rubric. They support bounded search, exact problem/version lookup and a pinned public feedback rubric for Solve code. Staged problems expose anonymous part 1 only. The adapter does not fetch unlocked account parts, retrieve authored Review exercises, submit code, run tests, mutate progress or return solutions and private judging material. Its rubric is guidance for a reviewer, not an automatic grade.

Connect a local MCP client

Use a trusted local checkout with the web dependencies installed, Rust available and Node on your client's PATH. From the repository root, build the adapter once:

cargo build --locked --release --manifest-path apps/practice-mcp/Cargo.toml

Configure your client to launch the resulting binary using its absolute path, with no arguments. For clients using a conventional mcpServers JSON configuration, the entry looks like this:

{
  "mcpServers": {
    "beyond-big-o": {
      "command": "/absolute/path/to/beyond-big-o/apps/practice-mcp/target/release/bbo-practice-mcp",
      "args": []
    }
  }
}

Replace the example path and use your client's documented configuration location. Client formats differ. The binary speaks MCP over stdin/stdout; do not type commands into it or wrap it in a script that prints banners. It currently pins the checkout location at build time, so rebuild after moving the checkout. The local apps/practice-mcp/README.md contains complete setup and verification details.

Local SDK and wire tests pass, including current discovery and older initialization flows. An isolated Codex CLI check called all three tools successfully. Claude Code connected and discovered the tools; its tool-call check needs client sign-in, so full two-client acceptance is still pending. No normal client configuration was changed automatically. These checks are not evidence of learner benefit or compatibility with every client.

When the server is configured with BBO_CONTENT_ROOT, it reads the shared immutable problem release. Newly activated compatible problems appear on subsequent tool calls without rebuilding or reconnecting the agent. Exact retained versions remain readable; staged exercises still expose anonymous part 1 only. Publishing content does not grant execution or change your agent's tool permissions.

The adapter bounds frames to 32 KiB including the newline, serialized tool results to 128 KiB, child operations to four at once, and initialization/operations to five seconds. It has no operation retry queue. The content server needs no account credentials, model key or execution access; your agent client may still need its normal provider sign-in.

Inspect public context from a local checkout

These commands are for a local development checkout with its dependencies installed; they are not commands to connect your client to the public website. From the repository root, enter the web application directory:

cd apps/web

Search the current public catalog:

printf '%s' '{"limit":10,"language":"python"}' | pnpm --silent practice:public-content search

Retrieve an exact published problem version:

printf '%s' '{"slug":"one-pass-string-parser","version":"2.0.0","format":"solve"}' | pnpm --silent practice:public-content problem

Retrieve its separately pinned feedback rubric:

printf '%s' '{"slug":"one-pass-string-parser","version":"2.0.0","format":"solve","rubricVersion":"1.0.0"}' | pnpm --silent practice:public-content rubric

The tool writes JSON to stdout, accepts at most 32 KiB of input with a five-second input deadline, and caps a content response at 128 KiB. Requests use explicit versions rather than silently selecting new requirements. No account credentials, model key or execution access are needed. Choosing to share that output or your code with your own agent remains your decision.

Try the original Review pack locally

The first TTL patch-review pack has Go and Python starters, a public rubric and a disclosed renew-on-read variation. It runs as a local task bundle, outside the website judge. From the repository root, choose a fresh output directory:

python3 packs/ttl-review-v1/tools/export_task.py fixed-expiry python /tmp/my-ttl-review

Use go instead of python for the Go bundle and follow the generated START.md. The visible examples intentionally pass the flawed patch: your job is to add a counterexample before repairing it. These commands execute local code and are not a sandbox. The pack does not count as a Solve completion or unlock normal problem parts. Explanation quality still requires review.

What comes next

The local adapter is implemented. Next, finish Claude Code's signed-in tool-call check and assess feedback usefulness in both selected applications. Record friction and incorrect advice as well as successful tool calls. Authored Review projection and its distinct completion identity remain separate work; the current rubric tool supports Solve exercises only.

Remote code execution, account attempts and stored feedback are later capabilities with separate ownership, isolation and privacy requirements. MCP itself does not make those operations available or turn agent advice into a verified result. For now, begin with the foundation problems, then practice reviewing the boundaries of a solution you can explain.

For a focused stateful exercise, retrying job queue asks you to preserve FIFO order while fencing stale attempts and handling cancellation. Reviewing a boundary counterexample is another way to check an agent's plausible-looking change.