And he's pretty awesome. Read more about Fredrick "Flee" Lee in the link.

https://www.redditinc.com/blog/introducing-fredrick-lee-reddits-chief-information-security-officer

Written by Ryan H. Lewis, Staff Software Engineer, Developer Platform

Hello Reddit!

It’s that time of the half-year again where Reddit employees explore the limitless possibilities of their imagination. It’s time for Snoosweek! It’ll run from August 21st to 25th (that’s next week). We’ve reported back to y’all with the results of previous Snoosweeks, and this time will be no different. But really, we are so proud and excited about every Snoosweek that I couldn’t stop myself from getting the jump on it (and we had some last-minute blog post schedule changes).

So, in this article, I’ll give you some background info on Snoosweek and share what will be different this time around.

TL;DR: What is a Snoosweek (and why)

Reddit employees are some of the hardest working and creative people I’ve ever worked with. As a semi-large company, it takes significant organization and planning to have everyone working in the same direction. That means that there’s often a larger appetite for creativity than can be fit into a roadmap.

Snoosweek gives everyone the spacetime to exercise their creative muscles and work on something that might be outside their normal work. Whether it’s fixing some annoying build issue, implementing their dream Reddit feature, or making a podcast (I did that), these projects are fun for employees and have a positive impact for Reddit. There are many projects that were promoted to production, and others that acted as inspiration for other features. Some of the more internal tasks that we took on were able to be used immediately.

And There’s Swag

We also organize an internal competition for a shirt design from employees and everyone votes for their favorite. Employees who participate in Snoosweek will get a shirt sent to them! And, it may even be the right size (at the discretion of the fulfillment center). Here’s this Snoosweek’s design!

Awards & Challenges

As with each Snoosweek, we have a panel that judges all the projects and bestows Awards (I’ve never won, but I’ve heard it’s great). This Snoosweek will be no different, with the same 6 categories as previous Snoosweeks.

What is different this Snoosweek is a special Challenge for participants. You’ve probably heard rumblings about our Developer Platform (currently in beta; join the waitlist here). This time, the Developer Platform team is sponsoring a challenge to promote employees building their wild ideas using the Developer Platform. The great thing about this (aside from free beta testing for the platform) is that these projects could see the light of day quickly after Snoosweek. Last Snoosweek, there were over fifteen projects that were built on Developer Platform. This time there will definitely be more!

Interested in Snoosweeking?

If this sounds fun to you, check out all of our open positions on our careers page. We’ll be back after Snoosweek to share some of the coolest (or most ridiculous) projects from the week, so keep an eye out for that.

Written by Emily Mucken on behalf of Reddit’s Women Eng Employee Resource Group (ERG)

Who is Women Eng?

We are a community of women Snoos (employees) who are working in engineering roles here at Reddit!

The goal of our group is to foster a greater sense of community & belonging with each other and our allies through events, camaraderie, and upskilling.

Here’s a little more about us:

We are global!

Most of our Women Eng Snoos are located in the US & Canada, but we also have members in Spain, the UK and the Netherlands! Most of our engineering roles are 100% remote, allowing us the freedom and flexibility to work from a location that suits our life and needs best.

We are ambitious!

Women in engineering here at Reddit partner with tech leaders to host internal education and development events (recent highlights were a Design Docs class, and a Code Review class hosted by internal experts on these topics).

Reddit offers our Snoos a professional development stipend to use towards upskilling and adding knowledge in areas we are curious about.

We are building community!

We have weekly (optional!) virtual & IRL hangouts with each other to stay connected.

The vibe is real-talk, supportive… and fun!

We love having a safe space to vent to peers who “get it”.

In addition to being part of Women Eng, many of our members belong to other communities here inside of Reddit:

• Black People of Reddit

• Trans @ Reddit

• Ability (space for Snoos who have disabilities)

• LGBTQSnoo

• RAN (Reddit Asian Network)

• OLE (Hispanic, Latino/a/x Snoos)

• Women of Reddit

In our group, you’ll find: kid moms, cat moms, dog moms, plant moms, musicians, artists, scientists, athletes, puzzle-lovers, fashionistas, speakers, writers and podcasters and more!

We are each unique, but united by a passion for promoting, supporting and advancing our talented women in engineering here at Reddit.

We are … building Reddit!

We have women in engineering roles of all levels and distributed across all orgs:

• Ads!

• Security, Privacy, and Compliance Engineering!

• Data Science!

• Infrastructure!

• Core Experience!

• Core Engineering!

• Consumer Product!

• Safety!

If you’re interested in what it’s like to be an engineer and a trans woman at Reddit, check out our most recent Building Reddit podcast episode featuring Lonni Ingram!

Hello Reddit!

Happy July 4th! I’m happy to announce the eighth episode of the Building Reddit podcast. In this episode I spoke with Matt Knox, Principal Software Engineer, about the experimentation framework at Reddit. I use it quite a bit in my coding work and wanted to learn more about the history of experimentation at Reddit, theories around experimentation engineering, and how he gets such great performance from a service with so much traffic. Hope you enjoy it! Let us know in the comments.

Also, this is the last episode created with the help of Nick Singer, Senior Communications Associate. He is moving to another team in Reddit, but we will miss his irreplaceable impact! He has been absolutely instrumental in the creation and production of Building Reddit. Here is an incomplete list of things he's done for the podcast: initial brainstorming and conceptualization, development of the Building Reddit cover image and visualizations, reviewing and providing feedback on every episode, and reviewing and providing feedback on the podcast synopsis and blog posts. We wish him the best!

You can listen on all major podcast platforms: Apple Podcasts, Spotify, Google Podcasts, and more!

Watch on Youtube

Experimentation might not be the first thing you think about in software development, but it’s been absolutely essential to the creation of high-performance software in the modern era. At Reddit, we use our experimentation platform for fine-tuning software settings, trying out new ideas in the product, and releasing new features. In this episode you’ll hear from Reddit Principal Engineer Matt Knox, who has been driving the vision behind experimentation at Reddit for over six years.

Check out all the open positions at Reddit on our careers site: https://www.redditinc.com/careers

By Savannah Forood, Steven Schoen, Catherine Chi, and Laurie Darcey

In June, Savannah Forood, Steven Schoen, Catherine Chi, and Laurie Darcey presented a tech talk on Tactics for Moving the Needle on Broad Modernization Efforts at Droidcon SF. This talk was for all technical audience levels and covered a variety of techniques we’ve used to modernize the Reddit app: modularization, rolling out a Compose-based design system, and adopting Anvil.

As promised to the audience, you can find the presentation slides here:

• https://app.box.com/s/24o2rx6e0ewgxw50f9pd3k867y8ojcc6

Dive deeper into these topics in related RedditEng posts, including:

Compose Adoption

• Building Reddit’s design system for Android with Jetpack Compose by Alessandro Oddone

• Building Reddit Recap with Jetpack Compose on Android by Aaron Oertel

• Reactive UI state on Android, starring Compose by Steven Schoen

Core Stack, Modularization & Anvil

• Refactoring our Dependency Injection using Anvil by Drew Heavner

• Reddit Recap: State of Mobile Platforms Edition (2022) by Laurie Darcey & Eric Kuck

• Android Modularization by Catherine Chi

We will follow up with the stream and post it in the comments when it becomes available in the coming weeks. Thanks!

Written by Ryan Lewis, Staff Software Engineer, Developer Platform

Hi Reddit 👋

You may have noticed that at the beginning of the year, we started producing a monthly podcast focusing on how Reddit works internally. It’s called Building Reddit! If you haven’t listened yet, check it out on all the podcasting platforms (Apple, Spotify, etc.) and on YouTube.

Today, I wanted to give you some insight into how the podcast came together. No, this isn’t a podcast about a podcast. That would open a wormhole to another dimension. Instead, I’ll walk you through how Building Reddit came to be and what it looks like to put together an episode.

The Road to Building Reddit

Before I started working here, Reddit had experimented with podcasts a few times. These were all produced for employees and only released internally. There has been a lot of interest in an official podcast from Reddit, especially an Engineering one, for some time.

I knew none of this when I started at the company. But as I learned more about how Reddit worked, the idea for an engineering podcast started to form in my brain. The company already had a fantastic engineering blog with many talented employees talking about how they built stuff, so an audio version seemed like a great companion.

So, last fall, for our biannual engineering free-for-all Snoosweek, I put together a proof of concept for an engineering podcast. Thankfully, I work on a very cool project, Developer Platform, so I just interviewed members of my team. What I hadn’t anticipated was having 13 hours of raw audio that needed to be edited down to an hour-long episode… within two days. In the end, it came together and I shared it with the company.

Enter the Reddit Engineering Branding Team (the kind souls who make this blog run and who organize Snoosweek). Lisa, Chief of Staff to the CTO, contacted me and we started putting together ideas for a regular podcast. The goal: Show the world how Reddit builds things. In addition to Lisa and the Engineering Branding Team, we joined forces with Nick, a Senior Communications Associate, who helped us perfect the messaging and tone for the podcast.

In December, we decided on three episodes to launch with: r/fixthevideoplayer, Working@Reddit: Engineering Manager, and Reddit Recap. We drew up outlines for each episode and identified the employees to interview.

While the audio was being put together for those episodes, Nick connected us to OrangeRed, the amazing branding team at Reddit. They worked with us to create the cover image, visual assets, and fancy motion graphics for the podcast visualization videos. OrangeRed even helped pick out the perfect background music!

Producing three episodes at once was a tall order, but all three debuted on Feb. 7th. Since then, we’ve kept up a monthly cadence for the podcast. The first Tuesday of every month is our target to release new episodes.

A Day In The Life of an Episode

So how does an episode of the podcast actually come together? I break it down into five steps: Ideation, Planning, Recording, Editing, Review.

Ideation is where someone has an idea for an episode. This could be based on a new feature, focusing on a person or role for a Working@Reddit episode, or a technical/cultural topic. Some of these ideas I come up with myself, but more often they come from others on the Reddit Engineering Branding team. As ideas come up, we add them to a list, usually at the end unless there’s some time element to it (for example the Security Incident episode that comes out tomorrow!). As of right now, we have over 30 episode ideas on the list! For ideas higher on the list, we assign a date for when the episode would be published. This helps us make sure we’re balancing the types of episodes too.

When an episode is getting close to publication, usually a month or two in advance, I create an outline document to help me plan the episode. Jameson, a Principal Engineer, developed the template for the outline for the first episode. The things I put in there are who I could talk to, what their job functions are (I try to get a mix of engineering, product, design, comms, marketing, etc), and a high-level description of the episode. From there, I’ll do some research on the topic from external comms or internal documents, and then build a rough outline of the kinds of topics I want to talk about. These will be broken down further into questions for each person I’ll be interviewing. I also try to tell some type of story with each episode, so it makes sense as you listen to it. That’s usually why I interview product managers first on feature episodes (eg. Reddit Recap, Collectible Avatars). They’re usually good about giving some background to the feature and explaining the reasoning behind why Reddit wanted to build it.

I reach out to the interviewees over Slack to make sure they want to be interviewed and to provide some prep information. Then I schedule an hour-long meeting for each person to do the interview over Zoom. Recording over Zoom works quite well because you can configure it to record each person’s audio separately. This is essential to being able to mix the audio. Also, it’s very important that each person wears headphones, so their microphone doesn’t pick up the audio from my voice (or try to noise cancel it which reduces the audio quality). The recording sessions are usually pretty straightforward. I run through the questions I’ve prepared and occasionally ask follow-ups or clarifying questions if I’m curious about something. Usually, I can get everything I need from each person in one session, but occasionally I’ll go back and ask more questions.

Once all the audio is recorded, it’s time to shut my office door and do some editing. First I go through each person’s interview and clean it up, removing any comments or noises around their audio. As I do this, I’ll work on the script for my parts between the interviewee’s audio. Sometimes these are just the questions that I asked the person, but often I’ll try to add something to it so it flows better. Once I’ve finished cleaning up and sequencing the interviewee audio, I work on my script a little more and then record all of my parts.

