How to Practise: A 45-Minute Checklist

Ananya had read every building-block chapter twice. In her first mock, for a food delivery app, she asked twelve questions, worked out five years of storage, and drew her first box at minute 19. The feedback was one line: 'Good ideas, but we never saw a design.' She knew enough. What she lacked was practice at using it against a clock, with someone asking 'why?' after every box. This chapter closes that gap.

Companies ask for a design because the decisions that cost most to undo, such as the storage choice, the data model and how services talk, are design decisions. A vague prompt also shows how you handle a problem with no specification, like every real project in its first week. The bar rises with experience:

At every level, three things are graded: structure, trade-offs and communication. A tidy design you can defend beats a clever one you cannot explain. It also rewards preparation: the same dozen building blocks appear in almost every prompt, so each new question rearranges parts you already know.

Many hiring loops include more than one design round, and each tests something different. Ask the recruiter which one you have, or read the prompt: boxes, numbers and failures mean high-level design; classes and method names mean low-level design; a working program by a deadline means machine coding.

This course prepares you for the first round only. Prepare for low-level design and machine coding separately, in code. Some habits carry over: asking before designing, naming the entities, the data models and state machines from the product chapters, and cutting scope before you start.

A 45-minute slot loses about 5 minutes to introductions and to your own questions at the end, which leaves about 40 minutes to design. Here are the six steps of those 40 minutes, each with what you need before you move on.

The deep dive gets the largest share because that is where strong answers stand out. In a 60-minute slot you get about 50 minutes to design: requirements 0–6, estimates 6–10, API and data model 10–16, high-level design 16–28, deep dive 28–46 and wrap-up 46–50. Spend the extra time on a second deep dive or a failure walk-through, not on more questions.

Step 1 decides everything after it, and prompts are vague on purpose: 'Design a food delivery app.' Ask three to five questions whose answers change the design, not fifteen:

When the interviewer has no preference, state an assumption and move on: an assumption they can correct costs seconds, and an open question costs minutes. Write the agreed requirements in a corner of the board, and point back to them each time you choose.

Rounds rarely run to plan, so decide now what you will cut. Two rules hold every time: never skip the requirements, and always save the last three minutes for the wrap-up.

Each move trades detail for time, so the deep dive keeps its 15 minutes.

Silence reads as being stuck, and an unexplained box reads as a guess. Narrate each decision with the fact behind it, ideally a number: "Reads outnumber writes about 100 to 1 here, so I will put a cache in front of the database." Numbers beat adjectives: "about 200 ms at the 99th percentile" can be checked, and "fast" cannot.

Each phrase below does one job. Learn the shape, then use your own words.

The interviewer is not an audience: they nudge you towards the parts they want to see, and each kind of question tests something specific:

Each is answered best with a traced request or a number, not a list of tools.

Strong answers look alike whatever the product, and so do weak ones. The table is both a guide and the rubric for scoring a mock: score each row 0, 1 or 2, where 1 sits between the two columns.

Aim for 14 or more out of 18 with no zeros. The lowest row matters more than the total: carry one fix into the next mock and score again. Notice what earns nothing: naming many technologies.

Here is one round from start to finish, on a prompt no chapter designs: "Design an online exam. A university runs its entrance test for 1 lakh (100,000) students at once: 2 hours, 100 multiple-choice questions." Try the first 8 minutes yourself before reading on.

0–5 · Requirements. "Students log in, get the paper at 10:00, save answers as they go and are scored after the exam closes; teachers upload papers in advance. Out of scope: proctoring video, question writing and payments. What matters most is that no saved answer is ever lost, and that everyone starts at 10:00 sharp. Is the question order shuffled per student? Can a student resume after a dropped connection?" The interviewer says yes to both.

5–8 · Estimates. "1 lakh students open the paper within about 2 minutes: roughly 830 requests a second, call it 1,000. Each saves 100 answers, say 150 with changes, so 1.5 crore (15 million) saves over 7,200 seconds, about 2,000 a second. One relational database can take that. And at 12:00 the clock runs out for everyone at the same moment."

Each number the candidate kept changes a choice: the start rush shapes how the paper is delivered, 2,000 saves a second means one database is enough, and the 12:00 cliff is designed away in the deep dive. Estimate only what decides something.

8–13 · API and data model. "Four calls. GET /exams/{id}/paper returns the encrypted paper. GET /exams/{id}/key answers only from 10:00. PUT /attempts/{id}/answers takes a batch of answers, each with a sequence number. GET /attempts/{id} returns saved answers and the deadline, for resuming. Two main tables: attempts, with the student, deadline and status, and answers, keyed by attempt id and question number, because the main query is all answers for one attempt."

13–22 · High-level design. "The paper is encrypted and pushed to a CDN. Phones download it in the 20 minutes before the start, so at 10:00 they fetch only a small key. Answers go through a load balancer to stateless exam servers, four to six across two zones at about 1,000 requests a second each, then into one relational database with a synchronous replica in the second zone. After 12:00, a batch job scores every attempt."

Notice what is missing: no cache and no queue, because no number so far needs them. Every box on the board answers a requirement or an estimate from the first 8 minutes.

22–37 · Deep dive. The interviewer picks "never lose an answer". "Each answer is written to the phone first, then sent with a sequence number. The database keeps an answer only if its sequence is newer than the stored one, a conditional update, so retries and late arrivals cannot overwrite a newer choice. The phone shows 'saved' only after the server confirms. The server's clock closes the exam: whatever is saved at 12:00, plus a 60-second grace window for answers in flight, counts. Nobody has to press submit, so the 12:00 cliff disappears."

37–40 · Wrap-up. "To sum up: the paper is preloaded and unlocked by a small key, answers are saved on the phone and in a replicated database with sequence numbers, and the server's clock closes the exam. At 10× the first bottleneck is the answers database, which shards by attempt id. The riskiest failure is losing its primary: the replica in the other zone takes over within a minute, while phones keep answers and retry with jitter. Next I would add proctoring and result publishing."

What the candidate skipped matters as much: no storage maths for five years, no list of tools, and no second deep dive started at minute 36.

The recommended path through the course takes six weeks at about 45 minutes a day: every chapter in order, one product per weekday, and timed practice every weekend. If you are just starting, read this chapter now, then come back to it before your first mock.

Before each product chapter, attempt its brief for 15 minutes; afterwards, list what you missed and answer its drill questions aloud. Reading builds knowledge, but timed rounds build the skill. If you fall behind, move a chapter to the weekend or stretch the plan, but never drop the weekend round.

A mock helps only if it feels real: a prompt you have not prepared, a clock, and someone asking "why?". Take turns with a partner preparing for the same interviews.

Five prompts that no chapter designs for you. Open the points only after your mock: each lists three things a strong answer must hit, and the chapters it draws on.

Inside the round, the table in "What strong answers do" is your guide. Outside it, preparation goes wrong in a few predictable ways:

If your mocks never reach the wrap-up, move the last alarm from minute 37 to 35 until they do, then move it back.

Depth comes from real systems and repetition. After the course, keep one of these going each week for a few months.

• Build a small version. Put a cache in front of a toy link shortener, load-test it, and find what breaks first.
• Read postmortems. Match each published incident report to a pattern in Lessons from Real Outages.
• Read the docs of tools you name. Learn how each database or queue you mention replicates and what it guarantees.
• Study the systems around you. Ask how your team's service survives a traffic spike or a dead database, and draw it.
• Teach it. Explain a building block to a friend in five minutes, or play the interviewer in their mock.