How a design round runs: six steps in 45 minutes

A design round starts with one open sentence. For example: "Design a website where students see their exam results." Then you talk for 45 minutes. Nobody tells you what to do first.

A common mistake is to start drawing boxes in the first minute. At minute 30 the candidate finds that the design is wrong for the problem. There is no time to fix it.

Interviewers look for a clear way of working. They want to see three things. You ask before you build. You build the simple thing first. You use your last minutes on the parts that can break. A good engineer works like this every day.

A weak answer is one big drawing with no questions and no numbers. A strong answer follows steps, says each step out loud, and watches the clock. The level you apply for changes what the interviewer expects. At SDE-1 they mostly check that you can follow the steps. At SDE-2 and SDE-3 they check that you can lead the round.

Think about a cook who must feed a family function. A good cook does not light the stove first. The cook first asks how many guests there are and what they eat. Then the cook lists what is needed: rice, vegetables, plates, helpers. Then the cook decides how food moves from the kitchen to each guest. Then the cook decides where the stoves and tables go. At the end the cook asks: "What if the gas cylinder is empty? What if 100 more guests come?"

A design round has the same order. There are six steps. Many people teach a frame like this one. It is not the only way, but it works for most problems.

The six steps

1. Requirements. Ask what the system must do and how well it must do it. These are the two kinds of needs from lesson 1. Get a number for users, for speed and for failures. You produce a short list of three to five lines, written where both of you can see it.
2. Entities. An entity is a main thing that the system keeps data about. In a results website the entities are the student and the mark. You produce a list of two to five entities, each with a few facts about it, called fields, for example roll number and name. These are the data the database will store.
3. API. An API (application programming interface) is the list of requests that a client can send to the system. For each request you write its name, what the client sends and what comes back. For example, getResult(rollNumber) returns the name and the marks. Check that every need from step 1 has a request.
4. Data flow. The data flow is the path that one request and its data take: from the client, through each part, and back. You write it as numbered steps. This shows what each part does and finds parts that you forgot.
5. Design. Now you draw the parts as boxes, with arrows between them. Use the client, the servers and the database from lesson 1. Write a number on each box or arrow, for example "500 requests per second". Start with the simplest design that meets the numbers from step 1.
6. Deep dives. A deep dive is a close look at one part of the design. You ask questions like these. What if this part breaks? What if traffic (the requests that arrive) becomes 10 times bigger? What if the data is very large? You answer with numbers and say what each fix costs.

The clock

Here is a split for a 45-minute round. It is a guide made by Tradeoff, not a rule of any company. Interviewers differ, and some rounds are 60 minutes.

The total is 5 + 2 + 4 + 3 + 10 + 18 + 3 = 45 minutes. Steps 1 to 4 take 14 minutes, so the first drawing appears at about minute 14. Deep dives take 18 of 45 minutes, which is 40% of the round. We do this because a deep dive is where the interviewer sees how well you think.

What each level is expected to do

This is our own guide to what each level should do. It is not an official rule, and companies differ.

• SDE-1: follow the steps, ask the main questions, and build a simple design that works. The interviewer may guide you. Explain each choice in simple words.
• SDE-2: lead the round yourself. Put numbers on the design. Compare two options for a choice and say what each costs. Take a deep dive into the part that is most likely to break.
• SDE-3: do all of this, and also find the hardest part without help. Say when you would change the design as traffic grows, and what the change costs.

Two habits

The steps are a map, not a script. You may go back. If a number changes in a deep dive, update the requirements and say so.

Also say which step you are in: "I will start with requirements." The interviewer then knows where you are, and can help you.

We design the results website from lesson 1, with all six steps, in a tiny version.

Assumptions (made up to teach with, not real traffic):

• 2 lakh (200,000) students check their result in the first 10 minutes after results open. 1 lakh = 100,000.
• Each student opens the page 2 times.
• One server answers 500 requests per second (as in lesson 1).
• One database answers 2,000 simple lookups per second. A lookup is one question to the database, such as "find roll number 4821". Each request makes one lookup.