As you can see in the photo of my office above, I hang large sound blankets to remove as much reverb as I can. If I don’t put these up, it would sound like I was in an empty room with lots of echo. When I record my parts, I always stand up. This gives my voice a little more energy and somehow just sounds better than sitting. Once my audio is complete, I edit those parts in with the other audio, add the intro/outro music, and do some final level adjustments for each part. It’s important to make sure that everyone’s voices are at about the same level.

Although I listen to each mixed episode closely, getting feedback and review from others is essential. I try to get the first mix completed a week or two before the publication date to allow for people to review it and for me to incorporate any feedback. I always send it to the interviewees beforehand, so they can hear it before the rest of the world does.

Putting it All Together

So, we have a finished episode. Now what? The next thing I do is to take the audio and render a video file from it. OrangeRed made a wonderful template that I can just plug the audio into (and change the title text). Then the viewer is treated to some meme-y visuals while they listen to the podcast.

I upload the video file to our YouTube channel, and also to our Spotify for Podcasters portal (formerly Anchor.fm). Spotify for Podcasters handles the podcast distribution, so uploading it to that will also publish it out to all the various podcast platforms (this had to be set up manually in the beginning, but is automatic after that). Some platforms support video podcasts, which is why I use the video file. Spotify extracts the audio and distributes that to platforms that don’t support video.

The last step after uploading and scheduling the episode is to write up and schedule a quick post for this community (example). And then I can sit back and… get ready for next month’s episode! It’s always nice to see an episode out the door, and everyone at Reddit is incredibly supportive of the podcast!

So what do you think? Does it sound cool to build Building Reddit? If so, check out the open positions on our careers page.

And be on the lookout for our new episode tomorrow. Thanks for listening (reading)!

Written by Chase Sturgill

Hey y’all! This week we are taking a break from our typical technical content to showcase some of the fun things that happen behind the scenes at Reddit. One of my favorite things about working at Reddit is that there is no shortage of fun things happening, both for our in-office and virtual Snoos. With Halloween right around the corner, this is no exception! We would like to showcase the amazing decorations our teams have put up in our offices around the world. Be sure to let us know in the comments which office you think has the best decorations! 

While some may argue this is too early for Halloween decorations, I challenge that it isn’t early enough. And long may they reign until “All I For Christmas is You” tops the charts once again.

Decorations are only a small part of the fun though! On October 31st, all of our offices will be hosting pizza parties, with the pizza of choice being chosen via polling of local Snoos. Our NYC Snoos couldn’t make up their minds, so both Emmy Squared and John’s of Bleecker will be served. Really wishing I was based in NYC right about now 🙂

And of course it wouldn’t be a Halloween celebration without a costume contest! Every Snoo is encouraged to submit pictures of their Halloween costumes and company-wide awards will be given for the following categories: 

• Most Reddit-y

• Best Team Costume

• Best in Show (for the pets)

• Spookiest

• ThereWasAnAttempt (a costume that shows you tried…)

Additionally, every office will crown their own office winner for the Snoo who wears the best costume to the office on Halloween.

It’s an exciting time for our Snoos and we hope you’ve enjoyed this glimpse into some of the fun things that happen within Reddit - wishing you all a happy spooky szn!

Hey there r/redditeng!

We’d like to take a break from our regular programming to invite you to Reddit’s virtual hackathon. Join us to build a game or experience on the Developer Platform from now through March 27th! 

Sign up for the hackathon here!

The challenge

Build a new game, social experiment, or experience on Devvit (Reddit’s Developer Platform) using our Interactive Posts feature. We’re looking for massively multiplayer games and experiences. Standout apps create genuine conversation and speak to the creativity of redditors. 

Get Started

Getting started with Devvit is super easy. We have a number of resources available on our docs site to get you up and running.

How do I build an app for the hackathon?

1. Get started with the quickstart

2. Once you have devvit set up, dive deeper into interactive posts

3. Join us over on r/Devvit and on Discord for live support and office hours

Get Inspired

Check out our new r/gamesonreddit community to see games that other developers have built with the platform, as well as the project gallery from our first virtual hackathon, the Reddit Games and Puzzles Hackathon. See some of the games built by past Hackathon winners below:

Word Game Winners

1. Emoji Charades by Hayden Woods

2. Popped Corn by Bitan Nath and Swati

3. Word Trail Game by Mihajlo Nestorović

Puzzle Game Winners

1. Pixel Together by Fan Fang, Mai Hou, and Allison C

2. N_0V1 by Abdulla Sogay, Mujtaba Naik, and Ajaay P

3. Laddergram by Jenny Ho

Tabletop Game Winners

1. Daily Dungeon by Justin L

2. Fingerholers by Drew Anderson

3. Suspicious Skyscrapers by Srivats Shankar

User-Generated Content Award

• 575 by Thomas Park

We hope you join us and can’t wait to see what you build!

Hello Reddit!

I’m happy to announce the seventh episode of the Building Reddit podcast. In this episode I spoke with Chad, Reddit’s Security Operations Center (SOC) Manager, about the security incident we had in February 2023. I was really curious about how events unfolded on that day, the investigation that followed, and how Reddit improved security since then. Hope you enjoy it! Let us know in the comments.

You can listen on all major podcast platforms: Apple Podcasts, Spotify, Google Podcasts, and more!

Watch on Youtube

Information Security is one of the most important things to most software companies. Their product is literally the ones and zeroes that create digital dreams. Ensuring that the code and data associated with that software is protected is of the utmost importance.

In February of this year Reddit dealt with a security incident where attackers gained access to some of our systems. In this episode, I wanted to understand how the incident unfolded, how we recovered, and how Reddit is even more secure today.

Check out all the open positions at Reddit on our careers site: https://www.redditinc.com/careers

Written by Saikrishna Bhagavatula, Jason Hurt, Walter Michelin

Introduction

Reddit serves billions of images per day. Images are used for a variety of purposes: users upload images for their posts, comments, profiles, or community styles. Since images are consumed on a myriad of devices and product surfaces, they need to be available in several resolutions and image formats for usability and performance. Reddit also transforms these images for different use cases: post previews and thumbnails are resized, cropped, or blurred, external shares are watermarked, etc.

To fulfill these needs, Reddit has been using a just-in-time image optimizer relying on third-party vendors since 2015. While this approach served us well over the years, with an increasing user base and traffic, it made sense to move this functionality in-house due to cost and control over the end-to-end user experience. Our task was to change almost everything about how billions of images are served daily without the user ever noticing and without breaking any of the upstream company functions like safety workflows, user deletions, SEO, etc. This came with a slew of challenges.

As a result of moving image optimization in-house, we were able to:

• Reduce our costs for animated GIFs to a mere 0.9% of the original cost

• Reduce p99 cache-miss latency for encoding animated GIFs from 20s to 4s

• Reduce bytes served for static images by ~20%

Cost

We partnered with finance to understand the contract’s cost structure. Then, we broke that cost down into % of traffic served per feature and associated cost contribution as shown in Fig 1. It turned out that a single image optimization feature, GIFs converted to MP4s, contributed to only 2% of requests but 70% of the total cost! This was because every frame of a GIF was treated as a unique image for cost purposes. In other words, a single GIF with 1,000 frames is equal to the image processing cost of 1,000 images. The high cost for GIFs is exacerbated by cache hits being charged at the same rate as the initial image transformation for cache misses. This was a no-brainer to move in-house immediately and later focus on migrating the remaining 98% of traffic. Working closely with Finance allowed us to plan ahead, prioritize the company’s long-term goals, and plan for more accurate contract negotiations based on our business needs.

Engineering

Some CDNs provide image optimization for modifying images based on query parameters and caching them within the CDN. And indeed, our original vendor-based solution existed within our CDN. For the in-house solution we built, requests are instead forwarded to backend services upon a CDN cache miss. The URLs have this form:

preview.redd.it/{image-id}.jpg?width=100&format=png&s=...

In this example, the request parameters tell the API: “Resize the image to 100 pixels wide, then send it back as a PNG”. The last parameter is a signature that ensures only valid transformations generated by Reddit are served.

We built two backend services for transforming the images: the Gif2Vid service handles the transcoding of GIFs to a video, and the image optimizer service handles everything else. There were unique challenges in building both services.

Gif2Vid Service

Gif2vid is a just-in-time media transcoding service that resizes and transcodes GIFs to MP4s on-the-fly. Many Reddit users love GIFs, but unfortunately, GIFs are a poor file format choice for the delivery of animated assets. GIFs have much larger file sizes and take more computational resources to display than their MP4 counterparts. For example, the average user-provided GIF size on Reddit is 8MB; shrunk down to MP4, it’s only 650KB. We also have some extreme cases of 100MB GIFs which get converted down to ~10MB MP4s.

Results

Other than major cost savings, one of the main issues addressed was that the vendor’s solution had an extremely high latency when a cache miss occurs—a p99 of 20s. On a cache miss, larger GIFs were consistently taking over 30s to encode or were timing out on the clients, which was a terrible experience for some users. We were able to get the p99 latency down to 4s. The cache hit latencies were unaffected because the file sizes, although slightly larger, were comparable to earlier. We also modernized our encoding profile to use b-frames and tuned some other encoding parameters. However, there’s still a lot more work to be done in this area as part of our larger video encoding strategy. For example, although the p99 for cache miss is better, it’s still high and we are exploring a few options to address that such as tuning bitrates, improving TTFB with fmp4s using a streaming miss through the CDN, or giving large GIFs the same treatment as regular video encoding.

Image Optimizer Service

Reddit’s image optimizer service is a just-in-time image transformation service based on libvips. This service handles a majority of the cache-miss traffic as it serves all other image transforms like blurring, cropping, resizing, overlaying another image, and converting from/to various image formats.

We chose to use govips which is a cgo wrapper around the libvips image manipulation library. The majority of new development for services in our backend is written using baseplate.go. But Go is not an ideal choice for media processing as it cannot keep up with the performance of native code. The most widely used image-processing libraries like libmagick are primarily written in C or C++. Speed was a major factor in selecting libvips in order to keep latency low on CDN cache misses for images. In our tests, libvips was 3–4 times faster than libmagick on basic image processing operations. Content-aware smart cropping was implemented by porting smartcrop.js to Go. This is the only operation implemented in pure Go.

Results

While the cache miss latency did increase a little bit, there was a ~20% reduction in bytes served/day (see Figure 4. Total Bytes Delivered Per Day). Likewise, the peak p90 latency for images in India decreased by 20% while no negative impact was seen for latencies in the US. The reduction in bytes served is due to reduced file sizes as seen in Figure 4. Num of Objects Served By Payload Size show bytes served for one of our image domains. Note the drop in larger file sizes and increase in smaller filesizes. The resultant filesizes can be seen in Figure 5. The median size of source images is ~200KB and their output is reduced to ~40KB.

The in-house implementation also handles errors more gracefully, preventing large files from being returned due to errors. For example, the vendor’s solution would return the source image when image optimization fails, but it can be quite large.

Engineering Challenges

Backend services are normally IO-bound. Expensive tasks are normally performed asynchronously, outside of the user-request path. By creating a suite of just-in-time image optimization systems, we are introducing a computationally and memory-intensive workload, in the synchronous request path. These systems have a unique mix of IO, CPU, and memory needs. Response latency and response size are both critically important. Many of our users access Reddit from mobile devices, or on weak Internet connections. We want to serve the smallest payload possible without sacrificing quality or introducing significant latency.

The following are a few key areas where we encountered the most interesting challenges, and we will dive into each of them.

Testing: We first had to establish baselines and build tooling to compare our solution against the vendor solution. However, replacing the optimizers at such a scale is not so straightforward. For one, we had to make sure that core metrics were unaffected: file sizes, request latencies on a cache hit, etc. But, we also had to ensure that perceptual quality didn’t degrade. It was important to build out a test matrix and also to roll out the new service at a measured pace where we could validate and be sure that there wasn’t any degradation.

Scaling: Both of our new services are CPU-bound. In order to scale the services, there were challenges in identifying the best instance types and pod sizes to efficiently handle our varied inputs. For example, GIF file sizes range from a few bytes to 100MB and can be up to 1080p in resolution. The number of frames varies from tens to thousands at different frame rates. GIF duration can range from under a second to a few minutes. For the GIF encoding, we benchmarked several instance types with a sampled traffic simulation to identify some of these parameters. For both use cases, we put the system under heavy load multiple times to find the right CPU and memory parameters to use when scaling the service up and down.

