The short answer
A coding test for hiring is a short programming task that candidates complete before a live interview, so you only spend interview time on people who can write working code. A good one looks like the job: reading existing code, fixing a bug or extending a feature, and running tests. The Revvox coding round does this in the browser: candidates open a link, work on a small multi-file TypeScript service, run the tests in a sandbox, and submit. Your team sees every run and the result of hidden tests on the final code. It is in early access.
What a coding test should measure
Most engineering work is changing code that already exists. A test built from algorithm puzzles mostly measures practice with puzzles, which favours people with time to grind and can screen out experienced engineers who do not. A test built from a small, realistic codebase measures what the job needs: reading unfamiliar code, finding the right place to change, making the change safely and checking it with tests.
- Can they read code they did not write and find their way around it?
- Do they run the tests, read the failures and use them?
- Is the change correct on cases they were not shown?
- Is the code they hand in something a teammate could review and merge?
Example coding round tasks
The kind of task a realistic coding round uses, written by us. Two of these shapes are in our library today; the rest show how to write your own.
- A refund function in a billing service pays back more than was charged. Find and fix it.Reading the existing code, writing or running a test that shows the bug, and a fix that does not break other cases.
- An orders API returns every order at once. Add paging without breaking existing clients.A backwards-compatible change, sensible defaults and limits, and tests for the first and last page.
- A date-range filter drops records on the last day of the month. Fix it.Boundary handling and time zones, checked with a test on the edge case.
- Add input validation to an endpoint that accepts user profiles.Clear errors, no crash on bad input, and the happy path still working.
- A function is correct but too slow on large inputs. Make it fast enough.Finding the costly part, a better approach, and tests still passing.
Timed, take-home or live: which format
Many teams combine them: a short timed task on realistic code to narrow the list, then a live round with an engineer for the few who pass. The timed task should be short enough that good candidates do not drop out, which usually means under 90 minutes in total.
| Format | Good for | Watch out for |
|---|---|---|
| Timed online task | Screening many candidates fairly, with the same task and time for each | Puzzle-style tasks that test recall more than work |
| Take-home project | Seeing design and code quality on a larger task | Days of unpaid work; strong candidates often decline |
| Live coding interview | Hearing how someone thinks and takes hints | Costs an engineer's hour per candidate; nerves skew results |
How to design a fair coding round
- Start from your own work. Pick a bug or a small feature like the ones your team handles every week, in a codebase small enough to read in ten minutes.
- Write tests the candidate can run. Visible tests show them what done looks like. Keep a second set hidden to check the final code on cases they were not shown.
- Set a time that fits the task. Time your own engineers doing it, then allow more. A rushed task measures speed, not skill.
- Give everyone the same conditions. Same task shape, same time, same instructions. Vary the details per candidate so answers cannot be passed around.
- Decide what passing means before you look. Agree the bar first, so the result does not depend on who reviews it.
How the Revvox coding round works
The coding round is part of Revvox Dial, and sits between Vira's phone screen and the final interview. It is in early access, set up with each company by a founder.
- Candidates open a private link: no account and nothing to install. They see the company, the role, the tasks and the time allowed, and give consent before anything is recorded.
- They work in a browser editor with a file tree, tabs and TypeScript highlighting, on a small multi-file service on Node.js.
- They run the tests in an isolated sandbox as often as they like. The timer is kept on our server, so a reload costs nothing.
- When they submit, or at the time limit, hidden tests they never saw run on the final code.
- Your team sees each run: when, how many tests passed, how long it took and the failures, next to the phone-screen report.
- Each candidate gets their own variant of the task, with a different planted bug and different numbers.
- Today's library: a billing service whose refunds pay back too much (45 minutes, fix a bug) and an orders API that needs paging (60 minutes, extend a feature). Pick one or two tasks per role, up to 90 minutes in all.
What is not built yet
- Invites by WhatsApp and email: today you share the candidate's link yourself.
- Other languages: tasks run in TypeScript on Node.js today.
- Vira in the room, talking the candidate through the task by voice.
- A marked report scoring skills against a written rubric. Today your team sees the test results and every run, and decides.