When I was preparing for the Google product management interview, there was a technical round. Google has since narrowed it to a few PM roles, but at the time everyone got it, and I prepared the way everyone does. I read Alex Xu. I went through the System Design Primer. I read a stack of engineering blogs. It helped less than I expected.
What helped was asking friends at Google and Meta to interview me. Not to explain a system, but to hand me a problem, question me, probe me, and push until I was standing at the edge of what I knew. The single most useful session was with Mayank, my co-founder now, who was at Meta at the time. He did not let anything slide. Every box I put down came with a “what happens when that dies,” and every number I quoted came with a “where did you get that.”
I belive that’s the core of system design interview. You have to be clear what you know and what you do not. For the part you know, the trade-offs have to come out: why this, why not that, what breaks first. For the part you do not know, and there is always a part of the stack you do not know, you say so, reason about it out loud, and make a decision anyway. The interviewer is not looking for someone who knows everything. They are looking for someone they would be comfortable designing a system with.
The problem is getting enough of those sessions. Friends who have done the job are busy, and you get one or two conversations. Peers are easier to find, but peers are gentle. They do not push you to the boundary, and they do not give you calibrated feedback, so you leave feeling fine and learning little.
That experience is the brief for what we built. We have run product management and coding interviews on Tough Tongue AI for over a year and could have shipped a chat-style system design mock any time. We did not, because a chat cannot see what you drew. What we built instead starts with a vague prompt, opens a notepad where you decompose it and write down your judgment, moves to an architecture board where you draw the system, and then probes you on every box you placed. Do it ten times and the clarifying questions become reflex, the whiteboard stops being frightening, and being probed starts to feel normal. That is the state you want to be in when the real one starts.
This post covers what a system design interview actually tests, how the current AI tools compare, and 7 interviews on the board you can run tonight.
What a system design interview actually tests
A typical round runs 45 minutes at a big tech company, sometimes 60 at senior and staff level. You get a one-line prompt: design a rate limiter, design a web crawler, design Uber’s dispatch. You ask clarifying questions and lock requirements. You do a few minutes of capacity math. Then you draw a high-level design, and the rest of the interview is the interviewer pulling on threads in what you drew.
Underneath that shape, the interviewer is scoring three things.
Can you disambiguate and make progress. The prompt is deliberately vague. Turning it into scope, constraints, and a plan is the first test, and estimation is part of it, but only in service of a decision. You derive 10 million QPS through the rate limiter so you can conclude that QPS, not memory, forces the limiter to be distributed. You size the sliding log at 12 GB for a million users so you can argue for the 1.6 GB sliding counter instead. Reciting numbers scores nothing. Using them to pick an algorithm scores a lot.
Do you show trade-off judgment. The diagram is the artifact being judged, and the question behind every probe is whether the interviewer would be comfortable shipping what you drew. Would they stake their own promotion on it. That means knowing where it fails and where it scales: what happens when the box you just placed dies, what breaks at ten times the load, why you chose Cassandra over Postgres for this write pattern and not just in general. When speech and board disagree, a good interviewer asks about the gap, and how you handle that moment is signal.
Can you communicate, including what you do not know. Nobody asks “tell me about caching” in the abstract. They point at your cache and ask what is in it, what the hit rate needs to be, and what happens on a miss during a flash sale. The follow-up is generated from your design, not from the topic, and the test is whether you can work the problem with the person across the table the way you would with an engineer or PM on a real project: state your uncertainty, reason through it, and keep moving.
Where the current AI system design tools fall short
Most AI interview tools launched in the last two years are the same product underneath: a voice or text chat with a rubric at the end. That works for behavioral rounds. For system design it fails on all three points above, and the failure has a recognisable sound: the candidate narrating a diagram nobody can see. “So the load balancer forwards to service A, which talks to cache B, which falls back to database C.” Nobody in the room can point at anything, and the skill of drawing while talking never gets exercised.
With no board there is no artifact to judge, so the trade-off questions turn generic. With no answer key the feedback turns gentle, which is the same problem as practising with a friend. And most sessions are short, so the deep dives where the round is actually decided never arrive.
Some tools have added a canvas, which is progress. But if the AI only reads your board when you click submit, or walks you through a fixed sequence of steps, you get feedback on a finished drawing rather than an interviewer reacting to the drawing as it happens. The moment that separates candidates, the interjection right after you place the wrong box, is missing.
Here is how the main options compare, based on their own sites at the time of writing. Prices change, so treat that column as approximate.
| Tool | Format | Design board | Interviewer reacts while you draw | Full-length mock | Feedback | Price (per their site, Sept 2026) |
|---|---|---|---|---|---|---|
| ChatGPT or Claude with a prompt | Text, voice mode optional | No, you describe the diagram in words | No | Only if you push it | No rubric, grades generously | Free to $20 per month |
| Hello Interview, Guided Practice | Step-by-step guided practice on a whiteboard the AI reads | Yes | Checkpoint by checkpoint, in a fixed sequence (requirements, entities, API, high-level, deep dives) | Guided, not a free-running interview. Live human mocks wound down May 2026 | AI feedback per step; AI tutor is Q&A, not an interviewer | Premium $47 per month, $79 per year, $279 lifetime |
| interviewing.io | Anonymous live mocks with senior engineers, plus a free AI interviewer | Human mocks use a shared editor; AI interviewer is voice-first | Humans yes; AI, not stated | Human mocks yes | Written feedback from the engineer | Human mocks from $179 per session; AI interviewer free |
| Aced (formerly Exponent) | Peer mock matching with AI scoring, plus AI audio mocks | No dedicated design canvas | Depends on the peer you draw | Peer mocks yes | Peer feedback plus AI scoring | Around $79 per month, free tier with limited peer mocks |
| HackerRank AI mock interviews | Timed voice AI mock with a whiteboard | Yes | Not stated | Timed session | Post-session evaluation | 1 free session per month, then credits |
| Mockingly.ai | Voice or text AI with an interactive whiteboard | Yes | Real-time follow-ups per their site | Yes | Readiness score, detailed analysis on Pro | Free tier; Pro listed at $14 per month |
| Design Gurus / ByteByteGo | Courses and question banks | No live mock | No | No | None (self study) | Subscription |
| Tough Tongue AI, System Design collection | Voice AI interviewer on a shared notepad plus a live architecture board | Yes, typed components and labelled edges | Yes, it sees each element as you place it and interjects | 20-minute focused mock per question, candidate-led | Weighted rubric from the source book, hire band, top improvement areas | See the collection page |
A few honest notes on that table. Hello Interview’s written material is the best organised curriculum on the internet for this round, and its guided practice is a good way to learn the shape of an answer before you can improvise one. interviewing.io is still the place to go for a human who has actually sat on a Meta or Google hiring panel, and I would book one or two sessions there in the last two weeks regardless of what you use for volume. Mockingly.ai and HackerRank have both put a board in the room, which is the right instinct. What I could not verify from their sites is whether the interviewer reacts element by element mid-design or reads the board at checkpoints, so try the free tier and see for yourself.
What none of them do, as far as I can tell, is the thing in the last row combined: an interviewer that scribes requirements and math into shared notes, watches a typed architecture board as you build it, treats that board as the ground truth of your design, and grades you against the answer key from the book the question came from.
What we built instead
Each interview is a 20-minute voice session with a senior engineering manager persona who runs two surfaces.
The notepad is the interviewer’s. It opens with the agenda and blank sections for requirements and capacity math, and it fills in as you go. When you lock a requirement, it appears under Requirements. When you settle a number, the equation line lands under Capacity math. When you get stuck on the arithmetic, it writes a scaffold with blanks, 1M users x 10 req/sec = ___ QPS, and has you fill it aloud rather than handing you the figure.
The architecture board is yours. You drag typed components (clients, load balancer, API gateway, service, worker, Redis, queue, cache, blob store, and so on), wire them with labelled edges, and mark tiers as distributed when they scale out. The interviewer receives an event for every placement and connection. It does not narrate each one like a screen reader; it reacts like a person glancing at a whiteboard. Place a limiter tier with per-instance counters and it will ask how instance two knows about a request instance one counted. Draw a cache with no edge to anything and it will ask what reads from it. If it is not on the board, it is not in your design, and the interviewer will say so.
Three behaviours make the practice calibrated rather than merely available.
It probes your design, not the topic. The deep dives are picked from what you actually built. The interviewer reads the board before choosing where to dig, so two candidates on the same question get different second halves.
It hints on a ladder, and records where it had to. Stuck candidates get a nudge first (a question that names the gap), then a prescription (put a Redis between the limiter tier and the service fleet), then a sketch on the notepad with blanks. You still place the pieces. The report notes which rung you needed.
It grades against an answer key. Every question ships with a reference design and reference numbers, the same ones a well-prepared interviewer walks in with. The interviewer is told explicitly that the reference is one strong design and not a requirement, so a defensible alternative scores as well as the canonical one. But the rubric knows what a good interviewer knows: the boundary burst in a fixed window, the read-check-write race on a counter, the two places dedupe has to appear in a crawler, the DNS bottleneck nobody remembers.
Afterwards you get a report on a weighted rubric: requirements and clarification, capacity planning, architecture on the board, technical deep dives, scalability, and board usage and communication. Each score is backed by what you said or drew, you get a hire band (strong hire, hire, lean hire, no hire), your top improvement areas, and a percentile against everyone else who has run the question.
7 system design interviews you can practice now
Every interview below runs on the notepad and the architecture board and is graded on the rubric. The collection lives at System Design Interviews on Tough Tongue AI. Each one tells you where the signal concentrates so you can pick what to work on.
| Question | Where the signal is | Practice |
|---|---|---|
| Design an API Rate Limiter | Algorithm failure modes, the counter race condition, cluster-wide enforcement | Run |
| Design Pastebin | Key generation, read-heavy storage split, expiry and cleanup | Run |
| Design Typeahead Suggestion | Trie sharding, top-k caching, update pipeline vs query path | Run |
| Design a Web Crawler | URL frontier (priority vs politeness), two kinds of dedupe, the DNS bottleneck | Run |
| Design Twitter Search | Inverted index sharding, fan-out of queries, ranking under a latency budget | Run |
| Design Uber Backend | Location updates at scale, geo-partitioning, dispatch and matching | Run |
| Design Facebook Messenger | Persistent connections, message ordering, delivery guarantees, presence | Run |
If you want a suggested order: start with Pastebin or the API Rate Limiter to learn the rhythm of the two surfaces, since both have a small component count and the signal concentrates in one or two deep dives. Move to the Web Crawler when you want the board to matter (the frontier has to be the hub, dedupe has to appear twice, and the interviewer will check). Do Typeahead or Twitter Search for the sharding conversation. Save Uber and Messenger for when you want to be pushed on real-time state at scale.
A practice loop that works
The tool matters less than the loop you run it in. This is the one I give engineers.
- Run one board interview end to end. Twenty minutes, no pausing, pen and paper for the math if you want it. The first run is for finding out where you actually lose the interview, and it is rarely where you think. Most people believe they lose on deep dives; the reports say they lose on a board that does not match what they said.
- Read the whole report, not just the band. The category scores and the quoted evidence. If the interviewer had to hand you the shared store, that is your assignment.
- Redo the same question the next day. This is the step people skip and the one that produces most of the improvement. It tells you whether the fix stuck or whether you just knew the answer.
- Then one new question per day, mixing shapes. Alternate a small-surface question (rate limiter, Pastebin) with a large-surface one (crawler, Messenger). Alternate read-heavy with write-heavy. Real loops do not let you pick.
- Book one or two human mocks for the last two weeks. An AI interviewer cannot read the room or model the staff engineer who will actually sit across from you. Use it to get to the bar first, so the expensive human hours go to polish rather than to discovering you cannot size a sliding log.
Four ways to get more out of it
These are the things I show people in the video, in the order I would do them.
Read the notes first, then run the interviewer. Every question in the collection has reading material on the courses page, written from the standard sources for that problem. Read it the night before, not the hour before. The mock is for finding out whether the knowledge comes out under pressure, and that only works if the knowledge is there to begin with.
Adjust the difficulty. The default interviewer is calibrated to a real loop, which can be discouraging on your first attempt. Remix the agent into your workspace and prompt it to go easier: more hints, less pressure on the clock. Once you are clearing it, remix again and prompt it to be harder than the real thing. A friend who has interviewed at Meta will not go easy on you, and by the last week neither should this.
Build the question you were actually asked. If your target company is known for a question that is not in the collection, or you are recruiting for a specialised area (large-scale LLM serving, networking, storage), connect Claude or ChatGPT to Tough Tongue over MCP, paste in the chapter, the blog post, or your own notes, and generate an interviewer for it. Every question in the collection was built this way. The setup is on the agents page.
Let Claude be the coach between sessions. Once MCP is connected, Claude has access to your session history. Ask it where you lost points yesterday, which categories have been flat across your last five runs, or what to focus on tomorrow. The reports already tell you this per session; the coach view tells you what keeps happening, which is the thing a good human coach notices and a friend usually does not.
Where AI system design practice still has limits
I want to be plain about this, because the enthusiastic version overclaims and engineers will notice.
The board is typed, not free-form. You drag named components and wire them; you cannot doodle a consistent hash ring in the margin. That is a deliberate trade: typed components are what let the interviewer read the design and react to it, and most remote loops now use a structured canvas anyway. But if your real interview is a physical whiteboard, practice the drawing separately.
Twenty minutes is a focused mock, not a full round. Each interview goes deep on the two or three places where the question’s signal actually lives, rather than covering every phase at real-loop length. Chain two questions back to back if you want the endurance test.
And a rubric is only as good as its answer key. Reference numbers for a question vary between sources (the crawler’s scale, for one), and the interviewer follows the ones it was built with. When you disagree with a score, the transcript, the board, and the notepad are all there so you can check.
None of that changes the main point. For the parts of a system design interview that are learnable by repetition, which is most of it, the bottleneck has been an interviewer who can see your board and push you to the edge of what you know. That bottleneck has moved.
Start here
Pick the rate limiter from the table above, block twenty five minutes, and run it like it counts. Build the board while you talk. It will feel messier than reading about it did. That is the point. Then read the report and run it again.
The full collection is at System Design Interviews on Tough Tongue AI, and the rest of the interview courses are on the courses page. If you are earlier in your prep, the System Design Interviews 101 post covers the fundamentals before you start running mocks. For how the platform handles interactive tools beyond a conversation, the post on AI interview platforms goes deeper, and the AI interview practice page covers PM and coding rounds. If you did the consulting version of this, the MBB case interview post is the sibling of this one.