Caching & Purging: CDN caches are pivotal for delivery performance, but content also disappears sometimes due to a variety of reasons. For example, Reddit’s P0 Safety Detection tools purge harmful content from the CDN—this is mandatory functionality. To ensure good CDN performance, we updated our cache key to be based on a Vary header that captures our transform variants. Purging should then be as simple as purging the base URL, and all associated variants get purged, too. However, using CDN shield caches and deploying a solution side-by-side with the vendor’s CDN solution proved challenging. We discovered that our CDN had unexpected secondary caches. We had to find ways to do double purges to ensure we purged data correctly for both solutions.

Rollouts: Rollouts were performed with live CDN edge dictionaries, as well as our own experiment framework. With our own experiment framework, we would conditionally append a flag indicating that we wanted the experimental behavior. In our VCL code, we check the experimental query param and then check the edge dictionary. Our existing VCL is quite complex and breaks quite easily. As part of this effort, we added a new automated testing harness around the CDN to help prevent regressions. Although we didn’t have to rollback changes, we also worked on ensuring that any rollbacks won’t have a negative user impact. We created staging pipelines end-to-end where we were able to test and automate new changes and simulate rollbacks along with a bunch of other tests and edge cases to ensure that we can quickly and safely revert back if things go awry.

What’s next?

While we were able to save costs and improve user experience, moving image optimization in-house has opened up many more opportunities for us to enhance the user experience:

• Tuning encoding for GIFs

• Reducing image file sizes

• Making tradeoffs between compression efficiency and latency

We’re excited to continue investing in this area with more optimizations in the future.

If you like the challenges of building distributed systems and are interested in building the Reddit Content Platform at scale, check out our job openings.

Hello Reddit!

It’s National Intern Day! We put together a very special two-episode series to highlight the amazing work our Emerging Talent team and our Interns and New Grads are doing. In the first episode in the series (episode 09), I talk to Deitrick Franklin, the manager of the Emerging Talent team. You’ll get to hear all the details about the different Emerging Talent programs at Reddit, how they developed, and a little about Deitrick himself. In the second episode (episode 10), Deitrick interviews some of the Interns and New Grads that are working at Reddit right now! They talk through how they joined the program, what they’ve been doing since they started, and their favorite office snacks and nap spots. Hope you enjoy them! Let us know in the comments.

Find out about all the Reddit Intern and New Grad opportunities at Ripplematch: https://app.ripplematch.com/company/reddit/

You can listen on all major podcast platforms: Apple Podcasts, Spotify, Google Podcasts, and more!

Watch on Youtube

This is part 1 of a 2-part series on Emerging Talent at Reddit.

Employees are the lifeblood of any company. And it’s important that the pipeline of new people joining is kept fresh and vibrant as the company matures. At Reddit, Emerging Talent is one of the main teams that ensures we recruit the best of the best from Universities.

In this episode, you’ll hear from Deitrick Franklin, the manager of the Emerging Talent team, about how the program was developed, what interns and new grads can expect, and about his personal journey from engineering to recruiting.

Watch on Youtube

This is part 2 of a 2-part series on Emerging Talent at Reddit. Listen to the other episode here.

Employees are the lifeblood of any company. And it’s important that the pipeline of new people joining is kept fresh and vibrant as the company matures. At Reddit, Emerging Talent is one of the main teams that ensures we recruit the best of the best from Universities.

In this episode, you’ll hear directly from interns and new grads currently at Reddit. They’ll share how they joined the program, what they’re working on, and the best snacks at the Reddit Offices.

Check out all the open positions at Reddit on our careers site: https://www.redditinc.com/careers

Written by Dylan Glenn.

Here at Reddit, the Enterprise Applications team shepherds much of the financial and operational infrastructure for our business, from invoicing customers, to procuring software, to paying vendors. In contrast to Reddit’s fast-paced, innovative engineering culture where AI has already been used to improve the core product and create new experiences, the enterprise apps ecosystem is famously slow to adopt new technologies, favoring stability, predictability, and compliance instead.

This post explores how we navigate this tension through a pragmatic approach to AI adoption. Over the past year, we’ve learned that AI can increase our delivery velocity; code generation tools have made our engineers more productive and platform copilots have widened the scope of what our product managers can build. Now, the pieces are in place for the next pivotal shift: the integration of agentic AI capabilities, which will allow us to deploy autonomous systems that can reason, plan, and execute complex workflows.

AI Principles for Accounting and Financial Data

As a public company, implementing agentic AI systems for Accounting and Finance stakeholders can present some unique challenges:

• Accuracy is paramount: Many of our systems and processes directly drive financial reporting, and inaccurate results have real impact.

• Sensitive data must be protected: Financial, customer, and employee data must adhere to strict security and privacy controls.

• Processes must be auditable: We must maintain strict internal controls over financial data. Every system we build must produce a clear, immutable, and verifiable audit trail for every single transaction.

• Costs must be justified: As a cost center, the hype surrounding AI is not sufficient justification for a project. Every initiative must be backed by a clear business case demonstrating a tangible ROI, whether through increased efficiency, reduced error rates, or improved compliance posture.

With these requirements in mind, we outlined a framework for how our team will begin adopting AI. This framework resulted in us establishing a number of “red-lines” that we will not cross during initial adoption. Specifically, we will not use AI:

• To completely remove humans from SOX in-scope processes. Humans will remain in the loop for final action/review.

• To enable processes that do not comply with existing GRC operations without the appropriate controls in place.

• If available tools do not meet data privacy requirements.

• If business requirements can be met more quickly, cheaply, or effectively through other means.

This principle-based approach allows us to innovate safely. By understanding the current limitations of AI and designing our solutions around them, we can harness its power without exposing the business to unacceptable risk.

Case Study: Designing a Cash Matching Process

To illustrate our principles, let’s walk through our design for a homegrown Accounts Receivable (AR) cash application solution. The task is a matching puzzle: when a customer sends a single payment for multiple invoices, our accounting team must correctly apply the funds based on remittance information from bank statements, PDFs, or emails.

While the thought of building an end-to-end agentic AI system was tempting, we realized the core requirement was a subset sum problem, which is a task better suited to a deterministic algorithm than an LLM. So instead, we decided to meet this requirement with a custom Python service and to use our iPaaS tool, Workato, for orchestration, while still targeting specific parts of the process for AI augmentation.

The resulting hybrid architecture is broken down as follows:

This design delivers the best of both worlds. We leverage the infrastructure and controls we’ve established in Workato, the core transformation and matching logic satisfies our strictest requirements for accuracy and auditability, and AI tools handle the messy, unstructured parts of the problem, reducing manual effort and improving efficiency.

From Copilot to Agent: The Evolving AI Toolkit

AI has also become a force multiplier for our own team. For engineers, AI-first editors like Cursor accelerate development in our structured NetSuite codebase, and it has never been easier to automate away manual development tasks with a quick bash or Deno script. 

An even larger shift, however, has been empowering our product managers. AI is lowering the barrier to entry for building technical solutions, allowing our PMs, who possess deep business context, to own more of the end-to-end delivery process. Tools like Workato’s Copilots and our custom MCP server for building React apps in NetSuite allow them to more easily build and iterate on business applications.

The Next Frontier: Agentic AI

This evolution from assistant to copilot is paving the way for agentic AI systems. Agents are capable of understanding a high-level goal, creating a plan, and executing it by interacting with various tools across systems. This is no longer a far-off concept; we are seeing these capabilities emerge across our existing enterprise platforms now, from Workato’s Agent and MCP Platform to Tines’ AI Agent actions and NetSuite’s MCP Connector. We are actively experimenting across this evolving toolkit, ensuring we are ready to adapt to one of the fastest-moving technological waves in history.

Lessons Learned and the Road Ahead

Our journey has taught us that AI will not be a panacea to eliminate all manual tasks, but rather another set of tools to incrementally improve the efficiency of our business through the thoughtful integration of AI features into our existing enterprise application infrastructure.

The AR Cash Application project is just the beginning. We are now exploring the development of internal agents to strengthen our operational posture through integration test automation and exception monitoring. These agents will orchestrate complex workflows and augment error alerts with contextual data, helping us improve our own engineering standards. This pragmatic, principles-driven approach allows us to harness the power of AI to build things better, enabling Reddit to do its best work.

Author(s): Simon Kim, Ryan Lakritz, Anish Balaji

Context

In this blog post, we explore how the Ads Retrieval team is introducing an exploration mechanism into the Global Auction Trimmer (Retrieval Ranking) to address model bias and more effectively serve new and existing ad-user pairs. Our ultimate goal is to improve long-term marketplace performance by ensuring every manually created ad (e.g., flight, campaign) has enough opportunities to showcase its potential and gather sufficient data for accurate optimization.

Key Goals of Exploration

1. Mitigate Model Bias

   • Prevent early dismissal of ads due to incomplete or biased model signals.

   • Encourage sufficient exposure for new and underexplored ads.

2. Improve Ad Content Exposure

   • Dynamically explore ads when our predictive confidence is low (e.g., brand-new ads).

   • Ensure every manually created ad entity receives enough impressions to learn from.

3. Regularly Refresh Learnings

   • Continuously optimize the Global Ads Trimmer with updated feedback on ads’ actual performance.

   • Avoid “unlucky” scenarios by allowing lower-ranked ads occasional chances to show.

Global Ad Trimmer in Marketplace

Reddit’s ad marketplace aims to balance user experience, advertiser objectives, and infrastructure efficiency. Historically, the Global Ads Trimmer reduced the candidate pool from millions of potential ads to a more manageable subset. Candidates were then further ranked downstream to identify the top K ads for each user impression.

Past Workflow (Before Exploration Integration)

1. Cosine Similarity

   • The Global Ads Trimmer uses a two-tower model to encode user and ad features. A cosine similarity measure indicates user-ad relevance.

2. eCPM Calculation

   • The system multiplies the cosine similarity by the flight’s bid to estimate eCPM (effective cost per mille).

3. ALO for Final Selection

   • After trimming, ALO (Ad level Optimization) applies an exploration strategy downstream and ultimately picks the final candidate ad(s).

While ALO’s exploration strategy has value, it also introduces complexities:

• Auction Density & Infrastructure Cost

  • Volume of flights surviving the Trimmer can become large, increasing serving and computational costs.

• Model Performance Leakage

  • The final decision made by ALO can override or diminish the Global Trimmer’s prioritization, leading to suboptimal synergy between the two ranking stages.

Model Challenge

With the original setup, certain shortcomings emerged:

• Insufficient Exploration of Rare Ads: Ads that don’t receive initial engagement might be overshadowed by popular or well-established ads.

• Complex Multi-Stage Ranking: Handing off exploration tasks to ALO can inflate candidate pools and complicate cost controls in the auction.

• Exploration Policy not synced with Global Ads Trimmer: ALO’s exploration policy is completely separate from Global Ads Trimmer’s decisions. Its uncertainty measures don’t account for the same feature sets, granularity, and training window.

Our Solution: Integrating Exploration Directly in the Global Ads Trimmer

To address these challenges, the Ads Retrieval team is introducing an exploration strategy directly into the Global Ads Trimmer and deprecating ALO. This new approach maintains a leaner, more direct pipeline while ensuring we systematically explore ads with uncertain performance.

New Workflow Overview

1. Direct eCPM-Based Ranking

   • The Global Ads Trimmer calculates a utility score using eCPM (cosine similarity × bid) for the top K ads.

2. Bid Modifier

   • A specialized adjustment is applied for conversion/install-oriented flights, ensuring they remain competitive in the selection process.

3. Neural Linear Bandit Layer

   • A Neural Linear Bandit (NLB) is added on top of the two-tower model to incorporate exploration directly at the trimming stage.

By integrating the exploration logic here, we avoid re-expanding the candidate pool downstream and keep infrastructure costs more predictable.

How the Neural Linear Bandit Works in the Two-Tower Model

The two-tower model encodes users and ads into embeddings, typically combined via cosine similarity. However, it lacks a mechanism for uncertainty estimation, critical for deciding when to explore new or underexplored ads. This is where the Neural Linear Bandit layer (NLB) comes in:

1. Engagement Prediction

   • The NLB layer predicts clicks, conversions, or other engagement metrics while also estimating uncertainty in these predictions.

2. Covariance Matrix & Uncertainty

   • A key aspect of bandit approaches is tracking how “confident” the model is in its predictions. The covariance matrix captures how well each region of the embedding space is represented by observed data.

3. Score Perturbation (Exploration Bonus)

   • To encourage exploration, the NLB samples noise proportional to uncertainty and adds it to the cosine similarity. Ads in less-explored “directions” receive a bonus, increasing their final eCPM score.

4. Adaptive Exploration-Exploitation

   • As new data is collected, uncertainty estimates shrink, enabling the model to exploit ads it now knows to perform well while still occasionally exploring unproven ads.

Experiment 

In an online experiment, we observed that the new workflow with the NLB model outperformed the past workflow. We observed significant CTR and Conversion rate performance improvements and other ad key metrics in addition to the infrastructure and cost benefits of consolidating our systems. The results are shown in the table below.

Ad Impression Distribution Analysis 

We also checked the distribution of ad impressions between ads in the same flight (ad group) to measure whether the exploration model is effectively "rotating" ads within a given flight as expected.

Compute Impression Share per Ad:

• Calculate the percentage of impressions each ad receives within its flight (Impression share).

  • Impression Share=Impressions for Ad/Total Impressions in the flight

Measure Dispersion:

1. No Systematic Bias

The distribution of Impression_Share being centered around zero indicates that the test group does not systematically favor or disfavor specific ads compared to the control group. This confirms that the Neural Linear Bandit maintains fairness in overall impression allocation across flights, ensuring no unintended bias.

2. Entropy Observations

Most flights show similar entropy levels of impression share between the test and control groups, indicating a consistent overall balance in how impressions are distributed across ads. However, a subset of flights in the test group demonstrates lower entropy, reflecting a more focused impression allocation. This behavior suggests that the Neural Linear Bandit prioritizes exploitation in high-confidence scenarios while maintaining exploration in other cases to discover new opportunities.

(Entropy measures the unevenness or uniformity of impression distribution. Higher entropy indicates more evenly distributed impressions across ads, while lower entropy reflects a more concentrated allocation.)

Insights:

The Neural Linear Bandit demonstrates a robust ability to balance exploration and exploitation:

1. It maintains fairness in impression allocation across flights, avoiding systematic bias.

2. Marketplace performance metrics in the test group outperform the control group, showcasing the model’s effectiveness in optimizing ad ranking while ensuring diverse ad rotation.

These results confirm that the Neural Linear Bandit enhances ad performance by effectively balancing exploration and exploitation, providing a scalable and adaptive solution for the ads ranking system.

Conclusion and What’s Next

The Neural Linear Bandit addition to the Global Ads Trimmer significantly improves the balance between exploration and exploitation:

• Fairness & Reduced Bias: Ads receive more equitable opportunities to prove their performance potential.

• Adaptive & Scalable: The system efficiently explores uncertain spaces without ballooning infrastructure costs.

• Enhanced Marketplace Metrics: Early tests show encouraging gains in engagement and conversion rates, indicating the exploration bonus helps uncover promising ads that might have otherwise been missed. Importantly it also allows Global Ads Trimmer improvements to have a higher scale of impact by eliminating the two-tier system.

Over the coming months, we plan to refine the bandit parameters, analyze longer-term effects on advertiser ROI, and iterate on advanced exploration mechanisms that can enhance the performance of the downstream heavy ranker model. We look forward to sharing additional findings and best practices as we continue evolving the Global Ads Trimmer (Retrieval Ranking) to create a more vibrant, high-performing ads marketplace on Reddit.

Acknowledgments and Team: The authors would like to thank teammates from Ads Retrieval team as well as our cross-functional partners including Andrea Vattani, Nastaran Ghadar, Sahil Taneja, Marat Sharifullin, Matthew Dornfeld, Xun Tang, Andrei Guzun Josh Cherry & Looja Tuladhar 

Last but not least, we greatly appreciate the strong support from the leadership Virgilio Pigliucci, Hristo Stefanov & Roelof van Zwol

Written by Jen Davis

Hey there! My name is Jen Davis, and I lead recruiting for the Core Experience / Moderation (CXM) organization. I started on contract at Reddit in August of 2021 and became a full-time Snoobie in June of 2022. For those that don’t know, Snoo is the mascot of Reddit, and Snoobies are what we call new team members at Reddit.

What does a week in Talent Acquisition look like?

I work remotely from my home in Texas, and this is my little colorful nook. I like to say this is where the magic happens. How do I spend my time? I work to identify the best and brightest executive and engineering talent, located primarily in the U.S., Canada, U.K., and Amsterdam. From there it’s lots of conversations. I focus on giving information, and I do a lot of listening too. Once a person is matched up, my job is helping them have a great experience as they go through our interview process. This includes taking the mystery out of what they’ll experience and mapping out a timeline. I enjoy sourcing candidates myself, but we are fortunate to have a phenomenal Sourcing function whose core role entails the identification of talent through a variety of sources, engaging candidates, and having a conversation to further assess. Want to hear the top questions I’m asked from candidates? Read on!

What types of roles is Reddit looking for in Core Experience / Moderation (CXM), and are those remote or in-office?

Primarily for CXM we’re looking for very senior iOS, Android, backend, backend video, and frontend engineers. We’re also seeking engineering leaders to include a Director of Core Experience and a Senior Engineering Manager. Again, all remote, but ideally located in the United States, Canada, UK, or Amsterdam.

To expand further, all of our roles are remote in engineering across the organization. We do have a handful of offices, and people are welcome to frequent them at any cadence, but it’s not a requirement, nor does anyone have to relocate at any time. To find all of our engineering openings check out https://www.redditinc.com/careers, then click Engineering.

What do I like most about working at Reddit?

There are many reasons, but I’ll boil it down to my top four:

I believe in our product, mission, and values. Our mission is to bring community, belonging, and empowerment to everyone in the world. This makes me proud to work at Reddit. Our core values are: Make Something that People Love, Default Open, Evolve, and Add Value. For a deeper dive into our values check out Come for the Quirky, Stay for the Values. I also love the product. I’m personally a part of 65 communities out of our 100,000+, and they bring value to my life. I continually hear from others that Reddit brings value to their lives too. It’s cool that there’s something for everyone.

Some of my favorite subs:

I found inspiration here for my work desk setup. r/battlestations

I love animals, and it’s fun to get lost here watching videos. r/AnimalsBeingDerps

The audacity! r/farpeoplehate

Great communities. r/AutismInWomen and r/AutisticWithADHD

Never a dull moment. r/AskReddit and r/Unexpected.

Yes, I spent some time on r/place. r/BlueCorner will be back!

The people. The people are really a delight at Reddit. I say all the time that I’m an introvert in an extroverted job. I’m a nerd at heart, and I enjoy partnering with our engineering team as well as our Talent Acquisition team and cross-functional partners. You’ll find, regardless of which department you work in, people will tell you that they enjoy working at Reddit. We have a diverse workforce. We care about the work that we do, and our goal is to deliver excellent work, but we also laugh a lot in our day-to-day. We care about each other too. We remember the human, and we check in with one another.

Remote work. The majority of our team members work remotely. We do have offices in San Francisco, Chicago, New York, Los Angeles, Toronto, London, Berlin, Dublin, Sydney, and more sites coming soon! Being remote, I’m thankful that I don’t have to drive every day, fight with traffic, pay tolls, and overall I get to spend more time with my family. I also have two furry co-workers that have no concept of personal space, but I wouldn’t have it any other way. Baku’s on the left, Harley’s on the right. I also get to have lunch with my fiancé who also works from home. It’s pretty great.

Compensation and benefits. It makes me happy that in the U.S. we have moved to pay transparency, meaning we disclose our compensation ranges within our posted jobs, and in time we’ll continue on this path for other geographies. In the U.S., pay transparency means that compensation is listed in our job descriptions. I believe in pay equity. To quote ADP, “Pay equity is the concept of compensating employees who have similar job functions with comparably equal pay, regardless of their gender, race, ethnicity or other status.” Reddit compensates well for the skills that you bring to the table, and there are a lot of great extra perks. We have a few programs that increase your total compensation and well-being:

• Comprehensive health benefits

• Flex vacation and global days off

• Paid parental leave

• Personal and professional development funds

• Paid volunteer time off

• Workspace and home office benefits

How would you describe the culture at Reddit?

Candidates ask our engineers if they like working at Reddit, and time and time again I hear them say it’s clear that they do. It’s definitely my favorite environment and culture.

• There’s a lot of autonomy, and also a lot of collaboration. Being remote doesn’t hinder collaboration either. Our ask from @spez is that if any written communication gets beyond a sentence or two, stop, jump on a huddle, video meeting, or in short, actually talk to each other. We do just that, and amazing things happen.

• We are an organization that’s scaling, and that means there’s a lot of great work to do. If it’s a process or program that doesn’t exist, put your thoughts together and share with others. You may very well take something from zero to one. Or, if it’s a process that’s existing, and you have an idea on how to make it better, connect with the creator and collaborate with others to take it to the next iteration.

• We like to experiment and a/b test. If it fails, that’s OK. We learn and Evolve. I learned from our head of Core Experience that within the engineering environment when something goes wrong, they don’t cast blame. They come together to figure out how to fix said thing, and then work to understand how it can be prevented in the future.

• Recall I said we laugh a lot too. We do. We work to use our time wisely, automate where it makes sense, and focus on delivering the best regardless of which organization we work within. It is also a very human, diverse, and compassionate environment.

• We value work/life balance. I asked an Engineering Manager, so tell me, how many hours a week on average do engineers put in at Reddit? Their answer is a mantra that I now live by. “You can totally work 40 hours and call it for the week. Just be bad ass.”

I’m separating this last one out because it means a lot to me.

We are an inclusive culture.

We are diverse in many ways, and we embrace that about one another.

We share a common goal.

Reddit’s Mission First

It bears repeating: Our mission is to bring community, belonging, and empowerment to everyone in the world. As we move towards this goal with different initiatives from different parts of the org, it’s important to remember that we’re in this together with one shared goal above others.

I can summarize why I love Reddit in five words. I feel like I belong.

Shoutout to our phenomenal Employee Resource Groups (ERGs). Our ERGs are one of the many ways we work internally towards building community, belonging, and empowerment. I’m personally a member of our Ability ERG, and they truly have created a safe space for all people.

All in all, Reddit is a wonderful place to work. Definitely worth an upvote.

Hi r/redditeng community! We normally bring you fresh content weekly, but sometimes things don't go as planned. So, for this week, we've gone into our waybackmachine and are featuring one of our favorite podcast episodes about our favorite CTO, Chris Slowe. Enjoy and see you next week.

Working@Reddit: Chris Slowe (2024)

As you might’ve seen on our LinkedIn, our Experience team is whipping up a brand new quarterly series for our employees (Snoos). 🧑‍🍳 r/ (aka r-slash) brings community magic to various cities around the world through a one-day immersive experience and a full week of team on-sites and local engagements.

We kicked off the very first r/ event in London this month with The Great Reddit Bake Off. This pop-up featured a baking competition that would make Paul Hollywood proud and Reddit's own culinary communities, r/Breadit and r/DessertPorn. 🎂

This was only the beginning of an exciting year! The Experience Team is planning events around the world to bring in as many Snoos as they can to participate this year. The line-up includes celebrating music and streetwear in LA, bringing the yeehaw to our Texas Snoos with a rodeo, and ending the year with a surprise pop-up for all of our remote team members. 

Our world-class experience team is focused on ensuring all of our Snoos feel the same community and belonging at Reddit that we aspire for our users. If fun company-wide events like this sound exciting to you in addition to building cool shit, we currently have over 40 engineering positions open - head over to our careers page to discover how you can become part of the team!

By Alex Caulfield, Software Engineer III

