Deliveroo Interview Guide (2026)

1Snapshot, read this first#

The one thing to understand about Deliveroo: this is a product engineering company, not a LeetCode gauntlet.

• They care whether you can ship a correct, tested, well-reasoned service, not whether you can reverse a binary tree under pressure.
• Every round is run by an engineer who could end up being your teammate.
• They grade the way they would grade a pull request: is this correct, is it tested, would I trust this person to own a service.
• Treat every round like a code review, because that is literally what it is.

2Getting the call (the part most guides skip)#

Where the hiring happens.

• Heavy in London (their HQ), a large engineering hub in Hyderabad, plus smaller teams in other EU cities.
• Cold applications do get read, but a referral roughly doubles your odds of a first look and clears the ATS filter faster.

How people actually get shortlisted.

• Referral. Find a Deliveroo engineer on LinkedIn, send a short specific note ("I built X, I saw your team owns Y, would you refer me?"). Name the team and the thing you shipped. A generic "please refer me" gets ignored.
• Resume that matches the stack. Backend is mostly Go and Ruby, some Kotlin and Scala, on AWS with Kafka, PostgreSQL, Redis. Frontend is React/TypeScript. If you have shipped in these, say so in the top third of the page, because that third is all a recruiter reads before deciding.
• Quantified bullets. Recruiters and the ATS skim for impact plus scale. A bullet with no number reads as a task you were assigned, not an outcome you owned.

Weak: "Worked on backend services for the ordering team."

Strong: "Rebuilt the order-assignment service in Go, cut p99 latency from 420ms to 90ms and handled 3x peak dinner-rush traffic with zero incidents over 6 months."

Why the strong one wins.

• Numbers, the language (p99, peak, incidents), and ownership.
• It quietly seeds ATS keywords: Go, latency, traffic, service.
• Every bullet should answer: what changed, by how much, and did it hold up in production.

Keywords worth having somewhere real: distributed systems, microservices, REST, Kafka/event-driven, PostgreSQL, Redis, AWS, observability, CI/CD, testing. Put each one inside a true sentence, not a keyword-stuffed blob.

3The loop at a glance#

How the loop shifts by level.

• Senior and Staff loops add weight to architecture and behavioural, sometimes a second deeper technical talk about a system you have owned.
• Junior loops lean harder on the coding and fundamentals.
• The question moves from "can you code this cleanly" at L3/L4 to "can you own a system and the people around it" at L5 and up.

4The coding or technical rounds#

The HackerRank screen#

What backend candidates get in ~90 minutes.

• 15 multiple-choice questions (testing, microservices, REST, system basics).
• One algorithms / data-structures problem.
• One "build a small REST API" problem.
• Full-stack folks typically get a React challenge plus an API challenge and pick the order.

Budget the clock before you start.

• MCQs: 10 minutes.
• DS&A problem: 25 minutes.
• Everything left goes to the REST API, because that is the part that actually filters people.

Difficulty. Medium, occasionally medium-hard. This is not a FAANG hard-DP screen.

• The DS&A problem is doable if you are comfortable with hash maps, two pointers, sorting, intervals, simple graph/BFS, and string processing.
• The REST API is the real filter: can you model resources, handle input, return correct status codes (201 on create, 404 on missing, 400 on bad input, not 200 for everything), and keep the code clean under a clock.

The patterns they reuse.

• Frequency counting and grouping with hash maps.
• Interval merging and scheduling (think delivery time windows).
• Simple graph traversal (BFS/DFS) framed as a delivery or routing problem.
• Parsing and transforming structured input (orders, menus, logs).
• Stateful REST endpoints where you maintain and query an in-memory collection across requests.

How to prep for it.

• Do 40 to 60 LeetCode mediums across arrays, hash maps, two pointers, intervals, graphs, and strings.
• Then the part people skip: practice building a tiny REST API from scratch in your language in under 30 minutes. Routes, a data model, validation, correct responses, one happy path and one error path.
• That muscle wins this screen. If you have to look up how to define a route mid-test, you have already lost the time.

The pairing / coding round (the one that matters)#

The shape of it.

• Often you walk through a home task or a prior solution for 10 to 15 minutes.
• Then the interviewer gives you 2 to 3 live extensions: "Now support cancellations." "Now the input can arrive out of order." "Now two riders can be assigned the same order, handle the race."
• You code it with them watching. They are reading your process as much as your output.

How to actually win.

