What a tech interview loop actually tests
An interview loop is the full set of interviews a company runs on one candidate, usually four to six sessions over one or two days. Each round measures a different skill, so each one needs its own preparation.
Many candidates spend all their time on coding problems and walk into the design round with nothing prepared. The four rounds below are the ones you will meet at most large tech companies, along with what the interviewer is really grading.
Coding
You solve one or two problems in a shared editor while you talk. The interviewer cares more about how you reach the approach than about the speed of your typing.
A strong answer names the pattern, states the time and space cost before writing code, and tests one edge case at the end.
System design
You design a large service, such as a URL shortener or a chat app, on a whiteboard. There is no single correct diagram, so the interviewer grades your reasoning.
A strong answer fixes the requirements and the scale first, draws the simplest design that works, and then removes its biggest bottleneck.
Low-level design
Also called object-oriented design. You model a smaller system, such as a parking lot, as classes, interfaces, and the relationships between them.
A strong answer starts from the use cases, keeps each class responsible for one thing, and uses a design pattern only where it solves a stated problem.
Behavioral
You describe real situations from your work: a conflict, a failure, a decision you made without full information. The interviewer is checking your judgment.
A strong answer follows the STAR structure (situation, task, action, result) and ends with a number, such as a latency cut or a deadline met.
Learn the pattern, and new questions start to look familiar
Interview problems look endless, but most of them are variations of a much smaller set of patterns. A pattern is a reusable approach for a whole family of problems. Once you understand why a pattern works on one problem, you can recognize it on a problem you have never seen before.
Take the sliding window pattern. "Find the largest sum of any three numbers in a row" and "find the longest substring with no repeated letters" look unrelated. Both, however, ask about a run of neighboring elements, and both can be solved by keeping a window over that run and moving its two edges. That single idea turns a nested loop, which costs O(n×k), into one pass that costs O(n).
A memorized answer fails when the interviewer changes one detail of the question. A pattern still works after the change, because you know why it works.
System design works the same way, with building blocks in place of patterns. A load balancer, a cache, a message queue, and a replicated database appear in almost every large design. When you know what each block does and what it costs, a new design question becomes a question about which blocks to combine.
A system design answer in five moves
Here is the method applied to the most common opening question: design a URL shortener, a service that turns a long web address into a short one and sends visitors from the short address to the original page. The numbers are assumptions you would state out loud and confirm with the interviewer.
- Clarify the requirements. The service must create a short link from a long one and redirect a short link to its original page. Assume 100 million new links per month, and 100 redirects for every link created.
- Estimate the load. 100 million links per month is about 40 writes per second, so redirects run at about 4,000 reads per second. Over five years that is 6 billion links. At roughly 500 bytes each, storage is about 3 TB.
- Draw the simplest design that works. Users reach a load balancer, which spreads requests across a group of identical app servers. The app servers read and write one database that maps each short key to its long address.
- Remove the biggest bottleneck. Reads outnumber writes 100 to 1, so the database will feel the redirects first. Put a cache in front of it, so the most popular links are served from memory and the database only sees cache misses.
- Name the trade-off you chose. A short key can come from hashing the long address, which needs a collision check, or from a counter in a separate key service, which guarantees unique keys but adds one more component. Pick one and say why. Seven characters of letters and digits give about 3.5 trillion keys, which is far more than 6 billion.
The same five moves carry you through a chat app, a news feed, or a ride-sharing service. The components change from one question to the next, but the order of the conversation stays the same. Read the full step-by-step framework →
Where to begin, based on where you are now
The right first step depends on your experience and on which round is coming up first. Find the line that describes you, and begin at its first stop. You can skip a stop when you already know its material.
A one-minute self-test. Without notes, explain what a load balancer does, what happens when cached data goes stale, and why a database is copied to more than one machine. If any of the three is unclear, start with System Design Fundamentals. If all three are easy, go straight to Grokking the System Design Interview.
What each course teaches
The courses are mostly text, with diagrams and worked examples, so you can read at your own speed and come back to a lesson when you need it. Most courses let you preview lessons before you decide.
System Design Fundamentals
The building blocks every large design uses: load balancing, caching, replication, partitioning, and message queues. It assumes no earlier experience with distributed systems.
View course →The originalGrokking the System Design Interview
A step-by-step method for the design round, applied to 15 classic problems such as TinyURL, Twitter, Dropbox, and Uber, plus a full chapter on trade-offs.
View course →Senior and staffAdvanced System Design Interview, Volume II
Deeper problems and harder trade-offs for L5 and L6 loops, where the interviewer expects you to lead the discussion instead of following it.
View course →Coding roundGrokking the Coding Interview
The coding patterns behind most interview problems, each taught on a worked example first. Solutions are in Java, Python, JavaScript, C++, C#, and Go.
View course →Low-level designGrokking the Object-Oriented Design Interview
How to turn a vague problem into classes, interfaces, and relationships that an interviewer can follow, with code in Java and Python.
View course →BehavioralGrokking the Behavioral Interview
How to choose, structure, and tell stories from your own work, including the STAR method and the leadership principles that some companies grade against.
View course →Hear from Successful Tech Professionals
Here is what engineers who used the courses wrote about them, in their own words. Several of them describe the same change: a clear process for the interview in place of guesswork.
Thanks for a great resource! You guys are a lifesaver. I struggled a lot in design interviews, and Grokking System Design gave me an organized process to handle a design problem. Please keep adding more questions.
Software Engineer
Check out Grokking the Coding Interview. Instead of trying out random Algos, they break down the patterns you need to solve them. Helps immensely with retention!
Ashley PeanSoftware Engineer
Just wanted to say thanks for your Grokking the system design interview resource - it helped me immensely when I was interviewing from Tableau (very little system design exp) and helped me land 18 FAANG+ jobs!
Steven ZhangSoftware Engineer
I've tried every possible resource (Blind 75, Neetcode, YouTube, Cracking the Coding Interview, Udemy) and idk if it was just the right time or everything finally clicked but everything's been so easy to grasp recently with Grokking the Coding Interview!
Software Engineer
The famous "grokking the system design interview course" on designgurus.io is amazing. I used this for my MSFT interviews and I was told I nailed it.
Brandon LyonsSoftware Engineer
The courses which have "grokking" before them, are exceptionally well put together! These courses magically condense 3 years of CS in short bite-size courses and lectures (I have tried Grokking System Design Interview, OODI, and Coding patterns). The Grokking courses are godsent, to be honest.
Software Engineer
An eight-week plan for a working engineer
Most candidates need four to eight weeks of focused preparation. The plan below assumes the full eight weeks and seven to nine hours a week: short sessions on weekdays, one long session on Saturday, and one rest day. If your interview is sooner, shorten each phase rather than dropping one.
The days are not all the same on purpose. In the design weeks, a long session for a new problem alternates with a short session that reviews it. The last week is lighter, so that you arrive at the interview rested.
| Weeks | Focus | What you do | You are done when |
|---|---|---|---|
| 1 and 2 | Foundations | Review core data structures and Big-O notation. Read the system design building blocks: load balancers, caches, databases, and queues. | You can explain each building block in two sentences, including what it costs. |
| 3 and 4 | Coding patterns | Learn one pattern every one or two days, then solve about five problems that use it before moving on. | You can name the likely pattern within five minutes of reading a new problem. |
| 5 and 6 | Design problems | Work one classic design problem every two days on paper, with a 45-minute timer, using the five moves above. | You can run all five moves on a new question without looking at notes. |
| 7 and 8 | Practice and review | Do at least two mock interviews, write six behavioral stories in STAR form, and return to the patterns you found hardest. Keep the final days light. | Each story ends with a number, and no pattern is one you avoid. |
Eight weeks is not enough to finish every lesson in every course, and you do not need to. Cover the patterns and problems that appear most often first, then go deeper where you are weakest.
Free material you can read today
A large part of the site needs no purchase and no account. These are the best places to start if you want to try the teaching style before you commit to a course.
Learn System Design
Full-text lessons on the core concepts, from scaling and caching to API design. You can read every lesson without signing up.
Start reading →The system design interview, explained
What the round looks like, how it is graded, and how to prepare for it.
Read free →QuestionsCommon system design questions
The questions that come up most often, with guidance on how to approach each one.
Read free →ConceptsCore system design concepts
Short explanations of the terms you will hear in every design round, from sharding to consistency models.
Read free →CodingBlind 75
The 75 problems most often recommended for coding practice, in one list you can work through.
Read free →RoadmapInterview roadmaps
An ordered list of topics for the system design round, with a matching roadmap for the coding round.
Read free →CompaniesCompany guides
How the interview process works at specific companies, and what to expect in each round.
Read free →You can also read the blog, browse short answers to specific interview questions, or follow the coding roadmap. The newsletter brings new system design articles to your inbox.
When you know the material, practice saying it out loud
Reading teaches you what to say. A practice session with an experienced engineer shows you how your answer sounds under a clock, and where you stop explaining and start guessing. This step is most useful in the last two or three weeks before your loop.
A practice interview with a FAANG engineer
A mock interview is a full-length practice round, in coding, system design, or behavioral, run by an engineer who has conducted real ones. You get direct feedback on what to fix before the interview that counts.
See how it works →Resume reviewA resume that gets you to the first round
An engineer reviews your resume against what tech recruiters screen for, and tells you which lines to rewrite so your impact shows in numbers.
See how it works →Written by engineers who have conducted these interviews
Arslan Ahmad
Arslan is the founder of Design Gurus and the creator of Grokking the System Design Interview. He has worked as an engineer and hiring manager at large tech companies including Facebook and Microsoft, where he interviewed candidates in the same rounds these courses teach.
The courses are written and reviewed by a team of engineers from companies like these. The team also publishes free articles on system design, distributed systems, and interview preparation.
Frequently asked questions
What is a system design interview?
A system design interview asks you to design a large software system, such as a chat app or a video service, in about 45 minutes. The interviewer is not looking for one correct diagram. They want to see how you gather requirements, estimate scale, choose components, and explain what each choice costs.
How long does it take to prepare?
Most candidates need four to eight weeks of focused preparation. Engineers who already work on distributed systems can move faster, while engineers who are new to them should plan for the full eight weeks. The study plan above shows one way to use that time.
What is the difference between system design and low-level design?
System design, also called high-level design, covers how services, databases, caches, and queues work together across many machines. Low-level design, also called object-oriented design, covers the classes, interfaces, and design patterns inside one service. Most senior loops include both rounds.
Should I learn coding patterns or solve as many problems as I can?
Do both, in that order. Learn one pattern, then solve about five problems that use it, so that you practice recognizing the pattern and not only applying it. Solving hundreds of unrelated problems without naming the pattern behind them is slower and easier to forget.
What does "grokking" mean?
To grok something is to understand it so completely that it becomes intuitive. The name reflects the goal of the courses: to build real understanding of how systems and algorithms work, so that you do not depend on memorized answers.
Are mock interviews worth it?
They are most useful once you know the material, usually in the last two or three weeks. A mock interview tests the part that reading cannot: explaining clearly under time pressure while someone asks follow-up questions.
Can I start for free?
Yes. The free system design lessons, the interview guides, the Blind 75 list, and the newsletter need no purchase. Most courses also let you preview lessons before you buy.
Start with one free lesson
You do not need to buy anything to begin. Read one lesson today, and by the end of it you will know whether this way of learning suits you.
