System Design for Freshers: What SDE-1 Interviews Expect

"Design a URL shortener." For a senior engineer, this question is about sharding strategies, global replication and consistency trade-offs. For a fresher, the same question checks something simpler and still important: do you ask what it needs to do before drawing boxes, can you name the parts of a web system and say why each is there, and do you notice what breaks when traffic grows?

Many freshers either panic (because they think they must produce what senior engineers produce) or skip preparation entirely (because "design is for experienced people"). Both are mistakes. A few weeks of structured practice is enough to handle an entry-level design discussion well.

• What entry-level design rounds actually test.
• A seven-step framework for any design question.
• A URL shortener designed at fresher depth.
• The building blocks you should be able to name and justify.
• How to practise.

Expectations differ by company, and some companies do not ask freshers design questions at all. Where they do, entry-level rounds usually look for:

For a 30 to 45-minute discussion:

1. Requirements (about 5 minutes). Functional: what must it do? Non-functional: how many users, how fast, how available, how consistent? Write them down.
2. Rough estimates (2 to 3 minutes, if useful). Requests per second, storage per year. Round numbers are fine; the point is whether the system is read-heavy or write-heavy, small or large.
3. API (about 3 minutes). The main endpoints with inputs and outputs.
4. Data model (about 3 minutes). The main tables or collections and their key fields.
5. High-level design (about 7 minutes). Draw the main components and how a request flows through them.
6. Deep dive (10 to 15 minutes). Go deeper into one or two parts: the interesting algorithm, the bottleneck, or wherever the interviewer steers you.
7. Bottlenecks and trade-offs (about 5 minutes). What fails first as load grows, single points of failure, and what you would change.

Say the framework out loud at the start ("I'll start with requirements, then the API and data model, then a high-level design, and then go deeper where you'd like"). It reassures the interviewer that you have a plan.

Clarifying questions and illustrative answers:

• Create a short link for a long URL; visiting the short link redirects to the long one. (Yes.)
• Custom aliases? Expiry? Analytics? (Expiry yes; custom aliases and analytics optional, out of scope for now.)
• Scale? (Assume 100 million new links a month and reads about 100 times writes.)
• Latency and availability? (Redirects should be fast and highly available.)

• Writes: 100 million per month ≈ 100,000,000 ÷ (30 × 86,400) ≈ 40 per second on average.
• Reads: about 100 times that ≈ 4,000 per second on average, more at peaks.
• Storage: if each record is about 500 bytes, 100 million a month is about 50 GB a month, roughly 600 GB a year.

Conclusion to say aloud: read-heavy, modest write rate, storage that grows steadily. That points to caching reads and choosing a database that handles simple key lookups well.

POST /links          body: { "url": "...", "expiresAt": "..." }  ->  { "code": "aB3x9Kq" }GET  /{code}         ->  302 redirect to the long URL, or 404 if unknown or expired

links  code        (primary key, 7 characters)  long_url  created_at  expires_at  (nullable)

Client -> Load balancer -> Application servers -> Cache (code -> long_url)                                               -> Database (links)

A read: the server checks the cache; on a miss, it reads the database and stores the result in the cache; then it returns a redirect. A write: the server generates a code, stores the row, and returns the code.

Two common approaches, and their trade-offs:

Seven base-62 characters give 62^7, about 3.5 trillion codes, which is plenty for the stated growth for many years. Say which you would choose for this system and why.

• The database for reads. The cache absorbs most reads, because popular links are read repeatedly. Add read replicas if needed.
• A single application server. Run several behind the load balancer; they hold no state, so this is easy.
• Expired links. Check expires_at on read; clean up periodically.
• Caching and expiry together. Set the cache entry's lifetime no later than the link's expiry, or a stale redirect may be served.
• Abuse. Rate-limit link creation per user or IP; this connects to a rate limiter design.

That is a complete fresher-level answer: clear, justified and aware of where it would strain. A deeper treatment, including scaling further, is in Design a URL Shortener (and Pastebin): A Complete Walkthrough.

You should be able to explain each in two sentences and say when you would use it.

• Design common systems out loud, one or two a week: URL shortener, rate limiter, notification service, chat, news feed, file upload, ticket booking. Use the seven steps, with a timer.
• Scale your own project on paper. "My booking API works for 100 users. What breaks at 100,000? At 10 million?" This prepares you for the project deep-dive too.
• Draw diagrams in whatever tool your interviews use (often a shared whiteboard such as Excalidraw), so the tool is not new on the day.
• Read one good design walkthrough a week, such as the System Design Primer on GitHub or the System Design From Zero to Interview-Ready course on this site, then redo the design from memory.

Act as an interviewer running a 40-minute system design discussion for anentry-level engineer. The problem: [design a notification service / rate limiter /URL shortener]. Rules:- Do not reveal requirements unless I ask; answer my questions briefly.- Let me lead through requirements, estimates, API, data model and design.- After my high-level design, ask about one failure: "What happens if [component] goes down?"- Later, ask: "What breaks first at 10 times the load, and how would you fix it?"- At the end, tell me what I did well, what I missed, and what would have made the  answer stronger for an entry-level candidate. Keep expectations at entry level.

A voice mode makes this closer to the real thing (article 33). Assistants can be confidently wrong about specific numbers or product behaviour, so check facts you plan to rely on against a reliable source.

• Drawing boxes before asking what the system must do.
• Naming technologies without reasons ("Kafka, Redis, Kubernetes") instead of explaining needs.
• Going silent while thinking about a component.
• Over-engineering a design for a scale nobody asked for.
• Ignoring failure: no answer to "what if this server dies?"
• Memorising one design and forcing every question into it.

• Next: Mock Interviews: AI Voice Practice, Peers and Recordings puts coding, design and behavioral practice under realistic pressure.
• For a structured approach to design interviews, see The System Design Interview Framework: A Repeatable Method for Any Problem.
• For where to start with system design, see Start Here: What System Design Is and How to Learn It.