Introduction

At Stripe, we think a lot about scale. As we’ve scaled our products to process billions of dollars a year for millions of businesses, we’ve also needed to scale our engineering team. There’s a temptation for fast-growing companies to build their engineering team as quickly as possible. However, there are risks with rapid growth that include creating silos, diminishing user impact per engineer over time, and limiting ability to change how you work quickly to respond to changing user needs.

We’ve deliberately chosen to add engineers at a slower rate than the growth of of our user base and instead take an iterative approach to recruiting and developing our team. We were able to keep teams small, invest more in each person, and nimbly change our ways of working as needs changed. Since what works for fifty engineers may not work for ten or a thousand, we’ve built a culture of feedback and iterative thinking that enables us to continually make changes as we grow.

This guide talks through some of the things we’ve learned along the way.

Recruiting and hiring

Continuously evolve your process

Every company’s recruiting process and hiring needs are unique. When I first joined Stripe, we had just one dedicated technical recruiter supporting dozens of referrals and new applicants. Since then, we’ve improved, added, or replaced almost every part of the recruiting process and nearly quadrupled the size of our engineering team. I’ve found our processes run well for about 6-9 months before we need to update them. In order to safely experiment and evolve your recruiting process you need to:

Define a recruiting plan to meet organizational needs

Build consistency into your recruiting process to ensure efficiency and fairness

Never lose sight of candidate experience: no matter the outcome, you should leave a positive impression of your company and team

Revisit your recruiting process on a regular basis to measure progress and make changes as needed

Build a consistent recruiting platform

Consistent recruiting increases efficiency, prevents bias, and raises the hiring bar. It’s important to clearly define the process you use to identify, evaluate, and hire candidates; the more consistency you introduce, the more you can rely on predictable outcomes, use data to understand what’s working well and change the things that aren’t. We run regular training sessions for new hiring managers alongside our recruiting team. Clear documentation helps train new managers and share best practices, even for small details like when to email candidates and how written offers get sent. Every hiring manager, recruiter, and interviewer is aware of what they’re responsible for in the interview pipeline.

Training sessions are valuable for all levels of experience; even new managers who have led recruiting initiatives at other companies remark how useful it is to learn exactly how Stripe approaches hiring. This is as much about consistency as it is making your own team feel confident and effective.

The design of our interview process is drawn from industry studies and our own best practices. Our questions seek to understand how people approach real world problems, rather than testing for esoteric skills you might demonstrate on a whiteboard. During the Bug Squash engineering interview, candidates and interviewers sit side-by-side to solve a real historical bug in an open-source project while working in the candidate’s programming language of choice. For engineering managers, we use Team Role Plays to simulate working through issues during a one-on-one conversation with a teammate.

We standardize questions using written rubrics that define exactly how to run each interview, evaluate those questions consistently, and compare scores across candidates. A good rubric outlines the goals of the interview and provides clear criteria to evaluate the candidate’s performance. Before an interview, every interviewer reads the rubric to understand what skills they will assess. For each skill, we provide examples of how candidates with different levels of proficiency might respond. We also integrate rubrics directly into our applicant tracking system so interviewers can consistently reference them as they’re providing feedback.

Here’s an example of a rubric we use to evaluate how effectively a candidate can communicate:

Communications skills Do they answer questions clearly?

Do they provide specific details about their work, especially when prompted, vs. generalities and just describing the work of the team/company?

Are they able to process prompts and feedback during the conversation? Scoring the interview The candidate’s communication is scattered, erratic, or otherwise unclear. The candidate does not provide details or specifics, even when asked, or talks exclusively about things other than their personal work and contributions. The candidate may not be able to enter an effective two-way conversation with the interviewer, for example ignoring requests to change the subject. The candidate’s communication is not consistently clear. They provide details in some but not all cases when asked, or the details they do provide do not back their higher-level points, or most details are about something other than their own work. The candidate may be an inconsistent partner in the two-way conversation, for example by rambling for a long time with some answers. The candidate’s communication is consistently clear, making high-level points and substantiating them with specific examples and details. They effectively engage in a two way conversation with the interviewer. Candidate is extremely clear and provides specific details supporting their general claims. The candidate communicates their personal trajectory and impact as well as the relation to projects / teams / companies they were working on. The candidate fluidly adapts to the conversation and prompts of the interviewer.

In addition to building clear rubrics, we began unconscious bias training to maintain consistency and objectivity. We also incorporated our standardized questions into a new Candidate Review process we use to give feedback to interviewers and hiring managers once interviews are completed.

Candidate Review is a recurring meeting with a set of experienced reviewers that’s used to examine all interview results. In each session, reviewers read over results, give feedback to individual interviewers, and identify ways we can improve the overall process. Reviewers don’t second guess decisions, but do ensure that everyone leaves sufficiently detailed feedback and makes decisions based only on information we see.

