Navigating the New Grad SWE Job Hunt: System Design Interviews - Part 1

Table of Contents

1. Part 3: The System Design Interview
2. Educational Resources 📚
3. Computer and Application Architecture 💻
    3.1 Computer Architecture
    3.2 Application Architecture
    3.3 Design Requirements
    3.4 Considerations for Designing Scalable Systems
4. Networking
    4.1 Internet Protocol (IP) Addresses
    4.2 Transmission Control Protocol (TCP) & User Datagram Protocol (UDP)
    4.3 Domain Name System (DNS)
    4.4 Anatomy of a URL
5. Application Programming Interfaces (APIs) 👩🏼‍💻
    5.1 What Are APIs?
    5.2 HTTP Structure Breakdown
    5.3 Designing Robust & Practical APIs

1. Part 3: The System Design Interview

Hi there! It’s been a while since the last post in this series; thanks for your patience, and welcome back! I’ve been busy settling into my new job, which I started last fall, but I’m excited to continue. Next up on our list is preparing for system design-style interviews and questions, so let’s dive in.

Before we get into the core concepts, I want to clarify something: in my experience interviewing for new grad roles in Canada, system design interviews were rare. I’ve spoken with recruiters and candidates at FAANG companies who also confirmed they’re uncommon, if not absent, at the Junior/SWE I level. So, I suggest focusing on a high-level understanding of the fundamentals to set yourself up for success. 😊

Here’s what we’ll cover in this series:

• Fundamentals: Scalability, availability, throughput, reliability, fault tolerance, latency
• Networking: TCP/UDP, DNS
• APIs: HTTP(s), REST, GraphQL, WebSockets, gRPC
• Infrastructure: Caching, Content Delivery Networks (CDNs), load balancing
• Databases: NoSQL, SQL, replication, sharding, object storage, CAP theorem
• Architecture: Microservices vs. monolithic architecture

If you want to go further, try designing systems like a URL shortener or Google Drive, or revisit past projects and think about how you’d scale them. That said, this might be overkill—in most cases, a solid grasp of the topics above is more than enough to handle any entry-level system design questions.

---

2. Educational Resources 📚

Before we take a glance at the most critical topics to know for your system design interviews, I'd like to provide a list of learning materials so you can dive deeper when you're ready to explore more.

• System Design repo by systemdesign42 - https://github.com/systemdesign42/system-design

• System Design Primer repo by donnnemartin - https://github.com/donnemartin/system-design-primer

• NeetCode's System Design for Beginners course - https://neetcode.io/courses/system-design-for-beginners

---

3. Computer and Application Architecture 💻

To start, let’s look at the fundamentals of computer architecture before moving on to how we build systems that scale.

3.1 Computer Architecture

Be familiar with the key components of a computer’s hardware architecture, including:

• Disks: Persistent, non-volatile storage. Know the difference between Hard Disk Drives (HDDs) and Solid State Drives (SSDs).
• Random Access Memory (RAM): Temporary storage used to hold data for quick access by the CPU.
• Central Processing Unit (CPU): The “brain” of the computer that executes instructions and handles computation.
• Cache (SRAM): A small, high-speed memory located close to the CPU that stores frequently accessed data to reduce latency.

You should understand how these components compare in terms of read/write speed, access latency, and storage capacity at a high level.

3.2 Application Architecture

While computer architecture focuses on hardware within a single machine, application architecture looks at how thousands of computers (or nodes) work together to run modern software and services. Key concepts include:

• Client-Server Model: Understand the basic interaction where clients (e.g. browsers or apps) send requests and servers respond with data or services.
• Scaling:
  • Vertical Scaling: Adding more resources (e.g. CPU, memory) to a single server.
  • Horizontal Scaling: Adding more machines to handle the load. This is generally preferred in large systems for greater reliability and scalability and is often supported by load balancers.
• Supporting Services: Large-scale systems require more than just clients and servers. You’ll often see tools for:
  • Logging (e.g. ELK stack) to capture app behaviour
  • Monitoring (e.g. DataDog dashboards) to track performance metrics and alerts for errors, latency, and usage patterns.

3.3 Design Requirements

At a high level, system design comes down to solving three fundamental challenges:

1. Moving Data: Efficiently transferring data between geographically distributed clients and servers.
2. Storing Data: Ensuring data persistence and accessibility.
3. Transforming Data: Processing and manipulating data to derive value.

You’ll also want to understand how Service Level Agreements (SLAs) and Service Level Objectives (SLOs) shape system design:

• SLAs: A formal contract with clients defining guarantees like up-time (e.g. 99.999% monthly availability). If the SLA isn’t met, providers often owe financial compensation.
• SLOs: Internal targets that help ensure SLAs are consistently met (e.g. 99.99% response time under 200ms). These agreements are a major driver behind the focus on up-time, fault tolerance, and reliability in distributed system design.

3.4 Considerations for Designing Scalable Systems

When designing systems at scale, consider these critical factors:

1. Availability: The percentage of time a system is operational. Measured in "nines" (e.g. 99.999% availability equates to ~5 minutes of downtime annually).
2. Reliability: The likelihood a system operates without failure over a specified period.
3. Fault Tolerance: The system's ability to detect and recover from failures without affecting functionality.
4. Redundancy: Backup resources, such as shadow servers, to maintain service continuity during failures.
5. Throughput: The volume of operations a system can handle within a given time frame.
6. Latency: The round-trip time for a request to travel from client to server and back.

---

4. Networking

4.1 Internet Protocol (IP) Addresses

Next up, let’s cover some networking fundamentals. You’ve probably heard the term IP address tossed around — and maybe even configured one before — but here’s a quick refresher just in case:

IP Address: A unique identifier for every device, allowing them to receive and send data on a network.

Think of it like a digital home address for your device. Every phone, computer, or smart toaster that connects to a network gets one so it can send and receive information.

There are two main types of IP addressing systems:

• IPv4: The older, more common one - uses 32-bit addresses (e.g. 192.168.0.1).
• IPv6: The newer system - uses 128-bit addresses to support the massive growth of internet-connected devices (e.g. 3002:0bd6:0000:0000:0000:ee00:0033:6778).

When multiple apps run on the same device (which they always do), ports help keep things organized:

• Think of a port like an apartment number in a building. It lets your device know which app a packet of data is meant for. For example, port 80 is typically used for HTTP (web browsing).

So, how does data get from one device to another?

• Internet Protocol (IP) breaks information into data packets — each with a header (think: address info), the actual content (payload), and a trailer (extra info like error checking).
• Devices can live on public networks, where they have a globally unique IP address assigned by an Internet Service Provider (ISP), making them reachable from anywhere.
• Or they can be part of private networks, like your home Wi-Fi, where devices use local IPs and aren’t directly accessible from the outside world.

There are two types of IP addresses you’ll come across:

• Static IP: Manually set and doesn't change - useful for things like servers.
• Dynamic IP: Assigned temporarily by a network (usually via DHCP), and it can change over time - which is what most home devices use.

4.2 Transmission Control Protocol (TCP) & User Datagram Protocol (UDP)

When data is sent across a network, it's broken into smaller pieces called packets. Two of the most common transport layer protocols that handle this process are TCP and UDP. Both serve different purposes depending on what the application needs: reliability or speed.

• Transmission Control Protocol (TCP): TCP is all about reliability. It ensures that packets arrive in order, without errors, and without missing anything. If any packets are lost or arrive out of sequence, TCP handles re-transmission and reordering behind the scenes. This makes it ideal for tasks where data integrity is critical - like loading web pages, downloading files, or sending emails.
• User Datagram Protocol (UDP): UDP focuses on speed over reliability. It sends packets without waiting for acknowledgements, meaning there's no guarantee they’ll arrive in the right order - or at all. That sounds risky, but it’s perfect for use cases like live video streaming, online gaming, or VoIP, where low latency is more important than perfect accuracy. If a few packets drop, the user experience often isn't noticeably affected.

In short:

• Use TCP when you need accuracy and consistency.
• Use UDP when you need speed and real-time performance.

4.3 Domain Name System (DNS)

DNS is like the Internet's phone book — a decentralized, hierarchical naming system that translates human-readable website names into numerical IP addresses.

• For example, when you type google.com, DNS translates it into the corresponding IP address that your browser can use to find Google’s servers.

4.4 Anatomy of a URL

You probably already know what a URL is, but let’s quickly refresh the concept just in case.

URL stands for Uniform Resource Locator, and it’s the address used to access resources online, like web pages, files, images, or APIs. A URL typically includes a protocol, a domain name, and an optional path to a specific resource.

Protocol - The protocol (also called the scheme) defines how data is transferred:

• The most common are HTTP and HTTPS (the secure version).
• Others include FTP (for file transfers) and SSH (for secure shell access to servers).

Domain - The domain has several parts:

• Subdomain: A prefix that defines a distinct section of a site. For example, blog.example.com uses blog as a subdomain.
• Primary Domain: The main part of the domain, like example in example.com. This is the part you typically purchase from a domain registrar.
• Top-Level Domain (TLD): The suffix, such as .com, .org, or .tech. TLDs often give context about the site's purpose, location, or industry.

---

5. Application Programming Interfaces (APIs) 👩🏼‍💻

APIs are the glue of modern software. They define how different systems, services, or components talk to each other, often over a network, without needing to know how the other is built internally. Let’s break down some common paradigms, how APIs work under the hood, and what makes a well-designed API.

5.1 What Are APIs?

APIs come in many forms, but here are a few popular styles you'll likely encounter:

• REST (Representational State Transfer): One of the most common architectural styles. It uses standard HTTP methods (GET, POST, PUT, DELETE) and works with resources identified via URLs. REST APIs are stateless, widely supported, and easy to understand, making them great for most general use cases.

• GraphQL: A more flexible alternative to REST, GraphQL lets clients specify exactly what data they need - no more, no less. It's powerful for front-end-heavy applications or situations where bandwidth is a concern. However, it introduces added complexity and requires more tooling to manage effectively.

• WebSockets: Unlike HTTP-based APIs (which follow a request/response model), WebSockets provide full-duplex communication. This means both the client and server can send messages anytime. It’s perfect for real-time applications like chat, multiplayer games, or live dashboards.

• gRPC: Developed by Google, gRPC uses Protocol Buffers (a compact binary format) and is great for high-performance, internal service communication, especially in microservice architectures. It’s strongly typed, efficient, and supports bi-directional streaming, but it's less human-readable and trickier to debug compared to REST.

GraphQL is great for apps where the client needs precise control over the shape of data (e.g. mobile apps on limited bandwidth). On the other hand, gRPC is often used in high-throughput, service-to-service communication within backends.

5.2 HTTP Structure Breakdown

Most APIs, especially REST and GraphQL, are built on top of HTTP, so it’s worth understanding how it works:

• Client-Server Model: The client (e.g., your browser or app) makes a request to the server, which processes it and sends back a response.

• Requests and Responses:

  • Headers (metadata like content type or authorization)
  • Body (the data being sent or returned)

• SSL/TLS: Secure communication happens over HTTPS, which encrypts data using SSL/TLS to protect against eavesdropping or tampering.

5.3 Designing Robust & Practical APIs

Good API design is essential for usability, maintainability, and scalability. A few core principles:

• Simplicity: Keep endpoints predictable and easy to use. Stick to consistent naming conventions and avoid unnecessary complexity.
• Consistency: Follow established standards (like using plural nouns for REST resources) and make behaviour uniform across endpoints.
• Versioning: Use clear versioning (e.g., /v1/users) to avoid breaking clients when making changes.

• Pagination & Streaming:

  • For large datasets, implement pagination (limit/offset or cursor-based) to avoid overloading the client or server.
  • For real-time or continuous data, consider streaming responses — either via HTTP streaming, WebSockets, or gRPC.

---

If you’ve made it this far—congratulations! System design fundamentals are no small feat, but I hope this overview has helped you get a solid start. In the next article, we’ll dive into caching (including CDNs, proxies, and hashing strategies for load balancers) and storage concepts like SQL vs. NoSQL databases.