Interview with Rex Salisbury, Early Engineer at Checkr

This article is part of a series revealing the stories of early employees from the most successful tech companies of the past few years. You’ll walk away having learned about what these individuals experienced, what they wish they knew, and the advice they’d give to others joining high-growth startups. Key takeaways are at the top and you can find the full interview below. 

This interview is with Rex Salisbury. Rex was an early engineer at Checkr, joining the company in 2016 just a few years after it was founded. Checkr is now valued at $4.6bn. Rex has since gone on to start Cambrian, a fintech venture capital fund and community. Below is an edited version of a conversation he had with us here at Compound. 

Note: If you’re looking for an all-in-one solution to manage your personal finances, Compound can help. We can help you diversify concentrated stock positions, optimize company equity, plan asset allocation, and more. Request access here and we’ll be in touch.

Key Highlights

• The first product Rex built at Checkr – “On Zillow, a landlord can see all the properties that are for rent, then see all the leads come in. They can then use a rental manager app to manage the leads, and that app will do things like run tenant background checks through Checkr. [...] The tech behind it was pretty easy, but the hard part was all of the other pieces we had to do. This tends to be a trend at the companies I work for: at the beginning it’s more about writing and shipping code, but the more time you spend there, the more time you spend in things like Jupyter Notebooks writing queries to understand the downstream implications of a change. ”
• On the team structure at Checkr – “We had a small product organization and it meant that a lot of the product work actually fell to the engineering team. Our product was also pretty technical so a lot of times it was easier for the engineers to get involved earlier. Oftentimes I would get an PRD from someone in product, and I’d be like, “look, this isn’t how our system works.”
• On the importance of strong sales and customer success colleagues – “But when the company gets bigger, you’re no longer just building technical products, you’re building “solutions”. And if you’re building solutions, you need to talk to non-technical stakeholders at the customer, plus we need to have a salesperson and a customer success person involved internally. Having the right sales folks or customer success folks who know how and when to bring in and collaborate with engineering is hugely important.”
• On collaborating with product council – “Before you start writing code, you should talk to your product person and your product council and say, “I’m going to build this product, it’s going to do these things, and it interacts with this part of the regulated industry. Is this going to cause any problems?” You want someone in the product council who understands both the product side and the legal side really well. When you talk with them, you want it to be a collaborative, constructive conversation about how you’re going to build this thing rather than just, “nope, you can’t do that.””
• On Checkr’s growth and revenue concentration – “Checkr was great in that it found product-market fit relatively early and we were able to build a cash flow positive business basically from the start. We were growing on the back of the on-demand economy (rideshare, food delivery, etc.). The upside of that was we got to sit there and grow with a few big customers very quickly. The downside was that we had a risk through concentrated revenue.”
• Advice for breaking into tech – “If you want to break into tech and work for really cool companies, the number one piece of advice that I can give is to physically move somewhere that has a high density of networks. Especially if you’re coming from a school or location that isn’t already connected to those networks within the tech ecosystem, move to somewhere that has it.”

How did you find Checkr? What made you decide to join?

I started my career in investment banking and totally hated it. I got a lot more excited about actually building things, so after a few years I left banking, taught myself to code, and moved to the west coast. 

Once I got here, I started talking to anyone who was working on something interesting (whether or not it would lead to a job opportunity at that point in time). I ended up working at this mortgage company called Sindeo for a few years. It was a great learning experience but the company ultimately failed. 

For my next role, I was looking for two things: a high-growth company, and an engineering-centric culture. The engineering-centric culture was important to me – if you’re a developer, you want to be in an organization where developers are first-class citizens. It’s not to say that there aren’t other great kinds of companies to work for, but within every organization, certain functions have more power than others.

I found Checkr through a contact I had kept in touch with and after checking with a few other references, I learned that Checkr met my criteria. Checkr was both high-growth and had an engineering-centric culture. I decided to join. 

One piece of advice that I always remember is from Andy Radcliffe (founding partner at Benchmark and CEO of Wealthfront). The number one advice he gives people is to join a high-growth mid-size company. Even if you end up with a more senior role at an earlier-stage company, it’s not going to matter. There’s a way of articulating that anyone who joined Uber early on is great – I understand who they are and I want to hire them. That’s true for a lot of other companies too, and was part of my thinking in joining Checkr. 

What was the first thing you worked on at Checkr?

Two projects come to mind. 

First, I built our first-ever instant-tenant screen product for Checkr, which we did in partnership with Zillow. I don’t know if it’s still in production, but there’s a chance that if you use Zillow Rental Manager you’ll see the product. On Zillow, a landlord can see all the properties that are for rent, then see all the leads come in. They can then use a rental manager app to manage the leads, and that app will do things like run tenant background checks through Checkr. It was one of the first instant tenant search products that I built. 

The tech behind it was pretty easy, but the hard part was all of the other pieces we had to do. This tends to be a trend at the companies I work for: at the beginning it’s more about writing and shipping code, but the more time you spend there, the more time you spend in things like Jupyter Notebooks writing queries to understand the downstream implications of a change. 

A lot of the work ended up being things like, “okay if I architected it this way, how do I appropriately compensate to make sure we don’t have an unacceptable level of false positives or false negatives.” False positives are really the big concern because you don’t want to unfairly penalize someone in a way that they don’t end up with a house as the result of your poorly considered search. So it was a lot of data work. 

The other big project I worked on early on was rebuilding our entire motor vehicle screenings to support multiple states. One of Checkr’s biggest clients was Uber. And every time they onboard a new driver, they need to do a check on that drivers’ driving records. Those records are held at the state level. So if you onboard a driver in California, you want to pull the driver’s history and make sure they don’t have any negative records. 

