Revolut Build It Interview Round: What It Is & How to Pass

Last updated: August 2026

Quick Answer

The “build it” round is what candidates call Revolut’s take-home build task and the walkthrough that follows: a small, practical fintech problem, typically 4-8 hours of work with a 5-7 day deadline, then a 45-60 minute session defending your submission to a senior engineer. Revolut does not publish this round name, but the stage is real and eliminates more candidates than any other. Rehearse the walkthrough in OphyAI Coding Interview.

Element	What it looks like
Task	Build a small service or solve a practical problem end to end
Effort	Commonly 4-8 hours, 5-7 day deadline
Deliverables	Code, tests, a README, design reasoning
Follow-up	A 45-60 minute walkthrough with a senior engineer
Where it sits	After the recruiter screen, before later technical rounds

What Revolut Is Testing in This Round

Revolut is testing whether the code you write unsupervised is code it could run in production. That is narrower than “can you program”, and it explains why strong algorithmic candidates fail here.

Four things carry the score. Correctness under real conditions: money in integer minor units, concurrency handled deliberately, errors handled rather than swallowed. Structure: separation of concerns, so a reviewer finds the business logic without reading everything. Tests: assertions on the interesting cases, not a smoke test for the happy path. Communication: a README saying what you built, what you left out, and why.

The walkthrough then checks that you own the decisions. Revolut’s hiring approach, open-sourced with QuantumLight, leans on structured problem-solving where candidates get no data unless they ask. The same applies here: an underspecified brief is a test, and a clarifying question is a legitimate move. Our Revolut hiring playbook analysis covers that rubric.

What to Expect

The brief arrives by email after the recruiter screen, usually with a five to seven day deadline. The task is practical rather than clever: a transaction processor, a currency conversion service, a small ledger, or a data pipeline. Engineering briefs commonly bundle two or three sequential tasks so later requirements stress the design you chose for the first one.

Non-engineering tracks get the same stage in a different medium: a proposal with metrics for product, an analysis for data, a risk assessment for compliance. The follow-up is always the same: a senior person asks why.

The walkthrough is 45-60 minutes on video. Expect the interviewer to pick one part of your submission and go deep: why this architecture, what happens when the downstream provider times out, where the money is at this instant. Interviewers commonly push a design until it breaks, which is a probe rather than a verdict.

Example Questions and How to Answer Them

“Why did you structure it this way?” Answer with the constraint that drove the choice, not a preference. “I put the FX conversion behind an interface because the rate source was most likely to change” is a decision. “I like hexagonal architecture” is not.

“What did you leave out, and why?” Show the omission was deliberate: no persistence because the brief did not require durability, no auth because it was out of scope, retries left as a TODO with the design in the README. Silent gaps read as unfinished.

“How would this behave at 10x the volume?” Name the bottleneck, the fix, and the cost of the fix. If your processor is single-threaded, say where you would partition and what breaks about ordering.

“What happens if the same request arrives twice?” This is the fintech question. Answer with idempotency: the key, where it is stored, how long it lives, and what the second request returns. If your submission did not handle it, say what you would add.

“How did you test it, and what would you do with another day?” Walk through one meaningful test and one case you chose not to cover, then answer the follow-up specifically: property-based tests for the rounding rules, a reconciliation script, structured logging on the failure path.

How to Prepare in 3 Days

Day 1: build a reference submission. Take a fintech brief (a currency conversion API or a transaction ledger) and build it end to end under a four-hour timer, with tests and a README. The point is to find where you run out of time, which is nearly always the tests.

Day 2: stress your own design. Write down what breaks with duplicate messages, a provider timeout, a partial failure mid-transfer, and concurrent updates to one balance. Fix what is cheap, document what is not.

Day 3: rehearse the walkthrough out loud. Present your submission in ten minutes, then answer the questions above without notes. Use OphyAI Coding Interview to pressure-test the design and find the step your explanation skips, then present again unassisted. Start practicing →

Common Mistakes

Shipping without tests. The most common rejection reason here. Untested code signals what your first month looks like.

Gold-plating the wrong thing. A polished front end on a task about correctness spends hours where no points are available.

Floating point for money. Use integer minor units. Reviewers read this as a proxy for financial systems experience.

No README. Reviewers read it first. Without it your design decisions are invisible and deliberate omissions look like gaps.

Treating the walkthrough as a demo. Rehearse defending decisions, not describing features.

Related Guides

• Revolut interview guide (the hub)
• Revolut software engineer interview
• Revolut system design interview
• Revolut skills interview

Frequently Asked Questions

Is “build it” an official Revolut interview round?

No. Revolut publishes its hiring stages but does not use “build it” as a round name. Candidates use the phrase for the take-home build task and the walkthrough that follows, which is a real and heavily weighted stage. Recruiters call it the take-home task or the technical assessment, so ask about “the take-home and its review” to avoid confusion.

How long should the Revolut take-home task actually take?

Candidate reports consistently describe roughly four to eight hours of genuine work inside a five to seven day window. Revolut has not published a time limit, so treat those as typical rather than official. Budget the hours before you accept the brief: a rushed submission fails on exactly the dimensions reviewers weight most heavily, which are tests, error handling and documentation.

What happens if I cannot finish every part of the task?

Finish a smaller thing completely rather than starting everything. Reviewers respond well to a submission that implements the core requirement, tests it, and uses the README to describe what comes next. An unfinished feature with no tests reads as an unfinished engineer; a scoped submission with explicit trade-offs reads as someone who has shipped before.

Can I use AI tools to write the Revolut take-home?

Revolut has not published a policy we could verify, and rules differ by employer and role, so ask your recruiter and follow what they say. The walkthrough is unchanged either way: you defend every decision under questioning. Use Interview Practice and Interview Copilot to rehearse that defence, and never submit code you cannot explain.

Sources and verification notes

Last reviewed August 2026. Revolut publishes its hiring philosophy but not the brief, rubric or time limit, so the effort ranges and scoring dimensions here describe what candidates consistently report. Direct fetches of first-party pages were blocked in the environment this post was written in.

• Revolut Careers, Engineering: official role descriptions and hiring stage language.
• QuantumLight and Revolut hiring playbook announcement: the structured interview framework, scorecards, and the problem-solving stage where candidates receive no data unless they ask.
• InterviewQuery, Revolut Software Engineer interview guide: reported take-home content, deliverables and the architecture review that follows.
• Glassdoor, Revolut interview reports: candidate-reported task types, effort and deadlines. Self-selected, so read for pattern.