Question 1

Do internship interviews actually include system design?

Accepted Answer

Full distributed-system design rounds are uncommon for interns. What is common is a scoped design discussion — "how would you build a URL shortener" or "design the classes for a parking lot" — testing structured thinking rather than production architecture experience. Treat it as a conversation about trade-offs. Nobody expects an intern to size a Kafka cluster; they expect you to ask what the requirements are, propose something reasonable, and know why you chose it.

Question 2

How do I structure a system design answer in 30 minutes?

Accepted Answer

Spend five minutes on requirements and scale, five on the API and data model, ten on the high-level design, five on one deep dive the interviewer picks, and five on bottlenecks and trade-offs. Write the requirements down and confirm them before designing. The most common failure is drawing boxes before agreeing what the system must do. Asking "read-heavy or write-heavy?" and "how many users?" changes the entire design and shows the interviewer you know that.

Question 3

What does a load balancer do, and what are the trade-offs?

Accepted Answer

It distributes incoming requests across multiple servers so no single one is saturated, and removes failed servers from rotation. The main choices are the algorithm (round-robin, least-connections, hashing) and whether sessions are sticky. Sticky sessions are the trap: they make scaling and failover worse because a server's loss takes its sessions with it. The better answer is to keep servers stateless and put session state in a shared store like Redis.

Question 4

When and where should I add a cache?

Accepted Answer

Add a cache when reads greatly outnumber writes and the same data is requested repeatedly. Common layers are the browser, a CDN for static assets, an application cache such as Redis, and the database's own buffer pool. Always state the invalidation strategy — TTL, write-through, or explicit invalidation on write — because stale data is the cost you are trading for speed. Saying "I would add Redis" without saying how entries expire is an incomplete answer.

Question 5

What is database sharding and when is it justified?

Accepted Answer

Sharding splits one logical database across multiple machines by a shard key, so each holds a subset of rows. It is justified when a single primary can no longer hold the data or serve the write volume — not before. The shard key is the whole decision. A poor key creates hot shards; a key that does not match your query pattern forces scatter-gather queries across every shard. Also note what you lose: cross-shard joins and transactions become hard or impossible. Try read replicas, caching and vertical scaling first.

Question 6

What is the difference between SQL and NoSQL for an interview answer?

Accepted Answer

Relational databases give you a fixed schema, joins and strong transactional guarantees, and are the right default. NoSQL stores trade joins and sometimes consistency for horizontal scale and flexible documents. The credible answer names a reason, not a preference: "relational, because the data is highly interconnected and I need transactional integrity on payments" or "document store, because each record is self-contained and the schema varies by tenant". Saying "NoSQL because it scales" invites a follow-up you will not enjoy.

Question 7

How would I design a URL shortener?

Accepted Answer

Requirements: create a short code for a long URL and redirect on lookup, read-heavy. Generate a unique ID and base62-encode it, store the mapping, cache hot codes, and serve redirects with a 301 or 302. Discuss collision handling and custom aliases. The nuance worth raising is 301 versus 302: a permanent redirect is cached by browsers, which cuts load but destroys your click analytics. Choosing 302 deliberately and saying why is exactly the trade-off reasoning being tested.

Question 8

What is a low-level design (LLD) round and how is it graded?

Accepted Answer

You design the classes, interfaces and relationships for a bounded system — a parking lot, an elevator, a splitwise-style expense app — and often write the core classes. It grades object modelling, separation of concerns and use of design patterns. Start from the nouns for classes and verbs for methods, then ask what is likely to change and put an interface there. Naming a pattern is only worth marks if you can justify it: "Strategy for pricing, because the fee rule differs per vehicle type and I want to add types without editing existing code".

Question 9

What are the SOLID principles, briefly?

Accepted Answer

Single responsibility: one reason to change per class. Open/closed: extend without modifying. Liskov substitution: a subtype must be usable wherever its base type is. Interface segregation: many small interfaces beat one large one. Dependency inversion: depend on abstractions, not concretions. Interviewers want an example, not a definition. The strongest is Liskov via the square-rectangle problem, or dependency inversion via injecting a payment gateway interface so tests can substitute a fake.

Question 10

How do I design a good REST API in an interview?

Accepted Answer

Use nouns for resources and HTTP verbs for actions, return correct status codes, make GET/PUT/DELETE idempotent, paginate collections, version the API, and never put actions in the path like /createUser. Two follow-ups are near-guaranteed: which methods are idempotent (GET, PUT, DELETE — POST is not) and how you would handle a client retrying a payment (an idempotency key). Have both ready.

Question 11

What database normalisation do I need to explain?

Accepted Answer

First normal form: atomic values, no repeating groups. Second: no partial dependency on part of a composite key. Third: no transitive dependency between non-key columns. Denormalise deliberately afterwards for read performance. The mature answer acknowledges both directions: normalise to prevent update anomalies, then denormalise specific read paths when measurement shows the joins hurt. Reciting the forms without that trade-off reads as textbook recall.

Question 12

What does a database index actually do, and what does it cost?

Accepted Answer

An index is a sorted structure, usually a B-tree, that lets the database find rows without scanning the table, turning a linear scan into a logarithmic lookup. It costs disk space and slows every insert, update and delete, since the index must be maintained. Know that a composite index on (a, b) helps queries filtering on a, or a and b, but not b alone — the leftmost-prefix rule. That single detail separates candidates who have tuned a query from those who have read about indexes.

Question 13

What is the CAP theorem, in plain terms?

Accepted Answer

When a network partition occurs, a distributed system must choose between remaining consistent (rejecting requests it cannot confirm) and remaining available (answering with possibly stale data). You cannot have both during a partition. The common misstatement is "pick two of three". Partition tolerance is not optional in a real network, so the actual choice is C or A during a partition. Ground it: a bank balance chooses consistency, a social feed chooses availability.

Question 14

What is machine learning system design and what gets asked?

Accepted Answer

You design an end-to-end ML product — a recommendation feed, fraud detection, search ranking. Cover framing the problem, data and labels, features, model choice, offline and online evaluation, serving latency, and monitoring for drift. The step candidates skip is labels: where does ground truth come from, and how delayed is it? For fraud, labels arrive weeks later via chargebacks, which changes both training and evaluation. Raising that shows real understanding.

Question 15

What is the difference between concurrency and parallelism?

Accepted Answer

Concurrency is structuring a program so multiple tasks are in progress in overlapping time periods; parallelism is actually executing them simultaneously on multiple cores. Concurrency is about dealing with many things at once, parallelism about doing many things at once. Follow-ups usually cover race conditions, mutexes and deadlock's four conditions. In Python, expect the GIL question: threads help with I/O-bound work, multiprocessing is needed for CPU-bound work.

Question 16

How do I answer "how would you scale this from 1,000 to 1 million users"?

Accepted Answer

In order: measure to find the actual bottleneck, add caching, add read replicas, move static assets to a CDN, scale the application tier horizontally behind a load balancer, make services stateless, then introduce queues for asynchronous work — and only then consider sharding. Leading with "I would measure first" is the answer senior engineers give and interns rarely do. Jumping straight to microservices and Kafka is the classic over-engineering signal.

System Design and Low-Level Design for Interns Interview Questions and Answers

How to use this set