Advanced System Design Fundamentals
Vote

0% completed

​

The First Ten Minutes

  1. The Ten Minutes That Decide the Level
  1. Separate the Two Kinds of Requirement
  1. Ask Questions That Change Something
  1. State Assumptions Out Loud, and Say What Would Change Them
  1. Handling a Deliberately Vague Question
  1. The Scoping Script

1. The Ten Minutes That Decide the Level

Interviewers form a view of your level early, and almost all of it comes from what you do before you draw anything. That sounds unfair until you consider why it is true.

Scoping behavior is the cheapest signal to read and the hardest to fake. Technical depth takes forty minutes to assess and can be studied for. How somebody responds to a vague problem shows within two minutes, and it reflects how they actually work, because it is a habit rather than something you can study for.

So the opening is not a gentle start before the real interview. It is the part where the least time tells the interviewer the most, and skipping past it is the single most common way a strong engineer interviews at the wrong level. This lesson is the procedure, and it is deliberately mechanical, because the opening is where having a routine helps most.

One column defines the scope, the other shapes the architecture, and only one gets asked about.
One column defines the scope, the other shapes the architecture, and only one gets asked about.

2. Separate the Two Kinds of Requirement

Requirements come in two kinds, and they do different work.

  • Functional requirements say what the system does. A user can post. A driver can be matched. A file can be shared with a link. These define scope, and candidates are generally good at listing them.
  • Non-functional requirements say how well it must do those things, in numbers. How many users, how fast, how fresh, how available, how durable. These shape the architecture, and candidates routinely skip them.

"Users can share a file" is satisfied by a design serving ten people and by one serving ten million, and those two designs have nothing in common. So the thing to gather in the opening is the small set of numbers and qualities that will eliminate options later.

  • Scale, as an order of magnitude rather than a precise figure.
  • The read-to-write ratio, which decides where effort goes.
  • Latency expectations, and specifically whether they are human-facing or machine-facing.
  • Consistency tolerance, meaning how stale an answer may be before it is wrong.
  • Availability expectations, and what the system should do when it cannot meet them.
  • The size of the largest single item the system handles.

Six items, and most interviews need only three or four of them. The skill is knowing which ones.

Six figures worth gathering, of which most interviews need three or four.
Six figures worth gathering, of which most interviews need three or four.

3. Ask Questions That Change Something

Not all questions are worth asking, and interviewers can tell the difference between a real question and one that only sounds like one. The test is to connect the question to a decision before you ask it. Compare these two:

  • "How big are the files?"
  • "How big is the largest file, because above roughly ten megabytes I would move uploads off the request path entirely."

Both get the same answer. Only the second shows that you know what you will do with the answer, and it gets a better answer, because the interviewer now understands what you are really asking.

Questions that are reliably worth asking:

  • "Who uses this, and how often?" which establishes scale and shape together.
  • "What is the read-to-write ratio?" which usually determines where the hard part is.
  • "How stale can this be?" which is the question that decides more architecture than any other and is asked least.
  • "What happens if this is unavailable for a minute?" which turns a vague availability target into something a product owner can answer.

Questions that usually waste time include anything about technology preferences, anything you could reasonably assume and state, and anything you would design the same way whatever the answer.

The same question, with and without the decision it is attached to.
The same question, with and without the decision it is attached to.

4. State Assumptions Out Loud, and Say What Would Change Them

You will not get answers to everything, and you should not try. The alternative to asking is assuming, and an assumption nobody heard does not count. The useful form has two parts:

"I am assuming X. If it were Y instead, I would change Z."

The first part makes the assumption visible. The second is what makes it a senior move rather than a guess, because it shows the assumption really affects the design, and that you know how.

For example: "I am assuming reads outnumber writes by about a hundred to one. If it were closer to even, I would stop treating the read path as the hard part and spend the effort on write throughput instead."

An interviewer who disagrees now has something specific to challenge. Several interviewers will deliberately contradict an assumption to see whether you actually meant the second half of the sentence.

The second clause is what turns a guess into a stated assumption.
The second clause is what turns a guess into a stated assumption.

5. Handling a Deliberately Vague Question

Some questions are vague because the interviewer wants to see you narrow them. "Design a notification system" could be three different interviews, and choosing which one is part of the assessment. The move is to narrow it yourself and get agreement, rather than asking the interviewer to narrow it for you.

  1. Name the possible meanings. "This could be the delivery pipeline, the user preference and targeting side, or the real-time transport to devices."
  2. Choose one, with a reason. "I think the delivery pipeline is where the interesting problems are at scale, so I will make that the core."
  3. Keep the others outside the core. "I will treat preferences as a service I call, and say what I would need from it."
  4. Check. "Does that split work for you, or would you rather I went elsewhere?"

That sequence takes under a minute and does several things at once: it gives an open problem a shape, it gives the interviewer a cheap chance to redirect you, and whatever you build next is something you both agreed was the point.

The failure to avoid is asking the interviewer to make the choice. "What would you like me to focus on?" hands back the exact decision you were being asked to make.

Five moves, about eight minutes, and the behavior that undoes all of them.
Five moves, about eight minutes, and the behavior that undoes all of them.

6. The Scoping Script

Put together, the opening is roughly eight minutes and has five moves. Having the sequence memorized is worth more than any individual question in it.

  1. Restate the problem in one sentence and say what you think the core is. Thirty seconds.
  2. List the functional requirements briefly, and mark one or two as out of scope on purpose. A minute.
  3. Ask for three or four numbers, each tied to a decision. Three minutes.
  4. State your assumptions, each with what would change if it were wrong. A minute and a half.
  5. Say what success looks like for the design you are about to produce, which is where you name the non-functional targets as numbers. Two minutes.

That leaves about two minutes of the first ten for the conversation to go somewhere unexpected. Then you draw.

Two things make this work and are easy to leave out. The first is pausing to check after step two or three, because an interviewer who wanted a different emphasis will say so and you have lost nothing. The second is writing the numbers where both of you can see them, because every later trade-off refers back to them.

What the interviewer is scoring: in this part of the interview the assessment is almost entirely about whether your questions were connected to decisions. An interviewer forms the judgment "this person has designed something real" the first time a question arrives with its reason attached. Expect at least one of your assumptions to be contradicted on purpose, which tests whether the second half of your sentence was meaningful. The behavior that reads worst is going quiet and starting to draw, because it looks exactly like having decided the answer before hearing the question.

Flashcards Review

Why do the first ten minutes decide the level?

1 / 22

Reading Progress

0%

Vote for new content

On This Page

  1. The Ten Minutes That Decide the Level
  1. Separate the Two Kinds of Requirement
  1. Ask Questions That Change Something
  1. State Assumptions Out Loud, and Say What Would Change Them
  1. Handling a Deliberately Vague Question
  1. The Scoping Script