What it's like to be a new software engineer at Stripe

Being a software engineer at a new company—anywhere—is hard. The codebase is completely new, you have to adapt to new patterns (for both code and culture) and most likely the problem space is completely new to you too.

When I joined Stripe, I knew it would be challenging: this was my first role in a rapidly growing technology company, a new programming language, first time working with payments and first time working full-time in English. Still, I had no idea how overwhelming and exciting it would be. And yet, even though it was one of the biggest challenge I’ve had to face in my career the onboarding experience was an amazing and interesting process. I decided to share an overview on how it feels to be a new engineer here at Stripe having gone through the whole process.

First weeks: living abroad

I flew from Dublin to San Francisco on a Sunday morning, the day before my first day in the company. The first real challenge was dealing with the timezone: 8 hours of difference. The next day, with a mix of anxiety and jet lag, I woke up at 4 in the morning. There was no way I could sleep.

I arrived to the office and a huge table had a sign: “New Hires Table”. I had breakfast and met most people from my start class. Much like university, everyone that started on the same day forms a class. The first week you jump into an intense pace of classes. You learn about what Stripe is: the good things and things we need to get better at, how to talk to customers and how the world of payments operates. Welcome to Stripe 101!

Because of the intense pace and complicated subject matter, it is very reassuring to have a start class to lean on. They help you understand things you are struggling with and you can share how you’re feeling. Since everyone that’s starting in the company is there, you get to meet people from all over the company and world! I met people from Japan, Singapore, Ireland and the US who were joining the sales team, operations, financial crimes, legal and, of course, engineering team.

During this first week, we worked across teams in our start class every day and always tried to have lunch and breakfast with different people. Even though we were in a big class—almost 50 people—I was able to spend at least a little time and get to know everyone in our class. By the end of the week I was able to understand all about Stripe’s products, how a charge is made, how our customers see us and where the company’s future direction.

On our second week we still had some classes left in Stripe 101 but we also began classes for Engineering 101. In these specialized classes, we learned about Stripe’s overall architecture, design patterns, programming languages and much more. We were able to better visualize how projects are executed, the types of problems we may face and how people work on a day-to-day basis.

After the first day!

Recognizing the difficulty

While I’m writing this, I can’t seem to quite explain how overwhelming it can be during these first two weeks. One of the things that I loved the most was that the first thing said to us in our first class was a kind reminder about impostor syndrome. If you are not familiar with the concept, impostor syndrome is the unfounded feeling that someday someone will realize that you are a fraud—and that you will somehow be revealed as one. Usually those with impostor syndrome feel that they don’t really deserve their successes, and that all they’ve achieve is primarily the result of luck.

This small 5-minute talk was focusing on telling us we did belong at Stripe, that we were there for a reason and all beginnings are hard. I did not feel like an impostor when I heard those words, but it was very reassuring to hear them. However, later in the week, these words made all the difference to me. At some times, I was sure I wouldn’t survive the first two weeks and I would be fired. I was sure that my hiring was a mistake and that they would realize that eventually. I repeated those words over and over to make sure I wouldn’t freak out.

/dev/start project

After you have finished your onboarding classes, you are grouped with other newly-hired engineers to develop a project. This project is a small and well-scoped project, designed to be completed in two weeks. Each team gets a mentor to help navigate building products at Stripe. The idea is pretty awesome: when nobody knows anything about the system, no one is afraid to ask basic questions. So you have a group of people to lean on and learn together. The focus is not only to finish the project, but to create new interactions, learn the basics of operational processes (including deployment) and build confidence.

My /dev/start team had people that would later join very different teams, people that you may never work with again at Stripe. We developed a tool to explore and pre-visualize files in S3 buckets on an internal online tool (without needing to SSH into a production machine). My project used Scala, which I have never worked before. I was terrified that I would be useless because I had never worked with a JVM language like Scala before. That’s when I started to doubt myself and what I was doing there. I talked to the people on my team and told them about my struggles. I told that Stripe might have made a mistake hiring me. Guess what? They all felt something similar: we were all insecure. We ended up helping each other: pairing on code and talking when insecurities resurfaced. I can’t say how amazing and important this experience was for me. After just a couple of days, we were committing code, deploying things and feeling comfortable with the main tools. We made a great team and we were able to deploy our tool before the end of our project’s second week.

