Interview Playbook
A fresher-to-staff interview guide: clarification questions, a 45-minute answer sequence, invariants, failures and role-specific evidence.
What, why, when and how
What is it?
The playbook is a practical set of prompts for clarification, a complete baseline, justified deep dives and a concise recap.
Why is it needed?
It helps select what to say next when the prompt is vague or the interviewer changes direction.
When should I use it?
Use it during timed practice and adapt it to the actual interview duration, scope and follow-up questions.
When should I choose something else?
Avoid reading the entire checklist aloud or forcing a 45-minute agenda onto a different format. Questions should change a decision.
How do I use it?
Write the agreed user actions, measurable targets and invariant. Trace one write and read, choose a bottleneck, inject a failure and recap what remains unresolved.
Can you show a concrete example?
When asked to design video, first clarify whether the focus is playback, live streaming or recommendations. A playback baseline covers entitlement, a published manifest and authorized segment delivery; ranking is an extension unless requested.
Read the diagram
Ambiguous prompt: design a video service; Clarify: playback, live streaming or ranking?; Playback scope: entitlement, manifest, media path
Follow the detailed diagrams below to trace the additional state changes and failure cases behind these answers.
Start with a conversation, not a component list
“Design WhatsApp” is a product name, not a complete specification. It could mean one-to-one text chat, large groups, voice calls or multi-device history. “Design Netflix” could mean a video catalog, on-demand playback or recommendation ranking. Ask questions whose answers change the architecture, summarize the agreed boundary, then move on. This is an original teaching framework; real interview formats and expectations vary.
A functional requirement is an action the system supports, such as send a message. A non-functional requirement describes a measurable property, such as how long an online recipient waits. An invariant is a rule that must survive concurrent requests and failures, such as one logical message identity producing one accepted message. A trade-off describes what improves and what it costs. A baseline is the smallest complete design that satisfies the agreed core journey. Learn these ideas before adding specialized technology.
What to ask in the first five minutes
Begin: “Who uses the system, and which two or three actions should we design first?” Propose a scope so the interviewer can react. Then ask the highest-impact questions below. Do not recite every question regardless of the prompt; spend roughly three to five minutes establishing the boundary and revisit assumptions when the design exposes a new decision.
| Clarification | Example question | Architectural consequence |
|---|---|---|
| Users and journey | Who creates the data, who reads it, and what does success mean to them? | Separates producer, reader and administrator paths |
| Included features | Are groups, live playback, offline mode or payments required? | Changes ordering, publication, retention or external effects |
| Exclusions | Can search, recommendations and analytics be extensions? | Keeps the first path small enough to finish |
| Scale and skew | Active users, concurrent users, peak rate, record size and hot groups/titles? | Drives connection, shard, bandwidth and fairness choices |
| Freshness and latency | Which latency percentile matters? How stale may each result be? | Determines caching and asynchronous boundaries |
| Correctness | What must never happen? What does an acknowledgement prove? | Identifies durable ownership and conditional transitions |
| Failure policy | What should happen during a network or regional failure? What data loss and recovery delay are acceptable? | Separates availability, recovery point and recovery time |
| Security and privacy | Who may access each object? Encryption, deletion, retention and regional requirements? | Shapes authorization, key management and lifecycle boundaries |
| Resources | Any existing stack, budget, team or migration constraints? | Prevents a proposal that cannot be built or operated |
If the interviewer says “choose reasonable numbers,” label them as assumptions: “I’ll assume one million concurrent viewers and 3 Mbps average encoded media; that implies 3 Tbps before protocol overhead.” Do not present an exercise assumption as a company's production traffic. If an answer is unavailable, state the assumption and explain which choice changes if it is wrong. Keep a small visible requirements list so both people can point to it.
Use a complete 45-minute answer
| Time | Deliverable | What to say or draw |
|---|---|---|
| 0–5 minutes | Scope and success | Two or three user actions, exclusions, one or two measurable targets, one invariant |
| 5–8 minutes | Decision-driving estimates | Peak request rate, concurrent connections or delivery bandwidth; record size times retention |
| 8–13 minutes | Entities and contracts | IDs, ownership, access patterns, one write API, one read API, pagination and retry/error behavior |
| 13–25 minutes | Complete baseline | Follow one request to durable truth, acknowledgement, read/delivery and authorization |
| 25–38 minutes | Two justified deep dives | Select correctness and the dominant scaling pressure from the requirements |
| 38–43 minutes | Failure and operations | One ambiguous timeout, one overload/failover, relevant observability and recovery |
| 43–45 minutes | Recap | Requirements satisfied, rejected alternative, material limitation and next step |
Read the diagram
0–5 min: clarify users, flows, exclusions, scale and guarantees → 5–8 min: estimate peak rate, connections, bandwidth and retained bytes → 8–13 min: define operations, records, keys and access patterns → 13–25 min: draw a baseline; trace one write and one read → 25–38 min: justify two deep dives using load and failure cases → 38–43 min: recovery, security, SLIs, cost and rollout → 43–45 min: recap decisions, limits and remaining risks
Use this as a flexible agenda. In a 30-minute interview reduce features and deep dives; in a 60-minute interview add depth only after finishing the baseline. Ask “Would you prefer that I go deeper on consistency or bandwidth?” when the interviewer signals another direction. Explaining a decision clearly is more useful than filling every minute with component names.
Work from a user action to an enforceable rule
For “send message,” write a stable client message ID and conversation ID. Define accepted as “message and retry identity committed at the owner.” Sketch sender → authenticated API → authorized conversation owner → durable append → acknowledgement. Add recipient delivery and offline replay as another path. A queue may wake a device, but the durable history is still needed if that wake-up disappears.
For “record expense,” define who paid, who owes what, currency and rounding. The write atomically records the expense revision and its obligations. A retry returns the same operation result. Derived balances can lag under an explicit policy; a settlement decision must use the authoritative ledger and current authorization. A database box alone does not enforce any of these rules.
Choose keys after naming reads. A conversation history needs bounded sequence pagination; a group ledger needs currency, group and revision scope. State why a cache or index earns its place. Draw alternatives only when their difference matters to a requirement. Demonstrate the guarantee with concrete records and a failure, not an unsupported adjective such as “exactly once.”
What changes from fresher to staff
These are learning tracks, not universal hiring rubrics or definitions based on years worked. Every track still needs requirements and a complete path. A fresher can demonstrate strong reasoning without claiming experience operating a global service.
| Learning track | Core evidence to practice | Typical follow-up |
|---|---|---|
| Fresher / foundation | Define unfamiliar terms, state assumptions, show entities/APIs and one working request, identify one bottleneck | Why is this data in a database? What if the response is lost? |
| Intermediate | Choose indexes/cache/queue from access patterns, calculate a useful estimate, explain retries and authorization | What changes when traffic peaks or one key becomes hot? |
| Senior | Defend durable ownership, concurrency and recovery; state SLOs, bounded work, observability, security and cost | How do you diagnose and repair partial failure without losing or duplicating effects? |
| Staff | Frame cross-system boundaries and alternatives; prioritize risk, migration and rollback; define ownership and a measurable adoption plan | How do multiple teams evolve this safely, and what evidence would make you reverse the decision? |
Staff depth is not “add more regions.” Explain why regions are needed, how ownership moves, which writes pause, what clients observe, and who operates the handoff. A staged plan might first isolate one domain, shadow reads against the new projection, reconcile differences, move a bounded cohort, observe SLOs and retain rollback until compatibility is proven. A rollback that reintroduces two writable owners is not a safe rollback.
For senior/staff discussion, make six commitments explicit: customer-visible SLO; authority and invariant; resource/admission limit; failure/reconciliation policy; signals and on-call recovery; rollout and cost. Do not claim that a region, queue or managed service guarantees these on its own.
Explain any unfamiliar prompt through its dominant constraint
| Prompt family | Clarify first | Invariant / dominant pressure | First deep dive |
|---|---|---|---|
| Messaging / collaboration | Ordering scope, devices, offline history and membership | Stable operation identity and bounded fanout | Reconnect/replay, membership and conflicting edits |
| On-demand video | Catalog versus playback, content source, device/rights support | Playable publication plus delivery bandwidth | Manifest/segments, CDN and authorization |
| Live sports | Latency, synchronized viewers, DVR and kickoff concurrency | Fresh media timeline under a common burst | Ingest redundancy, origin protection and player recovery |
| Money / expenses | Currency, split/rounding, edits, settlement versus real payment | Per-currency conservation and replay-safe effects | Atomic ledger revisions, reconciliation and access |
| Scarce inventory | Hold lifetime, purchase boundary, overlapping resources | No double ownership or negative inventory | Conditional transaction, expiry and stale work |
| Search / feeds | Ranking, freshness, visibility and pagination | Current authorization and stable browsing contract | Source-to-index lag, bounded retrieval and deletion |
| Async jobs / schedulers | Deadline, retries, cancellation and external work | One current owner and explicit unknown outcomes | Fencing, queue age, retry budget and recovery |
The question breakdowns let you apply this method to different products. Compare WhatsApp, on-demand video, live video and Splitwise. These are interview exercises, not claims about a named company's private implementation.
Show failures before declaring the design complete
Walk through an operation that commits but loses its response. Which stable identity does the retry reuse? Where is the result discoverable? Then make a dependency slower than its arrival rate. Where is admission bounded, what is rejected/deferred, and how does unrelated traffic progress? Finally, apply a revoked permission or a stale writer. Which serving/writing authority rejects it?
Measure at the user's boundary: message acceptance and delivery separately; video startup and rebuffering separately; ledger correctness and projection lag separately. An API returning 200 is not evidence that media played, a device received a message or a provider completed a payment. Define a usable runbook: symptom, invariant at risk, safe mitigation, reconciliation query and recovery verification. State a cost driver in its actual unit, such as delivered GB, stored GB-month or concurrent inference work.
Practice, assess and transfer
Try a 45-minute design without opening a worked solution. Save your questions, agreed assumptions, data model, first architecture and one failure trace. At foundation level explain each arrow in plain language; at senior level inject a timeout and overload; at staff level require an incremental migration with rollback and team ownership.
| Dimension | Incomplete evidence | Useful evidence |
|---|---|---|
| Clarification | Product name silently defines scope | Answers change the written requirements |
| Baseline | Components appear without one user journey | Request, durable state and response form a complete path |
| Correctness | “Exactly once” without a protocol | Retry/race trace identifies the enforcing authority |
| Scaling | More machines without a bottleneck | Estimate and limit select a concrete mechanism |
| Operations | “Add monitoring” | User SLI, bounded mitigation and recovery check |
| Staff scope | Global diagram without rollout | Compatibility, ownership, adoption gates and reversal criteria |
Question: The interviewer asks for Netflix. Is starting with a recommendation engine reasonable?
Show answer and explanation
Answer: Ask whether recommendation ranking is the focus. For a playback-focused prompt, start with catalog selection, entitlement, a published manifest and authorized media delivery. Recommendations are a different workload and can be an explicit extension.
Question: A staff candidate proposes active-active writes because availability matters. What needs clarification?
Show answer and explanation
Answer: Which data may conflict, what resolves conflicts, what cannot be violated, and what happens during a partition. A chat receipt, a money ledger and an exclusive seat have different failure policies. Availability must be defined per operation.
Question: Should a fresher attempt every staff deep dive?
Show answer and explanation
Answer: Complete and explain a sound baseline first. Add one change you can defend. Use the deeper track to learn boundaries progressively rather than using unfamiliar terms without a mechanism.
Recover when the interviewer changes the contract
At minute twenty, a messaging design has durable server acceptance and asynchronous recipient delivery. The interviewer asks: “Can send succeed only after every device receives the message?” First confirm whether offline devices are included. Do not simply add more fanout workers.
| Agreed interpretation | Design consequence | Limitation to say aloud |
|---|---|---|
| Server acceptance remains success; device status is separate | Keep durable acceptance and expose per-device delivery observations | Accepted does not mean delivered |
| Every currently connected eligible device must acknowledge | Track the agreed recipient/device set, acknowledgements and a deadline | Disconnection or timeout leaves completion unresolved under that policy |
| Every registered device, including offline devices, must acknowledge | Persist pending acknowledgements and define how long the sender waits | An offline device can prevent success indefinitely without a changed deadline or success policy |
Show answer and explanation
Answer: Ask which interpretation the product needs, update the written requirement, and show the changed state and response boundary. Explain that a response timeout still does not erase an accepted message. Preserve the stable message identity across retries. If the stricter contract is selected, reduce optional scope so the revised baseline and recap fit the remaining interview time.
The evidence is the chain from changed requirement to changed state, API promise and failure policy. Use the same method for a new payment or streaming constraint rather than replacing the entire architecture from memory.