System Design for a Fourth-Year Student: The 5 Questions Every Product-Company Interview Will Ask

The system design round at product companies terrifies entry-level candidates because it has no correct answer. Unlike a coding round where your code compiles and passes test cases or it does not, system design asks you to make tradeoffs under uncertainty and defend them. The interviewer is not grading you against a solution key. They are evaluating how you think about systems: what questions you ask, what constraints you identify, what tradeoffs you surface, and whether you can reason about a system you have never built before. This is learnable. The questions are finite and the evaluation framework is predictable. Here is exactly what you need to know to pass a system design round at an entry-level product company interview.

The Five Questions That Cover 90% of Entry-Level System Design Rounds

These five problems appear in entry-level product company interviews with remarkable consistency. Each tests a different dimension of systems thinking. Master the framework for all five and you are prepared for any entry-level design round.

Question 1: Design a URL Shortener (like bit.ly)

This is the most common entry-level design question. It tests your ability to design a simple API, choose a data model, and reason about scale. The framework: define the API (POST to create a short URL, GET to redirect), define the data model (id, original_url, short_code, created_at, user_id, click_count), choose a short-code generation strategy (hash the URL and take the first 7 characters, with collision handling via retry), estimate scale (1 million URLs created per day, 100 million redirects per day — this tells the interviewer you think about load), and discuss the redirect mechanism (301 permanent redirect for caching, 302 temporary if you want to track click analytics). The key insight the interviewer wants: understanding the tradeoff between hash collision probability and short-code length. A 7-character base62 code gives 62⁷ ≈ 3.5 trillion possible codes, which is sufficient. You do not need a distributed ID generator for this.

Question 2: Design a Rate Limiter

This tests your understanding of API design, middleware, and state management. The framework: where does the rate limiter sit (middleware layer, before the route handler), what is the limiting strategy (token bucket, sliding window, or fixed window — explain why you chose one), where is state stored (Redis with TTL on keys), what happens when the limit is exceeded (429 Too Many Requests with a Retry-After header), and how do you handle distributed rate limiting (Redis is shared across all instances). The insight: explain that you chose a sliding window over a fixed window because fixed windows allow burst traffic at window boundaries, which defeats the purpose of rate limiting.

Question 3: Design a Notification System

This tests your understanding of asynchronous processing, message queues, and external service integration. The framework: the notification is triggered by an event (user action, system event, scheduled), the event goes to a message queue (RabbitMQ, SQS, or Redis pub/sub), workers consume from the queue and dispatch to channels (email via SendGrid, push via FCM, SMS via Twilio), each channel has its own worker pool to prevent a slow channel from blocking others, and delivery status is tracked in a database for retry logic. The insight: decoupling event generation from notification delivery via a queue means the main application does not slow down when an external SMS provider is experiencing latency.

Question 4: Add a Caching Layer to an Existing API

This tests your understanding of performance optimization and cache invalidation. The framework: identify what to cache (read-heavy endpoints, expensive queries, rarely-changing data), where to cache (Redis, between the API and database, using a cache-aside pattern — check cache first, on miss query database and populate cache), set TTLs appropriately (short TTLs for rapidly changing data, long TTLs for reference data), and handle cache invalidation (the two hard problems in computer science are naming things, cache invalidation, and off-by-one errors — acknowledge this, then describe write-through or write-behind strategies). The insight: never cache user-specific data without a user-specific cache key. Serving cached data from user A to user B is a security incident, not a performance optimization.

Question 5: Design the Database Schema for a Multi-Role Application

This tests your understanding of data modeling and normalization. The typical scenario: a placement management system with students, TPOs, companies, job postings, and applications. The framework: identify entities and their relationships (Student 1:N Application, Company 1:N Job Posting, Job Posting 1:N Application), normalize to 3NF (no repeating groups, no partial dependencies, no transitive dependencies), define foreign key constraints, choose indexes (on foreign keys and on columns used in WHERE clauses of frequent queries), and discuss the tradeoffs between normalization (data integrity, no duplication) and denormalization (faster reads, more storage). The insight: for an OLTP system like a placement dashboard, normalize. For an OLAP system like an analytics dashboard, consider denormalization with summary tables. Recognizing the difference between OLTP and OLAP workloads is the signal that separates candidates who understand database design from candidates who memorized normalization rules.