#1 - Hiring Engineers with Ammon Bartram

**Craig Cannon** (0:00)
Hey, this is Craig Cannon, and you're listening to Y Combinator's podcast. In case you don't know about YC, here's what we do.
Twice a year, we invest 120K in a large number of startups. The companies moved to Silicon Valley for three months to work with us and build their company. At the end of the three months, they demoed to a room full of investors. Many of the companies have gone on to be very successful. Some of the ones you might know are Dropbox, Reddit, and Airbnb.
I'm excited to get our podcast rolling again, and want to thank Aaron Harris and Kat Menialik for starting the original YC podcast, Startup School Radio. Our first episode is with Ammon Bartram. Ammon has co-founded two YC companies, Socialcam and Triplebyte. Triplebyte connects software engineers with companies that are hiring. And some of the most frequently asked questions at YC are around hiring, so I thought it would be good to have Ammon in as he thinks about it all day. Our discussion mostly focuses on hiring engineers, though much of the advice he shares could be applied to hiring for other roles. Okay, here we go.
Hey, guys, today we have Ammon Bartram, co-founder of Socialcam, Triplebyte, and he is here to talk to us about hiring. So could you just give us a quick intro about what you've worked on?

**Ammon Bartram** (1:07)
So I joined Justin TV fresh out of school in 2009 It was just 25 folks and kind of went through the roller coaster of the early days of Justin TV.
And there I worked mostly on the video system, and I think that was my first sort of taste of hiring. You know, we were, at the end of that, we were hiring pretty aggressively, and that was when I first realized how much noise there is in the hiring process. And then I was part of the spin-off of Socialcam, and that was a sort of video-sharing app. I did that for about three and a half years, and we were acquired by Autodesk in 2012, and I worked there until 2014 And then took a bit of time off and started Triplebyte.

**Craig Cannon** (1:57)
And so Triplebyte just for context, for people? Can you explain?

**Ammon Bartram** (2:00)
Sure. Yeah, so we're a recruiting startup. So we help startups hire engineers.
And so engineers apply to us, and then we do sort of a full interview with them, pass the engineers who are good, and match them with companies where they have a high probability of doing well.

**Craig Cannon** (2:18)
Cool. So people ask us a million questions about hiring, recruiting, all of it.
In general, let's assume that you're an early stage startup. What should companies be looking for in an engineer?

**Ammon Bartram** (2:34)
There's not a crisp answer to that.
I think the pithiest answer I can give to that is you have to decide what it is you want to look for, and then you have to effectively look for that. I think there's an important truth here. Most companies think that they are trying to hire good engineers. That's what they say to themselves. What they don't realize is that company A's definition of a good engineer is significantly different from company B's.
So what you have is a situation where everyone has this definition in mind, and they're all different.
And this is a big source of noise. For example, if one company thinks that engineers need to be very fast and productive and be able to show that in an interview, and a different company thinks that engineers need to be very intellectual and be able to deeply understand computer science topics and talk crisply about that, what happens is all of the awesomely productive engineers, engineers very practical, not necessarily in a strong academic, who applied to the second company, fail. And all of the very academic could totally solve all your hard problems, but maybe aren't quite as flashy in a web environment. Engineers who applied to the first company also fail. And so for companies at a bit of a larger stage, I think the obvious answer is you want to hire both those people. And so it's about building a process that can identify more broadly different types of skill. For smaller companies, I think you're more in a situation where you may well actually only want one of those folks. The thing that's holding your company back may well be productivity, and we need someone who's going to come in and be productive and sort of bang out code. And if that's the case, you need to realize that it's not important that everyone you hire be strong in computer science. And if you are a company where you're facing security issues and really clean code, really precise code, and solving hard problems is important to you, then at an early stage, it probably makes sense to have a process that skews more in that direction.