My team having dinner together

Feeling comfortable

Before you start at Stripe, an engineer from your future team is designed to be your spin-up buddy. Your buddy is there to talk about your experience starting at Stripe and to help you with all kinds of things, from asking where the bathroom is to how processes and cultural norms work in the company.

Because I would be based in Dublin, my spin-up buddy was in Dublin while I was onboarding in San Francisco. Timezones and distance don’t make communication easy, so you also get a local spin-up buddy in SF for the first weeks. During my time in SF, I met with my local buddy three times a week to talk about my project, the company, or anything else on my mind.”

When I got to Dublin I met my long-term team and my spin-up buddy. One of the tasks of a spin-up buddy is to define a spin-up project. A spin-up project is also a small, well-scoped project inside your team. It should be a couple of weeks long and the idea is for you to start to understand more about your team and the project you will be working on. I spend a long time alone trying to learn more about things, but more often than not I paired with my spin-up buddy so I could get help on any details where I was stuck.

1:1 culture

An important part of Stripe’s culture is having 1:1 meetings (or coffee walks) with lots of people. People just start adding meetings at your calendar! Although very different at first, this was an interesting experience: I got to meet people from all teams and offices and make bonds that would be very hard on virtual-only communication. This was true in my first two weeks, but it never went away. It is normal for people who visit your hub to schedule some time to get to know you or to discuss about something you are working on. Now that I have a couple of months of company, I’m the one scheduling coffee-walks with new hires.

Opportunities to learn

We have a specific team, Education, responsible for launching new workshops and courses. We have an internal learning system that allows you to search for new courses or re-watch a Stripe 101 class. The team is constantly creating new content and asking for feedback after you finish a course, which means that the quality of educational material increases over time.

In the Dublin Hub, the engineering team hosts “Lunch and Learn” (or Learnch), where someone presents a quick talk about a subject while everybody is having lunch. This could be company-specific or about some random topic.

We also have Study Groups. Every other week, you can meet with a Ruby study group or attend a paper discussion. You can also find a lot of books spread through the offices, most of them from Stripe Press, but we also have an online library and budget to buy new books for our hubs.

There is no excuse to not learn something new!

Dealing with an overwhelming amount of information

As you can imagine, it was (is) a LOT of information. And the deeper I go, it only increases. Soon enough I found out that it’s extremely important to develop strategies for learning and absorbing so much useful content.

Checklists

Recently, some engineers and I got together and to create a checklist of things each new engineer should do and read in their first weeks.

The checklist goes from week 1 until week 12 (~90 days since your start) and includes tasks to be done, people you should meet and things you could read. To avoid being buried in things to do, we divided the tasks of each week as obligatory and optional. This way, a new engineer can prioritize the tasks that must be done while still having resources to read when they feel like it, but without the pressure of doing everything.

Keeping a diary

Something that works really well for me throughout the day is to create a work diary. This means that every day I list the tasks that I did, people I talked to (and what we talked about), links that are useful, etc. I’m currently using the Bear App notebook. This is my favorite tool ever!

With Bear App, I create one note per day and I add information of things that I did, people that I met and things that I can’t forget while organizing everything with hashtags and sub-hashtags. This way, I filter by notes that I have were I met #People/Bob to talk about #Project/ABC. It is amazing. Almost all of team now uses Bear to keep our notes and organize ourselves.

Here’s an example of how I organize my notes daily:

I also use this diary as a keeper of my learnings. If I discover how to do something that is not so simple, or if I struggle with a bug, I record the problem and solutions there. This is always useful to feel a personal sense of improvement, even on days that you’ve spent struggling with something. And it’s really handy to have a list of things you did for your daily team meetings. For example, if there is a sequence of commands that I want to store I can add tags like #code/tool and #code/project-abc.

Brag document

The last resource I use is a brag document. This document shares your main achievements over a course of time. While my work diary is really granular with small details that occur on daily basis, my brag document records major accomplishments that I think should be recorded. Julia Evans did an amazing job explaining about this, so go there and find more about it. Brag documents are useful both for your peers at review time, but also to build confidence by looking back on all the things you’ve accomplished.

Well, it’s been a crazy and exciting journey, and I can’t believe how fast six months flew by. I hope you like learning more about how it feels to be a new engineer at Stripe.

Comments