• Clarify first. Before a line of code, restate the problem and ask about edge cases. "Can orders be empty? Can IDs repeat? Should this be idempotent if I get the same request twice?" This alone separates seniors from juniors, because it shows you think about failure before the happy path.
• Narrate. Say what you are checking out loud: does the dataset fit in memory, does this stay O(n). The interviewer cannot read your mind, and silence reads as "does not collaborate." Talk through the approach before you type, then talk through what you type.
• State complexity unprompted. "This is O(n log n) because of the sort, O(n) space." Every time. If you could do better and chose not to, say why: "I could bucket this to O(n) but n is small and the sort is clearer."
• Write a test before they ask. Even one assertion. Deliveroo cares about testing more than most companies at this stage. Reaching for a test case by reflex is one of the strongest signals you can send. Cover the happy path, then one edge case.
• Keep it simple. The most common senior mistake is building a framework when they asked for a function: config objects, strategy patterns, premature interfaces. Solve the task in the simplest correct way, then say "if this grew, here is how I would extend it." Describing the abstraction beats building it.

5System design: the architecture round#

The setup. Sixty minutes, usually a product brief rather than an abstract "design Twitter." Expect something Deliveroo-shaped: a real-time logistics or payments problem you could plausibly meet on the job.

Classic prompts in this family.

• Design the order-assignment system that matches a new order to the best available rider.
• Design restaurant menu storage and serving at scale with frequent updates.
• Design a notification/ETA system that pushes live delivery updates to customers.
• Design a surge-pricing or delivery-fee service.
• Design a rate limiter or an idempotent payment-processing flow (the fintech side shows up here).

A framework that lands well.

1. Scope and requirements (5 min). Functional first ("match order to rider, show ETA"), then non-functional (scale, latency, consistency). Ask about traffic. Deliveroo has sharp dinner-rush peaks, roughly a 5x to 10x spike between 6pm and 9pm, so mention it. It shows you understand the business, not just the diagram.
2. Estimate. Rough QPS, read/write ratio, data size. Keep it quick: "say 2M orders a day, peak maybe 10x the trough, reads dominate writes 20 to 1 because customers refresh the map."
3. API and data model. Define the few key endpoints and tables/events. This grounds everything that follows and stops you hand-waving.
4. High-level architecture. Draw the services, the queue (Kafka shows up a lot here), the datastore (Postgres), the cache (Redis). Event-driven thinking scores well at Deliveroo because that is how their platform actually works.
5. Deep-dive where they push. Usually one area: consistency of assignment, handling rider cancellations, hot partitions at peak, exactly-once vs at-least-once on payments.
6. Production realities. Monitoring, failure modes, retries, idempotency, what breaks at 10x. This is where seniors earn the level. Name the metric you would alert on and the first thing that falls over under load.

Tradeoff reasoning beats the diagram.

• When you pick at-least-once delivery plus idempotency keys over exactly-once, say why: exactly-once across a distributed system is expensive and fragile, idempotency keys are cheap, boring, and survive retries. That one sentence is worth more than a perfect box diagram.
• Same with consistency: strong consistency for payment capture, eventual consistency for the ETA on the map. Say which and why.

For L3/L4 this round is lighter and may blend with fundamentals. Know these cold:

• How a database index works and when it stops helping.
• ACID vs eventual consistency.
• What a deadlock is and how two transactions cause one.
• HTTP status codes, process vs thread.
• A shaky answer on an index at L4 reads worse than a messy design.

6Behavioural and culture fit#

The values (from their own careers site), roughly: Customer obsession, Build trust, Think big, Celebrate difference, Succeed as a team, Deliver results. The behavioural round maps directly to these.

What they ask. Why Deliveroo, your strengths and weaknesses, a hard tradeoff you made, a conflict, a time you owned a failure.

How to prep the stories.

• Prepare 5 to 6 STAR stories and tag each to a value, so "a time you had to make a tough call" already has a story attached.
• Have at least one real failure story where you take responsibility. No deflection, no "my only weakness is caring too much."
• They can smell a sanitized answer from the first sentence.

A full worked STAR example (tag: Deliver results + Build trust):

• Situation: Our checkout service was timing out during peak hours, and about 4% of orders were failing at payment.
• Task: I owned the payment integration and had to stop the bleeding without a risky rewrite the week before a big promo.
• Action: I traced it to synchronous calls to the payment provider with no timeout budget, so one slow upstream call was stacking up requests and tipping the whole service over. I added idempotency keys, moved the capture step to an async queue with retries, set a tight timeout plus circuit breaker, and shipped it behind a feature flag so I could roll out to 5% first and watch the numbers. I wrote integration tests for the retry path and walked the team through the design before merging.
• Result: Payment failure rate dropped from 4% to 0.3%, we cleared the promo weekend with zero payment incidents, and the async pattern got adopted by two other teams.

