Critical review of AI output
ExceptionalThe candidate caught a bug in the AI's fix1 and proved the fix with the race tests2 before committing.
Technical assessments for AI-assisted engineering
Everyone says they code with AI. Test who can actually ship with it.
Candidates build in a real repository with an AI assistant. You get a verdict where every claim is cited, like a footnote, to the moment it happened.
In the candidate's session
AIDone.
defer lease.Release(ctx) now releases the lease on every return path.1CandidateThis still passes the request ctx to Release. If the client cancelled, Release fails and the lock waits out the 30s TTL. Give it its own short-lived context.
00:08:20 $ go test -race ./...
2ok checkout 1.31s · no data races
2ok checkout 1.31s · no data races
In your report
How a finding is cited
- 1
The candidate asks the AI for a fix
They describe the problem and the approach they want.
- 2
The AI misses an edge case
Like any coding assistant, it gets most of it right. The miss would pass a quick review.
- 3
The candidate spots it and checks the fix
They explain the problem, have the AI correct it, and run the tests.
- 4
The report links to each moment
Prompt, change, test run and commit, each with a timestamp.
ctx is the request's context. Once the client cancels, Release fails and the lock stays held for the full 30s lease.
What the report judges
Every report ends in a plain verdict on whether you can trust the candidate's code: Yes, Needs a check, or No.
- Verdict. Trusted to merge, with the reasons in one line.
- Checks. Any failed check means No.
- Ratings. Nine dimensions, each with its reason.
- Hidden tests. Tests the candidate never saw.
Candidates get a real repo and the tools they use at work
A realistic task with a time limit you set. Nothing about it feels like a quiz.
- Nothing to install. A link opens a browser IDE with an editor, terminal, git and an AI assistant.
- AI is allowed. They use the built-in assistant the way they would at work.
- Questions get answers. "Ask the team" answers questions about the requirements, the way your team would.
- A short debrief. After submitting, they answer four questions about their own work.
Live coding tests recall. Take-homes hide the process.
Ban AI and you test a workflow nobody uses. Allow it unobserved and you can't tell who understood the code.
| Live coding / LeetCode | Take-home project | RavelCode | |
|---|---|---|---|
| AI use | Banned | Allowed, but unseen | Built in, every prompt recorded |
| What you learn | Algorithm recall under pressure | The finished repo, not how it was built | How they steer AI, verify and debug |
| Bad AI output | Not tested | Invisible if it happens to work | Visible in the session and hidden tests |
| Engineer time | An interviewer per candidate | A reviewer reads every repo | Review a cited report |
Frequently asked questions
Who is RavelCode for?
Teams hiring engineers who work with an AI assistant every day. Engineering leads review a cited report instead of sitting in every first-round interview, and hiring managers can explain each decision with what the candidate actually did.
What does a RavelCode assessment test?
How well an engineer ships working code with an AI assistant: how they steer it, whether they check its output, and whether the result passes tests they never saw.
Can candidates paste answers from ChatGPT?
They don't need to. An AI assistant is built into the IDE, and its conversation is part of the record. Pastes into the editor are recorded too, and hidden tests check whether the code actually works.
Can we use our own codebase?
Yes. Bring a slice of your own code instead of a template or a generated repository.
Does the AI give wrong answers on purpose?
No. It's a normal coding assistant, and like any AI it is sometimes wrong. Separately, each repository is built like real work, with the kind of misleading details real codebases have. Careful engineers notice them.
How do you stop the report from making things up?
Every finding must cite a real session event: a prompt, a file change, a test run or a commit. Findings whose citation doesn't match a real event are rejected.
What is recorded about the candidate?
Only what happens inside the assessment: AI conversation, code changes, commits and terminal commands. Nothing on their own machine is accessed.
How do we get started?
Register, create a job, pick or generate an assessment, and invite candidates by email or link.
See how your candidates really work with AI.
Register, pick an assessment and send candidates a link. Every finding in the report links back to the session.