Mock Interview Practice
Run a timed 45-minute mock alone or with a partner, then work eight new prompts with clarifying questions, likely deep dives and a self-review.
Reading ten case studies feels like progress. Then the clock starts, someone is watching, and you hear yourself say "um, so, a database" with no plan. Reading trains recognition; interviews test saying a design out loud, on time, while someone interrupts.
The fix is timed, spoken practice on prompts you have not seen: how to run a session, then eight prompts no case study covers.
Run a 45-minute mock
Use the split from the real interview. Each step says what a partner does, and what you do alone.
0-2 read the prompt, say your plan2-11 clarify, then estimate11-17 API and data model17-27 high-level design, end to end27-42 deep dives and failures42-45 wrap up: weakest part, next stepsafter review the recording with the checklist- clock
- 0 min
1Draw a prompt, start a recording, say your plan out loud. A partner only reads the prompt.
- clock
- 2 min
2Ask your questions. A partner answers from a facts sheet written beforehand. Alone, write your assumed answers first, so you cannot quietly change them.
- clock
- 11 min
3Endpoints and records. Start the 15-minute timer on a prompt below at minute 0: when it rings, you should be finishing this step.
- clock
- 17 min
4One path working end to end. A partner stays quiet unless it does not connect.
- clock
- 27 min
5Go deep on the hard part. A partner probes: "what if this dies?", "10 times the traffic", one curveball. Alone, ask yourself those three out loud.
- clock
- 42 min
6Name your design's weakest part and what you would do next.
- clock
- review
7Replay the recording and tick the checklist at the end of this page. A partner gives one strength and two fixes; work on those two next time.
| Option | Good at | Bad at | Pick it when |
|---|---|---|---|
| Random draw Usual default | Like the real thing: you do not choose. | May repeat your strengths. | Most sessions. |
| Your weakest area | Fixes a known gap fast. | Easy to overfit to one pattern. | After two reviews flag the same gap. |
| The company's domain | Interviewers often ask near their product. | Tempts you to memorise one answer. | The final week before a specific interview. |
Eight prompts
Run the whole mock before opening a box's notes: questions to ask, likely deep dives, and three checks for your review.
A mobile game with 20 million daily players wants a global leaderboard and a "your rank" screen.
Compare with a model answer
Ask: global only, or friends too? Daily, weekly or all-time? How often do scores change? Must rank 9,000,000 be exact, or is "top 45%" fine?
Deep dives: a structure that answers rank in O(log n), such as a sorted set; sizing: 20 million entries at about 100 bytes is 2 GB, so one in-memory node and a replica hold it, and sharding is not the hard part; rejecting impossible scores.
Check yourself: I estimated peak score updates. I argued exact versus approximate rank. I rebuilt the board from durable scores when its node died.
A chain of 500 garages wants online reservations and entry gates that keep working when the network is down.
Compare with a model answer
Ask first: "The class design or the distributed system?" It is asked both ways. Then: specific spots or a count per type (compact, EV)? How long is a reservation held for a late driver?
Deep dives: no double booking, with a conditional decrement on (garage, type, time slot); the gate's offline mode, with today's reservations cached locally and synced later; paying once even when the gate retries.
Check yourself: I said the scale is small. I designed the offline gate and its sync. I made payment idempotent.
10,000 servers each send 200 metric values every 10 seconds. Engineers want charts for the last 30 days and alerts.
Compare with a model answer
Ask: how fresh must charts be? How long is full resolution kept? How many label combinations? Can data arrive late?
Deep dives: ingest rate, 10,000 × 200 ÷ 10 = 200,000 points a second, buffered through a stream; time-series layout partitioned by metric and time, compressed; rollups to 1-minute and 1-hour points so a 30-day chart reads 720 hourly points per series, not 259,200 raw ones.
Check yourself: I computed the ingest rate. I planned rollups and retention. I said what happens to alerts if ingestion falls behind.
Users submit solutions to programming problems: 10,000 submissions an hour, 10 times that during contests.
Compare with a model answer
Ask: which languages? Time and memory limits per test? Is there a contest scoreboard? (The code is untrusted; say so yourself.)
Deep dives: sandboxing with no network, CPU and memory limits, a fresh environment per run; workers sized for contests: 10,000 an hour is about 3 a second, 30 at peak, and at 10 seconds per run that is 30 × 10 = 300 runs at once; returning results by polling or push.
Check yourself: I treated submitted code as hostile. I sized workers from rate × run time. I said what users see when the queue is long.
Travellers search and book rooms across 50,000 hotels for date ranges.
Compare with a model answer
Ask: specific rooms or a room type? Pay now or at the hotel? Is any overbooking allowed? Do hotels also sell through other sites?
Deep dives: inventory as a count per (hotel, room type, night), so a three-night stay decrements three rows in one transaction, each only if above zero; search from a stale copy, the real check at booking; a hold that expires if payment stalls. Compare ticket booking.
Check yourself: I booked a date range atomically. I split stale search from strict booking. I handled abandoned payments.
Readers comment under articles on a news site. Most articles get a few comments; a breaking story gets thousands an hour.
Compare with a model answer
Ask: how deep can replies nest? Sort by newest or top? Moderation before or after publishing? Must new comments appear live?
Deep dives: storing threads (a parent id per comment, plus a thread path for sorting) and cursor pagination; caching the breaking story's first page for a few seconds; asynchronous moderation that can hide a comment later.
Check yourself: I chose a thread model and showed one page's query. I handled the hot article. I said what users see during moderation.
Show owners of short links clicks per hour, top countries and unique visitors. Peak traffic is 20,000 clicks a second.
Compare with a model answer
Ask: how fresh, seconds or an hour? Exact unique visitors, or within 1%? How long are raw clicks kept? Should bots count?
Deep dives: stream aggregation into per-link, per-hour counters, with raw events kept for reprocessing; approximate uniques with a sketch such as HyperLogLog, under 1% error in about 12 KB per counter; duplicate and late events. It extends the counting in the URL shortener.
Check yourself: I kept analytics off the redirect path. I justified exact or approximate uniques. I fixed a counting bug by replaying raw events.
Timed auctions. Most get a few bids, but the last minute of a popular one gets hundreds of bids a second.
Compare with a model answer
Ask: minimum increments? Does a late bid extend the end? What do watchers see live? When is the winner charged?
Deep dives: ordering bids on one auction, with a conditional write "only if higher than the current top" or one owner per auction; pushing new top bids to watchers through persistent connections; closing on the server's clock, never the client's.
Check yourself: I serialised bids per auction, not globally. I sized the live fan-out. I handled a bid at the closing second.
In the interview
Use the same opening on every unseen prompt, so something automatic comes out while you think:
- "Let me make sure I have the scope: [restate it]. A few questions on features, then scale."
- "I'll get one path working end to end, then go deep on [the hard part]."
Your auction service just died during the last minute of a popular auction. What happens?
Bids are rejected until another instance takes over, maybe 10 to 30 seconds. Accepted bids are in the database, so none are lost. But bidders lost part of the last minute, so I'd extend the auction by the outage length.
Practise the closing follow-ups: "What would you build first?", "What is weakest?", "How would you know it works?"
Common mistakes
A code judge gets 30 submissions a second at contest peak, and each run takes about 10 seconds. How many runs are in progress at once?
You have run three mocks. Two reviews say you never raise failure until asked. What should the next session be?
After your attempt, tick what you really did. Be strict: "I thought about it" is not "I said it out loud".
Opening
Numbers and shape
Depth
Delivery
What to practise next
When a review flags the same gap twice, go back to its lesson: trade-offs, common mistakes or numbers to know.