Asking better questions and senior-level signals

Questions come from a checklist, not inspiration. Split the whiteboard into two columns and fill each with its own acronym. ACTORS gives you the functional requirements (what the system does). SCALED gives you the non-functional ones (how well it must do it). Say the two words in your head the moment the prompt ends.

• Minutes 0-5: ACTORS and SCALED, all of it. Write answers in two columns (Functional, Non-functional) and put numbers next to Count. These choose your design, so do not draw anything before you have them.
• Minutes 5-10: turn answers into estimates. Count gives QPS and storage. Write "Hard part: ..." at the bottom of the board (the one letter that was unusual, like bursts or ordering).
• Deep dive: ask again, but per box. Now the four what-ifs (slow, down, duplicated, 100x bigger) on each component. These are the "deep" questions you keep missing, and they only make sense once boxes exist.
• Last 5 minutes: where it breaks at 10x, what you would monitor, what you would build differently.

"Before designing, let me clarify. Functional first:
 A  who are the users: end users only, or admins too?
 C  the core flow is X, is that right? Anything else for v1?
 T  does it start from a user action, an API, or a schedule?
 O  what does the user get back, and does it need to be real time?
 R  any rules: permissions, limits, opt-outs?
 S  what is out of scope, and can items be edited or deleted?

Now non-functional:
 S  anything sensitive: PII, auth, abuse, compliance?
 C  how many users and requests per second? Peak? How much data, kept how long?
 A  what must never go down, and what can degrade?
 L  which part must be fast, and what is the target?
 E  can we lose, duplicate or reorder? Strong or eventual consistency?
 D  any third parties with limits or cost, and a budget?"

• After each design, write one line: "what made this problem special?" Notifications: bursts + priority + dedupe. URL shortener: read-heavy + key lookup. After 6-8 problems you have a pattern library.
• When stuck, say a trigger phrase aloud instead of going silent: "Let me think about failure modes" or "Let me check the data model". It buys time and shows structure.
• Drill one problem a day with the System Design cards in the Reels section.

1. You drive the interview. "I will spend 5 min on requirements, 10 on the high-level design, then deep-dive where it is hardest. Okay?" Check in as you go.
2. You name trade-offs, with costs. Not "I would use Kafka" but "Kafka for replay and throughput, at the cost of operational complexity; at small volume SQS is simpler".
3. The numbers choose the design. "At 40 writes/s one Postgres plus a cache is enough." Not over-engineering is itself a signal.
4. You find the hard part early and say it: "The hard part is the 100x burst and OTP priority, so I will spend my time there."
5. You raise failure unprompted: retries, duplicates, a dependency down, a hot key, a region outage.
6. You think in time and evolution: v1 is simple, what changes at 10x and 100x, and how to migrate from the old system safely.
7. You bring operations and people: monitoring and alerts, rollout (feature flags, canary), cost, which team owns which service.
8. You push back politely when requirements conflict: "Strong consistency and 5 ms global latency cannot both hold, so which matters more?"

• Where would this break first at 10x scale?
• What would I monitor?
• What would I build differently with more time?