For the admin

Author a coding challenge. Send it in a click.

Pick from the library or write your own. Add a grading guide and a few questions about the choices the candidate made, then drop them a tokenised link and watch it land.

1

Set the brief

Challenge

Library challenges are shared across the platform. Org-owned ones stay in your team. Either way, you shape the brief, grading guide and questionnaire before it leaves the door.

Challenge

Acme ledger service

Mid · 3h estimated · Ruby · GitHub submission

Build a small double-entry ledger in Ruby. Accounts, transfers, a reliable way to move money between two accounts without losing a penny. Commit the repo and tell us how you'd harden it for production.

Edit brief Grading guide Questionnaire Send to candidate →

2

Watch the activity feed

Timeline

Installed, started, submitted, reviewed. Every event lands in the audit log. Reviewers can answer "when did they actually start, and on which commit?" without a Slack thread.

Jane Candidate installed the Graden App on acme-ledger 09:41

Jane Candidate submitted — commit pinned at a8f3c12 13:11

Graden AI finished the review 13:13

Link lands in the candidate's inbox…

For the candidate

Open the link, do the work, submit the commit.

No account, no countdown timer. They see what's expected, install the Graden App on the single repo they're submitting, and explain the choices they made in their own words.

1

Welcome page sets expectations

Kick-off

No countdown timer. They read the brief, install the Graden App on the repo they want to submit (read-only, per-repo, revocable), and click Start when they're ready. That's when we note their start time.

Ready to begin, Jane?

Acme has sent you a take-home challenge. No countdown timer, we just note when you click Start.

Read the brief.
Install the Graden App on the repo you'll submit (read-only, just that repo).
Answer a few short questions about the choices you made.

I'm ready, start the challenge →

2

Answer the questions on your choices

Free-text

Short prompts in the candidate's own words. A strong signal against AI-drafted submissions. We cross-check the stated rationale against what the code actually does.

One last step

Answer in your own words so Acme can see the choices behind your code.

How did you make a transfer atomic between two accounts, and what trade-offs did you accept?

I wrap the withdraw and deposit in a single database transaction and lock both accounts in a deterministic order to avoid deadlocks. I accepted a small hit on throughput for stronger guarantees…

Which part of your implementation are you least sure about?

The retry path. I raise on a failed transfer and let the caller decide, but I haven't proven it's safe to retry the same request twice without double-booking…

AI review runs in the background…

For the reviewer

Open a review that's already prepared.

By the time the reviewer sits down, Claude has drafted scores and talking points against the grading guide, and pinned each one to a file and line. The reviewer reads the code themselves, agrees or overrules, adds their own notes, and walks into the interview prepared. Scores are inputs to judgement, not verdicts.

1

Scores, summary, talking points

AI review

Calibrated scores against every grading criterion, a short plain-English summary, and a list of talking points tagged by file and severity.

Correctness

78/100

Concurrency

62/100

Tests

85/100

Solid small ledger. Domain modelling is clear, the transfer API is well-named, and the spec suite covers the happy paths and a few sharp edges. The weakest spot is concurrency: the transfer isn't wrapped in a transaction, so a crash between withdraw and deposit would leave accounts out of step.

Spec suite is properly scoped. transfer_service_spec.rb covers overdraft, self-transfer and zero-amount cases, which most mid candidates skip. transfer_service_spec.rb:14-48 · tests

Withdraw and deposit run outside a surrounding transaction. A crash between the two lines leaves the ledger unbalanced. The candidate called this out in their answers, so ask how they'd fix it. transfer_service.rb:40-41 · concurrency safety

2

Read the candidate's own words

Q&A

The questionnaire answers sit alongside the AI review. Where the stated rationale contradicts the code itself, the AI flags it as an integrity talking point.

How did you make a transfer atomic between two accounts, and what trade-offs did you accept?

I wrap the withdraw and deposit in a single database transaction and lock both accounts in a deterministic order to avoid deadlocks. I accepted a small hit on throughput for stronger guarantees, which felt right for a ledger.

Which part of your implementation are you least sure about?

The retry path. I raise on a failed transfer and let the caller decide, but I haven't proven it's safe to retry the same request twice without double-booking. An idempotency key would be the next step.

3

Read the code yourself

Source

Every talking point links to the exact place it's scoring. For code you get a source viewer pinned to the commit, with tree, syntax highlighting and line-anchored reviewer notes. Non-code deliverables land in the same pane with the same flag, agree and note controls. The AI draft is a head-start, not the verdict.

acme-ledger @ a8f3c12

app/
services/
transfer_service.rb
models/
account.rb
transfer.rb
spec/
transfer_service_spec.rb

transfer_service.rb

38  def call(from:, to:, amount:)
39    from.lock!
40    from.withdraw(amount)
41    to.deposit(amount)   # ← no surrounding transaction
42  end

Reviewer note — Agreed with the AI here. Worth asking how they'd make this atomic.

transfer_service.rb:40-41 · added by Priya

Reviewer walks into the interview prepared.

See Graden in action: an engineering take-home, prepared for the reviewer.