Case interview for systems analyst

Why design cases dominate the SA loop

For middle and senior systems analyst roles, the design case is the load-bearing screen in the loop. Coding rounds are short and often optional, but a 45-to-60-minute whiteboard session where you sketch an integration, an API contract, or an event flow is where the offer is decided. A hiring manager at Stripe or Notion is not testing whether you can recite the CAP theorem — they want to see you take a vague prompt like "design webhook delivery for a payments product" and turn it into a defensible architecture, a written contract, and a list of trade-offs the engineering team can argue about on Monday.

The other reason cases dominate is risk insurance. A SA who ships a sloppy spec costs three engineering sprints; a SA who clarifies scope, picks the right consistency model, and writes a precise sequence diagram saves the same three. The case is a proxy for that judgment. You are graded on three axes: clarifying behavior, depth on the component that matters, and whether you name the two or three trade-offs any senior engineer would name unprompted.

The four categories you should expect

Almost every SA case falls into one of four buckets. Knowing the bucket lets you reach for the right vocabulary in the first minute.

A useful habit is to announce the category out loud in the first minute: "This sounds like an integration case, so I want to anchor on contract, idempotency, and failure modes — let me confirm scope before I sketch." That single sentence frames the next forty minutes for the interviewer and tells them you have seen this shape before.

The categories overlap — a Stripe webhook case is both integration and process — but naming the dominant one keeps you from drifting.

A four-step framework that scales

The four-step framework below is the one most senior SAs at companies like Linear, DoorDash, and Snowflake actually run. It is not original; it is just consistent. Run it the same way every time and the interviewer can grade you against a rubric instead of a vibe.

1. Clarifying questions — 5 to 10 minutes.
2. High-level architecture — 10 to 15 minutes.
3. Deep dive on the component that matters — 15 to 20 minutes.
4. Trade-offs and edge cases — 5 to 10 minutes.

If you blow past step one, you will spend step three defending a solution to the wrong problem. If you skip step four, the interviewer marks you down as junior even if your diagram is correct.

Step 1: clarifying questions

The goal here is not to interrogate — it is to narrow the surface area to something you can defend in forty minutes. Ask three to five questions, then summarize back what you heard. Three buckets cover most prompts.

Functional scope. What must the system do, and what is out of scope? Who are the users — internal operators, external developers, end customers? Which use cases are launch-blocking versus nice-to-have? The interviewer has a short list of two or three flows they want to see, and you find them by asking.

Non-functional scope. What is the rough order of magnitude — 100 requests per second or 10,000? What is the acceptable latency budget — p99 under 200ms or under 2s? What is the durability requirement — at-most-once, at-least-once, exactly-once? Is the system global or single-region? Are there compliance constraints like SOC2, HIPAA, or GDPR?

Constraints. Is there an existing platform — a Kafka cluster, a Postgres primary, a service mesh — that you must reuse? What are the team boundaries — one team or four? What is the timeline — a two-week spike or a quarter? These constraints often eliminate half the architectures you might otherwise propose.

End the step with a one-sentence summary: "So we are designing public webhook delivery, 5k events per second peak, at-least-once, single region, on the existing Kafka and Postgres stack. Sound right?" That sentence is worth points on its own.

Step 2: high-level design

Now sketch. Five to seven boxes, arrows showing data flow, and labels on the arrows for what is sync versus async. Keep this loose; you will refine in step three.

[Producer service] --emit--> [Outbox table] --CDC--> [Kafka topic]
                                                         |
                                                         v
                                              [Delivery worker pool]
                                                         |
                                                         v  HTTPS POST
                                                  [Customer endpoint]
                                                         |
                                                         v
                                              [Delivery attempts log]
                                                         |
                                                  retry / DLQ

While you sketch, narrate. Silent thinking does not score. Say "I am putting the outbox here so the producer transaction and the Kafka write commit together — that gives me at-least-once without distributed transactions." A two-sentence justification per box is the right cadence.

Show four things on the whiteboard: the major components, the data flow, where state lives, and which hops are synchronous versus asynchronous. Resist the urge to draw eighteen boxes. Five well-justified boxes beat eighteen sketched in panic.

Step 3: component deep dive

The interviewer will pick one component and ask you to go deeper. Sometimes they tell you which one; sometimes they wait for you to pick. If they wait, pick the component that maps to the case category — for an integration case, the retry and idempotency machinery; for a data case, the schema and partitioning; for a process case, the state machine.

For each deep-dive component, cover four artifacts. API contract: method, path, request shape, response shape, status codes, error envelope. Data model: the two or three tables or events that matter, with keys and indexes that determine the access pattern. Sequence flow: the happy path as a numbered list, plus one failure path. Cross-cutting concerns: auth, rate limiting, observability hooks.