I’ve been a frontend engineer at Reddit for almost 6 months, and I work on our Anti-Evil team, which works on keeping Reddit safe for all of our users. Currently, I work fully remote from Boston. My team is split across 4 different time zones in 3 countries, so among other skills I’ve picked up over the past six months, I’ve gotten very good at subtracting three and adding five to my current time. Soon, I’ll be visiting the SF and NYC offices, but for now, I get to enjoy my work-from-home setup each day.

Since many company and department meetings don’t start until people on the west coast log on, I usually have most of my mornings free to get through emails, slacks, code reviews, and do some focus work. We have our standup around lunchtime on the east coast so that everyone can join during their normal work hours. We generally take that time to talk about any blockers we have and what we’ll be focusing on for the next day.

After standup, if I’m stuck on something, I often jump on a call to do some pair programming with a teammate. At first, it can be a bit intimidating to share your screen while you code, but having someone there to confirm your approach and help answer questions you have has been incredibly helpful in getting onboarded to the team’s services.

When I get to a good stopping point, I usually like to take a break and get outside around lunchtime. If I had a productive day the day before, I’ll be able to reach into my fridge and throw something tasty in the microwave for lunch. More likely, I will cobble together something from my fridge and hope that it cooks in time for my 1 pm meeting.

If the weather is not so nice, I might take a “working lunch” and open up the beta version of our iOS app for “testing”. I like reading r/fantasyfootball during the NFL season to help prevent me from coming in last place in my league, or r/boston to get any relevant local news.

Back at my desk, I will get some heads-down work done if there aren’t any more meetings. My team works on managing real-time safety systems at Reddit, and as a frontend engineer, I mostly work on building UIs for tools that support these systems. Recently, I’ve gotten to learn more about esbuild to bundle our new TypeScript, React, and Koa.js application and am often able to take the time to integrate interesting technologies into our stack (I’m hoping to add React Query to our app soon).

I enjoy being able to reach out to our users and make sure the tools we’re building for our data scientists are successful in helping them and their algorithms track down spam, harassment, and hate speech on our platform. Even as a frontend engineer, I’m encouraged to learn about our backend real-time stream processing systems and get my hands dirty to impact how malicious content is detected and removed from our site as quickly as possible.

We also have multiple meetings where engineers share what they’ve been working on. I’m a member of the frontend guild, where engineers give presentations on different frontend tech they’ve integrated into their work (like Tailwind CSS, web components, and Playwright end-to-end testing). It’s great to have a space to hear about what other teams within the company are working on, and it helps me learn about new technologies that I can add to my team’s applications and services.

Either before work or after I’ve logged off, I try to get some exercise in. Sometimes I like to go for a bike ride along the Charles River. Back when I had to go into an office, I really enjoyed my bike commute since I got to spend some quality time with Boston drivers quiet time outside.

As a newer employee, I’ve had the opportunity to build new projects from scratch and have a lot of autonomy in the work I do. The work the Anti-Evil team does makes a positive impact for all of our users and is a motivator to build great things every day. If this type of work interests you, check out our careers page.

Written By Corey Roberts, Senior Software Engineer, UI Platform (iOS)

The Reddit Product Language, also known as RPL, is a design system created to help all the teams at Reddit build high-quality and visually consistent user interfaces across iOS, Android, and the web. This blog post will delve into the structure of our design system from the iOS perspective: particularly, how we shape the architecture for our components, as well as explain the resources and tools we use to ensure our design system can be used effectively and efficiently for engineers.

A colleague on my team wrote the Android edition of this, so I figured: why not explore how the iOS team builds out our design system?

Motivation: What is a Design System?

You can find several definitions of what a design system is on the internet, and at Reddit, we’ve described it as the following:

A design system is a shared language between designers and developers. It's openly available and built in collaboration with multiple product teams across multiple product disciplines, encompassing the complete set of design standards, components, guidelines, documentation, and principles our teams will use to achieve a best-in-class user experience across the Reddit ecosystem. The best design systems serve as a living embodiment of the core user experience of the organization.

A design system, when built properly, unlocks some amazing benefits long-term. Specifically for RPL:

• Teams build features faster. Rather than worry about how much time it may take to build a slightly different variant of a button, a team can leverage an already-built, standardized button that can be themed with a specific appearance. A design system takes out the worry of needing to reinvent the wheel.

• Accessibility is built into our components. When we started building out RPL over a year ago, one of our core pillars we established was ensuring our components were built with accessibility in-mind. This meant providing convenience APIs to make it easy to apply accessibility properties, as well as providing smart defaults to apply common labels and traits.

• Visual consistency across screens increases. When teams use a design system that has an opinion on what a component should look like, this subsequently promotes visual consistency across the app experience. This extends down the foundational level when thinking about what finite set of colors, fonts, and icons that can be used.

• Updates to components happen in one place. If we decided to change the appearance of a component in the future, teams who use it won’t have to worry about making any changes at all. We can simply adjust the component’s values at one callsite, and teams get this benefit for free!

Building the Foundation of RPL on iOS

Primitives and Tokens

The core interface elements that make up the physical aspect of a component are broken down into layers we call primitives and tokens. Primitives are the finite set of colors and font styles that can be used in our design system. They’re considered the legal, “raw” values that are allowed to be used in the Reddit ecosystem. An example of a primitive is a color hex value that has an associated name, like periwinkle500 = #6A5CFF. However, primitives are generally too low-level of a language for consumers to utilize effectively, as they don’t provide any useful meaning apart from being an alias. Think of primitives as writing in assembly: you could do it, but it might be hard to understand without additional context.

Since a design system spans across multiple platforms, it is imperative that we have a canonical way of describing colors and fonts, regardless of what the underlying value may be. Tokens solve this problem by providing both an abstraction on top of primitives and semantic meaning. Instead of thinking about what value of blue we want to use for a downvote button (i.e. “Do we use periwinkle500 or periwinkle300?”) we can remove the question entirely and use a `downvoteColors/plain` token. These tokens take care of returning an appropriate primitive without the consumer needing to know a specific hex value. This is the key benefit that tokens provide! They afford the ability of returning correct primitive based on its environment, and consumers don’t need to worry about environmental scenarios like what the current active theme is, or what current font scaling is being used. There’s trust in knowing that the variations provided within the environment will be handled by the mapping between the token and its associated primitives.

We can illustrate how useful this is. When we design components, we want to ensure that we’re meeting the Web Content Accessibility Guidelines (WCAG) in order to achieve best-in-class accessibility standards. WCAG has a recommended minimum color contrast ratio of 4.5:1. In the example below, we want to test how strong the contrast ratio is for a button in a selected state. Let’s see what happens if we stick to a static set of primitives.

In light mode, the button’s color contrast ratio here is 14.04, which is excellent! However, when rendering the same selected state in dark mode, our color contrast ratio is 1.5, which doesn’t meet the guidelines.

To alleviate this, we’d configure the button to use a token and allow the token to make that determination for us, as such:

Using tokens, we see that the contrast is now much more noticeable in dark mode! From the consumer perspective, no work had to be done: it just knew which primitive value to use. Here, the color contrast ratio in dark mode improved to 5.77.

Font tokens follow a similar pattern, although are much simpler in nature. We take primitives and abstract them into semantic tokens so engineers don’t need to build a UIFont directly. While we don’t have themes that use different font sets, this architecture enables us to adjust those font primitives easily without needing to update over a thousand callsites that set a font on a component. Tokens are an incredibly powerful construct, especially when we consider how disruptive changes this could be if we asked every team to update their callsites (or updated on their behalf)!

Icons

RPL also includes a full suite of icons that our teams can use in an effort to promote visual consistency across the app. We recently worked on a project during Snoosweek that automatically pulls in all of the icons from the RPL catalog into our repository and creates an auto-generated class to reference these icons.

The way we handle image assets is by utilizing an extension of our own Assetsclass. Assetsis a class we created that fetches and organizes image assets in a way that can be unit tested, specifically to test the availability of an asset at runtime. This is helpful for us to ensure that any asset we declare has been correctly added to an asset catalog. Using an icon is as simple as finding the name in Figma designs and finding the appropriate property in our `Assets` class:

Putting it All Together: The Anatomy of a Component

We’ve discussed how primitives, tokens, and icons help designers and engineers build consistency into their features. How can we build a component using this foundation?

In the iOS RPL framework, every component conforms to a ThemeableComponentinterface, which is a component that has the capability to be themed. The only requirement to this interface is a view model that conforms to ThemableViewModel. As you may have guessed, this is a view model that has the capability to include information on theming a component. A ThemeableViewModel only has one required property: a theme of type RPLTheme.

The structure of a component on iOS can be created using three distinct properties that are common across all of our components: a theme, configuration, and an appearance.

A theme is an interface that provides a set of tokens, like color and font tokens, needed to visually portray a component. These tokens are already mapped to appropriate primitives based on the current environment, which include characteristics like the current font scaling or active theme.

An appearance describes how the component will be themed. These properties encompass the colors and font tokens that are used to render the surface of a component. Properties like background colors for different control states and fonts for every permissible size are included in an appearance. For most of our components, this isn’t customizable. This is intentional: since our design system is highly opinionated on what we believe a component should look like, we only allow a finite set of preset appearances that can be used.

Using our Button component as an example, two ways we could describe it could be as a primary or secondary button. Each of these descriptions map to an appearance preset. These presets are useful so consumers who use a button don’t need to think about the permutations of colors, fonts, and states that can manifest. We define these preset appearances as cases that can be statically called when setting up the component’s view model. Like how we described above, we leverage key paths to ensure that the colors and fonts are legal values from RPLTheme.

Finally, we have a configuration property that describes the content that will be displayed in the component. A configuration can include properties like text, images, size, and leading/trailing accessory views: all things that can manipulate content. A configuration can also include visual properties that are agnostic of theming, such as a boolean prop for displaying a pagination indicator on an image carousel.

The theme, appearance, and configuration are stored in a view model. When a consumer updates the view model, we observe for any changes that have been made between the old view model and the new one. For instance, if the theme changes, we ensure that anything that utilizes the appearance is updated. We check on a per-property basis instead of updating blindly in an effort to mitigate unnecessary cycles and layout passes. If nothing changed between view models, it would be a waste otherwise to send a signal to iOS to relayout a component.

A wonderful result about this API is that it translates seamlessly with our SliceKit framework. For those unfamiliar with SliceKit, it’s our declarative, unidirectional presentation framework. Each “slice” that makes up a view controller is a reusable UIView and is driven by view models (i.e. MVVM-C). A view model in SliceKit shares the same types for appearances and configuration, so we can ensure API consistency across presentation frameworks.

Keeping Up with the Reddit Product Language

Since Reddit has several teams (25+) working on several projects in parallel, it’s impossible for our team to always know who’s building what and how they’re building it. Since we can’t always be physically present in everyones’ meetings, we need ways to ensure all teams at Reddit can build using our design system autonomously. We utilize several tools to ensure our components are well-tested, well-documented, and have a successful path for adoption that we can monitor.

Documentation

Because documentation is important to the success of using our design system effectively (and is simply important in general), we’ve included documentation in several areas of interest for engineers and designers:

• Code documentation: This is the easiest place to understand how a component works for engineers. We outline what each component is, caveats to consider when using it, and provide ample documentation.

• RPL documentation website: We have an in-house website where anyone at Reddit can look up all of our component documentation, a component version tracker, and onboarding steps for incoming engineers.

• An iOS gallery app: We built an app that showcases all of the components that are currently built in RPL on iOS using SliceKit. Each component includes a “playground,” which allows engineers to toggle different appearance and configuration properties to see how the component changes.

Testing

Testing is an integral part of our framework. As we build out components, we leverage unit and snapshot tests to ensure our components look and feel great in any kind of situation. The underlying framework we use is the SnapshotTesting framework. Our components can leverage different themes on top of various appearances, and they can be configured even further with configuration properties. As such, it’s important that we test these various permutations to ensure that our components look great no matter what environment or settings are applied.

Measuring RPL Adoption

We use Sourcegraph, which is a tool that searches through code in repositories. We leverage this tool in order to understand the adoption curve of our components across all of Reddit. We have a dashboard for each of the platforms to compare the inclusion of RPL components over legacy components. These insights are helpful for us to make informed decisions on how we continue to drive RPL adoption. We love seeing the green line go up and the red line go down!

Challenges we’ve Faced

All the Layout Engines!

