System design interview practice — solo, with AI feedback

System design is the round where strong engineers underperform and average engineers occasionally hit a home run, because the bar isn't "do you know the answer" — it's "can you reason about a fuzzy problem out loud under time pressure". You can drill that. AI mocks give you the rare combination of unlimited reps and consistent, structured feedback.

What's actually scored in a system design round

Candidates assume the score is "did you design the right system". It's not. Real interviewers score five things, and they correlate weakly with each other. First: did you clarify the problem before designing — concretely, did you ask about scale, read/write ratio, latency requirements, and constraints. Second: did you do back-of-envelope math, or did you wave at "lots of traffic" without numbers. Third: did you propose an API and data model before drawing boxes. Fourth: did you make an architecture that fits the requirements you just defined — not a generic one. Fifth: did you go deep on at least one component and articulate tradeoffs, or did you stay at the surface for an hour.

Most candidates fail on #1 and #5. They start drawing immediately because it feels productive, and they stay at the "boxes and arrows" level for the entire hour without ever defending a single choice. The fix is structural: follow a framework, on every problem, until the framework is automatic.

The framework: six phases, on every problem

Use this on every design, including the ones that look easy. It's slower the first three times and faster forever after.

1. Clarify (5 min). Functional requirements — what does the system do, what does it not do. Non-functional — scale, latency, availability, consistency. Constraints — budget, team, regulatory. Confirm scope before designing. The interviewer will sometimes give you no scope on purpose, to see if you ask.
2. Estimate (5 min). Users, QPS, storage, bandwidth. Write the numbers down (out loud, since you're talking). 100M DAU, 10 reads per user per day, 80/20 read/write split — that's roughly 12K QPS read, 3K QPS write. You don't need to be right; you need to be plausible.
3. API (5 min). Define the 3–5 most important endpoints. Method, path, params, response shape. This step matters more than candidates realize because it forces you to name your nouns. "POST /shorten" with a body of {url, custom_alias?} is more concrete than waving at "the URL service".
4. Data model (5 min). Tables or document schemas, keys, indexes. State your data store choice (Postgres, DynamoDB, Cassandra) and defend it in one sentence. The choice is part of the data model — not a separate decision later.
5. Architecture (15 min). Now you draw boxes. Client, load balancer, API gateway, services, caches, message queues, databases. Walk through the read path and the write path separately. Don't try to draw the perfect diagram on the first pass — sketch it, then add boxes as you discover you need them.
6. Deep dive + tradeoffs (15 min). The interviewer will say "let's go deep on X". Or they won't, and you should volunteer. Pick the most interesting component and explain how it works in detail — replication strategy, eviction policy, scaling approach. End with explicit tradeoffs: "we picked eventually consistent because the use case tolerates 30 seconds of staleness and the alternative was a 3x cost increase".

Common designs you should rehearse cold

URL shortener

The deceptively easy one. The system is simple — generate a short ID, store the mapping, redirect on lookup. The interview is hard because the interviewer pushes you on every detail. How do you generate IDs? (Random vs incrementing vs base62 hash — each has tradeoffs.) What database? (KV store like Redis for hot reads, relational for analytics.) How do you handle collisions? (Retry with longer ID, or pre-allocate a pool per node.) What's the read/write ratio? (100:1 minimum — design for read-heavy.) Caching strategy? Read-through with high TTL since URLs rarely change. This design covers maybe 40% of the topics that show up in other designs too.

Social feed (Twitter-style)

Fan-out is the canonical question. Push (write tweet → write to all follower timelines) vs pull (write tweet → read from following list at query time). Push optimizes read latency at the cost of write amplification — bad for celebrity accounts with 10M followers. Pull optimizes write cost — bad for users with thousands of follows. The real-world answer is hybrid: push for normal users, pull for celebrities. Be ready to explain which threshold you'd pick (e.g., follower count > 10K triggers pull behavior) and why.

Chat system

Three interesting subsystems: message storage, delivery, and presence. Storage: partition by conversation ID, store messages in append-only logs, archive cold conversations. Delivery: websocket connection per active user, message queue for offline delivery, push notifications for mobile. Presence: ephemeral, heartbeat-based, eventually consistent. The interviewer will push on message ordering (causal? total? per-conversation total ordering is usually enough) and delivery guarantees (at-least-once is the default — handle dedup on the client).

Using AI mocks for system design specifically

Pick "Full Interview" mode and tell the AI you want a system design round, not a screening. Specify the design ("URL shortener", "Instagram feed") or let it pick. Talk through the framework out loud — describe what you'd draw, walk through the read path, explain tradeoffs as you make them. The AI will follow up with the same kinds of questions a real interviewer asks: "what happens if the cache fails?", "how do you handle a hot key?", "what's your replication strategy and what's the failure mode?". Answer in complete sentences with explicit tradeoffs, because that's how the real round is scored.

One specific trick: tell the AI to act as a senior interviewer at a FAANG. It will push harder on assumptions and refuse to accept generic answers. This is the highest-leverage setting for senior+ candidates because you need practice defending choices against pushback, not just stating them.

What the AI feedback won't catch (and what to do about it)

AI feedback is excellent at structure, tradeoff articulation, and missed components. It's weaker on diagram quality (you're describing, not drawing) and on whether your numerical estimates are realistic for the specific company's scale. Mitigate by doing one or two sessions with an actual whiteboard — open excalidraw on a second monitor and draw while you talk. Pair AI mocks with one or two peer or coach rounds in the last week before the real interview, especially if you're going for staff or principal.

For the parts AI is great at: structure and tradeoff articulation. Re-read the scored feedback after each session and write down two concrete changes for the next one. Two changes per session compound fast — three sessions and you'll be measurably more structured than 80% of candidates walking into the room.

Frequently asked questions