The Questions Everyone Asks (FAQ)

By now you have the method: the clock, the scope, the board, the voice, the picture. And there is still a list of things people lie awake about the night before.

How much detail is enough? What if they ask about a technology I've never used? Do my numbers have to be right? Am I allowed to say "I'd use DynamoDB"? What if I finish early? What if I've literally built this at work?

Read them together and they're all one question wearing different hats: how do I know if I'm doing enough?

That question feels unanswerable because you're imagining an absolute bar — some complete, correct system that exists somewhere, which you're falling short of. There isn't one. Here's the actual bar, and it's the thing that makes the rest of this lesson short:

You are not measured against a complete system. You are measured against what someone at your level would do with this problem, in this hour.

Relative, not absolute. And it moves — which is why the same answer can be under-levelled for one candidate and over-reaching for another.

Before the open questions, the good news — and it's worth actually looking at, because a surprising number of these anxieties are already dead and you may not have noticed.

Those six on the left aren't repeated here. Pointing at them is more useful than re-answering them, and if any still feel unresolved, the honest move is to go back to that lesson rather than collect a shorter version of the same answer.

What's left on the right is what the method deliberately left open — and the first one is the hardest question in this entire part of the course.

This is the question everybody asks and nobody answers properly, because the honest answer is it depends on who you are — which sounds like a dodge until you see what it actually depends on.

The bar moves along three separate axes, and they don't move together.

Look at the top row again, because it's the one that surprises people: breadth goes down as level goes up.

Almost everyone assumes seniority means knowing more things out loud, so they prepare by widening. It's backwards. At mid-level, broad general knowledge genuinely is what's being checked — you're expected to know the pieces exist and roughly what they're for. By senior, that's assumed; nobody probes whether you know what a cache is. What changes is the kind of knowledge: it is no longer enough to state a preference for a type of technology, and you're expected to draw on things you've actually run — roughly two areas, with real specifics. At staff and above, breadth tapers further still and depth is expected in several places, with something the interviewer hadn't thought of.

The third axis is the one people never think of as a skill: how much you drive. Mid-level, you're expected to lead the opening and then let the interviewer steer. Senior, you stay proactive — and, notably, you're expected to name the weaknesses in your own design before anyone asks. Staff and above, you lead nearly the whole hour and behave like a colleague rather than a candidate.

Which gives the practical translation of how deep is deep enough: pick two components and take them further than feels comfortable; leave the rest named and justified. Not everything. Not one thing. And pick the two where the risk actually lives — depth on the comfortable component reads as avoiding the hard part, which is worse than not going deep at all.

A description of three axes is hard to convert into what do I actually do on Tuesday. So here's the same judgment as an allocation problem.

You get a depth budget — because depth everywhere was never an option — and four components to spend it on. Choose how far you take each one, and how much of the hour you drive.

Then do the thing the lesson is really about: change the level and don't change anything else. Watch an answer you were happy with turn into reads a level below, or an answer you thought was thorough turn into ran out of clock. The panel at the bottom scores your exact allocation at the other two levels at the same time, so you can see the whole shape of it at once.

The second-most-common fear: they'll ask about something you've named and you'll have nothing underneath it.

There's a clean rule for how much is enough, and it sits between two failure modes.

Treat every system as a black box with certain capabilities — but be able to describe how those capabilities are achieved.

You do not need a product's API memorised. You do not need its source. You need to be able to open the box one level, because the follow-up is always some version of "how does that actually scale without losing data?"

For a log-based queue, one level down is: it's an append-only log, partitioned by key, with consumers tracking their own offsets; ordering holds within a partition and not across them; durability comes from replicating each partition and choosing how many replicas must acknowledge a write. That's four sentences, no API, and it answers most of what anyone will ask.

This gives you a test you can run on yourself while you're drawing:

Never name a component you can't say one sentence about the mechanism of.

And when you can't — the escape is completely safe, and it's not a climbdown. Use the generic noun. "A message queue here", "an object store", "a search index." Nobody has ever been marked down for saying message queue. Being probed on a brand name you can't open, on the other hand, is genuinely expensive — a candidate who says Kafka and then can't answer what happens when a consumer falls behind has actively spent points that message queue would have cost nothing.

No. Not close to it, and the anxiety here is entirely misplaced.

Nobody is checking your arithmetic. An interview isn't a math test — and being visibly precise actively works against you, because engineers who have genuinely sized systems in production round aggressively. They round to the nearest power of ten and move on, because at the design stage the precision doesn't change any decision. Rounding is the senior behaviour; grinding out 61,200 is the junior one.

So: a hundred million is fine. Ten thousand a second is fine. "Call it a million requests a day, so roughly ten a second average, maybe fifty at peak" is a completely acceptable sentence, and it took eight seconds.

Two things that do matter. Keep the working visible — write the arithmetic where you both can see it, so a wrong assumption gets caught rather than a wrong answer being mysterious. And remember the rule from The Delivery Framework: only do the math that changes a decision. A number that doesn't move a design choice was four minutes you spent buying nothing.

Usually yes — and the fact that this varies is exactly why it's worth knowing about.

Naming real products shows familiarity, and generic nouns show you understand the pattern. Neither is wrong, and the pattern matters more than the brand. But the preference is genuinely company-dependent:

• Amazon interviewers generally expect you to think in their building blocks — the managed services are the vocabulary.
• Google tends to want you to build the component rather than name a managed one, which is why the earlier lesson flagged it: budget for explaining mechanism.
• Some interviewers explicitly don't want cloud-vendor answers, and there are documented cases of candidates hurting themselves by continuing to reach for one after being told not to.

So the move is a five-second question, early: "Are managed services fair game here, or would you rather I build the pieces?" Then follow the answer — including if they change it mid-interview.

One thing holds regardless of which way they answer: the reason still has to be audible. "DynamoDB" is a name. "A key-value store with predictable single-digit-millisecond reads at this scale, which is what our redirect path needs" is a decision — and that one works whether or not you're allowed to say the brand.

Four questions people are slightly embarrassed to ask, with straight answers.

"What if I've actually built this at work?" A real advantage — you have failure modes and trade-offs you can speak to with authority, which is exactly the experience-based specificity senior interviews are looking for. One trap, though: your production system solved your company's constraints, and those aren't the constraints on the board. Re-derive from the scope you committed to in Requirements & NFRs That Matter, not from memory. "We built something close to this, and we chose X because our write pattern was Y — here the requirement is different, so I'd lean Z" is close to the strongest sentence available in the whole interview.

"What if I finish early?" You almost certainly haven't — finished usually means stopped. There is always more: a bottleneck you haven't stressed, a failure mode you haven't walked, an alternative you rejected and never said why. Offer one: "we've got ten minutes — the thing I'd want to stress next is what happens when the queue backs up. Want me to go there, or is there somewhere you'd rather?"

"What if I change my mind halfway through?" Do it, out loud. Reversing a decision because a later requirement made it wrong is the design process working, not failing. The one thing to avoid is changing it silently, leaving two incompatible ideas on the board — which is the erasing point from Whiteboard & Diagram Craft applied to decisions rather than boxes.

"What if the interviewer is unhelpful?" Some are quiet, some are distracted, some are having a bad day. Remember from Anatomy of the System Design Interview that a flat reaction is often deliberate — they're trained not to leak signal. Your move doesn't change: keep narrating, keep checking in, and if you get nothing back, state your assumption and proceed rather than waiting. You cannot control the room; you can control whether there's something in it to grade.

And then the real one, which people ask last and quietly: what if I just blank?

It happens, it happens to strong engineers, and it isn't a knowledge problem — which is why no amount of extra studying fixes it. What actually helps is that you now have somewhere to put your hands when it happens. The board has a requirements corner you can re-read. The method has a next move that doesn't depend on inspiration. And "let me take a second and look back at what we committed to" is a legitimate, senior-sounding sentence that buys you fifteen seconds and often restarts the engine on its own.

That's most of what the method is for. Not to make you look organised — to give you something to do when the thinking stalls, so a bad thirty seconds doesn't become a bad interview.

Getting stuck isn't a dealbreaker. Getting stuck silently is.

So: the bar is relative, not absolute. Two components deep, the rest named and justified. Open every box you name by one level, or use the generic noun. Round the numbers hard. Ask once whether managed services are welcome. Say when you've built it before, and re-derive anyway. And when you stall, say that you're stalling and go back to the requirements.

That's the whole method — the clock, the scope, the board, the voice, the picture, and the calibration. The only thing left is to watch it run end to end on a real problem, which is exactly what's next: the Full Mock Walkthrough.