Candidate Review started small, and I personally attended every session for six months to help train new reviewers, read feedback, and learn from first-hand observations. It was amazing to see what a difference we were able to make in a short amount of time. Engineers appreciated knowing someone was personally reading their notes, and we quickly saw the quality and consistency of feedback improve–both in level of detail and adherence to rubrics. Crucially, this helped us make several improvements to the interviews themselves.

Define clear hiring goals and effective processes

Clear goals enable you to measure success and make the right changes to your process when needed. If you rely primarily on a passive funnel of inbound applicants and referrals, you can end up hiring whoever walks through the door rather than who you really need right now.

For years after Stripe launched, we hired primarily generalist engineers who could work efficiently across the stack. As we tackled more specialized problems, such as scaling our secure credential storage infrastructure and building international mobile payment flows, we had to change our approach to attract the specialists we then needed. As a hiring manager for frontend specialists, I’d frequently meet candidates who would tell me, “Stripe doesn’t need any frontend engineers, you’re an API company.”

In one interview, I was explaining how we work on problems beyond API development but it was clear I was quickly losing the candidate’s interest; clearly they just couldn’t visualize what they’d work on if they joined. I ran to grab my laptop and spent 30 minutes showing them live demos of our web and mobile dashboards. My pitch worked: they immediately began to ask questions and make product suggestions. Shortly afterwards, they interviewed and joined the company. This experience inspired us to design a new candidate experience for frontend engineers that didn’t require improvisation. Today we have many frontend engineers across Stripe–some are embedded directly on product teams and others build shared components and infrastructure that empower everyone to write better frontend code quickly and easily. As you expand into different product areas, it’s important to bring the same structure you initially built for generalists and tailor it to more specialized roles.

We started with a small number of roles (infrastructure, front-end engineering) to understand how to retool our recruiting operations one at a time. We now hire across many different pipelines, ranging from Android to machine learning to security. These changes have steadily increased our offer acceptance rates and we now have specialists in every pipeline. Each detail affects every part of the recruiting process, including:

Posting different job descriptions publicly

Deciding which recruiters are staffed against which roles

Creating specialized interview questions, rubrics, and candidate preparation guides for each role

We recently launched Elements, our UI toolkit for payment flows. The Elements team benefited from the collective experience of specialists spanning security, front-end engineering, and user experience to tackle an extensive list of challenges: secure isolation of card details with iframes, resolving browser-specific bugs, adding internationalization, incorporating modern JavaScript API design, and optimizing conversion flows.

The interview process defines every candidate’s first impression of how your company and engineering teams operate. We strive to provide a great experience for everyone, no matter how well they perform in their interviews. We’ve developed some best practices that provide consistent touch points at each step in the process, help people prepare, set appropriate expectations, and give every person who comes on site the same chance of interviewing successfully and showing their best work.

To better understand our recruiting funnel, we recently conducted a private poll across several recruiting teams in the SF Bay Area. Based on these benchmarks, recruiting funnels for these teams have an acceptance rate between 12-20% from the onsite interview to an accepted offer. Most companies focus on meeting, then optimizing these numbers. It’s easy to forget that for every hire, four to seven people go work at other companies and take their interview experience with them–this means there’s a small army of people out there who implicitly represent your company and what you stand for, even if you never talk to them again. You are very likely to hire people from your candidates’ social and professional networks; if you leave a great impression, even those who don’t go on to work for your team can help generate great referrals.

Before the interview, we share written guides to help them understand Stripe’s culture and prepare for the interview. Engineers choose from a number of different programming languages and can use their own laptop and development environment. Afterwards, we send follow-up anonymous surveys to candidates to learn more about their experience and identify ways for us to improve.

We speak with every candidate after they interview, even the ones that don’t end up working at Stripe. For those who don’t accept our offer, we schedule a call to understand their choice and how they felt about the role. When we don’t extend an offer, recruiters give candidates personalized feedback to help them learn from their experience.

Across the board, our surveys have shown that candidates have a good experience interviewing at Stripe: those without offers rate their experience an average of 4.1 out of 5 on the questions above (and people who do get offers average 4.5). Even more striking, candidates who don’t join Stripe often go on to refer their friends and colleagues to us later.

Tips and exercises

Write rubrics for your most commonly asked interview questions and integrate them into your applicant tracking system.

Write and share an interview prep guide with incoming candidates.

Setup a quick survey to learn about the interview experience and ways to improve it.

Training and onboarding

Spin up your new hires effectively

Growing teams work incredibly hard to hire new employees, but can overlook helping new teammates succeed once they start. Joining a high-growth startup can be an intimidating experience, and without guidance, new hires have to work twice as hard to learn what they need to be productive.