A concrete example for the webhook case: the delivery worker pulls a batch from Kafka, looks up the customer endpoint and current backoff state in Postgres, posts with an idempotency key derived from the event ID, writes the attempt result back, and either commits the offset on success, schedules a retry on 5xx, or moves to the dead-letter queue after eight attempts over 24 hours. That paragraph is the kind of specificity that wins offers.

Step 4: trade-offs

The last ten minutes are not for cramming more diagram — they are for proving that you understand the cost of every decision you just made. Pick three or four axes and argue both sides.

The point is not that one column is correct — it is that you can name the condition under which each becomes correct. A senior signal is the sentence "I would pick A here because the customer base is largely backend teams that already handle idempotency; if we were shipping to mobile SDKs I would flip to B."

Common pitfalls

The most common failure mode is silent design. You stand at the whiteboard, draw for two minutes without speaking, then present a finished diagram. The interviewer cannot grade what they cannot hear. Talk through every box as you draw it, even if it feels redundant. Half of the rubric is your reasoning, not your final picture.

A close second is skipping clarification. The prompt "design a notification system" is deliberately under-specified. If you start sketching push, SMS, and email pipelines without asking who the users are or what the volume looks like, you will spend the rest of the session defending a system you did not need to build. Always ask at least three questions before the first box, and restate scope before moving on.

Perfectionism is a subtler trap. You do not need a production-ready design with circuit breakers, retries, and observability stitched into every box. You need the two or three components that matter rendered in depth, and the rest sketched. A SA who tries to render the whole system at uniform fidelity runs out of time and ships a shallow answer.

Ignoring non-functional requirements is a junior tell. If you finish the deep dive without naming a latency target, a throughput target, or a failure mode, the interviewer marks you down. You can recover even thirty minutes in by asking "what is the latency budget here, and what is the acceptable error rate?" Better late than never.

Single-path thinking — presenting one architecture as inevitable — costs the senior bar. Whenever you make a meaningful choice, name the alternative you rejected and the reason. "I am using Kafka instead of SQS because we need replay and the platform team already runs it." That sentence converts an arbitrary choice into a defended one.

The last pitfall is forgetting business context. The SA role exists to translate between product and engineering. If your design is technically tight but you cannot answer "why does this matter to the customer," you have done half the job. Tie every major decision back to a user outcome or a cost line.

Related reading

• Acceptance criteria with Given-When-Then for systems analysts
• Kafka questions in systems analyst interviews
• SQL window functions interview questions

If you want to drill SA design prompts the same way candidates drill LeetCode, NAILDD is launching with hundreds of real loop questions across exactly these four case categories.

FAQ

How long does a typical SA case interview run?

Most loops allocate 45 to 60 minutes per case, and a full onsite often includes two cases — one integration or API, one data or process — back to back. Plan your time so step one ends by minute 10, step two by minute 25, step three by minute 45, and you have ten minutes for trade-offs and questions. If the interviewer interrupts with a new constraint mid-way, treat it as a deliberate scope change and re-state the new scope before continuing.

Do I need to write code in an SA case?

Usually no, but you should be willing to write a short SQL query, a JSON request body, or an OpenAPI snippet if the conversation goes there. The expectation is that a SA can read code fluently and produce a precise contract, not that they can implement the service. If you are interviewing for a hybrid SA-engineer role at a smaller company, expect one round of actual coding.

How is this different from a software engineering system design round?

The two overlap heavily, but the SA version weights contract precision, scope discipline, and stakeholder framing more than the engineering version. An engineer can get away with a hand-wavy API as long as the back-end is solid; a SA cannot. The SA round is more forgiving on raw scaling math — you will rarely be asked to compute exact shard counts, though order-of-magnitude reasoning is still expected.

Should I bring a structured framework or improvise?

Bring the framework. Interviewers grade on consistency, and a candidate who runs the same four-step structure across every case looks senior. Improvisation is fine inside each step — which questions you ask, which components you deep-dive — but the skeleton should be repeatable. The framework gives you something to fall back on when the prompt is unfamiliar.

What if I do not know the domain at all?

Say so, briefly, and lean harder on the framework. "I have not built a payments system before, so I will lean on first principles — let me start with clarifying questions." Interviewers respect honesty paired with structure far more than confident bluffing. The cases are designed so a strong generalist can reason from scratch; what kills candidates is pretending to know things and getting caught on the follow-up.

How do I practice if I do not have a study partner?

Pick a prompt — "design webhook delivery," "design a feature flag service," "design order fulfillment with cancellations" — and write the answer as a one-page design doc. Set a 45-minute timer, run the four steps end to end, and force yourself to name three trade-offs at the close. After a dozen reps the framework becomes muscle memory.