Boxes first is the mistake

Part of the free System Design course on LogicWiz, in the chapter: How to run a design interview. The interactive whiteboard exercises and simulations run in the app.

Week 1: The design review that went sideways

"I had the whole thing drawn in four minutes. Then Kabir asked one question and I had no answer."

Meera, in her first week at SwiftKart

A system design interview is a conversation with a drawing

"System design" sounds like an exam on a body of facts. It is not. It is a conversation. You and an interviewer build something together on a whiteboard, and the interviewer watches how you decide. The drawing is only the shared notepad.

Meera joined SwiftKart, a quick-commerce app, as an SDE-2. In her first design review, Kabir (her tech lead) said: "Design the order-tracking page." She went straight to the board: app, load balancer, three services, a database, a cache. Four minutes, a tidy diagram. Then Kabir asked: "How many people open this page during the IPL final?" The final of the Indian Premier League is one of the busiest evenings for any Indian app.

She did not know. Worse, she could not say whether her cache was needed. She had never decided what the page had to do, or how fast it had to be.

💡 Tip: An interviewer who sees boxes in the first minute learns one thing about you: you start building before you understand the problem. That is the opposite of what they are hiring for.

The five phases

Every strong design walk-through, in an interview or at work, moves through the same five phases. You do not need to memorise a template; you need to know what question each phase answers.

  1. Requirements: what must it do, and how well? (Next lesson goes deep.)
  2. Estimation: how big is it? Requests per second, storage, bandwidth. (Module 2.)
  3. API and data: what do callers send and get back, and what do we store?
  4. High-level design: the components and how they connect. This is the only phase most people practise.
  5. Deep dive and failure: pick the riskiest part and make it hold up. Think about scale, bottlenecks (the one part that runs out of capacity first) and what breaks.

Notice what the exercise above asks for. It is not a clever architecture. It is the smallest design that works. A client, a service, a database. Phase four starts simple on purpose. Complexity has to be earned by a requirement or a number you found in phases one and two.

Where the time goes

In a 45-minute interview, a reasonable split looks like this:

  • 5 minutes: requirements and clarifying questions
  • 5 minutes: estimation
  • 5 minutes: API and data model
  • 15 minutes: high-level design
  • 10 minutes: deep dive and failures
  • 5 minutes: buffer, trade-offs, questions

The high-level design is the biggest block, but notice it is only a third of the time. Candidates who spend 35 minutes drawing leave no room for the deep dive. That is the part that separates a good answer from a great one.

More boxes do not make a better answer

Meera's first instinct was that an impressive answer needs many famous parts. She pictured Kafka (a message log), Redis (an in-memory cache), a CDN (servers that keep copies of files close to users) and six microservices. That is not what impresses. An answer with eleven boxes and no reason for any of them loses to an answer with four boxes where every box answers a stated requirement.

Kabir gave Meera a test. For every component you draw, finish the sentence "I need this because ______." If the blank says "it is common" or "it scales", you have not earned the box yet.

⚠️ Warning: "Because it scales" is not a reason. Say which number needs it: "reads are 10,000 per second and one database handles about 1,000 of these, so I need a cache."

What Meera does differently next time

She opens with a question instead of a marker. "Before I draw: who uses this page, and what do they need to see? Is a 5-second delay fine, or must it feel live? Roughly how many people watch at peak?" Kabir answers, and the numbers appear. The diagram that follows is shorter, and every part has a reason.

📌 Summary: Ask about requirements before you draw anything. Keep the design as small as the numbers allow. For every box, be able to say which requirement or number needs it.

What Meera learns next

Phase one decides everything after it. Next: the questions that turn "design an order-tracking page" into a problem you can solve.

Check your understanding

  1. An interviewer says: "Design the order-tracking page for SwiftKart." What is the best use of your first minute?
  2. In a 45-minute interview, a candidate is still adding boxes at minute 35 and has not discussed failures. What is the main problem?
  3. A candidate adds a cache and says "because it scales". Which reason would pass Kabir's "I need this because ___" test?
  4. For phase four on the tracking page, Kabir asks for "the smallest design that works". Which fits?