Practice rounds
Most of Semicolony is reference material — long-form deep dives you read when you want to understand something. This section is the opposite. Pick a flow, set the timer, work through it the way you'd work through an actual interview round. Every flow links back into the deep material when you need to look something up.
Four flows are live: a 45-minute system-design round with fourteen canonical prompts, a hundred interview flashcards across six categories, a coding pattern drill covering twenty patterns, and a request-trace exercise for networking rounds. Supporting material covers the day-of warm-up, company loop shapes, a self-grading rubric, and L5 vs L6 vs staff differences.
Live flows
01
System design · 45 min
A randomised prompt from the system-design playbook — URL shorteners, news feeds, rate limiters, ride-matching, object storage. A clock counts down 45 minutes, divided into the seven phases of a real interview: clarify, capacity math, API + schema, high-level architecture, deep dive, scaling + failure modes, follow-ups. When the timer ends, the reference solution from the playbook unlocks for comparison.
14 prompts45 minself-scored
02
Concept drill · 15 min
A hundred cards across six categories: distributed systems (consensus, CRDTs, quorums), databases (LSM, MVCC, vacuum), networking (TCP, HTTP/2, BGP), operating systems (mmap, page faults), system design (queues, caching), and languages (goroutines, GC, the event loop). Filter by category. Spacebar to reveal, arrows to navigate.
100 cards · 6 categories~15 min per passkeyboard-driven
03
Coding patterns · 45+ min
Pick one of the twenty canonical coding patterns — two-pointers, sliding window, BFS, DFS, backtracking, DP, greedy, heap, monotonic stack, union-find, trie, topological sort, bit manipulation, linked list, tree DP, graph algorithms, math, binary search, recursion, hash map. Three problems per pattern at escalating difficulty (easy, medium, hard), each with a reveal-able approach hint and a LeetCode link. Pattern-wide timer.
20 patterns60 problemstime-boxed
04
Request trace · 25 min
The "what happens when you press Enter" warm-up. Six scenarios — curl to an EC2 instance, browser to a CDN, signed S3 URL, SSH tunnel to managed Postgres, gRPC through Istio, WebSocket through an L7 LB. Write your trace freehand (saves to your browser), then reveal the canonical step-by-step trace with deep-dive links.
6 scenarios~25 minself-scored
Supporting material
Day-of
Printable checklist for the night before, morning of, between rounds, and after the loop. Plus a one-page trade-offs cheat sheet.
Open →Companies
FAANG-tier loop shapes — Google, Meta, Amazon, Apple, Netflix, Stripe. Round-by-round breakdown, quirks, what they're grading on.
Open →Self-grade
24-point self-scoring rubric across the seven phases. Deep dive is double-weighted. Calibrated bands map your total to a hire / no-hire reading.
Open →Levels
What actually changes between senior, staff, and principal IC loops. Round-by-round delta. Common downlevelling signals.
Open →Software engineers with three to ten years of experience interviewing for L5 / senior, L6 / staff, or equivalent IC roles at FAANG-tier companies and the hundred or so other companies that run the same kind of loop. The flows are biased toward the system-design round and the distributed-systems concepts round, because those are the two that most candidates with strong fundamentals still find hard. Coding rounds get less attention here — there are better resources for raw LeetCode reps elsewhere.
If you are interviewing for an L4 or junior role, the flows still work — the system-design round is the same shape, just shallower. The flashcards and pattern drills are level-agnostic. If you are interviewing for a principal / staff+ role, the flows are a warm-up; the real prep at that level is mentoring junior engineers through their interview prep and remembering what fundamentals look like.
The pattern that worked for a half-dozen senior engineers we have helped through interview loops. Six hours a week, four weeks. Adjust by ±1 week depending on how rusty you feel on day one.
Refresh fundamentals. Read or re-read Designing Data-Intensive Applications chapters 5–9 (replication, partitioning, transactions, consistency, consensus). Skim the Spanner, Raft, and Dynamo papers. The aim is not memorisation — it is making the vocabulary feel native.
Start the flashcards. One pass over the hundred cards takes about 30 minutes; note the ones you fumble. Open the deep-dive linked under each fumbled card and spend the rest of the week reading those. Then do another pass. The cards you still miss are your study list.
2 weeks out
Time-boxed rounds
Start the 45-minute system-design rounds. Do one round every other day. Do not skip the timer — practising without it gives you false confidence in your pacing. After each round, compare your work against the reference solution; write down two specific things you missed. Aim for five rounds in this week.
Stop adding new material. Do one final flashcard pass on Monday or Tuesday. Do one final timed round on Wednesday. Sleep, exercise, and re-read your own notes on the two days before. Walking into a round tired with new concepts in your head loses to walking in rested with last week's patterns sharp.
Patterns we have watched candidates repeat across hundreds of mock rounds. None of them are about gaps in knowledge — they are about pacing, framing, and committing.
The five minutes you spend pinning down requirements is the most expensive five minutes you have. A round that drifts into a 400 QPS write path when the real requirement was 4M QPS spent the whole hour solving the wrong problem. Ask: read/write ratio, latency budget, "available" definition, the consistency model the product needs, what counts as a hot key, geographic distribution.
Saying "we shard at a few thousand QPS" without showing the math reads as "I am repeating something I read". Always do the napkin estimate on the whiteboard — peak RPS, bytes per request, storage in TB, bandwidth in Gbps. Even rough numbers anchor the rest of the design and signal that you can actually reason about scale.
Drawing client → load balancer → app → cache → database for forty-five minutes is what bombs senior rounds. The interviewer wants you to pick the load-bearing component (the hot read path, the write fanout, the matching algorithm) and go deep. If you do not nominate that component yourself, the interviewer will, and you will be answering on someone else's terms.
Sprinkling "consistent hashing", "CQRS", "event sourcing" without context is a red flag. Each pattern has a cost — name it. If you say "we use consistent hashing to balance load", the follow-up is "and what does that cost when a node joins or leaves?". If the cost is news to you, the interviewer downgrades.
Walking through three options without picking one is a senior anti-pattern. Pick. State the trade-off you are accepting. Defend it. The interviewer will push, and you will refine — but the design has to start somewhere. "I would lean SQL because the access pattern is mostly key lookups by indexed columns, and the operational tooling around Postgres is mature" beats "well, you could go SQL or NoSQL, depending".
Senior rounds expect at least one substantive answer to "what fails first?". Hot keys, slow downstream services, region outages, queue backpressure, runaway clients — pick one and walk through the symptom, detection, blast radius, and recovery. If you have run anything in production, this is the section where it shows.
Two engineers can produce the same final architecture and still leave the interviewer with very different ratings. The difference, in our experience, is structure plus owned trade-offs. Structure means walking through the seven phases in order, naming the phase you are in, and not skipping the boring ones. Owned trade-offs mean every choice has a defensible reason, and you can name what you gave up to get it.
"Owned trade-offs" is also why CAP and PACELC come up so often in senior rounds — they are the canonical examples of an unavoidable trade-off, and an interviewer asking about them is testing whether you can reason about cost, not whether you can recite letters.
LeetCode is a problem bank — thousands of coding problems with sparse explanations. designgurus is a paid course. This is a small set of time-boxed practice flows that drill the four most common senior-IC interview shapes (system design, distributed-systems concepts, coding patterns, request walkthroughs), each linked back to long-form reference material on the site. There is no progression and no progress tracking — pick a flow and start a timer.
The system-design round is the same shape at L4, L5, and L6 — the difference is depth in the "scaling + failure modes" section and breadth in trade-offs. The flashcards and pattern drills work at any level. If you are interviewing for an L4 role, ignore the staff-level distractions in the system-design prompts (e.g. multi-region active-active) and focus on the basics.
Most candidates with 5+ years of experience need 4 to 8 weeks of part-time prep (about 6 hours a week) before a FAANG-tier round. The bottleneck is usually system design — you need to have driven enough production systems that the trade-offs feel intuitive, not memorised. Coding rounds need less prep if you write code daily; flashcards close the rest of the gap in a week.
In the last few years: feed / timeline systems, key-value stores, distributed counters and rate limiters, search and typeahead, real-time chat, ride-matching, notifications, ride-share / object storage, and pipelines (event ingestion, distributed scheduling). The fourteen prompts in our system-design flow are drawn from this canonical set. Less common but still tested: video streaming pipelines, payments, multi-region replication design.
For system design: Designing Data-Intensive Applications by Martin Kleppmann is the universal recommendation. For coding patterns: Cracking the Coding Interview is dated but the section on patterns is still good. For distributed-systems theory: read the Spanner, Raft, and Dynamo papers in the /papers/ section of this site — they get cited often in interviews.
No. The system-design flow unlocks a reference solution from the playbook when the timer ends; you compare against it yourself. The flashcards reveal an answer drawn from the related deep dive. There is no scoring, no progress, no streaks. The point is to surface gaps, not to optimise a number.
No. Behavioural rounds are too company-specific and too context-dependent for a generic flow to help. The Manager Tools podcast and the book Cracking the PM Interview (yes, despite the PM in the title — the leadership chapter generalises) are the public resources we recommend.
The interview flows sit on top of the long-form material on the site. The pages below are the most useful when prepping for a round: