DEV Community: Gabrielle Niamat

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

Gabrielle Niamat — Fri, 03 Jul 2026 13:00:00 +0000

Part 4: The System Design Interview - Continued
1. Caching 🗂️
    1.1 What is Caching?
    1.2 Content Delivery Networks (CDNs)
2. Proxies & Load Balancers 🔀
3. Storage 🗄️
    3.1 SQL vs. NoSQL
    3.2 Object Storage
    3.3 Replication
    3.4 CAP Theorem & Consistency
    3.5 Sharding
4. Wrap Up

Part 4: The System Design Interview - Continued

Hi there, welcome back! 👋🏼 I recognize it's been over a year since my last post; life got in the way, and honestly between work and some personal stuff, writing just wasn't in the cards for a while. But I'm back for 2026, and I'm excited to finally close out this new grad guide before shifting my writing toward more intermediate-level content.

If you're new to this series, I'd recommend starting from the very beginning here, or at least checking out part 1, which covers computer and application architecture, networking (TCP/UDP, DNS), and APIs (REST, GraphQL, WebSockets, gRPC). This article picks up right where that one left off - covering caching, proxies, and storage to round out the fundamentals.

Alright, enough preamble. Let's get into it!

1. Caching 🗂️

1.1 What is Caching?

Caching is the practice of storing copies of data in a fast, temporary location so you don't have to fetch it from the original (slower) source every time. The two main benefits are improving performance and reducing load on your databases and downstream services.

Cache: A high-speed data storage layer that holds a subset of data so that future requests are served faster than by accessing the primary storage location.

Cache levels - Caching can happen at multiple layers:

Client-side: Browsers cache assets like images and scripts locally.
CDN: Edge servers cache content close to the user geographically (more on this below).
Server-side: The application caches frequently accessed data in memory using tools like Redis or Memcached.

Key terms:

Cache Hit: The requested data is found in the cache ✅
Cache Miss: The data isn't found — the system falls back to the primary source ❌
Cache Hit Ratio: The percentage of requests served from cache. Higher = better.

Write strategies — when new data is written, you need a way to keep the cache and database in sync:

Write-through: Written to cache and database simultaneously. Consistent, but slower writes.
Write-back (Write-behind): Written to cache first, database updated asynchronously. Faster writes, but risk of data loss if the cache goes down.
Write-around: Written directly to the database, bypassing the cache. Prevents caching data that likely won't be re-read soon.

Eviction policies — when a cache is full, something has to go:

LRU (Least Recently Used): Removes the item accessed longest ago.
LFU (Least Frequently Used): Removes the item accessed fewest times.
FIFO (First In, First Out): Removes the oldest item regardless of access frequency.

Popular server-side caching tools are Redis and Memcached. Redis is the more common recommendation since it supports richer data structures, optional persistence, and replication — making it useful beyond just caching (e.g., session management, pub/sub, leaderboards).

Cache invalidation (deciding when to remove or update stale data) is genuinely one of the trickier problems in distributed systems, and it's worth knowing about even if you never have to implement it yourself. The two most common approaches are setting a TTL (Time-to-Live) on cached entries so they expire automatically, or explicitly invalidating cache entries whenever the underlying data changes.

1.2 Content Delivery Networks (CDNs)

A CDN is a geographically distributed network of servers that caches static content — images, videos, CSS, JavaScript — and delivers it to users from the server closest to them, reducing latency.

Two main caching models:

Push CDN: Content is proactively pushed to edge nodes before it's requested. Best for content that doesn't change often.
Pull CDN: Content is fetched from the origin on the first request, then cached on the CDN going forward. Better for large sites with lots of assets.

2. Proxies & Load Balancers 🔀

A proxy is an intermediary server that sits between a client and a backend. There are two types:

Forward Proxy: Sits in front of the client — the server doesn't know who the original client is. Common use cases: VPNs, corporate firewalls.
Reverse Proxy: Sits in front of the server — the client doesn't know which backend is handling its request. Nginx is a popular example. In system design, when someone says "proxy," they typically mean this.

A load balancer is a type of reverse proxy that distributes incoming traffic across multiple servers. Common strategies:

Round Robin: Requests are sent to servers in rotation.
Least Connections: Traffic goes to whichever server has the fewest active connections.
IP Hashing: A client's IP is hashed to consistently route them to the same server — useful for maintaining session state.

Regular vs. Consistent Hashing

With regular (modular) hashing (hash(key) % num_servers), adding or removing a server causes almost every key to be remapped which is essentially a full reshuffle every time. Consistent hashing fixes this full N shuffle problem by mapping both servers and requests onto a virtual ring, so when a server is added or removed, only the keys that were assigned to that specific server need to be remapped. This minimizes disruption during scaling and is widely used in distributed caches and databases.

As an extra fact, reverse proxies also provide SSL termination, security (hiding internal server structure), caching, logging, and response compression — all in one place.

3. Storage 🗄️

3.1 SQL vs. NoSQL

One of the most common system design questions is: "What kind of database would you use, and why?"
SQL (Relational Databases) store data in structured tables with predefined schemas. Popular examples: PostgreSQL, MySQL. Most use B+ trees as their primary index structure, which keeps data sorted and supports efficient range queries.

SQL databases follow ACID properties:

Atomic: Every operation in a transaction succeeds completely, or none of it does. No partial writes.
Consistent: A transaction can only bring the database from one valid state to another — no rule-breaking in between.
Isolated: Concurrent transactions execute independently of each other, as if they were run sequentially.
Durable: Once a transaction is committed, it stays committed — even if the system crashes immediately after.

NoSQL (Non-Relational Databases) trade some structure and strict consistency for flexibility and horizontal scalability. Instead of ACID, most follow BASE:

Basically Available: The system guarantees availability — it will always return a response, even if it's stale or partial.
Soft State: The state of the system can change over time, even without new input, as replicas sync up.
Eventual Consistency: Given enough time, all replicas will eventually get the update/correct value.

3.2 Object Storage

Object storage is designed for large, unstructured files — images, videos, backups — rather than queryable data. Amazon S3 is the most widely used example. Unlike traditional file systems, there's no folder hierarchy — just a flat structure of objects, each with a unique key and metadata.

Key properties: highly durable, cost-effective at scale, accessible via HTTP API. Not suitable for frequently updated records or low-latency lookups.

3.3 Replication

Replication is the practice of copying data across multiple database instances to improve availability, read performance, and fault tolerance.

Synchronous replication: The primary waits for replicas to confirm the write before returning success. Always consistent, but slower.
Asynchronous replication: The primary confirms immediately; replicas catch up later. Faster, but there's a brief window of inconsistency.

Architectures:

Leader-Follower: One primary handles writes; replicas serve reads. Simple, but the primary is a single point of failure for writes.
Leader-Leader (Multi-Primary): Multiple nodes accept writes. More resilient, but introduces conflict resolution complexity.

3.4 CAP Theorem & Consistency

The CAP Theorem states that a distributed data store can only guarantee two out of three of the following properties simultaneously:

Consistency: Every read returns the most recent write, or an error.
Availability: Every request gets a response (not necessarily the freshest data).
Partition Tolerance: The system keeps running even if some nodes can't communicate.

Since network partitions are inevitable in real distributed systems, P is always required — so the real trade-off is between C and A:

CP systems (e.g. HBase): Refuse requests during a partition rather than return stale data.
AP systems (e.g. Cassandra, DynamoDB): Stay available during partitions but may return slightly outdated data.

This connects to the strong vs. eventual consistency trade-off: strong consistency guarantees every read reflects the latest write (higher latency); eventual consistency allows brief inconsistencies in exchange for better performance and availability.

3.5 Sharding

Sharding is a horizontal partitioning strategy where data is split across multiple databases (shards), each holding a subset of the total dataset. It's how you scale a database beyond what a single machine can handle.

Common sharding strategies:

Range-based: Partition by a value range (e.g. user IDs 0–25M on shard A, 25M–50M on shard B). Simple, but can lead to uneven load if some ranges are more active ("hot shards").
Hash-based: Hash the shard key to assign records. Distributes data evenly, but makes range queries harder.
Directory-based: A lookup table maps records to their shard. Very flexible, but the lookup table itself becomes a bottleneck.

The main downside of sharding is that cross-shard queries are expensive and complex. Re-balancing data when adding or removing shards is also non-trivial — another place where consistent hashing helps.

4. Wrap Up!

That wraps up the system design series! 🎉

Across both parts, we covered computer architecture, scalability fundamentals, networking, APIs, caching, proxies, and storage. As I mentioned in Part 1 — formal system design rounds are rare for new grad roles in Canada, but having a solid handle on these fundamentals will make a real difference when verbal technical questions come up, and it'll set you up well for your first few months on the job.

Start with the core concepts, practice explaining them out loud, and don't stress about memorizing every detail. The more you read, design, and discuss these systems, the more naturally it all clicks.

And honestly, I wouldn't worry too much about knowing these topics in detail - I was personally asked about them at a higher level and managers were often impressed that I knew some fundamentals a all!

This post was written with the help of AI but all thoughts and opinions are my own.

I Signed Up for a Software Engineer Mentor. I Got an AppSec Engineer Instead.

Gabrielle Niamat — Sat, 27 Jun 2026 19:57:44 +0000

I've been with my new company for a little over 2 months now. I joined at the end of April as an SWE II (go me 🥹🎉). A few weeks into joining, I saw a post on Slack that our next Women in Tech mentorship cohort was starting. Being brand new, I of course, didn’t hesitate to jump at the opportunity.

When I signed up, I was determined to get matched with a mentor strong in system design and architectural thinking. What I got instead was an AppSec engineer — and just being honest, my initial reaction was disappointment. System design felt like the move, the natural next step for a fresh intermediate engineer trying to broaden her technical foundation. I knew security was important, of course, but it hadn't felt like the most critical thing for me to be learning right now.

Two sessions in, I'm still very much a beginner so I hesitated to write this post just yet — but I'm truly already feeling like this pairing has been invaluable. It's changing how I think about the code I ship every day, and I hadn't realized how big of a gap this was in my thinking until someone sat me down and started walking me through it. I'm sharing my learnings here in case you're like me — an engineer who never really considered cybersecurity as something that fell into your lane.

What even is cybersecurity?

At a high level I knew what cybersecurity was — or at least I thought I did. My mentor opened our first session with a simple framing: cybersecurity exists to protect networks, devices, and data from unauthorized access — because unauthorized access leads to fraud, criminal activity, and loss of trust. At a smaller fintech company especially, that trust is everything — it's not something we can afford to lose. Cybersecurity breaches affect real businesses and real money, and if we lose that confidence with our customers, we’re, for a lack of a better term, SOL.

The whole field is built on three central pillars, called the CIA triad:

Confidentiality — data should only be accessible to people who are authorized to see it
Integrity — data shouldn't be modifiable without authorization
Availability — access to resources is controlled; you get what you need, not everything

The tricky part is translating those three ideals into how an actual engineering organization operates, which is exactly where different security teams come in.

Blue teams, Red teams, and everything in between

Security teams are typically broken into a few distinct groups — and yeah, they really do go by colours.

Defensive security (blue team) is focused on protection and detection, and there are a few subgroups:

SOC (Security Operations Center) — monitors all company activity and flags suspicious behaviour. Why is someone from HR accessing an AWS server at 2am? The SOC catches that.
Incident Response — steps in when something alarming is confirmed. This is notably different from engineering incident response and something I found pretty cool: you can't just fix it and move on. You have to preserve evidence and chain of custody for potential forensics — treat it more like a crime scene than a bug. You might even tell people not to restart their computers because the data in memory could matter later.
Threat Hunting — proactively digs through existing logs to understand what could have happened if a known vulnerability had been exploited. Sometimes in doing that exercise, they uncover incidents that were actually real.

Offensive security (red team) flips the script — instead of defending, you're simulating what an attacker would do. The main approaches are:

Penetration Testing — actively attempting to find and exploit vulnerabilities before a real attacker does. There are three types: black box (no prior knowledge), grey box (some knowledge), and white box (full knowledge of the system). This is what most fintechs focus on.
Red Teaming — a full 360-degree security assessment that goes beyond the application to include physical access, social engineering, even impersonating employees to see if you can get into a building. This is much broader in scope, but also more expensive and less common.

There can also be a purple team, which is a hybrid of blue and red. It tests both security controls and defending against them at the same time.

Where AppSec fits in (and where it doesn't)

AppSec doesn't neatly slot into blue or red. It's a combination of both, but with a very specific focus: protecting the product, not the company as a whole.

If someone's laptop gets stolen, that's an enterprise security concern which is important, but it’s not AppSec's domain. AppSec is all about securing the application and its users (think: protecting a product that real businesses use to manage their money).

What I found really surprising is how much tooling quietly exists in the background to support this. Some of it was already running quietly in my own daily workflows — I just never knew what it was actually doing.

SAST (Static Application Security Testing) — scans code for known vulnerability patterns
SCA (Software Composition Analysis) — checks runtime dependencies for known malware or vulnerabilities; this can be run on most pull requests via Datadog
Sonatype — acts as a package firewall, blocking downloads of suspicious or low-confidence packages to guard against supply chain attacks

There can also be custom in-house tools — for example a bot that scans all the links on a company’s marketing directory page to check whether domains are still valid and not about to expire. This is important because an expired domain can be bought by an attacker and used for phishing or social engineering. I genuinely had no idea that this was even a threat vector before this.

What ultimately stuck with me - "100% secure doesn't exist"

My mentor closed our first session with something I keep coming back to: perfect security is an unobtainable illusion. Chasing 100% security leads to hyper-rigidity, and that level of rigidity doesn't belong in an environment that prioritizes shipping fast to serve customers. We have to balance shipping features quickly with shipping them securely — and the way you do that is through layered controls. If we can implement enough guardrails that an attacker has to work really hard to get anywhere, and if they do gain access somewhere they shouldn't, it's limited in scope and impact — then we've done the best we can.

A genuinely mind-blowing example of why this mindset matters is the Target breach of 2013 (something I'd never heard of before this). Hackers didn't break into Target's systems directly. They compromised the network of an HVAC company that serviced Target's physical stores, then pivoted from there into Target's internal infrastructure, eventually reaching point-of-sale systems. The result: 40 million credit and debit card numbers stolen, 70 million customer records compromised, an $18.5 million settlement, and over $200 million in estimated total losses — driven by damaged customer trust and a tanking share price.

It's not enough to trust that your third-party integrations are secured — never assume someone else has it covered. The HVAC vendor's network wasn't Target's problem — until it very much was, and by then it was far too late.

How an AppSec mindset is starting to change things for me

I came into this mentorship wanting to think bigger about system design. What I didn't expect was that AppSec would make me think more carefully about the systems I'm already building.

The thing my mentor kept highlighting is that AppSec at our company isn't a blocker. The team won't hold up a feature over a security concern — they'll flag it, provide recommendations, and work within the reality that the business needs to move fast. But, honestly that's actually all the more reason for engineers to be thinking about this, not less. If AppSec is a collaborator rather than a gatekeeper, the security mindset has to live somewhere — and a big part of that somewhere is the people planning projects and writing the code.

I didn't know I needed to learn any of this quite yet. Two sessions in, I'm really glad I accidentally did.

Disclaimer: This post was written with the help of AI (Claude Sonnet 4.6), but all thoughts, opinions, and experiences are my own and have been reviewed and edited by me.

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

Gabrielle Niamat — Tue, 01 Jul 2025 15:00:00 +0000

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:

Moving Data: Efficiently transferring data between geographically distributed clients and servers.
Storing Data: Ensuring data persistence and accessibility.
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:

Availability: The percentage of time a system is operational. Measured in "nines" (e.g. 99.999% availability equates to ~5 minutes of downtime annually).
Reliability: The likelihood a system operates without failure over a specified period.
Fault Tolerance: The system's ability to detect and recover from failures without affecting functionality.
Redundancy: Backup resources, such as shadow servers, to maintain service continuity during failures.
Throughput: The volume of operations a system can handle within a given time frame.
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.

Navigating the New Grad SWE Job Hunt: Behavioural Interviews

Gabrielle Niamat — Mon, 07 Oct 2024 12:00:00 +0000

Part 2: The Behavioural Interview
Personality Questions
Qualification Questions
Problem-Solving Questions

Part 2: The Behavioural Interview

Welcome back 👋🏼

Let’s dive right into Part 2: preparing for the behavioural interview round. You’ll face these questions in nearly every stage, from phone screens to bar raisers. In my experience, they pop up all throughout the Canadian new grad interview process. If you're like me and need to practice what you're going to say before you actually say it, I hope this part of the article helps you feel more confident and nail your answers—so you’re not just winging it through trial and error during the interviews.

Let's break down behavioural interviews into the 3 key areas they're assessing:

Your personality – Do you fit into the team/company’s engineering culture?
Your qualifications – What experience do you have with different frameworks, languages, and tech stacks?
Your problem-solving abilities - Given a complex situation, how do you go about solving it?

1 - Personality Questions

Personality questions, regardless of who asks them, are all about getting to know you. They’re interested in learning about your work style, how you handle conflicts, whether you prefer working independently or in groups, and more. Being able to answer behavioural questions using the STAR format is key, and I recommend preparing at least two examples for each type of question.

Here’s a comprehensive list of all the personality-type questions I’ve ever been asked, along with specific advice for some of them:

Introduce yourself / Tell me a bit about your background.
- list your educational and work experience
- explain any achievements that you're proud of and showcase your expertise
- discuss where you see yourself headed in the future
Walk me through your resume.
What is your biggest strength/weakness as it relates to this role (e.g. a technical strength)?
Describe a time when you had to push or advocate for something in a project. What impact did it have?
- Pick an example that showcases your leadership skills, and ability to communicate while creating clarity in times of uncertainty
Why did you choose to pursue software engineering?
- Try to avoid saying 'money' or 'flexibility to work where you want'. Great candidates stand out when asked this question by giving a memorable story that sets them apart from others.
- For example, when I was asked this question, I shared that during high school, I played an otome game where the characters used a chatroom app they had built from scratch. This sparked my interest in how software could be developed to meet specific needs, inspiring me to explore how I could do the same.
Tell me about a time you received negative or constructive feedback and how you responded.
Give an example of when you took initiative or leadership during a challenging time at work.
What are you looking for in your next role?
Where do you see yourself in 5 years?
Why did you apply for this role/company?
- This is really asking why they should hire you over other candidates. Be sure to list your technical competencies, as well as anything that stood out about the company/position that enticed you to apply.
What part of the tech stack do you enjoy the most?
Describe a time when you had a conflict with a coworker or team, and how you resolved it.
Explain a difficult bug you fixed in the past 6 months.
- This question seeks to dive deeper into your problem-solving abilities and how you unblock yourself when stuck. Focus on explaining things like time-blocking, independent investigation, consulting various resources, and pair-programming with other devs.
Walk me through a project you’re most proud of and why. What challenges did you face? Describe them in technical detail and how you solved them.
- Be ready to discuss at least 1-2 challenges for each experience and project on your resume.
How do you handle pressure and tight deadlines? Give an example from work.
How do you de-stress and relax?

The goal of these questions is to understand your personality, work style, and communication skills. They also help the interviewer assess whether you’re approachable, friendly, and able to clearly articulate your thoughts. If you can keep the conversation engaging, maybe make your interviewer smile or laugh with a good story, you're on the right track. The key is to present yourself as someone who is not only pleasant to work with but also capable of performing well on the team. Be authentic, and have a strong story about why you chose this career and company—it’ll help you stand out, especially when competing against similarly qualified candidates.

Tip: Before my interviews, I always reviewed the job posting I applied to and checked Glassdoor reviews for insights on the interview process. Glassdoor is an invaluable resource, and many people share exact questions they were asked, along with details about the number of interview rounds. Definitely use it to get a feel for the questions you might face.

2 - Qualification Questions

The second type of interview questions you’ll encounter dive deeper into your technical background and previous experiences. Since I had three software engineering internships and one full-stack project on my resume, I was often asked to explain what I did in each role, which part of the tech stack I’m most comfortable with, and some of the challenges I faced in those positions.

These questions require thorough preparation, so my advice is to sit down and think through how you’d expand on each bullet point in your resume. Ask yourself the following for every experience, project, or club you’ve listed:

Can I give a high-level overview of my responsibilities and the impact of my work?
What challenges did I face, and how did I overcome them?
Can I explain the technologies and frameworks I used, and why I chose them?
Did I improve any processes? If not, is there anything I would improve now?
- You should always have something to say regarding what you can improve, from processes to documentation to architecture etc. The important thing is that you've reflected and thought about how to make your work more efficient, which is a positive signal to interviewers.

Try to prepare answers for these types of questions, focusing on the technical details to highlight your skills and expertise:

What tech stack did you use and why?
What projects did you work on (in school and at previous jobs)?
What was the most challenging situation in your previous role, and how did you solve it?
Have you ever creatively solved a problem or challenge? How did you approach it?
How did you resolve a disagreement with a coworker or classmate? (This could be about code style, architecture decisions, or a PR that got held up due to comments.)

Make sure you fully understand the technologies you’ve listed on your resume. While my resume suggests that most of my experience is in frontend development, my personal interest is in backend engineering, so I made sure I could speak confidently about both areas. For backend topics, I brought up concepts like SQL vs. NoSQL databases, REST vs. GraphQL APIs, sharding, scalability (horizontal vs. vertical), and CDNs (Content Delivery Networks) when discussing my design decisions for personal projects. On the frontend side, I made sure I could explain concepts like state and props, dependency injection, lazy loading, debouncing, and asynchronous JavaScript—especially when talking about my past work with frameworks like React.js, Vue.js, and Angular.js.

It’s important to be well-versed in both the areas you’ve worked in and the areas you want to move into. That way, if an engineer or hiring manager asks you about a particular technology or concept, you’re not caught off guard.

3 - Problem-Solving Questions

In addition to personality and qualification questions, you’ll likely encounter problem-solving or technical questions where interviewers assess your ability to think on your feet. These questions might not always be a formal coding challenge; sometimes, they’ll involve discussing how you’d approach a technical problem verbally, walking the interviewer through your thought process.

I encountered quite a few of these types of questions, and it really helps to be comfortable with high-level concepts, including some system design topics. Here are a few examples of the kinds of verbal technical questions you might face:

How would you optimize the performance of the frontend for an application that’s experiencing slow load times?
Can you explain the difference between synchronous and asynchronous programming, and when you would use each?
What is the event loop?
What’s your approach to debugging a large codebase when you’re unfamiliar with the code?
Would you choose to design a REST API or GraphQL API for an application like Twitter, and why? Walk me through the basic endpoints you’d create.
What kind of database (NoSQL, SQL, document) would you choose to store X and why?

In these questions, the focus is on how you break down a problem, consider trade-offs, and arrive at a solution. The interviewers aren’t necessarily looking for a perfect solution but rather your ability to communicate your thought process clearly, collaborate on ideas, and show that you can handle real-world technical challenges.

Tips for tackling problem-solving questions:

Think out loud: Let the interviewer in on your thought process, even if you’re not 100% sure of the answer right away. This helps show how you approach challenges.
Consider trade-offs: Be ready to discuss the pros and cons of different solutions. For example, if you’re asked about scaling an application, you might talk about database sharding vs. vertical scaling, or the trade-offs between performance and cost.
Don’t panic if you don’t know something: If you’re not familiar with a specific concept or technology, be honest about it, but try to relate it to something you do know. You can also talk about how you’d go about researching and solving the problem. I’ve had moments where I didn’t have all the specifics, but I drew parallels to similar knowledge I had, and the interviewers were fine with that.
Ask clarifying questions: Don’t be afraid to ask for more information if the problem is vague. Asking good questions shows that you’re thinking critically about the problem.

Tips for working from the office?

Gabrielle Niamat — Wed, 02 Oct 2024 13:56:17 +0000

With more companies announcing mandatory return to office (RTO) policies, I’m curious — how are other developers handling the shift back to in-person work? Do you prefer working from the office, or are you still team WFH?

I recently accepted a new grad offer as a Software Engineer I, and starting soon, I’ll be commuting to the office 3-4 days a week in downtown. My past internships were all remote, so this is a large shift for me.

For those of you who have already worked in-office, I’d love to hear your advice on a few things:

How do you handle the fatigue from commuting?
If you’ve ever felt awkward or shy in the office, how did you overcome it?
What’s typical attire like for engineering teams these days?
Do you usually pack your lunch, or grab something near the office?

For those who work in-office or have a hybrid schedule, I’d really appreciate any tips on making the most of the experience. Thanks! 😊

Navigating the New Grad SWE Job Hunt: Landing Interviews

Gabrielle Niamat — Wed, 02 Oct 2024 13:53:19 +0000

Introduction
Part 1 - Landing Interviews
Writing a Software Engineer Resume
My Current Software Engineer Resume
Reflect - Are you focusing on the right thing?
Conclusion

Introduction

Hi everyone, it’s been a while since my last post—I hope you’ve all been doing well. Today, I want to share my journey in searching for a new graduate software engineer position here in Canada. I’ll also provide a timeline of my study process and some advice based on my recent interview experiences. I know the job market has been tough over the last year or two, and many of my fellow alumni have struggled to land interviews, so I hope my insights will help you approach your job search with more confidence.

To start, a little background about me: I’m Gabby, a Canadian citizen and recent Computer Science graduate from Western University. I completed my degree in April 2024 and was fortunate enough to secure 3 software engineering internships during my undergrad, primarily focused on fullstack development. After graduation, I took about two months off to relax and spend time with my family. I started applying for jobs seriously in mid-July and continued through to the end of September. While I didn’t keep track of the exact number of applications (and honestly, I don’t think you should either), I progressed to the final rounds with three companies and received an offer from a Fortune 500 company 🎊.

During my time off, I treated the break as an opportunity to recharge and prepare for interviews. I focused primarily on the Neetcode 150 list of questions, following Neetcode’s beginner and advanced roadmaps. In hindsight, while I dedicated most of my time to data structures and algorithms (DS&A) preparation, I’ve realized that behavioral interviews and resume preparation were equally—if not more—important. From my experience, non-FAANG companies emphasized behavioral interviews far more than Leetcode-style technical interviews, and these were often the key factors in determining the outcome of your application.

A quick disclaimer: I’m writing this from the perspective of a typical CS graduate seeking full-time employment. By "typical," I mean someone who isn’t specifically aiming for top FAANG or quant firms. There are plenty of great resources available if you're targeting those highly competitive positions, and some of the ones I mention can certainly help you get started on that path. However, the focus of these articles is to provide young professionals with the tools they need to feel confident interviewing for roles that prioritize work-life balance (WLB) at a variety of companies, not just exclusively FAANG.

Of course, working for a prestigious company that offers top-of-market TC is amazing — but please don’t feel like that’s the only option. During my undergrad, I saw a lot of "FAANGMULA or bust" mentalities in students that, in the end, only hurt the confidence and resiliency of those who didn’t land those roles.

Part 1 - Landing Interviews 🔎

Before you start sinking hundreds of hours into interview prep, it's crucial to ensure you can actually land interviews in the first place. One common cause of burnout during the job search is spending months on Leetcode and cold applying to jobs, only to end up with no interviews, feeling completely drained, and realizing you haven’t made any progress with companies that are hiring 😪. I also think this might be one of the hardest parts of the job search, so it's essential to make yourself as competitive as possible.

In Part 4, I’ll discuss a bit more regarding how networking and joining local tech communities can help you secure referrals and uncover unadvertised roles through word-of-mouth (see: the hidden job market). For now though, I want to focus on optimizing your resume, LinkedIn, and social media profiles to increase your chances of passing ATS filters and recruiter resume screens.

Writing a Software Engineer Resume

There’s a lot of conflicting advice out there about resume best practices, but here are some guidelines I strongly recommend:

Keep your resume to a maximum of 1 page - unless you have more than 10 years of experience
International candidates: Be sure to indicate if you need visa sponsorship or if you already have a visa and don't require sponsorship.
Avoid listing every achievement - While professional publications and certifications are great, you likely don’t need to include them unless they’re directly relevant to the positions you’re applying for.
Skip listing hobbies, interests, or the high school you attended (assuming you have college or university experience) — this doesn’t add any value to your application
Don't include a professional summary - again, unless you have enough seniority to justify it
Stick to a single-column format for your resume — it’s easier to read for both ATS systems and recruiters

If you haven’t come across it yet, I highly recommend checking out the Tech Interview Handbook. It’s an excellent resource that goes way more in depth on resume writing, and also covers how to prepare for every stage of the software engineering interview process 🫶🏼.

If you're struggling to condense your experience into concise bullet points, I completely understand — it’s tough! Writing a resume requires deep reflection on the work you did, the projects you were involved in, and the impact you had. I’ve found that many people are pretty darn good at explaining their impact verbally, but struggle to translate that into written text on paper. If that sounds like you, try using voice-to-text software to capture your thoughts. You can also ask friends to quiz you about your past internships—it’s a solid way to uncover the technologies you used and the impact you made.

Some additional tips for writing your resume include:

If you’re stuck on what to write, start by listing everything you’ve done. It’s easier to refine from too much detail than from too little.
Don’t hesitate to reach out to classmates, friends, or family for multiple rounds of edits on your resume. It’s normal to go through several revisions before reaching a final version.
Don’t rely solely on friends for feedback. In my experience, close friends may hold back from being overly critical. Consider taking advantage of resources like ChatGPT, and online communities like BobaTalks (their Discord server offers excellent feedback from mentors), and CS Careers Dev (their Discord server provides brutally honest resume reviews, which is exactly what everyone needs).
Tailor your resume to the roles you’re targeting. For instance, I’ve seen people focus heavily on including frontend development experience while applying for full-stack roles, only to be frustrated when they get rejected. Make sure your resume aligns with the types of roles you want. If you’re aiming for cloud computing roles, having certifications or licenses, like an AWS Cloud certification, could help bridge the gap if your experience is lacking.

My Current Software Engineer Resume

I think thanks to my past engineering internships, I’ve been fortunate enough to receive a good response rate from my resume, so I’d like to share the formatting and approach I use with all of you. Hopefully, it will give you some ideas and inspiration on how to write effective bullet points that follow the STAR method.

Purple highlights - impact/result of my actions
Yellow highlights - the action taken
No highlights - context, situation, and/or technologies I used

You can see I used Jake’s resume template, which is super popular in the tech community for its clean, no-nonsense design. You don’t have to use this exact one, but I’d suggest sticking to a single-column format for readability. If you're early in your career, it's a good idea to put your education at the top so recruiters can quickly spot your degree and graduation date.

One thing to note: always include start and end dates for all your experiences. For your degree, the start date is optional, but definitely include the end date or your anticipated graduation date. Make sure your resume has your phone number, a non-school email, LinkedIn, and GitHub. If you have a polished personal website, throw that in too.

Common mistake: avoid listing generic tools like MS Office or IDEs you’ve used. Your resume has limited space, so focus on showcasing the key languages and frameworks you're skilled in and that are relevant to the jobs you're applying for.

To get through resume screens, you need to think about keywords recruiters might search for. While it’s optional, I do think highlighting technologies and including some quantitative metrics helps make your resume more skimmable for recruiters. You’ll notice that my bullet points really try to cram in as much impact as possible while being concise and logical. I always mention the technologies and frameworks I used, plus explain what kind of difference my work made. Be honest about your metrics, and if exact numbers aren’t possible, give your best educated guess. Numbers stand out, so even if you have to estimate, try to include metrics where possible ‼️

If you don’t have much software engineering experience yet, list your strongest experience first—whether it’s personal projects, freelance work, or internships—and leave the less relevant stuff toward the bottom. If you're still in school or just graduated, pick your best project(s) (ideally something you built on your own, not just a class project) to show off your skills and initiative.

Reflect - Are you focusing on the right thing?

When you've finished writing, rigorously editing, and re-editing your resume - take a step back. Ask yourself, “What kinds of roles does my resume seem most suited for? 💭” Ideally, it should align with the roles you’re applying to. If not, there’s a serious mismatch between your content and your goals, and you need to fix this.

Let's break down the technologies in my resume as an example:

Tech-stack	Internship 1	Internship 2	Internship 3	Project
Front-end?	Angular.js	Vue.js	React.js	React.js
Back-end?	Ruby on Rails	-	-	Nest.js, PostgreSQL
Misc?	DataDog	AWS EC2, Docker	Electron.js, Axios	Prisma

If you were my recruiter, where would you say my experiences and skill-sets lie? Probably more front-end focused than back-end, right? Overall, when applying to positions I need to keep in mind that my resume is more suited for front-end or full-stack roles, rather than purely back-end roles, thanks to my past experiences.

If my goal was something else—like AI or Cloud Engineering—I’d need to rethink my approach. I’d focus on selecting internships or personal projects that highlight skills in those areas, like cloud infrastructure or AI-related technologies. You should always think about how your resume comes across and align your experiences with your target roles.

Conclusion

Getting interviews is arguably the hardest part of the recruitment process, especially in today’s market where even experienced engineers struggle to get callbacks after sending out hundreds of applications. I hope some of my advice helped you craft a stronger resume. Many of these tips can also be applied to optimizing your LinkedIn profile (though feel free to include certifications, research papers, volunteering, etc. on LinkedIn—it’s the place where all your qualifications can really shine 🤩).

I’d love to hear any additional advice you might have for crafting resumes or landing interviews through cold applications. Thanks for reading all the way through!

Advice for newbie devs that are Working From Home? 💻

Gabrielle Niamat — Wed, 05 Jul 2023 15:54:24 +0000

Hi all! ☀️

I'll be starting my first full-time software developer co-op in the fall and I will be working entirely remotely. I'd love to hear your tips/advice on how to be productive and consistent when working in an entirely remote setup!?

I also want to secure a return offer with this company, so any guidance on how to excel during my WFH co-op would also be fantastic :) 🐳

MLH Fellowship: My Admissions Timeline & Program Experience!

Gabrielle Niamat — Sun, 08 Jan 2023 06:19:23 +0000

What is the MLH Fellowship ⁉️

In case you’re unfamiliar or just need a refresher, the MLH Fellowship is a 12-week program designed to support individuals who are interested in pursuing a career in the tech industry. The program provides participants with the opportunity to work on real-world projects from top engineering companies, receive mentorship from industry professionals, and develop valuable skills that will help them succeed in their future careers. Some notable companies that partner with the MLH Fellowship include Google, Meta, Amazon, G-Research, RBC, GitHub, Solana Labs, and many, many more.

For more information, check out their official website: https://fellowship.mlh.io/

Timeline ⏰

My timeline for applying to the Fall 2022 MLH Fellowship is outlined below (note the duration between application steps might be slightly different for each individual):

August 5, 2022 - Submission of initial application 🤞🏼
August 8, 2022 - Application went into review ⭐️
August 21, 2022 - Invitation to schedule behavioural interview round 👩🏻‍💼
August 25, 2022 - Completed behavioural interview ✅
August 27, 2022 - Invitation to schedule technical interview 💻
September 5, 2022 - Completion of technical interview ✅
September 12, 2022 - Email of acceptance into the program 🎉

As you can see, the process took a bit over one month to complete from start to finish. I would strongly encourage all applicants to apply at least 2 months before the program start date, as the process is lengthy and highly competitive. Applying early also means you get to know that you’re a part of the program earlier, as acceptances are sent out on a rolling basis.

Onboarding Process 🏄‍♀️

Curious to know what the on-boarding process for the MLH Fellowship looks like in the weeks leading up to the program’s start? The following is a short recap of my personal experience getting set up for the Fellowship.

Firstly, I received an email of acceptance which told me I was successfully matched to a project! This invitation came straight from the wonderful Amanda D'Avria herself and included the program start and end date, the track, time commitment, meeting days and times, and the stipend amount. Included in the email is also a link to a form I was required to fill out to confirm my enrolment in the program.

Some other little things I did before the program started included:

Signing the Educational Fellowship Agreement (basically a contract and ToS for the program)
Joining the MLH Fellowship GitHub organization via invitation
Joining the MLH Fellowship Discord server (this is where all pod meetings, announcements, educational events, etc. take place)
Signing the Handbook Acknowledgement
Creating a Calendly account and meeting link (so others could book a meeting)

Once all that was done, the only thing left to do was wait for the program to begin!

Fellowship Activities and Events 🎭

The MLH Fellowship also provided a great number of activities and events for Fellows to partake in. While I, unfortunately, couldn’t attend most of them due to class, it was still really nice to have the option to join these events when possible as it helped to build a sense of community and have some fun during the program.

Some things the Fellowship offered to all Fellows, regardless of track, included:

Weekly educational events → LeetCode workshops, resume and interview preparation workshops, industry speakers going over a Day in their Life
Introductory week hackathon → all Fellows are required to participate in the hackathon and build a project using tools from their partner company. At the end of the week, winners from 3 categories are chosen, and special prizes are mailed out (not to brag but my team was one of the winners 🎖️✨)
Final week Capture the Flag → it’s not required for fellows to participate but it’s highly recommended. This CTF involves numerous cyber-security and hacking puzzles that teams must complete to win first place. The winners are announced during the graduation ceremony of the program.

Project Details 📁

During the program, I had the privilege of working with G-Research, Europe’s leading quantitative and research firm. I was initially quite unsure about working with a fintech company as I hadn’t researched the field before but quickly grew to love my Pod members (also working with G-Research) as well as my professional maintainers and technical leads from the company.

I specifically worked on the frontend for G-Research Open Source Software projects and used frameworks and technologies like Vue.js, AWS EC2, Confluence, Jira, Docker, bash, and npm.

A lot of my time was spent on algorithm design and refinement, but more importantly, understanding the mindset behind open-source contributions. My maintainer taught me the importance of being able to understand large code bases, troubleshoot bugs and errors, independently work on assigned tasks, take initiative to reach objectives, and the importance of clear communication as a software engineer.

Additional Thoughts / Feelings / Stories 🥳

While I was initially a bit disappointed that I wasn’t working on backend development or with a fancy FAANG company like Google, the MLH Fellowship was absolutely an incredible experience that has bolstered my confidence and technical ability as a rising software engineer. The skills and connections I created during the program were invaluable, and I hope to continue applying the knowledge I gained in open-source development to help others build efficient and purposeful software.

Thanks for reading about my journey! If this article helped you learn more about the MLH Fellowship, feel free to like it and share it with other curious developers ❤️

Applying to the MLH Fellowship in 2023 🎊

Gabrielle Niamat — Fri, 23 Dec 2022 19:43:51 +0000

Introduction
What is the MLH Fellowship
Application Tips and Tricks
Conclusion
Additional Resources

Introduction 📖

Hey there, nice to meet you 👋🏼! I'm Gabby, a returning MLH Fellow in the Software Engineering track for Spring 2023, a 3rd-year computer science student at Western University, and a Software Engineering and DevOps enthusiast!

Over the past couple of weeks, I've received quite a few DMs on LinkedIn and Discord asking for advice on how to nail the MLH Fellowship application and interview process. As a result, I've decided to compile all the advice I've gathered from past Fellows, the admissions team, and my personal experience into one master list of tips and tricks to help make your application stand out and increase your chances of being invited to the Fellowship 🎉

What is the MLH Fellowship? 💭

If you're curious about the MLH Fellowship and not sure where to start, I highly recommend checking out their official website for more details on the program https://fellowship.mlh.io/

In short, the MLH Fellowship is a highly competitive program for aspiring technologists (hint: think SWEs, SREs, DevRel specialists and more!). It provides a unique opportunity for talented individuals to work on meaningful projects, learn new skills, earn a stipend while receiving education from expert mentors, and make a real impact in the tech industry.

What I especially love about the program is that it's open to applicants from virtually any country and does not require you to be in post-secondary education to qualify. You do have to be 18 years or older, however, so for high school students do your best to contribute to other Open Source projects while you wait!

Application Tips and Tricks 🎩✨

So you've decided that you're going to apply to the MLH Fellowship, but you're unsure how to guarantee that your application demonstrates your excellence to the admissions team and stands out from the rest of the crowd. Don't worry, I've been there too! By following the tips below on how to craft your application, you'll be setting yourself up for success as a future MLH Fellow.

1) Start early

"The early bird really does get the worm when it comes to getting into the Fellowship [...] Most folks who will get into the Spring program will have applied by November 30th." - Amanda, MLH Admissions Team

MLH Fellowship applications typically open several months before the start of the program so it's important to start preparing your application as early as possible. According to the admissions team, about 50% of Fellows apply at least 2 months before the start of the program. By giving yourself enough time to write a strong essay application and build a polished code sample, you'll already have a leg-up compared to other applicants. Don't forget to update your social media like GitHub and LinkedIn to reflect your most recent experiences!

When I first applied to the Fellowship, I only applied a month before the start date. The 3-step admissions process took quite a while, nearly 4 weeks from the time I submitted my application to the time I received my acceptance letter. So please don't be like me and give yourself enough time to comfortably go through the process, especially if you are not a returning Fellow!

2) Tailor your application

A large factor in determining whether you get an invitation to the behavioural interview stage is how strong your essay application is. One of the questions you will need to write a response to is

"[...] What perspective or experience will you bring to the fellowship to strengthen our community?"

When answering this question, take the time to highlight what unique experiences or insights you have and how you believe they will help to strengthen the MLH community. Keep in mind, you don't have to have to be an ex-FAANG intern to be able to highlight your unique qualities as an applicant! When I first applied I explained how my perspectives as a political science student gave me a unique outlook on incorporating ethics and security into the software I built. Try to draw on your past school experiences, personal interests, hackathons and more for this question!

Additionally, make sure that your resume has been tailored to showcase your strongest and most relevant experiences when applying to the Fellowship. And please, make sure to answer the question you're asked during the essay portion of the application - by directly answering the question you demonstrate to the admissions team your ability to succinctly and efficiently solve problems.

3) Show your passion

One of the key qualities that the MLH Fellowship is looking for is a passion for growth and learning. Make sure your code sample and essay answers are well-thought-out, and that you've taken the time to polish them to the best of your abilities. Submitting the best version of your work possible signals to the admissions that you are serious about producing high-quality work and that you already have a good grasp of the technical skills needed to excel in the program.

Be sure to also stress why you're an excellent applicant when answering the essay questions

"Why do you want to become an MLH Fellow" and "Is there anything else we should know about you."

Too often people leave the last question blank when in reality they should be sharing a story with the admissions team that leaves a great first impression about their passions and excitement to join the Fellowship.

4) Demonstrate your technical skills

The MLH Fellowship is a technical program, so it's important to demonstrate your technical skills and capabilities in your application. This includes highlighting any relevant coursework, projects, or hackathons that you've participated in, in your resume.

More importantly, please make sure you add enough detail and polish to your code sample. If you're creating a web app, make sure to deploy it and put the link somewhere visible on your GitHub repository so the admissions team can easily interact with your website. If you're building a mobile app, provide a zipped download file or even a link to the application on the App Store! Making your project visible is an enormous factor in making it easier for the admissions team to assess your skills and competency.

Also, be sure that your code is nicely formatted (using a linter or similar tool), that your commit history is informative (i.e. all the commit messages aren't just 'commit'), that you have sufficient complexity and Isolation of Concerns in your codebase (i.e. don't throw everything into 1 file that is only a few lines long), and that you create an informative and easy to understand Readme.MD (this is crucial to the success of your application).

5) Network and seek out mentors

This is a tip that I leveraged a lot, especially when I first applied to the Fellowship.

Networking can be a key factor in the success of your application, so don't be shy to seek out mentors and advisors who can provide guidance and advice on how to improve your application. Message people on LinkedIn and even join the official MLH Fellowship Discord to ask the team and past/current Fellows any questions you may have!

6) Follow the application instructions

I've already mentioned this in a previous point but I cannot stress it enough. Please please please make sure to answer all questions in your initial application as thoroughly as possible, and pay special attention to what they say they're looking for in a code sample.

I've had a few applicants message me and ask why their code sample got rejected, and their GitHub repository included 3 commits and 3 files in total. This is unfortunately not enough information for the admissions team to determine whether your code was original and whether you can create larger projects of sufficient quality during the program. The MLH Fellowship is a highly competitive program and as such, they are looking for proof that you understand how to write good documentation and substantial code.

Conclusion ✅

If you've made it this far into the article, congratulations and thank you! I hope the advice I've shared about the application process will help you find success as a future MLH Fellow. With that said, please don't be discouraged if you don't get in the first or even the second time you apply! The program is highly competitive and as the admissions team says, you should take the rejection as a "not right now" instead of "never"!

Please feel free to comment about more articles you'd like to see and reach out on LinkedIn for any personal questions you may have about the program. ✨

Additional Resources 📚

Looking for more information on the Fellowship? Here are some great links to get started:

The official MLH Fellowship website: https://fellowship.mlh.io/
The official MLH Fellowship LinkedIn page (hint: find past fellows here and reach out about their experiences) https://www.linkedin.com/school/mlh-fellowship/
The November 2022 MLH Fellowship information session, hosted by the admissions team: https://lnkd.in/g6KGiek3

DEV Community: Gabrielle Niamat

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

Table of Contents

Part 4: The System Design Interview - Continued

1. Caching 🗂️

1.1 What is Caching?

1.2 Content Delivery Networks (CDNs)

2. Proxies & Load Balancers 🔀

3. Storage 🗄️

3.1 SQL vs. NoSQL

3.2 Object Storage

3.3 Replication

3.4 CAP Theorem & Consistency

3.5 Sharding

4. Wrap Up!

I Signed Up for a Software Engineer Mentor. I Got an AppSec Engineer Instead.

What even is cybersecurity?

Blue teams, Red teams, and everything in between

Where AppSec fits in (and where it doesn't)

What ultimately stuck with me - "100% secure doesn't exist"

How an AppSec mindset is starting to change things for me

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

Navigating the New Grad SWE Job Hunt: Behavioural Interviews

Table of Contents

Part 2: The Behavioural Interview

1 - Personality Questions

2 - Qualification Questions

3 - Problem-Solving Questions

Tips for working from the office?

Navigating the New Grad SWE Job Hunt: Landing Interviews

Table of Contents

Introduction

Part 1 - Landing Interviews 🔎

Writing a Software Engineer Resume

My Current Software Engineer Resume

Reflect - Are you focusing on the right thing?

Conclusion

Advice for newbie devs that are Working From Home? 💻

MLH Fellowship: My Admissions Timeline & Program Experience!

What is the MLH Fellowship ⁉️

Timeline ⏰

Onboarding Process 🏄‍♀️

Fellowship Activities and Events 🎭

Project Details 📁

Additional Thoughts / Feelings / Stories 🥳

Applying to the MLH Fellowship in 2023 🎊

Table of Contents

Introduction 📖

What is the MLH Fellowship? 💭

Application Tips and Tricks 🎩✨

1) Start early

2) Tailor your application

3) Show your passion

4) Demonstrate your technical skills

5) Network and seek out mentors

6) Follow the application instructions

Conclusion ✅

Additional Resources 📚