Historically, Reddit has used both UIKit and Texture as layout engines to build out the Reddit app. At the time of its adoption, Texture was used as a way to build screens and have the UI update asynchronously, which mitigated frame rate hitches and optimized scroll performance. However, Texture represented a significantly different paradigm for building UI than UIKit, and prior to RPL, we had components built on both layout engines. Reusing components across these frameworks was difficult, and having to juggle two different mental models for these systems made it difficult from a developer’s perspective. As a result, we opted to deprecate and migrate off of Texture.

We still wanted to leverage a layout engine that could be performant and easy-to-use. After doing some performance testing with native UIKit, Autolayout, and a few other third-party options, we ended up bringing FlexLayout into the mix, which is a Swift implementation of Facebook’s Yoga layout engine. All RPL components utilize FlexLayout in order to lay out content fast and efficiently. While we’ve enjoyed using it, we’ve found a few touch points to be mindful of. There are some rough edges we’ve found, such as utilizing stack views with subviews that use FlexLayout, that often come at odds with both UIKit and FlexLayout’s layout engines.

Encouraging the Usage of RPL

One of our biggest challenges isn’t even technical at all! Something we’re continuously facing as RPL grows is more political and logistical: how can we force encourage teams to adopt a design system in their work? Teams are constantly working on new features, and attempting to integrate a brand new system into their workflow is often seen as disruptive. Why bother trying to use yet-another button when your button works fine? What benefits do you get?

The key advantages we promote is that the level of visual polish, API consistency, detail to accessibility, and “free” updates are all taken care of by our team. Once an RPL component has been integrated, we handle all future updates. This provides a ton of freedom for teams to not have to worry about these sets of considerations. Another great advantage we promote is the language that designers and engineers share with a design system. A modally-presented view with a button may be an “alert” to an engineer and a “dialog” to a designer. In RPL, the name shared between Figma and Xcode for this component is a Confirmation Sheet. Being able to speak the same language allows for fewer mental gymnastics across domains within a team.

One problem we’re still trying to address is ensuring we’re not continuously blocking teams, whether it’s due to a lack of a component or an API that’s needed. Sometimes, a team may have an urgent request they need completed for a feature with a tight deadline. We’re a small team (< 20 total, with four of us on iOS), so trying to service each team individually at the same time is logistically impossible. Since RPL has gained more maturity over the past year, we’ve been starting to encourage engineers to build the functionality they need (with our guidance and support), which we’ve found to be helpful so far!

Closing Thoughts: Building Towards the Future

As we continue to mature our design system and our implementation, we’ve highly considered integrating SwiftUI as another way to build out features. We’ve long held off on promoting SwiftUI as a way to build features due to a lack of maturity in some corners of its API, but we’re starting to see a path forward with integrating RPL and SliceKit in SwiftUI. We’re excited to see how we can continue to build RPL so that writing code in UIKit, SliceKit, and SwiftUI feels natural, seamless, and easy. We want everyone to build wonderful experiences in the frameworks they love, and it’s our endless goal to make those experiences feel amazing.

RPL has come a long way since its genesis, and we are incredibly excited to see how much adoption our framework has made throughout this year. We’ve seen huge improvements on visual consistency, accessibility, and developer velocity when using RPL, and we’ve been happy to partner with a few teams to collect feedback as we continue to mature our team’s structure. As the adoption of RPL in UIKit and SliceKit continues to grow, we’re focused on making sure that our components continue to support new and existing features while also ensuring that we deliver delightful, pixel-perfect UX for both our engineers and our users.

If building beautiful and visually cohesive experiences with an evolving design system speaks to you, please check out our careers page for a list of open positions! Thanks for reading!

By Jewel Darger-Sacher (she/they), u/therealadyjewel, Staff CorpTech Full-Stack Engineer

I joined Reddit to work as a Senior Software Engineer. Then I got a promotion to Senior Software Engineer II. Then I switched to Engineering Manager. Then I switched to Senior Software Engineer. Today I’m working as a Staff Software Engineer. But what even changed? Me. A lot – for the better.

This is a career ladder story, but it’s actually a story of how I swung back and forth over the years to figure out my own shit and to figure out how to accomplish my goals within a company. It’s weirdly also a story of how I’ve stayed at the same company for seven years in an industry that expects movement every few years, and I kept moving, but I somehow ended up in the same place – but different.

When I first signed up with Reddit seven years ago, all I knew was Señor Sisig, charge my phone, be bisexual, play board games & hack on the desktop site. I had built up several years of experience as a product engineer focusing on webapps and mobile apps, loads of domain expertise on social media and on Reddit as a consumer and moderator (shout-out to r/Enhancement), and collaborating with both “lean MVP” teams or fully staffed teams partnering cross-functionally like with product managers and QA. So I figured I could just keep doing product engineering at Reddit for a while. And that worked out! I got to help design and build the prototypes for “new reddit” (the desktop website intended to supersede old.reddit.com) leveraging my knowledge of web development, Reddit Enhancement Suite, the Reddit tech stack, and the Reddit community.

I gradually worked my way through supporting various projects and products – the “new Reddit” desktop site, search, NSFW, a long time on Chat, admin tooling for community managers, legal tooling for GDPR compliance, and plenty of architecture advice for teams across the company.

Let’s start pulling my pendulum

After years of wandering around different teams – I got promoted! My first engineering manager in the Safety org was a big advocate for career growth for his team. He collaborated with me to build a promo packet that advanced me up to Senior Engineer II. Alongside that, he provided me with plenty of opportunities and coaching for leadership: managing contractors, supporting interns, leading projects – and reporting up on all of it to him.

But then, he dropped a big announcement to us: our beloved manager was regretfully leaving the company. Although I was sad to see my favorite manager leaving, my focus was on an even bigger question:

Who wants to step up as manager?

Wait.

What.

That … could be me. I could be the manager.

But why?

In the past several years, I found myself drawn more to discussions of sociotechnical systems and resiliency engineering and mentorship – less code, more people, more systems, more coordination, more projects. I wanted to accomplish things bigger than what I could do by myself. I wanted to put together groups and tools that would outlast me and grow beyond me. I wanted to see my friends and peers succeed in their ambitions, get that bag, and build up their own teams and groups. And I wanted to see improvements in Reddit’s offerings for Consumer Safety.

Working as a manager

Holy shit, people management is hard work. And it’s new kinds of work. I didn’t really have it together before, and I needed to have it together.

Bless my leadership, though, for all the support they gave me. We slowly ramped up my workload by bringing a few projects for me to architect, and hiring some contractors to build it – nothing too new to me, but with only me at the helm. Then my managers said “Your team needs to take on more. You, personally, need to take on less. You need more team, and you need to delegate.” And we gradually brought in more full-time employees to oversee the contractors and replace the contractors. Then they started taking on the technical management I didn’t have time to do anymore, since I was responsible for people and process management. I was suddenly directly responsible for coaching people in their career growth AND course-correcting individual behavior that was harming their work or relationships AND tracking the success of multiple projects AND reporting up AND course-correcting projects that were off track AND triaging new bugs AND reviewing upcoming projects AND schedule AND AND AND

Holy moly, it was a lot. I had to learn fast how to keep up and to follow up and to report up. And there’s one other huge thing I learned, but not from my senior manager or my peer product manager, or my manager training sessions.

If I wanted to manage a team, I had to learn to manage my own disability.

I realized I had been failing myself over the years and only made it this far through the support of my parents, my teachers, my partners, and my managers. And now that I was the manager, I had so much more on the line that I didn’t want to fail – not just my own career but my team members’ careers and our team’s mission. And I needed help.

All those “haha relatable memes” about ADHD? They were my guidebook to coping with this disability: building lists, writing reminders, transcribing everything, and scheduling time to organize my notes. I found friends who shared their experiences, a psychiatrist, and medication, and an ADHD-focused life coach. I built systems – and for systems. (Previously, on r/RedditEng: Yo dawg, I heard you like templates.)

And my managers? They helped me find the people to keep the team running. Not just our program managers and our project managers, but also our tech leads, our individual team members, and our technical project partners The continued success of the Consumer Safety team is a testament to the tenacity and follow-through of everyone on that team, and the accountability of our upper management.

We got it together. We built up systems. We built relationships. We kept on following up. And we got the work done. And it was tough work, but good work, and worthy work.

But after a few years? I needed to do some other work.

I’ll manage myself out of managing

A lot came together all at once. I told my manager in December 2021, “I’ve enjoyed working as a manager for several years, but I need something new. Let’s schedule a sabbatical and then move to a new team or a new role.” With that rough plan in mind, I started scheming to fill in the gaps.

I stumbled over an IC role on the Reddit job board that looked like it was written for me: working in IT (Corporate Technology) as a software engineer, building products that improve work-life for my peer managers, ERG leads, and employees all across the company. I scheduled a video chat with the hiring manager and director to pitch them on “a potential referral to this role – oh, the referral is me.”

I asked my team’s tech lead if she wanted to finally switch to management. She was the obvious pick: an astonishingly capable woman with prior experience as both ops manager and engineering manager, a popular lead with the rest of the team and the department, a rising star within Reddit Safety Eng – and she had been angling for a manager role since she first joined. When I asked, she immediately knew her response: “Put me in, coach 🤩”

I brought this plan to my then-manager and my heir-apparent: I would work a few more months. Then I’d take a sabbatical while our tech lead would fill in as “acting manager”. When I came back, we would announce my transition to IC elsewhere in the company and officially instate her as manager. Everybody liked this plan, and my then-manager did her part by evangelizing how capable and competent I was to my new manager, and handling the negotiations and coordinations for both of us to change roles.

In parallel, I was managing some major changes in my personal life. I finally came out to myself as a trans woman after years as a non-binary / genderqueer person. Like many trans women, this led to some major shifts in my relationships to myself, my people, and my priorities. I needed to change my work life to support that, so I could refocus energy on supporting myself – and I needed a lot of time off for therapy and healthcare. (Side note: thanks to Reddit for funding a $25,000 lifetime HRA for gender-affirming healthcare.)

When I got back from my sabbatical, I saw that my plans (thanks to a lot of evangelism from my old and new managers) had finally landed.

In one Slack thread, there was a message from my new manager: “Your transfer has been approved!”

In another Slack thread, my then-manager had closed the loop with me: “Your new ‘acting manager’ is doing great and we’re working on her transition paperwork.”

And in one last thread, a message from my old tech lead: “Are you joining our team’s planning meeting today? Oh, wait. Your title changed in Slack already. I guess not.”

Ope. Well, sometimes work doesn’t go according to plan. But we keep on moving.

Are we manager or are we IC

My first few months as an IC software engineer turned out to be … very managery. Because I had moved to a new team with only one junior engineer and a manager who was already overloaded, it turned out that I’d definitely need to leverage the management skills I’d learned in order to succeed.

I started by onboarding myself: asking a lot of questions about the team’s responsibilities, each team member’s responsibilities, what processes were currently followed, and what resources we had available. The answers were “a lot of responsibilities, barely any process or support.” Time to get to work, then.

I instituted the managerial processes I knew would work – especially the “agile rituals” and knowledge management that my new manager foresaw we would need to support this team now that it was growing. I scheduled meetings every couple of weeks to plan what we’re working on and share who’s unavailable; retros on opposite weeks to review how work has been going; and templates with checklists to support the whole process. We documented what processes the team needed to follow for planning, change management, and requesting reviews. We caught up on product documentation for features the team had already built and set expectations for writing the docs for new features. We organized the team wiki to put all of that information into a logical set of folders and indexes. It was lots of fun collaborating with an experienced manager to determine what practices would fit best in this space!

After a few weeks of learning how to work on this team, I even started writing my own code! Thanks to my experience from years of product development within Reddit, I started shipping bugfixes and new features within just a month – rather than the three to six months we expect of a completely new hire.

I also got to provide loads of mentorship to the other engineers on the team by walking them through frameworks like software development life cycle and project management. The “say, see, do” model took us through my describing how it worked, showing how to do it, then pairing with them doing the work themselves. This covered topics like designing products, architecting software, requesting risk reviews, responding to code reviews, writing user manuals, testing code, deploying code, and fielding customer feedback. We also worked on breaking down products into features and tasks, grouping them into milestones and deliverables, and reporting on project status.