Step 1: Requirements. These are the three questions, with the answers the interviewer gives.

• What must it do? A student types a roll number and sees the name and marks. Board staff load the marks before results day.
• How many users, and when? 2 lakh students in 10 minutes, as above.
• How fast, and how bad is a failure? The page must open in under 2 seconds. Marks must never be wrong. If one server breaks, the site must still work.

Now the arithmetic for the busiest 10 minutes:

• Requests = 200,000 students x 2 = 400,000
• 10 minutes = 10 x 60 = 600 seconds
• Requests per second = 400,000 / 600 = 667 (rounded from 666.7)
• Servers to handle the traffic = 667 / 500 = 1.33, so 2 servers
• If one may break, 2 servers are not enough, because 1 x 500 = 500 is less than 667. With 3 servers, two can still answer 2 x 500 = 1,000, which is more than 667. So we need 3 servers.

Step 2: Entities. Student (roll number, name). Mark (roll number, subject, marks).

Step 3: API.

• getResult(rollNumber) returns the name and the marks. Students use it.
• uploadMarks(file) stores the marks. Board staff use it. Every need from step 1 now has a request.

Step 4: Data flow for getResult:

1. The phone sends getResult(4821).
2. A server receives the request.
3. The server asks the database for roll number 4821.
4. The database returns the name and the marks.
5. The server sends them back to the phone.

Step 5: Design. Phone -> a part that shares the requests between the servers -> 3 servers -> 1 database. Labels: "667 requests per second in total". Each server gets 667 / 3 = 222 requests per second, which is 222 / 500 = 44% of what it can do.

Step 6: Deep dives. We choose two questions.

• What if one server breaks at the busiest moment? Two servers are left. Each gets 667 / 2 = 333 requests per second, which is 67% of 500. The site works. The cost is one extra server.
• Which part reaches its limit first if more students come? The 3 servers can answer 3 x 500 = 1,500 requests per second. The database can answer 2,000. The servers reach their limit first, but we can add servers. We cannot fix the database by adding servers, so the database is the real limit. It is reached at 2,000 requests per second, which is 2,000 / 667 = 3 times more traffic (6 lakh students). I would change the design when traffic gets near that number.

Closing. "The site needs 667 requests per second. Three servers and one database meet it, even when one server breaks."

Here is the answer to the predict box. The three questions are: what must it do, how many users and when, and how fast must it be and how bad is a failure. Each answer gave a number that shaped the design: 667 requests per second led to 3 servers.

• It solves: a round with no direction. The steps make sure you ask first, put numbers on the design, and have time for deep dives.
• It costs: time before the first drawing. In this split the drawing starts at about minute 14. The interviewer may feel you are slow to show a design.
• I would change it when: the interviewer gives you the requirements and asks you to go straight to the design. Then confirm the numbers in one minute and start at step 5. I would also shorten steps 2 and 3 when the question is about one part of a system.
• Use the steps in order unless a number changes. If it changes, go back, fix it, and say what it changes.

"I should start to draw at once, so the interviewer sees that I am fast." Speed does not help if the design is wrong. In the example, the number 667 requests per second came from questions. Without it, you cannot know if 1 server or 3 servers is right. Ask first. It takes 5 minutes.

"Deep dives are a bonus. If time is short, I can skip them." They are the main part. They take 18 of 45 minutes in our split, because they show how you think about failures and growth. If time is short, make the earlier steps shorter instead.

"The six steps are a script. I must finish one step before the next, and never go back." The steps are a map. A deep dive may show that a requirement was wrong, for example that traffic is higher than you thought. Go back, change it and say so. This shows that you think clearly.

1. Name the six steps in order. What do you produce in the entities step?
2. In a 45-minute round you spend 6 minutes on requirements and 3 on entities. You spend 5 on the API, 4 on data flow and 14 on the design. (a) How many minutes are left? (b) The closing needs 3 minutes. How long are the deep dives, and how does this compare with the 18 minutes in the guide?
3. You finish the design at minute 38, and the interviewer says nothing. What do you do with the time that is left?