Why you need a delivery framework
Most mid-level candidates who fail don't fail on knowledge. They run out of time and never finish a working system — and it lands on the scorecard as vague “time management” feedback.
The fix usually isn't working twice as fast. It's spending your 45 minutes on the right things, in the right order.
Overall structure
The framework is a fixed sequence with a timing budget. Follow it and you stay focused on what's graded — and you have a script to fall back on when nerves hit.
Interviewers don't grade “framework adherence” as its own line item — it usually shows up under communication. But candidates who follow a structure consistently finish with a working system. Candidates who don't, usually don't.
Read the diagram left to right first — then notice the two arcs looping back to requirements:
- High-level design → Functional requirements: by the end of HLD, every feature you promised should have a working path on the whiteboard.
- Deep dives → Non-functional requirements: scale, latency, consistency, and failure modes get proven here — not as random rabbit holes.
- Requirements — ~5 minutes (functional + non-functional + optional capacity math)
- Core entities — ~2 minutes
- API or interface — ~5 minutes
- Data flow — optional ~5 minutes — skip if not a pipeline-style system (dashed box on purpose)
- High-level design — ~10–15 minutes — primary goal: satisfy functional requirements
- Deep dives — ~10 minutes — primary goal: satisfy non-functional requirements
Stay linear to deliver a working system. Use deep dives to prove NFRs — don't invent microservices before the user path works.
Requirements (~5 minutes)
Goal: get a clear understanding of the system you're asked to design. Break requirements into two sections.
1) Functional requirements
These are your “Users / clients should be able to…” statements — the core features. Discuss them first, often as a back-and-forth with your interviewer like you're talking to a product manager: “Does the system need to do X?” “What would happen if Y?”
Example — Twitter-like system:
- Users should be able to post tweets.
- Users should be able to follow other users.
- Users should be able to see tweets from users they follow.
Example — cache system:
- Clients should be able to insert items.
- Clients should be able to set expirations.
- Clients should be able to read items.
Non-functional requirements
These describe system qualities — phrased as “The system should be able to…” or “The system should be…”
Example — Twitter-like system:
- Highly available — prioritize availability over consistency.
- Scale to support 100M+ DAU.
- Low latency — render feeds in under 200ms.
Rank them — don't list eight and hope one lands:
- Scale — read/write ratio and traffic shape. Decides whether you need caching or sharding at all.
- Latency — name the one path with a tight SLA (search, feed, checkout). Everything else just needs to be reasonable.
- Consistency vs. availability — pick a side per data type (CAP). This decides your database and replication strategy.
Capacity estimation
Skip ritual back-of-envelope math. Do the calculation only when the number will change your design.
In most scenarios you're designing a large distributed system — that's reasonable to assume. Many candidates calculate storage, DAU, and QPS only to conclude “ok, so it's a lot.” As interviewers, we gain nothing except that you can do arithmetic.
Suggested line: “I'll skip upfront estimations and do targeted math during design if a number would change my architecture.”
Still learn to estimate quickly — it helps you reason about trade-offs. Don't worry if you're bad at mental math under pressure; most people are. Round aggressively.
Core entities (~2 minutes)
A great design interview is a loop: requirements shape the design, and the design exposes new requirements.
Identify and list the core entities of your system. This defines terms, clarifies the data central to your design, and gives you a foundation to build on. These are the entities your API will exchange and your system will persist.
In the interview, jot a bulleted list and say it's a first draft.
Why not the full data model yet? Because you don't know what you don't know. As you design, you'll discover new entities and relationships. Start small; iterate. Once you're in high-level design and know what state updates on each request, add relevant columns/fields.
Twitter example:
- User
- Tweet
- Follow
Useful questions:
- Who are the actors in the system? Do roles overlap?
- What nouns / resources satisfy the functional requirements?
API or system interface (~5 minutes)
Before high-level design, define the contract between your system and its users. For product-style interviews this often maps directly to functional requirements (but not always!). Use this contract to guide your architecture.
Quick decision — which protocol?
- REST — HTTP verbs (GET, POST, PUT, DELETE) on resources. Default for most interviews.
- GraphQL — clients specify exactly what data they want. Use when diverse clients have different data needs.
- RPC (gRPC) — action-oriented, faster for service-to-service. Use for internal APIs when performance is critical.
- WebSockets / SSE — for real-time features; design your core API first.
For Twitter, choose REST and design endpoints using core entities as plural resources:
POST /v1/tweets
body: { "text": string }
GET /v1/tweets/{tweetId} → Tweet
POST /v1/follows
body: { "followee_id": string }
GET /v1/feed → Tweet[][Optional] Data flow (~5 minutes)
For some backend systems — especially data-processing systems — describe the high-level sequence of actions from inputs to outputs. If your system doesn't involve a long sequence of actions, skip this.
We usually define data flow as a simple list. You'll use it to inform high-level design next.
Web crawler example:
- Fetch seed URLs
- Parse HTML
- Extract URLs
- Store data
- Repeat
High-level design (~10–15 minutes)
Now design the high-level architecture: boxes and arrows for servers, databases, caches, queues, and how they interact. Whiteboard or Excalidraw. See Key technologies for common components.
Don't overthink this. Primary goal: an architecture that satisfies the API — and thus the requirements. In most cases, go one-by-one through your API endpoints and build the design sequentially.
- Narrate data flow and what state changes on each request.
- When a request hits the DB, document relevant columns next to it on the board.
- Skip obvious User columns (name, email, password hash) — focus on fields that matter to your design.
- Talk through your thought process continuously — silence reads as confusion.
Deep dives (~10 minutes)
Astute readers noticed our simple Twitter design is woefully inefficient at fetching feeds. That's fine. Deep dives are where you harden the design:
- Ensure it meets all non-functional requirements.
- Address edge cases.
- Identify and fix bottlenecks.
- Improve based on probes from your interviewer.
Seniority matters: junior candidates can expect the interviewer to point out weak spots. Senior candidates should identify them and lead. Staff+ goes further into org-level trade-offs.
Cost and performance levers
Interview Q&A by level
Practice saying these out loud for the delivery framework. Interviewers grade clarity and judgment more than buzzwords.
Match depth to the bar: define → trade off → operate. Don't dump principal answers in an entry-level screen.
Conclusion
Memorize the sequence: Requirements → Entities → API → (Data flow) → High-level design → Deep dives. It prevents “time management” failures and delivers what interviewers actually need — a working system, explained clearly.
Run this loop well and you naturally hit the four qualities every rubric rewards:
- Top 3 functional requirements — not forty.
- Quantified non-functional requirements — not vague “low latency”.
- Skip ritual math; do math when it changes the design.
- Simple HLD first; complexity in deep dives.
- Collaborate in deep dives — don't filibuster.
Worked micro-script: design a URL shortener
Timebox cheat sheet
- 0–5m clarify
- 5–10m capacity
- 10–20m API+data+HLD
- 20–35m deep dive
- 35–45m failures & trade-offs
Failure modes to mention
Call out at least one dependency failure (DB down, cache stampede, queue lag, region outage) and your mitigation (timeouts, retries with jitter, degraded mode, circuit breaker).