Interview Prep · Lesson 03

How you're scored

Every API / system-design round is graded against an invisible rubric. This lesson makes it visible — dimension by dimension, level by level — so you can walk in knowing exactly what earns points and what loses them.

Why knowing the rubric matters

A design round is not a test of omniscience. The interviewer is watching how you think, not whether you recall a specific algorithm. That "thinking" is structured — there is a checklist behind the curtain. Candidates who know what's on the checklist can deliberately demonstrate each item; those who don't often ace one dimension and forget three others entirely.

Think of it like a driving test. The examiner doesn't expect perfection on every manoeuvre, but they are filling in boxes: mirror-check, shoulder-check, speed. Miss a box too many times and a perfect parallel park doesn't save you. The same applies here.

The seven dimensions

1. Requirements gathering

Before touching a single endpoint, you should be interviewing the interviewer. The prompt "design a URL shortener" is deliberately underspecified — it could be a personal toy script or the next bit.ly handling 50 billion clicks a day. The right move is to surface and record functional requirements ("what does the shortener need to do?") and non-functional requirements ("how many redirects per second? link expiry? analytics?") before committing to any design. Interviewers watch whether you ask or assume.

2. Correctness of the API model

Once requirements are agreed, does your API actually satisfy them? This covers resource naming, method semantics (POST to create, PUT/PATCH to update, DELETE to remove), correct status codes, and whether the request/response shapes contain everything a real client would need. A common failure: designing endpoints that work for the happy path but have no way to signal partial failure, or returning a 200 when the work was only queued.

3. Non-functional and scale

Real APIs must survive load, latency targets, and data volume. Interviewers expect you to name the constraints ("10 k writes/s, p99 latency < 100 ms, 5-year data retention") and then show how your design satisfies them. This is where you mention read replicas, eventual consistency, async processing, or a CDN — but only when the scale warrants them. Adding complexity nobody asked for is just as bad as ignoring scale entirely.

4. Trade-off reasoning

No design choice is free. Normalising data improves consistency but increases join cost. Caching improves latency but adds staleness risk. Pagination reduces payload size but complicates client state. Senior candidates don't just pick an option — they name the cost of each choice, explain why they're accepting it, and acknowledge what they'd revisit if requirements changed.

5. Communication and narration

An interview is a collaborative conversation, not a whiteboard monologue. You need to: state your current intent before drawing, verify assumptions out loud, signal when you're simplifying ("I'll stub auth for now and come back"), and keep the interviewer oriented. Silence + a flurry of boxes is the single most common red flag. Narrating also helps you — talking through a decision often surfaces gaps before the interviewer points them out.

6. Cross-cutting concerns

These are the themes that cut across every modern API. Interviewers check whether you address them without being prompted:

• Authentication & authorisation — who can call it, scoped to which resources?
• Rate limiting — per key, per IP, or per tenant? what happens at the limit?
• Idempotency — can clients retry safely? do you need idempotency keys?
• Pagination — cursor vs. offset, what's the max page size, stable sort?
• Versioning — URL path, header, or content negotiation?
• Caching — which responses are cacheable, for how long, and by whom?

You don't have to design every one in depth, but you should name which apply and show awareness of the rest.

7. Depth under follow-ups

After the open-ended design phase, interviewers probe with targeted questions: "What happens if the database goes down mid-write?", "How would you evolve this API to support multi-tenancy?", "What breaks at 100× current load?" These questions separate candidates who have a shallow first-draft from those who understand the second and third-order effects of their choices. Good preparation means asking yourself "but what if …" for every assumption in your design.

Junior · mid · senior signal table

The same dimension can be answered at three different quality levels. Here's what each looks like in practice:

A worked example: scoring a payment API answer

Suppose the prompt is "Design the API for charging a customer." Here's a rough candidate answer and how it maps to the rubric:

POST /v1/charges
Body: { "amount": 2999, "currency": "usd", "payment_method": "pm_abc",
         "idempotency_key": "order_7c3a" }
← 201 { "id": "ch_01", "status": "pending" }

GET /v1/charges/ch_01
← 200 { "id": "ch_01", "status": "succeeded", "amount": 2999 }

POST /v1/charges/ch_01/refunds
← 201 { "id": "re_02", "status": "pending" }

Scoring that answer:

• Requirements: n/a here (assumed), but a real candidate should have asked: online vs in-store? multi-currency? recurring? partial refunds?
• Correctness: Strong — correct methods, 201 for creation, resource-oriented.
• Cross-cutting: Idempotency key included (good). Auth not shown (flag). Rate limiting not mentioned.
• Trade-offs: Two-step async pattern (pending → succeeded) was chosen — needed narration of why (card networks are slow).

Sources & further reading

• donnemartin — System Design Primer (widely used rubric reference)
• Stripe API reference — a real-world benchmark for idempotency, error envelopes, and versioning done well
• Google Cloud API Design Guide — resource-oriented design best practices
• Google SRE Book — SLOs — how to frame NFR conversations