Why System Design Is Appearing in Graduate Interviews
System design interviews used to be reserved for senior engineers. The assumption was that graduates hadn't shipped enough to have opinions about how large systems should be architected. That assumption is shifting.
In 2025-2026, UK companies including Goldman Sachs, Palantir, Amazon, Arm, and a growing number of scale-ups have introduced a "system design lite" component at the graduate level. It's not a full senior-level system design interview - they're not expecting you to design Twitter from scratch. But they are expecting you to understand fundamental concepts and reason intelligently about how software systems are built and how they fail.
This guide covers exactly what graduate-level system design involves, the concepts you need to know, and how to structure an answer. For the coding side of interview prep, see our guides on how to prepare for coding interviews and graduate software engineer interview questions.
What "System Design Lite" Actually Looks Like at Graduate Level
Graduate system design questions are not "design YouTube." They look more like:
- "How would you design a URL shortener?"
- "Walk me through how you'd build the backend for a job alerts system."
- "How would you design a simple key-value store?"
- "How would you ensure this API can handle 10x the current load?"
- "What would happen to your system design if the primary database went down?"
The scope is smaller. The depth is shallower. But the framework - identifying requirements, choosing components, discussing trade-offs - is identical to senior-level design. The candidates who do well are those who understand the building blocks and can reason about how they fit together.
The Five Core Building Blocks You Must Understand
1. The Client-Server Model and APIs
What you need to know: A client (browser, mobile app, other service) makes requests to a server over HTTP. The server processes the request and returns a response. RESTful APIs use HTTP verbs (GET, POST, PUT, DELETE) and status codes (200, 201, 400, 404, 500) to communicate meaning.
What graduates often miss: The difference between synchronous APIs (client waits for response) and asynchronous processing (client gets a job ID and polls later, or receives a webhook when done). Understanding when each pattern is appropriate is a sign of real engineering maturity.
In an interview: When asked to design any system, always start by defining the API. What endpoints exist? What do requests and responses look like? This structures everything else.
2. Databases: SQL vs NoSQL, and When to Use Each
SQL (relational) databases (PostgreSQL, MySQL): Store data in tables with defined schemas. Strong consistency. Support complex queries with JOINs. Best when: your data has clear relationships, you need ACID transactions, your access patterns are varied and unpredictable.
NoSQL databases (MongoDB, DynamoDB, Cassandra): Store data as documents, key-value pairs, or wide columns. Flexible schema. Horizontally scalable. Best when: you have a simple, well-defined access pattern, you need to scale write volume massively, or your data model doesn't have strong relationships.
The critical insight for interviews: The decision is not "which is better" - it's "which fits this specific access pattern." Being able to articulate why a relational model fits a given problem (or why it doesn't) demonstrates exactly the kind of thinking these questions are designed to surface.
3. Caching
What it is: Storing frequently accessed data in a fast store (Redis, Memcached) so you don't need to hit the database for every request.
When to use it: When you have data that is read frequently but changes rarely. User profile data, product listings, configuration settings - all are good cache candidates. User-specific real-time data (bank balance, current shopping cart) is a poor cache candidate because staleness matters.
The trade-off to discuss: Cache invalidation - how do you ensure that when the underlying data changes, the cached version gets updated? This is one of the famously hard problems in computer science. Interviewers love candidates who raise it proactively.
Cache hit vs miss rates: A cache with an 80% hit rate means 80% of requests are served from fast memory; only 20% hit the database. This is why caching dramatically improves performance under load.
4. Load Balancing
What it is: A load balancer sits in front of multiple server instances and distributes incoming requests across them. This prevents any single server from becoming a bottleneck.
Why it matters: A single server has a maximum request capacity. Load balancing allows horizontal scaling - adding more servers to handle more traffic, rather than buying an ever-more-expensive single server (vertical scaling). Modern cloud deployments are almost universally horizontally scaled.
What to know about load balancing strategies: Round-robin (requests distributed sequentially), least-connections (route to the server handling fewest active requests), and sticky sessions (always route a given user to the same server - relevant when server-side session state is stored locally rather than in a shared database or cache).
5. Message Queues and Asynchronous Processing
What it is: Instead of processing every task synchronously in the request-response cycle, slow or resource-intensive tasks are placed on a queue (RabbitMQ, AWS SQS, Apache Kafka) and processed by background workers asynchronously.
Classic use cases: Sending emails (don't block the HTTP response waiting for the email to send), processing uploaded images, generating reports, sending webhooks.
Why it appears in graduate interviews: It's a fundamental pattern for building resilient systems. If you know what a message queue is and when to use one, you demonstrate that you think beyond the simple request-response model.
How to Structure a System Design Answer
Use this framework for every system design question:
- Clarify requirements (2 minutes): "Before I dive in, can I ask a few clarifying questions? Is this read-heavy or write-heavy? What's the approximate scale - requests per second? Do we need real-time or is eventual consistency acceptable?" This signals engineering maturity immediately.
- Define the API (3 minutes): What endpoints or interfaces does the system expose? Draw them out. This constrains the design and gives you a structure to build around.
- High-level architecture (5 minutes): Client - Load balancer - Application servers - Database. Place these boxes. What does the basic flow look like?
- Deep dive into one component (5 minutes): The interviewer will usually steer you. Go deep on whichever component they're most interested in - database schema, caching strategy, or API design.
- Discuss trade-offs and failure modes (3 minutes): What happens if the database goes down? What happens if the cache is cold? What would you do differently at 10x scale? This is where senior thinking shows through.
The Concepts That Separate Good Candidates from Average Ones
Knowing the building blocks is table stakes. The graduate candidates who impress interviewers do these things:
- Raise trade-offs proactively. "I'd use a SQL database here because of the relational data model - the trade-off is that horizontal write scaling is harder, but for this scale I don't think we need it."
- Think about failure. "If the primary database fails, we'd lose write availability. We could address this with a read replica and automatic failover, but we'd need to accept the replication lag."
- Quantify things. "A Redis cache lookup is typically sub-millisecond. A database query on a large table without an index is potentially hundreds of milliseconds. That's why caching the most frequent queries is worth the added complexity."
- Mention what you don't know. "I haven't worked with Cassandra directly, but I understand it's a good fit for time-series data where the write volume is very high and the read patterns are predictable."
Company-Specific System Design Preparation
System design questions at graduate level vary significantly by company. Amazon's graduate design questions focus on scalability and failure modes. Palantir's focus on data pipeline design. Goldman Sachs focuses on low-latency financial systems concepts.
GradSignal's interview playbooks include the specific system design questions asked at each company, what level of depth they expect from graduates, and examples of strong answers. Use them to calibrate your preparation for the specific companies you're interviewing at rather than preparing generically.
Create a free account to access the playbooks and set up alerts for graduate tech roles at the companies you're targeting.