Hiring Engineers with Ammon Bartram

Hey guys, today we have Almond Bartram, co-founder of Socialcam and 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?

Cool, so I joined Justin.tv fresh out of school in 2009. It was just 25 folks, and I went to the roller coaster of the early days of Justin.tv. There I worked mostly on the video system, and I think that my first sort of taste of hiring, you know, we were, at the end of that, we were hiring pretty aggressively. That was when I first realized how much noise there is in the hiring process.

That's okay, yeah. And then I was part of a spin-off of Socialcam, and that was a video sharing app. I did that for about three and a half years, and we were acquired by Autodesk in 2012. I worked there until 2014 and then took a bit of time off and started Triplebyte.

Cool, so Triplebyte, just for context for people, can you explain?

Sure, so, yeah, we're a recruiting startup. We help startups hire engineers. Engineers apply to us, and then we do sort of a full interview with them. You know, we pass the engineers who are good and match them with companies where they have a high probability of doing well.

Cool. So, people ask us a million questions about hiring, recruiting, all of it in general. Let's assume that you're, you know, an early-stage startup. What should companies be looking for in an engineer?

There's not a crisp answer to that. I think the sort of the pickiest 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. So, sort of the status quo, actually, I think there's sort of an important roots here. Most companies think that they are trying to hire good engineers; that's what they say to themselves.

Um, at the end of the day, what they don't realize is that, you know, company A's definition of a good engineer is significantly different from company B's. 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.

So, for example, if one company thinks that engineers need to be, you know, very fast and productive and be able to show that in an interview, and a different company thinks that engineers need to be, you know, very intellectual and be able to deeply understand computer science topics and talk crisply about that; what happens is sort of all of the awesomely productive engineers who are, you know, very practical, not necessarily strong academically, who apply to the second company fail.

And, you know, all of the very academic engineers who could totally solve all your hard problems but maybe aren't quite as flashy in that way, in a web environment, could supply to the first company and also fail.

So, it's, you know, what comes out a bit of a larger stage. I think the obvious answer is you want to have 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 in a more specific situation where you may well actually only want one of those folks. You may well, you know, the thing that’s on your company back may well be productivity, and you need someone who's going to come in and be productive and sort of bang out code. If that's the case, you know, you need to realize that it is not important that everyone you hire be strong in computer science.

If you are, you know, a company where you're facing security issues and you know that really clean code—with precise code and solving hard problems—is important to you, then, you know, at an early stage, it probably makes sense to have a process that skews more in that direction.

So, do you have general advice for people that come to you guys at Triplebyte or just you as a friend or advisor for diagnosing, like, what kind of engineer is a good engineer for your company? What do you tell people who don’t know?

We don't know. So, it's funny; we're in a really good situation, actually. I think most people have strong preconceptions, so we’re more often in the situation of...