That was a year and a month ago. How’s it been since then?

I got a promotion! When I switched from management back to IC, we chose to level me as a Senior Software Engineer, so I could get my feet back under me as an engineering IC. In the year since that transition, I’ve consistently demonstrated that I’m working on a Staff Engineer level. (That’s not just doing the work – it’s also showing it off in a way my managers can see and understand.) And when performance review season came back around last month, my manager felt confident in putting in a promotion packet for me to level up from Senior to Staff!

That growth? It’s not just me! This team has grown, the team members have grown, and I have definitely grown over the years. We’re all more experienced and more effective. We’re also ready to take it to the next level by coordinating more reviews, writing more thorough documentation, and collaborating on more projects. We have smoothed out a lot of the pains of building, shipping, getting feedback, and iterating on our products.

I personally feel like I’ve gotten more buy-in on projects I wanted to accomplish, because I knew how to speak “manager” – like explaining the business value of my proposals up front, work estimates, executive summaries, peer feedback, performance reviews – or how to gradually build up support from multiple partners. (The CREAM principle looks great next to a big list of how much time I’ve spent on a process that I would like to automate.)

I’ve had opportunities to coach my teammates in that, too! IC Engineers across the company benefit from that knowledge of “how does management work” and “how do I talk to managers”. When the IC engineers get together to ask for advice on how to collaborate with our managers, it’s so gratifying to buddy up with the other staff and principal engineers so we can share our knowledge and support everyone.

I’ve gotten clarity on when it’s more appropriate to work like a leader more than a manager. The craft of software engineering happens sometimes in planning meetings and more in guild meetings and team retros architectural design sessions and product brainstorms. And we don’t need to ask an engineering manager to help us coordinate on code reviews and linters and style guides – except for when we want them to help enforce requirements and encourage collaboration. And these days, I spend much more time partnering with my peer software engineers and my program/product managers – since I’ve practiced more where I specifically need to lean on my manager.

And I’m finding that, even though my calendar has emptied out, I still have to put plenty of effort into collaboration within my team and across teams. My project tracker spreadsheets get used nearly as much as before. My knowledge management templates have been transformed into program wikis. And my calendar has plenty of free time to take care of my own needs or jump into ad-hoc discussions with other team members.

I’ve seen myself grow through my own accomplishments and through the eyes of my manager. Those weekly one-on-ones provide plenty of opportunities for feedback and reflection. Performance review season brings it all together, when we look back at the whole year of how much has changed and what we’ve built up. (And I’ve got the manager tools in hand to document and discuss what I’ve accomplished in that whole year!)

r/HailCorporate – thanks for the support

I’ve had a surprisingly easy time making all these transitions between my various roles and teams, thanks to the concrete impact of several company values “Evolve, Keep Reddit Real, Remember the Human, Reddit’s Mission First.”

Change and growth shows up plenty in the Reddit product and community – sorry not sorry about the constant churn in features, buttons, icons, and platform changes. For me personally, I have been privileged to receive so much support in career growth from my managers, upper management, peers, and the Learning & Development team.

My managers and peers consistently provide generous feedback, coaching, and review – especially when I’ve taken on a new role. When I’ve sought out a promotion, a new team, or a new role, my managers have been great champions for my moves – even when they regret “losing me” from their team.

As for my personal growth, this company has provided an astonishingly kind and supportive environment for me to cultivate myself. Everyone within the company accepts each other where we are and as we change – both on an individual level as peers, and through the systemic support of DBI initiatives and Employee Resource Groups like LGBTQSnoos, Trans@, and Ability (disability and neurodivergence). This hit so hard when I came out as a trans woman and realized how much I could lean on my people at work for support – and draw from our healthcare benefits for surgeries, therapy, and time off.

If you’re thinking about moving from engineering management back to purely IC engineering, that’s an option worth considering. People management isn’t for everyone all the time. Even if you enjoy and excel at the work of people management, sometimes our needs and interests shift – and our work should follow what we need to survive and thrive.

It’s been a hell of a ride swinging from senior software engineer into management and back to senior software engineer (but better). But I’m glad to carry through on that ride. And someday – even after landing a promotion to staff engineer – we’ll probably see Jewel as a manager again.

Read more of my writings or watch my talks on management, tech, ADHD, and queerness, at jewel.andraia.xyz.

We're taking a bit of a break this week but, fret not, we'll be back. Thanks for your support in 2021. See you next year!

Simon Kim (Staff Data Scientist,ML, Ads Data Science), Akshaan Kakar and Ellis Miranda

Context

For the last 2 years, the Reddit advertisement business increased rapidly. The Reddit Ads team successfully launched our own ad-level optimization (dynamic creative optimization) models for various types of Reddit Ads (such as CPC, CPI and CPA ads), and we confirmed its positive impact on users by presenting them with ads that they are more interested in. In this post, we share how we built and launched a system for our Ads level optimization model.

Creative Optimization:

When advertisers launch an ad group, they sometimes use several versions of the same ad such as different texts, images or headlines. We called these versions creatives. By measuring the individual success metric for each creative, the advertiser can determine the best way to advertise their product. However, an ad platform can do some of the work for advertisers. More specifically, a platform can automatically provide an optimization on this process by intelligently testing all ads and confidently selecting the highest performing creative. We have implemented this process with a Bayesian network based multi-armed bandit approach .

Multi-Armed Bandit (MAB)

Think about a gambler with multiple slot machines. In simple terms, exploration is when the gambler tests the machines that aren’t currently paying out the most to see if they’ll pay out more whereas exploitation is when the gambler pulls the machine that’s most profitable so far to maximize gambler’s total return. The goal of multi-armed bandit algorithms is to determine the best choice by optimizing this exploitation and exploration process.

Bayesian Network Model

For this MAB approach, we chose to use a Bayesian network model because it is good for explaining conditional dependencies of upstream and downstream conversion actions, which is similar to our ad conversion process. A Bayesian network model is a probabilistic graphical model that represents a set of variables and their conditional dependencies via a directed acyclic graph (DAG). We use an efficient algorithm to infer and utilize Bayesian networks to estimate a conversion rate of each action.

Architecture

For our model to be maximally effective, we wanted to ensure that it receives new updates from the ads marketplace as quickly as possible. A long delay between events (impressions, clicks. conversions) occurring in the marketplace and our model receiving them would mean sub-optimal predictions for long periods of time. We built streaming pipelines to gather events from the marketplace in real-time. These pipelines are able to gather impression, click and conversion events from our Kafka cluster as soon as they arrive and transform them into a format that is amenable to model prediction.

We set up our streaming pipelines to aggregate event counts in a feature store used by our inference server. Every time our inference server receives a request from the ad serving system, it reads from the feature store to fetch the latest aggregate event counts and feeds them into our model framework.

The model framework is a generalizable system for sampling from simple Bayesian models, designed to allow easy model experimentation and iteration. Depending on the type of ad (click ad, conversion ad etc.) we are selecting, the framework runs inference on the corresponding Bayesian network and samples scores for all ads in the candidate set. The highest ranking ad is then returned to the ad serving system. Our model framework is also equipped with real-time metrics and logging for model quality monitoring and introspection.

Conclusion and next steps

We confirmed that our ads performance substantially improved since we launched this model.

As part of the work on this project we have identified a few areas of opportunity that we plan to pursue in further launches:

• Further performance improvements via advertiser and user features with a contextual Multi-Armed Bandit model

• Further performance improvements by accounting for prior user-ad interactions and repetitive ad exposures

• Performance improvement by using deeper ad group and context related features such as image and text embeddings

If you want to join our journey, please check our open positions !

Written by Alex Gallichotte and Adam Espinola

Hi, we're Adam and Alex from Reddit's GraphQL team! We've got some interesting projects cooking in the GraphQL space, but today we want to share something a little different.

A Practical Guide for Clarity in Technical Writing

As we adjusted to remote work in the last year, written text became the default mode of communication for our team, in chat, email, and shared documents. With this change, we discovered several advantages.

For starters, writing gives you time to think, research, and find the right words to express yourself. There's no pressure of being put on-the-spot in a meeting environment, trying to remember everything you wanted to say. More folks on our team have contributed to discussions who might not otherwise have spoken up.

But written communication offers options that have no analog in face-to-face communication.

• Features like comments in Google Docs and threads in Slack allow us to have multiple conversations at once - a guaranteed train-wreck in a face-to-face meeting.

• Many conversations can be held asynchronously, allowing us to batch up communication and protect our focus time from distraction.

• Written communication provides a searchable record which can be collated, copied and reused.

And finally, something magical happens when we write - nagging thoughts get captured and locked down. Arguments become collaborative editing rounds. Half-baked ideas get shored up. Priorities are identified and reckoned with.

An Infallible Seven-Step Process For Effective Writing

Writing is hard! Communication is hard! It's one thing to jot down notes, but writing that prioritizes our reader's understanding takes patience and practice.

As our team creates documentation, design docs, and presentations, we need a reliable way to make our writing clear, brief, and easy to digest for a wide audience.

Draft a brain dump

Get your ideas out of your head and onto paper. Don't worry about phrasing yet. For now, we only need the raw material of your ideas, in sentence form.

Break it up

Put each sentence on its own line. Break up complex ideas into smaller ones. Could you ditch that "and" or comma for two smaller sentences?

Edit each sentence

Go through each sentence, and rewrite it in a vacuum. Our goal is to express the idea clearly, in as few words as possible. Imagine your audience, and remove slang and jargon. Be ruthless. If you can drop a word without losing clarity, do it!

Read each sentence out loud -

Often sentences read fine on paper, but are revealed as clunky when you say them out loud. Actually say them out loud! Edit until they flow.

Reorder for clarity

Now it's easy to reorder your sentences so they make logical sense. You may identify gaps - feel free to add more sentences or further break them up.

Glue it back together

At this point, your sentences should group up nicely into paragraphs. You might want to join some sentences with a conjunction, like "but" or "however".

Read it all out loud

Actually do it! Go slowly, start to finish. You'll be amazed at what issues might still be revealed.

A Real-World Example

Would it be funny if we used the introduction to this blog post as our example? We think so!

1. Draft a brain dump

This step started with a conversation - the two of us discussing this process, and different ideas we came up with as we reflected on remote work. There was a bullet list. But eventually, we had to take the plunge and actually write it out. Here's what we came up with:

This is a good start, but we can do better.

2. Break it up

This step is usually pretty quick. One line per sentence. Keep an eye out for "and", "but", "however", commas, hyphens, semicolons. Split them up.

3. Edit each sentence

This part takes a long time. Our goal here is to make every sentence a single, complete, standalone thought. Mostly, this process is about removing words and seeing if it still works. We also choose our tense, opting for an active voice, and apply it consistently.

Interestingly, this step removes a lot of our individual "voice" from the writing. That's ok! This is technical writing - reader understanding takes higher priority.

4. Read each sentence out loud

Little refinements at this stage. If there are two different options in phrasing, this step helps us choose one. Mostly cuts here, as we try dropping words and find we don't miss them

5. Reorder for clarity

As software engineers, we've had lots of practice moving text around in an editor. Untangling dependencies is a universal skill, but sometimes it's just about what feels better to read.

6. Glue it back together

Often, we start with one big paragraph, and end up with lots of smaller paragraphs. Many sentences seem to just work best standalone.

7. Read it all out loud

Little tweaks here. This step is especially useful for presentations, as we fine-tune sentences for what's most comfortable to read aloud. We also added a new final sentence here to tie it all together.

Before and After

Our goal is to produce writing that can be consumed in a glance. We avoid dense paragraphs, wordy run-on sentences, overlapping ideas and meandering logic. Regardless of the starting point, this process has left everything we've written better off.

Thank you for reading!

This wasn't the most technical post, but it does capture some of the challenges of our unique position here on the GraphQL team. We're the interface between many different teams, both client-side and server-side, so clear communication is a must for us, and we get lots of practice.
Stay tuned for more from our team. There are big changes afoot in GraphQL, and we can't wait to share them!

Written by Dominic Valenciana (u/kiricon)

For a while, everyone had been asking: What can a coding agent do?