In Stripe’s early days, we made the mistake of not investing enough in onboarding. Employees defined their ramping up period as a sink-or-swim experience. When I first joined Stripe, several teammates described this lack of support as a test–they assumed it was the company’s way of evaluating everyone again after they started. That was not the case, but by not investing enough in an onboarding program, we implicitly said that people were on their own; it’s easy to turn mistakes into accidental company norms. Today, we invest significant time and energy in onboarding and helping all new hires grow their impact.

Invest in dedicated training and onboarding programs

The first few months are critical for new hires. Asking an engineer to build a feature in their first week is tempting, but investing in onboarding and training makes for happier and more productive teammates.

For all new employees, we developed Stripe 101: a general onboarding program that connects new hires across the company. In just a few weeks, people learn about Stripe by attending classes, meeting with our co-founders, building a Stripe integration, and answering support tickets. They also get an early opportunity to collaborate with people in many different functions at the company. This operates at impressive scale, with over thirty sessions led by eighty-two instructors from across the organization. Last year, over two hundred Stripe employees went through the program. Employee surveys show that Stripe 101 is a positive experience and extraordinarily effective in sharing key information with them:

100% of new Stripe employees were able to summarize the function of at least three Stripe products by the end of Stripe 101.

94.5% of new Stripe employees felt their first week at Stripe was a positive experience and felt the 101 curriculum was an effective use of time.

90% of new Stripe engineers understood the components of the Stripe stack by the end of the program.

New hires also graduate with an immediate network of peers who work in different functions across Stripe. This helps them navigate the organization in a personal way as they tackle projects later in their career at the company–for example, when building a new feature, they may already know someone on the User Ops or Sales teams they can ask for early feedback.

Stripe 101 is helpful for general-purpose knowledge, but we saw the need for an additional onboarding experience for new engineers. They enjoyed meeting people across the company, but were anxious to spend time with technical teams and diving into code. We developed a new program to introduce them to our technical stack by solving a practical problem in our main application codebase. We called it /dev/start and started with a small pilot, featuring a handful of new engineers, volunteer mentors, projects pulled from team backlogs, and one-on-one feedback. Within months, it expanded to multiple organizations and was soon used for all of engineering.

Today, we group new hires into temporary virtual teams for 3-4 weeks. Teams work with a dedicated mentor to learn about our development process while shipping a concrete tool or product improvement. Experienced Stripe engineers gain project leadership and mentorship experience by serving as mentors–they sit with the team, break the project down into tractable tasks, answer both technical and product questions, review code, and serve as a bridge to the rest of engineering.

Don’t forget about soft skills and culture

Psychological safety is the shared belief by team members that it’s safe to take risks and share knowledge to support one another. In Google’s Project Aristotle, a study to understand the secrets of effective teams, psychological safety was identified as the most important factor to team success.

We aim to create this safety by writing guides to culture and group norms; we cover both general communication and team-specific practices. Stripe 101 includes a class called Communicating at Stripe that describes company mailing lists, best practices for email, and bug trackers, but also non-obvious communication patterns like how to schedule meetings. Norms for calendars may seem like common sense, but carry key cultural knowledge: understanding them can help people avoid embarrassing scheduling errors or discover important events.

Engineering teams provide specialized guides for specific tools (e.g. GitHub or JIRA) or common practices like code review. These act as a source of truth and allow teams to collaboratively agree on their processes upfront, reducing ongoing debate or confusion. Self-serve documentation also decreases our reliance on oral tradition, helping us scale more quickly.

Email at Stripe Use email for non-urgent messages. If you need a quick response that can’t wait until your recipient checks their email, use Slack.

If you’re going to be out of the office (OOO), consider putting up an autoresponder to tell people your response timeline and who’s covering for you. This is not required, and we leave it to your judgment.

You should send a shipped@ email when wrapping up a unit of work.

You shouldn’t lurk into people’s threads unnecessarily. Read to your heart’s content, but is your active lurking warranted? If you can meaningfully contribute, by all means politely chime in on list; if not, don’t impede others’ progress.

Open communication at Stripe only works if we create and promote an environment that feels safe to all Stripe employees. Lurking in unnecessarily and making someone feel self-conscious is a disincentive to communicate openly. Do, however, gently nudge others—especially newer Stripe employees—to stay the course and use lists. It may not always be comfortable, and it does require some courage, but the benefits are worth the perceived risk.

Tips and exercises

Pilot 1-2 onboarding classes that give an overview of your company and products.

Write a culture or group-norm-oriented guide for your team, e.g. how to email, calendar, and complete code reviews.

Engagement and retention

Invest in the team you have

Employee happiness often depends on two factors: whether they know the impact of their work and feel autonomy in the decisions they make every day. Beyond this, successful teams need to provide structure to keep team members engaged for the long-term. They need to actively listen to feedback, define clear paths for personal growth, and train leaders to best support their teams.

