SpeakUp SD

Technical Deep Dive

Present a technical deep dive of a system you personally built — the format used in senior/staff interview loops where you narrate one project end to end and defend your decisions under questioning.

00

Practice checkpoints

The requirements are open as a taste. From the numbers onward, the full guide opens in the app.

  1. 01
    Clarify scope
  2. 02
    Requirements + scale
  3. 03
    API + data modelUnlocks in the app
  4. 04
    Draw architectureUnlocks in the app
  5. 05
    Deep diveUnlocks in the app
  6. 06
    Trade-off decisionUnlocks in the app
01

Requirements that shape the design

Do not only state requirements. Ask for them. Each card pairs the design constraint with a clarification question you can say out loud before drawing the architecture.

Functional requirements

01What was the system for, in one sentence?

Open with the business problem and the one number that sized it (users, requests, dollars) — before any boxes appear on the whiteboard.

02Which part of this was actually yours?

Draw the ownership boundary up front: the components you designed and operated versus what teammates, platform teams, or tooling supplied.

03Walk me through one request, end to end.

Trace one real request end to end through the diagram — entry to response, what each hop does and its share of the latency budget — instead of touring every box.

04What was the hardest call, and what did you reject?

Present the hardest decision as a ledger: the constraint numbers at the time, the option chosen, the strongest rejected alternative, and the evidence that separated them.

05What broke in production?

Tell one real production incident: the trigger, the blast radius, time to detect, time to recover, and the design change it forced.

06Would you build it the same way today?

Close with measured outcomes against the original targets and one honest regret — what you would build differently today, and why the original choice looked right then.

Out of scopeTouring every service on the org diagram — anything you cannot open two levels deeper does not belong in your walkthrough · Company history, team politics, and product-roadmap narration — minutes spent there carry zero technical signal · Re-designing the system live as a fresh whiteboard exercise — this format defends what was actually built and measured

Non-functional requirements

01How busy was it, actually?

Every scale claim carries a number you personally measured — QPS, p95, data size, monthly cost — because "large-scale" is an invitation to drill until a number appears.

02Can you go one level deeper on that box?

Depth on demand: any component you drew, you can open two levels further (queries, data layout, failure mode) — if you cannot, it does not belong on your diagram.

03Was that you, or your team?

Attribution honesty: "I" only for work you can defend alone, "we" with your slice named — overclaiming collapses on the third follow-up, and one collapse ends the loop.

04What was your worst day running this?

One real failure told with numbers — blast radius, time to detect, time to recover — because a system that never broke reads as a system you never operated.

05How much of the slot will you spend narrating?

Pacing: the planned narration fills at most two thirds of the slot — the interviewer’s questions are the scoring surface, not an interruption to survive.

Keep asking — the interview is a conversation

Real interviews probe far more than a tidy list. These are the scope questions that separate candidates who interrogate the problem from those who recite it.

  • Would you like the 60-second overview first, or should I go straight to the architecture?
  • I can go deeper on the data model or on the scaling story — which is more useful to you?
  • Should I walk the happy path first, or start from the production incident?
  • How deep do you want on this component — design level, or down to the queries and indexes?
  • We have about fifteen minutes left — do you want my retrospective, or keep drilling here?
01

Unlock the full playbook for Technical Deep Dive

Numbers, architecture diagram, API and data model, deep dives, expected topics, self-check, whiteboard starter, and common mistakes unlock inside the app.

02

Numbers that force architecture decisions

Locked in the app

03

Architecture path

Locked in the app

04

API and data model

Locked in the app

05

Deep dive directions

Locked in the app

Practice this in the app →Browse pattern series
+Series

Practice the related series

Core system design foundations1 questions