But what if that driver moved to California less than two years ago but you want seven years of driving history? Now you need to check multiple states. You need to figure out their address history to learn what states they lived in and at what times. 

At the time our Motor Vehicle Reports (what we called them) only contemplated one state and it was a bit of a manual process. We had a state machine in the background to do this, so I had to re-architect the entire state machine to understand that we could have multiple states (and in the process clean up a bunch of tech debt). 

Today (if they fully rolled it out) anytime any driver is going through a Motor Vehicle Report, they’re going through that new architecture, even if it’s just a single state that’s being run.

Your LinkedIn says “Product Engineer”. How were teams structured at Checkr?

We had a small product organization and it meant that a lot of the product work actually fell to the engineering team. Our product was also pretty technical so a lot of times it was easier for the engineers to get involved earlier. Oftentimes I would get an PRD from someone in product, and I’d be like, “look, this isn’t how our system works.” 

I’d get back on the phone with the external stakeholder, redefine the product specs, and make sure we both understood what to do. I would end up doing the product work in order to do the engineering work effectively. I wasn’t technically part of the product organization, but a lot of the work that I ended up doing was product work in order to do the engineering work. 

Who are a few people that you learned a lot from and still inspire you in your work today? 

I worked with a lot of really great folks both at Checkr and at Sindeo. 

The first big callout would be Andy Carra. He was previously one of the founders of Sofi and the CTO at Sindeo. He was the first person who hired me for a fintech role even though I hadn’t done engineering at any company before. He took a chance on me and I think it worked out well (you can check with him on that). 

There were also a few people from my time at Checkr – one of the interesting things about fintech is that it’s, by nature, interdisciplinary. And by interdisciplinary, I mean that you work with folks in other departments to learn what and why you should be building. I worked with a lot of great engineers at Checkr (and I could name a bunch of those folks) but maybe what’s more interesting is to call out individuals in other functions that were very additive to my work as an engineer. 

As a company, when you’re first building an API product, you’re selling to other Y Cominator companies or tech companies. You’re an engineer, and you’re selling to an engineer and you both know what the product is and then you’re kind of done. 

But when the company gets bigger, you’re no longer just building technical products, you’re building “solutions”. And if you’re building solutions, you need to talk to non-technical stakeholders at the customer, plus we need to have a salesperson and a customer success person involved internally. 

Having the right sales folks or customer success folks who know how and when to bring in and collaborate with engineering is hugely important. Because otherwise what happens is you sell a product but you can’t actually deliver what you promised. So you throw it over to engineering and they tell you that you can’t build it, and then you have bad blood. 

So in the sales organization, there were a few people who I really enjoyed working with. One is Michael Johnson and the second is Kyle Mack. They both worked on large deals with enterprise customers or more strategic sales where we’d build a custom product. It was fun to work with both of them – we would co-conspire about what we should be building, why we were building it, and how to actually sell it. 

One other callout from my time at Checkr was Tyler Brown, our legal council. One of our strengths at Checkr – besides our great technical talent and strong collaboration – was our legal team. There’s a role within legal departments called “product council” and it’s a very important role in a highly regulated industry. Before you start writing code, you should talk to your product person and your legal person and say, “I’m going to build this product, it’s going to do these things, and it interacts with this part of the regulated industry. Is this going to cause any problems?”.

You want someone in the product council who understands both the product side and the legal side really well. When you talk with them, you want it to be a collaborative, constructive conversation about how you’re going to build this thing rather than just, “nope, you can’t do that.” 

I thought we had a great product council at Checkr and Tyler Brown was the person I worked with most often in this capacity. 

Was there ever a moment at Checkr where you saw “hockey-stick”-like growth? Or were there any existential moments you thought it wouldn’t work? 

Checkr was great in that it found product-market fit relatively early and we were able to build a cash flow positive business basically from the start. We were growing on the back of the on-demand economy (rideshare, food delivery, etc.). The upside of that was we got to sit there and grow with a few big customers very quickly. The downside was that we had risk due to concentrated revenue. 

This is true with a lot of API companies. They often unlock a change in the ecosystem and people who build on top of them are can get big fast, which means you have great growth, but a highly concentrated customer base. This has happened with API companies like Plaid, Twilio and others where they have a couple big customers that drives growth, but their revenue is highly concentrated. So your growth is de-risked, but you always have these existential questions – what are our other acts? Who are our other customers? How do we expand the market? 

When I joined Checkr the big question was how to we “cross the chasm” – proactively expand into other markets. How do we move this initial product market fit into other areas? 

What advice would you give to young people trying to break into the tech industry?

If you want to break into tech and work for really cool companies, the number one piece of advice that I can give is to physically move somewhere that has a high density of networks. Especially if you’re coming from a school or location that isn’t already connected to those networks within the tech ecosystem, move to somewhere that has it. 

You’ll have two main options to choose from: San Francisco (and the Bay Area) is number one. It’s sad we haven’t seen it fully come back compared to other ecosystems, but it still has a high density of tech folks. The second is New York City. 

Move to one of these main hubs for a few years and build your network then you can move back to a regional area. It’s so important for people early in their career to physically be in one of these hubs to build out your initial network. 

Second, after moving somewhere, the best way to find interesting opportunities is to canvas the ecosystem – have lots of conversations, participate in conversations and on Twitter, look for communities that are relevant. I started off building communities for folks in fintech and used it to convene with lots of people at different times. Every time you engage in a job search, don’t treat it as a transactional relationship. Instead, think of it as a way for you to build a platform that you can leverage in the future.