After hiring and onboarding new employees, companies can either focus on short-term output or the long-term productivity of their teams. At high-growth companies, conditions change rapidly and early decisions can have lasting impact, even as it gets harder to remember how decisions were made in the first place. Early employees can carry disproportionately more knowledge than new hires, be most effective at getting things done, and be the company’s greatest mentors through understanding both the technical context and how to navigate the organization. At the same time, they can start to feel overloaded or trapped in one part of the company or technical stack. Collaborate with your early employees to avoid this trap by building the right supporting structure for your team.

Don’t mistake productivity for engagement

As an early manager at a previous company, I was supporting a collaborative, highly productive team. One day, a long-tenured engineer arrived at our one-on-one and quietly handed me a letter of resignation. He’d been consistently delivering high-quality work, taking on challenging projects, and even mentoring new hires and interns. When I asked him why he was leaving, he said he no longer felt challenged–while he knew he was doing important work for the company, he couldn’t see any way to both increase his impact and learn new skills. I now call this the surprise resignation, when people feel stuck in a local maximum and conclude it’s easier to leave the company for an exciting opportunity rather than take on a new but seemingly less-impactful role within it.

I soon realized that while I hadn’t noticed any warning signs, a simple conversation about his career aspirations would have revealed his concern. People stay engaged when they feel a personal sense of growth, and you can support this by looking beyond day-to-day productivity and asking the right questions. Twice a year, we send out an employee survey called StripeSat to measure engagement. Here are some questions we asked in our last survey that we look at carefully:

Do you have opportunities at work to learn and grow? What would you like to learn or get better at?

Do you see yourself working at Stripe in three years? Why or why not?

Do you believe there are good career opportunities at Stripe (e.g. stretch assignments, increased responsibility, and internal mobility)? If not, what opportunities would excite you?

Create supported paths for mobility and learning

Helping people discover new opportunities and create independent projects enables them to shape their story and role at the company. At Stripe, we create internal resources to advertise new teams, encourage employees to rotate onto new projects, and run hackathons to foster creativity.

People use rotations to learn a new language, explore a different part of our stack, and in some cases permanently switch teams. In the past six months, over a dozen engineers rotated between projects as disparate as iOS mobile development, core payment API features, and machine learning applications. We also highlight roles that would benefit most from internal transfers–for example, bootstrapping a new team or tackling a complex technical problem. Highlighting these challenges helps direct longest-tenured engineers towards projects where they can provide the most help.

Trying something new doesn’t need to take weeks of planning or a new team; we also run internal hackathons to encourage building new tools and products. At a recent hackathon, eighty people participated across multiple offices, and we shipped seven projects to both internal and external users, including right-to-left language support in Stripe Elements and internal tools for employee productivity.

Ask for feedback and respond to it

As companies grow, responding to employee feedback requires both a scalable approach and listening carefully to individuals. Employees recognize problems at companies all the time, but don’t always know how to translate what they’re seeing into effective change. We respond to employee feedback with three steps:

Identify the problem Design a way to collect structured feedback Address the feedback, deliver the results

Two years ago, engineers consistently described our development environment as slow and inefficient. To address this, we formed a team of experienced Stripe engineers focused on the internal developer experience. Despite their intuition and expertise, they had trouble identifying the most impactful projects. The team launched a Developer Experience survey to guide their work, including questions such as:

In the last week, how many hours did you lose due to problems with your development process?

With our tools or infrastructure, what are 1-2 things we could do to make you more productive?

In the codebase you work in, what’s harder than it should be?

The survey results showed us the most common request (by a factor of two!) was for a faster and more reliable edit-sync-test loop. The team took this to heart and tackled a series of projects to improve the speed and reliability of syncing, reloading, and testing code. In the next round a few months later, results showed satisfaction in these areas had improved by 50 to 80%. This created a positive feedback loop between the team and their users, and helped engineers feel heard. Since then, we’ve run Developer Experience surveys every quarter and continue to learn from the results.

Tips and exercises

Create an internal job board that highlights specific teams in need or roles for experienced internal transfers.

Develop a hackathon pilot program: this could be over a range of time, like hack-a-month or hack-weeks.

Implement a company survey and identify one project you can take on in response to the feedback.

Wrapping up

As organizations evolve, how you scale your team has an enormous impact on your culture, productivity, and employee engagement, and subsequently the success of the business. At quickly growing companies, conditions change rapidly and what’s working well today may not hold up tomorrow. While these practices have helped us scale thus far, we’ll continue iterating and develop new ones as we grow. We hope these lessons are helpful to you in your scaling journey and are excited to share what we discover along the way.

Sound interesting? Join the Stripe engineering team. View Openings