What to Expect in the Ocado Technology System Design Interview

Expect a design discussion, reported at both graduate and senior level. Candidates report general purpose design questions rather than warehouse specific ones. Two reported examples are a link shortener service, with follow up questions on performance, scalability, and storage, and a service that receives jobs from people inside an organization and runs them. Interviewers ask about caching repeatedly in the follow up questions, so the round rewards the standard building blocks, explained clearly, rather than knowledge of robotics.

The Question Types

A classic service at scale. The reported link shortener question is a test of the basics: an API, a data store, a cache, and a plan for growth. Expect follow up questions on how storage grows and where the read traffic goes, and give rough numbers for traffic and storage before anyone asks for them.

A task submission and execution service. One reported question asks for a system that accepts jobs from people in an organization and executes them. Candidates report this one at the graduate assessment center. This is the closest reported question to the company's own work, because the platform assigns tasks to robots, to pickers, and to delivery vans, and the walkthrough below covers this question in full.

Caching and performance. Candidates report caching questions inside the design discussion, so be ready to say what you cache, how long you keep it, and how you remove stale entries.

Platform topics worth studying, though not reported as questions. Candidates do not report these, so treat them as preparation rather than prediction. One grocer must never see another grocer's data, which makes isolation between customers a natural topic. The careers pages list Kafka, which is a system for streams of events, so event driven design is sensible study, and the product problems behind the platform are inventory, order flows, and route optimization.

What the Interviewer Grades

Practical judgment counts more than unusual technology, so state the requirements before you draw anything, then estimate the load and size the storage and the traffic. Name each trade-off out loud, including the option you rejected and the reason. Candidates report friendly interviewers who still ask for detail, so defend every choice with a reason rather than a preference.

A Walkthrough: Design a Job Execution Service

Here is a high level plan for the reported question.

1. Requirements (5 minutes). People submit jobs, and each job runs once, may take seconds or hours, and reports its result. Ask about job volume, how long a job may wait, and whether order matters. Confirm whether users across different teams, or different customer companies, must stay separated.

2. The API and the data model. Offer three operations: submit a job, read its status, and cancel it. Store one record per job with its owner, its type, its input, its state, and its timestamps, where the state is queued, running, succeeded, failed, or canceled.

3. The queue and the workers. Put submitted jobs on a queue, which is a list that holds work until a worker takes it. Workers are separate processes that pull one job, run it, and write the result back. Scale by adding workers, because the queue separates how fast work arrives from how fast it is done.

4. Scheduling and fairness. Use several queues for different priorities, so an urgent job does not wait behind a long batch. Limit how many jobs one user or one customer can run at the same time, and explain how a scheduled job becomes a queued job.

5. Failures and retries. A worker can stop in the middle of a job, so use a visibility timeout, which hides a taken job for a period and returns it to the queue if no worker confirms it. That means a job may run twice, so make the work idempotent: running it again produces the same result. Move jobs that keep failing to a separate queue for inspection.

6. Scale and monitoring. Shard the job table by owner so one heavy user cannot slow the rest, and cache status reads, because polling is the heaviest read traffic. Report queue depth, waiting time, and failure rate, since those three numbers show a problem before users complain.

Common Mistakes in This Round

• Drawing before asking. Five minutes of requirements changes the design, and starting with boxes signals a memorized answer.
• No numbers. Scalability questions need estimates, so give the rough load, then the storage, then the number of machines.
• Ignoring failure. Retries, duplicate work, and jobs that always fail are the real content of a queue design.
• Forgetting the tenants. The platform serves competing grocers, so mention isolation between customers before the interviewer does.
• Silent drawing. A correct diagram with no explanation scores poorly, so narrate every decision as you make it.

How to Prepare

• Learn the building blocks. Grokking the System Design Interview covers queues, caches, sharding, and data stores, which every reported question uses.
• Go deeper for senior roles. Advanced System Design Interview, Volume II covers isolation, replication, and failure handling in more depth.
• Rehearse the six steps. Practice the walkthrough above out loud in under 40 minutes, with estimates included.
• See the full loop. This round is part of the Ocado Technology interview process, next to the motivation question and the waits described in how long it takes to hear back.