The interviewer at the startup has finished with your project and your coding question. Then he says, "Let's do something a bit different. Suppose we wanted to build a URL shortener like bit.ly. How would you design it?"
You have built a hostel complaint app and an e-commerce clone. Both ran on one laptop. The word "design" makes you think of the UML diagrams from the software engineering course, and you are fairly sure that is not what he means. You start describing a database table with two columns, then stop, because you do not know what he wants you to say next.
The short answer
System design questions are not common for freshers. Most entry-level interviews at large companies focus on coding, data structures and your project, and summaries like Design Gurus' match what most freshers see: design comes up in simplified form, mainly at product companies and startups that want to see how you think about building something bigger than a college project. When it does come up, the interviewer is not testing whether you know the architecture of bit.ly. He is testing whether you can turn a vague request into a set of decisions, and whether you understand what each decision costs. There is a five-step framework for doing that, and it is learnable in a week, because the skill is structure, not knowledge.
Why this throws freshers specifically
Everything in a B.Tech curriculum has a right answer. A design question does not, and that alone is disorienting. Worse, freshers have usually only built systems where scale never mattered: one user, one laptop, one database file. So they have never had to ask "what happens when a thousand people do this at once", which is the question every design round is really about.
The good news is that the interviewer knows all this. A fresher who draws three boxes and explains why each is there, and what would break first, scores well. A fresher who draws a complex diagram full of words from a YouTube video and cannot say why any piece is there scores badly. Structure beats vocabulary.
What the interviewer is scoring
Roughly four things. Whether you find out what you are actually building before you start. Whether you can reason about scale in rough numbers. Whether your design decisions have reasons behind them. And whether he could follow you, because a design you cannot explain is a design that does not score. The framework below is built around those four.
Step one: clarify what you are building
Before drawing anything, find out what the system needs to do and how well. Split it in two.
Functional requirements are what users can do. For the shortener: create a short link, follow a short link, maybe see how many times it was clicked. Ask which of these are in scope. Interviewers often leave something vague on purpose to see whether you ask.
Non-functional requirements are the qualities: how many users, how fast, how available, how consistent. These are what actually drive the design, and they are what freshers skip. "How many links are created per day, and how many are followed?" changes everything downstream. "Is it fine if a new link takes a few seconds to start working?" decides how strict you have to be about consistency.
Spend three to five minutes here, then say your understanding back to the interviewer before moving on. "So: create and redirect, click counts are nice-to-have, reads far outnumber writes, and a few seconds' delay on a new link is acceptable. Right?"
Step two: estimate the scale, roughly
You do not need accurate numbers. You need order-of-magnitude numbers that tell you which problems are real. Say the interviewer offers ten million new links a day and a hundred times as many redirects. That is roughly a hundred writes and ten thousand reads per second on average, several times more at peak. Each link record is a few hundred bytes, so storage grows by a few gigabytes a day.
Do this arithmetic out loud. Those numbers just told you three things: reads dominate, so cache aggressively; storage is modest, so one well-indexed database will do for a long time; and the write path is not the hard part. Every later decision can now be justified by pointing back at a number.
Step three: draw the simplest design that works
Now draw, and keep it plain. A client, an API layer, application servers, a database, a cache. Name what each box does and what talks to what. For the shortener: a create endpoint that generates a short key and stores the mapping; a redirect endpoint that looks up the key and returns an HTTP redirect; a database holding the mapping; a cache in front of it for popular links.
Resist adding anything you have not yet justified. A message queue, a CDN, database sharding, a search cluster: each is a correct answer to a specific problem, and putting them in before the problem exists tells the interviewer you are pattern-matching from a video rather than designing. The System Design Primer is a good free reference for what the standard components are and what problem each solves.
Step four: find the first bottleneck, and fix only that
With the simple design on the board, ask what breaks first as load grows or as something fails. This is where the round usually spends its longest stretch, and where depth is scored.
For the shortener, walk the read path. Ten thousand redirects a second all hitting the database is the first problem, and the fix is the cache you already drew, so now talk about it properly. What will the hit rate be, given that a small number of links get most of the clicks? What happens on a miss? When does something get evicted? Then the write path: how do you generate short keys without two servers producing the same one? You could hash the URL and handle collisions, or hand each server a pre-allocated range of keys; each has a cost. Then failure: what happens when the database goes down? Redirects can still be served from cache for popular links; creates cannot, and you have to decide whether to fail them or queue them.
Each answer should be a decision with a reason, and each should open the next question. The interviewer will steer toward whichever area he wants to probe. Follow him.
Step five: say what each decision costs
No design is free, and strong candidates say so before being asked. Caching speeds up reads and takes load off the database, and it introduces stale data and the question of when to invalidate. A single database is simple and is a single point of failure, so you add a replica, and now reads can lag writes. Pre-allocated key ranges avoid collision checks and need coordination to hand out. Every arrow you drew has a price. Naming the price is the most reliable way to move from "recited an architecture" to "understands one".
The classic vocabulary here is the CAP theorem: when the network splits, a distributed system has to choose between consistency and availability. You do not need to lecture on it. You should be able to say which your design favours and why that is acceptable for this product. A link that takes a second to work everywhere is fine. A payment ledger that shows different balances on different servers is not. For a deeper grounding in these trade-offs, Martin Kleppmann's Designing Data-Intensive Applications is the book working engineers most often recommend, and it is readable in your first year on the job.
Think out loud the whole time
The framework only works if it is spoken. Say the assumption before you make it, the option you rejected and why, the thing you are unsure about. Silence while you think looks like being stuck; the same thinking, narrated, looks like design. An interviewer who can hear your reasoning can redirect you when you head somewhere unproductive, which saves you minutes and scores you points for how you took the redirect. One who cannot hear it can only wait.
The mistakes that cost the most
Skipping requirements, and designing the wrong system perfectly. Always the first five minutes. Over-building, with queues and shards before the estimate says they are needed; every unjustified box is a question you will not be able to answer. Never committing, listing three options for every decision and choosing none. Ignoring failure, with a design that only works when everything is up. And forgetting the interviewer, drawing in silence for ten minutes and presenting a finished picture. The round is a conversation.
How to practise in a week
Reading about architectures does not train this; talking through problems does. Take a classic problem, a URL shortener, a simple news feed, a chat app, a rate limiter, and give yourself twenty-five minutes to walk it through the five steps aloud, drawing on paper as you go. Then do another. Within four or five problems the framework becomes reflex and your attention goes to the specifics, which is where it should be.
A practice round adds the follow-ups you cannot ask yourself. On 99Interview the system design practice track runs the round with an AI interviewer that pushes into the bottleneck and trade-off questions and scores the transcript, or as a live mock interview with a working engineer who has actually run these systems and steers you toward the parts of your design that would break, with written feedback afterwards; the options are on the pricing page. If your interview process also has a coding round, the two-week preparation plan shows where a design day fits.
Frequently asked questions
Is system design asked for freshers?
Rarely at large companies, where fresher interviews focus on coding, data structures and your project. More often, in simplified form, at product companies and startups. If it does come up, the interviewer expects structure and reasoning, not knowledge of real architectures.
How do I prepare for a system design interview with no experience?
Learn the five-step framework, then practise it aloud on four or five classic problems. Your college project is a fine starting point: ask what would break first if a thousand people used it at once, and design the fix.
What is the difference between high-level and low-level design?
High-level design is about components and how they connect: servers, databases, caches, queues. Low-level design is about classes, interfaces and data structures within one component. Freshers are more often asked about low-level design, or about a simplified high-level design like the shortener above.
What do interviewers look for in a system design round?
Whether you clarify requirements before designing, whether you can estimate scale roughly, whether your decisions have reasons and stated trade-offs, and whether you communicated clearly enough to be followed.
How long should I spend on each step?
In a forty-five minute round, roughly five minutes on requirements, five on estimation, ten on the high-level design, twenty on bottlenecks and trade-offs, and the remainder on wrap-up and questions. Let the interviewer pull you toward whatever he wants to probe.
Do I need to know specific technologies like Kafka or Redis?
Knowing what problem each solves is enough at entry level. "Something like Redis, an in-memory store, for the cache" is a perfectly good answer. Naming a tool you cannot explain is worse than describing the component generically.
Try it today
Take your own final-year project and ask the design question of it: what breaks first if a thousand students use it during registration week? Draw the fix, and say aloud what it costs.
The interviewer is not checking whether you have seen this system before. He is checking whether you could be trusted to design the next one. Which piece of your own project would fall over first?