Then agents became capable enough that a more practical question started to matter: What am I supposed to do while I wait for one to finish?

The answer seemed obvious: start another agent chat.

Parallel development has long been normal across teams, but parallel development for individuals was still far from the default. Most of the tools available at Reddit assumed one engineer, one repository, and one agent session at a time.

Getting antsy, I frankensteined together OpenCode, Cursor CLI agents, Git worktrees, Markdown instructions, and Bash scripts. The result was a basic terminal interface where I could run as many agents as I could keep track of, each operating with a high degree of autonomy.

Parallel agentic development at scale felt incredible. It also made every problem with agentic development at Reddit scale with it. Mo agents, mo problems.

Workspace collisions, slow CI feedback, scattered context between sources, interrupted sessions, inconsistent behavior during complex operations, and mismatched tool configuration all multiplied with the number of active agents. Four agents could produce four streams of work, but they could also produce four streams of friction.

My first attempt at solving this was to write more instructions: `AGENTS.md` files, skills, and increasingly detailed checklists. Those tools remain valuable for ambiguous work, but common deterministic operations should not require an agent to relearn them on every run. Loading the model with more instructions cost money, slowed it down, and still produced nondeterministic results.

It was time to go a layer deeper.

Prompts can suggest a process. A system can enforce one.

Isolation, continuity, validation, and safety needed to become guarantees rather than reminders. Common context and system access needed to be part of the environment, not another skill to configure or another enormous tool surface for the model to navigate.

Snoocode is Reddit’s solution to those problems. It is a batteries-included desktop application for working with multiple coding agents. It is not another model, another harness, or a replacement for the agent tools Reddit engineers already use. It is a unifying layer that runs those tools inside one Reddit-aware development application: multiple models, multiple harnesses, and our internal integrations under one roof that we control.

Here is the simplest way I have found to explain the layers. The model is the pilot, and the harness gives it a body. Together they form a coding agent. Snoocode is the six-story mech that the agent climbs into, equipped with the Reddit-specific tools, controls, and the environment it needs to work.

Snoocode Lets Us Own Our Destiny

As I built Snoocode, proprietary and open-source tools began shipping many of the same primitives we had discovered we needed. That convergence validated the problems while showing how quickly generic agent tooling could become a commodity.

With voluntary internal contributions, Snoocode repeatedly reached feature parity with much larger proprietary and open-source projects. That did not prove that we had built the one perfect agent product. It proved that the generic layer was buildable, the good ideas would converge, and the moat around agent-development tooling didn’t exist.

At Reddit’s scale, the traditional “buy versus build” calculation looks different. We could continue buying the models and harnesses that the wider industry builds well while cheaply owning the layer that determines how they operate inside Reddit.

This theory was tested when much of Reddit engineering had settled into a single agentic coding product. When the commercial relationship changed, access changed with it, and engineers had to reconstruct their workflows elsewhere on short notice.

Other capable agents existed. The disruption came from how much setup and habit had become coupled to one vendor. For Snoocode users, the underlying agent changed; the surrounding workflow mostly did not.

Vendor agnosticism  for coding agents is a core philosophy for this project. A software company should be able to replace a model or harness without replacing its development workflow. If we own the machine, changing the pilot should not require rebuilding the cockpit overnight.

For Reddit, there is another reason to own that layer: no third party can build it for us.

Our design, project management, development, testing, and delivery workflows include internal systems with no public equivalent. Even where we use common external products, only we can encode how they connect to our internal tools and what their signals mean here. A vendor cannot design tools or plugins for systems it has never seen.

Development at Reddit is its own terrain. No matter how capable the pilot or its body becomes, it still needs a machine designed for the environment in which it will work.

The principle is simple: buy the commodity, build the seam, and keep the freedom to change what sits on either side.

A Side Project Became Shared Infrastructure

When I shared the prototype, it went “viral” internally, at least by internal developer-tool standards. People downloaded it, modified it, and began using it for their own work. A personal setup became a shared experiment developed in public inside Reddit.

Within the first few months, it had been used across 94 repositories, and 26 engineers had contributed to Snoocode itself. Engineers used it against real Reddit workflows, found weak points, and helped improve the shared platform.

The community supplied the pressure that turned a productive hack into a product. It also gave us a development loop no external vendor can reproduce. The engineers using Snoocode can add the feature they need, fix the bug blocking them, and adapt the product as the industry changes. Maintainers provide coherence and remain responsible for what merges.

That direct loop lets a narrowly focused internal product move quickly toward Reddit’s needs. We do not have to persuade a vendor that our problem belongs on its roadmap or wait for a generalized solution designed for thousands of other customers.

Snoocode is now officially staffed, and we are expanding the project to increase developer velocity across Reddit. The goal is not to force engineers away from useful agent tools; those tools are components of Snoocode. The goal is to make the Reddit-native experience so comprehensive and fluid that managing a fragmented toolchain feels unnecessary by comparison.

How Snoocode Works

Snoocode acts as a control plane around any number of supported harnesses—in effect, a “harness for harnesses.”. It bootstraps and configures them, normalizes the concepts that benefit from being shared, and preserves their native capabilities where abstraction would get in the way.

Open-source projects such as [T3 Code] (https://github.com/pingdotgg/t3code) which was built in parallel with Snoocode has been a major inspiration and validation that our ideas are on the right track. They demonstrate how much value a focused interface can add around several coding agents. Snoocode takes that pattern further for Reddit by owning the automatic bootstrapping, internal integrations, and workflow on both sides of the harness.

From Setup to Shipping

Without Snoocode, starting a task can mean creating a worktree, signing into a harness, choosing a model, configuring internal development tools, and loading repository-specific skills. Each step adds context and another failure point, while the resulting session remains tied to one harness.

Snoocode turns that assembly into shared infrastructure. Engineers choose a task, repository, harness, and model; Snoocode supplies the isolated workspace, internal tools, and repository knowledge through one consistent experience.

Because we own the application—not just the agent’s prompt—we can also build experiences third-party harnesses cannot: mentioning coworkers from the company directory, visually attaching application elements, or surfacing local development resources directly beside the chat.

The result is more than a better-equipped agent. It is a cohesive development environment that gives every harness the same Reddit-specific capabilities while adding features no harness could provide on its own.

The common layer is where much of the leverage comes from. Internal integrations, identity, permissions, and deterministic workflows can be built once and reused across every supported backend. Improvements benefit every harness at once instead of being rebuilt in personal scripts or repeatedly interpreted from prompts. Several durable sessions can progress without sharing a checkout or losing their history, while the engineer moves between them and steps in when judgment is required.

This lowers the barrier to useful agentic development while reducing duplicated setup, model context, cost, and variance. It also lets Reddit adopt better models and harnesses without reconstructing the development environment around each one.

Because the contract belongs to us, the same core can eventually power whichever surface fits the work: IDE chats, terminal interfaces, desktop, web, mobile, cloud agents, or local containerized sandboxes. We do not have to wait for every vendor to understand our systems before we can bring its agent into them.

In the mech analogy, this is the payoff: Reddit owns the cockpit, instruments, attachments, and hangar. We can improve the machine for everyone at once, deploy it wherever engineers need it, and swap the pilot when a better one arrives.

Snoocode’s job is not to pick the winning agent. It is to ensure that whichever agent we use arrives ready to work at Reddit.

Key Takeaways

• Models are largely stateless and increasingly interchangeable. The durable value lives in the workflow, context, and environment around them.

• Generic agent tooling is converging quickly. Its moat is limited, and agents themselves make bespoke tooling cheaper to build.

• Software companies should not tie one of their most important development workflows to a single vendor.

• No third party understands a company’s systems and engineering practices well enough to build its ideal development environment for it.

• Context hydration, prompts, and skills remain useful, but they can only take an agent so far. Deterministic workflows belong in the system.

• As models improve, the limiting factor will increasingly be the environment in which they work.

Written by Jeremy Thompson.

From a product perspective, Brand Lift studies aim to measure the impact of advertising campaigns on a brand's overall perception. They help businesses to evaluate the effectiveness of their advertising campaigns by tracking changes in consumer attitudes and behavior toward the brand after exposure to the campaign. It is particularly useful when the objective of the campaign is awareness and reach, rather than a more measurable objective such as conversions or catalog sales. Brand lift is typically quantified by multiple metrics, such as brand awareness, brand perception, and intent to purchase.

Now that you have a high-level understanding of what Brand Lift studies are, let’s talk about the how. To execute a Brand Lift study for an advertising campaign, two unique groups of users must be generated within the campaign’s target audience. The first group includes users who

have been exposed to the campaign (“treatment” users). The second group includes users who were eligible to see the campaign but were intentionally prevented from being exposed (“control” users). Once these two groups have been identified, they are both invited to answer one or more questions related to the brand (i.e. survey). After receiving the responses, crunching a lot of numbers, and performing some serious statistical analysis, the effective brand lift of the campaign can be calculated.

As you might imagine, making this all work at Reddit’s scale requires some serious engineering efforts. In the next few sections, we’ll outline some of the most interesting components of the system.

Control and Treatment Audiences

The Treatment Audience is a group of users who have seen the ad campaign. The Control Audience is a group of users who were eligible to see the ad campaign but did not. To seed these two groups, we leverage Reddit’s Experimentation platform to randomly assign users in the ad campaign’s target audience to a bucket. More info on the Experimentation platform can be found here. Let’s suppose a ratio of 85% treatment users and ~15% control users is selected.

Treatment Users

Once assigned, Treatment users do not require any special handling. They are eligible for the ad campaign and depending on user activity and other factors, they may or may not see the ad organically. Treatment users who engage with the ad campaign form the Treatment Audience for the study. Control users are a little bit different, as you will read in the following section.

Control Users

Control users require special handling because by definition they need to be eligible for the ad campaign but intentionally withheld. To achieve this, after the ad auction has run but right before content and ads are sent to the user, the Ad Server checks to see if any of the “winning” ad campaigns are in an active Brand Lift study. If the campaign is part of a study, and the current user is a Control user in that study, the Ad Server will remove and replace that ad with another. A (counterfactual) record of that event is logged, which is essentially a record of the user being eligible for the ad campaign but intentionally withheld. After the counterfactual is logged, the user becomes part of the Control Audience.

Audience Storage

The Treatment and Control audiences need to be stored for future low-latency, high-reliability retrieval. Retrieval happens when we are delivering the survey, and informs the system which users to send surveys to. How is this achieved at Reddit’s scale? Users interact with ads, which generate events that are sent to our downstream systems for processing. At the output, these interactions are stored in DynamoDB as engagement records for easy access. Records are indexed on user ID and ad campaign ID to allow for efficient retrieval. The use of stream processing (Apache Flink) ensures this whole process happens within minutes, and keeps audiences up to date in real-time. The following high-level diagram summarizes the process:

Survey Targeting and Delivery

Using the audiences built above, the Brand Lift system will start delivering surveys to eligible users. The survey itself is set up as an ad campaign, so it can be injected into the user’s feed along with post content, the same way we deliver ads. Let’s call this ad the Survey ad*.* During the auction for the Survey Ad, engagement data for each user is loaded from the Audience Storage in DynamoDB. The system is allotted ~15ms to load engagement data from the data store, which is a very challenging constraint given the volume of engagement data in DynamoDB. Last I checked, it’s just over 5TB. To speed up retrieval, we leverage a highly-available cache in front of the database, DynamoDB Accelerator (DAX). With the cache, we do lose data consistency, but it’s a reasonable tradeoff to ensure we can retrieve engagement data at a high success rate.
Now that we’ve loaded the engagement data, for users in the Treatment or Control Audience with eligible engagement with the ad campaign, they are served a Survey ad. The user may or may not respond to the survey (industry standard response rate is ~1-2%), and if they do we collect the response. Once we’ve collected enough data over the course of the ad campaign, the data is ready to be analyzed for the effective lift in metrics between the Treatment and Control Audiences.

Next Steps

After the responses are collected, they are fed into the Analysis pipeline. For now I’ll just say that the numbers are crunched, and the lift metrics are calculated. But keep an eye out for a follow-up post that dives deeper into that process!

If this work sounds interesting and you’d like to work on the systems that power Reddit Ads, you can take a look at our open roles.