Assess your candidates' opencode skills on real repositories
Run opencode assessments in CodeSubmit IDE, locally over Git, or live in CodePair so your team can see how candidates plan changes, edit files, and test.
>Inspect the webhook retry handler and patch duplicate event processing.
Traced retry logic and patched idempotency check
Reviewed diff and ran test suite
All test checks passed
What to evaluate
Habits that show real judgment with opencode
Watching a terminal session reveals whether an engineer steers opencode deliberately or accepts the first generated patch without checking how the repository actually works.
Inspecting before editing files
Strong candidates use read-only planning in opencode to trace existing data flow before asking the agent to modify any source files.
Auditing terminal diffs carefully
Rather than accepting every generated edit, deliberate engineers read the terminal diff and reject changes that touch unrelated modules or weaken types.
Recovering from incomplete patches
When a model call returns a flawed patch, experienced developers narrow the prompt with compiler output or edit the file directly.
Verifying tests and explaining tradeoffs
Candidates run the repository test suite and linters from the workspace, then explain their architectural choices and remaining tradeoffs live or in writing.
How it runs
Run opencode in CodeSubmit IDE, Git, or CodePair
Assign a repository take-home in CodeSubmit IDE or over local Git, or use the CodePair browser workspace for live interviews with opencode.
Configure the repository task
Pick an open-ended task or upload your own repository, then choose CodeSubmit IDE with a per-candidate AI budget, local Git, or live CodePair.
Candidate plans and builds
In CodeSubmit IDE, opencode runs in a recorded, budget-capped workspace, or the candidate works locally over Git or live in CodePair.
- CodeSubmit IDE
- Git
- CodePair
Review the shipped evidence
Hiring managers inspect the working software, commits, tests, notes, recorded session, usage summary, and AI review, or open submissions in CodePair.
opencode assessment tasks
Repository tasks built for terminal agent workflows
Assign open-ended engineering problems where candidates inspect an existing service with opencode, ship a working change, and prove that existing behavior still holds.
Idempotent webhook retry handler for LedgerPulse
Duplicate payment webhooks from upstream gateways are creating double ledger entries during network retries. Update the ingestion handler so retried events remain idempotent.
Preserve existing database migrations and keep webhook response latency stable.
Timezone shift bug in Dockline
Carrier dispatch windows shift by one hour across daylight saving transitions. Fix the regional slot calculator and add regression tests for boundary dates.
Do not alter the public REST response schema for active carriers.
Scoped export permissions in MetricHarbor
Workspace viewers can trigger full CSV exports through the batch endpoint. Restrict export creation to analysts and admins while preserving shared download links.
Maintain existing middleware order and pass all role authorization integration checks.
What reviewers see
Every diff, test run, and tradeoff
Reviewers evaluate the finished software and the engineering choices behind it, with full access to the repository diff, test output, and candidate write-up.
Diffs and commits
Inspect the working software, file-by-file diffs, and commit history to see how the candidate scoped and verified each change.
Tests and notes
Read the test results alongside the candidate's written notes explaining their implementation approach, edge cases handled, and architectural tradeoffs.
AI review summary
Use the AI review to inspect repository structure, testing gaps, and follow-up prompts before opening the submission live in CodePair.
Why real tasks beat algorithm brainteasers
Timed algorithm brainteasers measure whether a candidate memorized a trick, which tells you very little about how they build software with opencode. In production, engineers read unfamiliar repositories, trace bugs across modules, steer terminal agents through scoped patches, and verify that their changes pass existing test suites without breaking adjacent features.
Giving candidates a realistic repository in CodeSubmit IDE, a local Git take-home, or live in CodePair lets you observe the judgment that actually matters on your team. You see how they inspect code before editing, how they recover when an agent patch falls short, and whether they can explain their tradeoffs clearly during review.
Frequently asked questions
- Can candidates use opencode in live coding interviews on CodeSubmit?
- Yes. CodeSubmit includes opencode as a harness inside the CodePair browser workspace. Candidates and interviewers share the same editor and terminal session, so you can watch how they inspect the repository, prompt the agent, review diffs, and run tests in real time.
- How do we assess developers using opencode in take-home projects?
- Assign an open-ended task in CodeSubmit IDE, where opencode runs in a recorded workspace with a per-candidate AI budget, or over local Git. Reviewers inspect the software, commits, tests, notes, and usage summary, then debrief in CodePair.
- What separates strong opencode skills from blind prompt copying in interviews?
- Deliberate engineers inspect the codebase before editing, keep prompts scoped to specific modules, and audit terminal diffs line by line. When a generated patch fails a check, they use test output or direct edits to fix the root cause and explain their tradeoffs.
- Can we use our own codebase for an opencode technical test?
- Yes. Bring your own repository or customize a library task for a take-home in CodeSubmit IDE with budgeted AI credits, a local Git take-home, a short coding screen, or a live CodePair interview with opencode.
Test opencode skills on real repositories
Start a free trial to run CodeSubmit IDE take-homes, Git assessments, or live CodePair sessions that show how candidates build and verify software.