Why that shape works.

• A number in the result, a tradeoff ("without a risky rewrite"), a staged rollout, and collaboration ("walked the team through it").
• The failure story follows the same shape. You just end it with what you learned and what you changed so it would not happen again.

On "why Deliveroo," have one real answer ready.

• The real-time assignment problem, the payments and fintech complexity, the scale of the rider network at peak.
• Any of those shows you looked at the engineering. "I love food delivery" shows you did not.

7Your prep plan#

4 weeks.

• Week 1: 25 to 30 LeetCode mediums across arrays, hash maps, two pointers, intervals, strings. Build one small REST API end to end with tests.
• Week 2: Graphs/BFS/DFS, more intervals, another REST API from scratch under 30 min. Start a system-design primer.
• Week 3: Do 4 to 5 full architecture designs out loud (order assignment, ETA, rate limiter, payments, menu serving). Record yourself and listen back for where you went quiet or hand-waved.
• Week 4: Write 6 STAR stories tagged to values. Two timed mock pairing sessions with a friend who interrupts you with extensions. Review your weak DS&A areas.

2 weeks.

• Days 1 to 5: 20 targeted mediums plus one REST API build on alternate days.
• Days 6 to 9: 3 system-design walkthroughs, learn the Kafka/Redis/Postgres tradeoffs (when to reach for each, and what each one costs you).
• Days 10 to 14: STAR stories, two mocks, read Deliveroo's engineering blog so your "why Deliveroo" is specific.

2-day crash.

• Day 1 AM: 10 mediums (hash maps, intervals, graphs). PM: build one REST API from scratch, write tests.
• Day 2 AM: two system designs out loud (order assignment + payments idempotency). PM: 5 STAR stories, memorize the six values, prep your "why Deliveroo."

8Why people get rejected at Deliveroo#

1. Coding in silence. The pairing round is a collaboration test first and a coding test second. No narration, no clear signal, likely no. Even a correct solution built in silence often fails here.
2. No tests, ever. They weight testing heavily. If you never reach for an assertion across a 60-minute pairing round, you look junior regardless of the level on the req.
3. Over-engineering the simple task. Building abstractions nobody asked for in a 30-minute extension. Solve the problem in front of you, then describe the bigger version in words.
4. Hand-wavy scaling. "I'd add a cache and it scales" with no reasoning about consistency, invalidation, or what happens when the cache is cold at peak. Seniors must name the failure mode.
5. Generic "why Deliveroo." Saying you love food delivery. Say something about the real-time logistics problem or the fintech/payments complexity. Show you understand the actual engineering, not the consumer app.
6. No ownership in stories. Blaming teammates or a vague "we" with no personal action and no number. Their values are built on ownership and trust, and a story with no "I" fails both.

Every round grades one question: would I trust this person to own a service and the people around it.

9The offer, comp and negotiation#

Rough 2026 total comp (base + RSUs + bonus), London.

• L3 (SWE1): ~£62-75k total, mostly base.
• L4 (SWE2): ~£80-95k base, ~£90-110k total.
• L5 (Senior): ~£95-120k base, ~£120-150k total with equity.
• L6 (Staff): ~£130k+ base, ~£160-200k+ total.

India (Hyderabad), rough.

• SWE2 around ₹25-40L total, Senior around ₹45-70L total.
• Teams and bands vary a lot, so treat these as ranges, not promises.
• Where you land in a band usually tracks the strength of your architecture and behavioural rounds, not the coding screen.

Negotiation tips specific to Deliveroo.

1. Push on base and level, not just equity. As a listed company the RSU grant is real, but the base band is where you have the most room. Ask explicitly which level the offer is pitched at and whether a higher band is possible given your scope. Getting bumped from L4 to L5 moves far more money than haggling over a few shares.
2. Use a competing offer honestly. A real competing number moves things here more than a vague "I have other options." If you have one, share the actual figure. If you do not, do not bluff one, recruiters talk to each other.
3. Negotiate the sign-on if base is capped. When the band is firm, a one-time sign-on bonus is often the lever a recruiter can actually pull without re-approving the whole offer. Ask for it by name and give a number.

10FAQ#

Want this turned into a dated, week-by-week plan around your actual interview date? Map your timeline backward from loop day and give each week one clear focus, and you will walk in calm instead of cramming.