This is the 11th episode of HackerRank Radio, a podcast for engineering leaders interested in solving developers’ toughest problems today: Hiring the right developers. Hosted by Vivek Ravisankar (CEO & Co-founder, HackerRank). You can subscribe to us on iTunes and Google Play.
This episode of the podcast is an excerpt from our HackerRank main() event in San Francisco. Vivek chats with Michael Glukhovsky, Developer Relations at Stripe, to understand how Stripe has become such a well-respected developer brand.
They dive into the following topics:
- Stripe’s successful developer brand
- How this translates into the recruiting process
- Standardizing your recruiting process
- Removing interviewing friction
Listen to the episode, or scroll below to skim the transcript.
Vivek: I'd love to maybe have you introduce your role at Stripe and your work and we think the interview can get started with that.
Michael: Yes, sounds great. So I work at Stripe as a developer advocate on the developer relations team and I'll give a little context on what that role looks like in a moment, but prior to Stripe, I was a founder of a developer tools company building an open source database called ReThink DB. So I’ve been doing developer tools for most of my career. In my role at Stripe today, our goal is essentially to reach out to the broad base of developers who use our platform. Stripe builds economic infrastructure, so the simplest version is being able to accept online payments, but you basically can use our API platform to be able to help build your online business and scale it globally. And so, we do is we try to find all the touch points and friction across the product and platform for developers and then advocate externally and internally to reduce friction and improve velocity, to spend a lot of time thinking about developer mindset, and a lot of time thinking about what developers need.
Vivek: So Stripe has one of the most respected developer brands and really great about it, are their specific principles or philosophies that you guys follow that help you get there? Of course one of them is obviously the core is API, so that should by default attract developers but I'm pretty sure that a lot of API companies who don't have a plan like Stripe. wWhat are some of the principles that you started to work on?
Michael: Yes. So, since starting Stripe two years ago I've shifted from working on a database where you download and install and run in your machine to an API platform. It's very different experience because API is like, they represent the world around us. Essentially the way that people approach APIs today like effective companies building API platforms, traditionally companies would sign paper contracts with each other, negotiate the terms of how to work with your service partner and then they would fulfill it and we have to do it all by hand. It's all like negotiation one-off for each individual partner.
With an API platform, the terms are pre-negotiated and then you can just transact freely and access to the platform is democratized, so it's economic infrastructure that allows anyone to get started very quickly. And if you think about a developer mindset one of the things that people don't often understand if they're not a developer themselves is a lot of folks focused on the tools, like, what languages do you know or what frameworks do you use? And they assume that that's like the thing that developers really care about.
But the truth is that be a lot like asking like a potter, do you like potters wheels? Do you work in my company? We have a kiln? And the truth is that, no it's about the art. What are you trying to create? What's the thing you're actually trying to build? And so when you have an API platform that sort of represents the world around you, it has to be well-defined, it has to be consistent and it has to allow you to express your ideas effectively.
Software is really just a vehicle for ideas. And so, when it comes to Stripe, a couple of things that we did differently, one is that the API is consistent, it's backwards compatible so as we update it, you don't have to change anything any of your software it just keeps working. If your platform breaks due to a version upgrade that amounts to a contract renegotiation and it's an opportunity for developers to leave your API platform. And so, we really try to respect this living contract with our users to understand that like if they're going be building their business and using our APIs to power their business process, then we need to make sure that it doesn't just abruptly change in them day to day.
The other thing is that when you look at traditional payments companies, roll back like 10 years, I myself actually with ReThink I try to set up a merchant service, a merchant account, to be able to do payments and it was just like a laborious crazy process because you fill out contracts like this, sign with each individual partner like Visa and MasterCard and then it takes like weeks to approve you. And that isn't very good from a developer perspective because developers really value load time like dopamine, just get that rush of, “Oh, it works. Oh man, what did I just do? I just made a payment? I just accepted someone's payment online?” That's a pretty rewarding experience.
And so, unlike companies that traditionally would ask for a lot of details about your business to ensure that they can accept you on their platform, Stripe has instant onboarding. So you just get started you sign up for an account and you can just start using it. You can start building with it and there's documentation to help you along the way very clearly defined and tools to help you see what's happening every part of the API platform. And so, this kind of approach towards thinking about it as a relationship that needs to be fostered and helping developers express themselves well is probably some of the driving forces behind Stripe success.
Vivek: And how does this translate into your recruiting process in terms of giving— you talked about it should be agnostic of a language and a framework. Do you actually extend this principle or philosophy even during a recruiting process? I've looked at your guides of how you help prepare candidates--we would love to know how does this extend to your recruiting.
Michael: Absolutely. So there's a couple of things that I've seen companies make mistakes of peers with startups who would try to hire teams and one is treating the interview process as a confrontational puzzle to solve because sometimes the director of engineering will be like, “Oh, I'm going to really stump the candidate. I know what I'll tell them.” And that's actually not how they're going be working in your in your role presumably. And so we try to give candidates the absolute best possible chance for success. We have lots of guides that we are preparing for the actual day and what kind of problems they’ll be working on. But when it comes to software development, a lot of people assume that there is deep specialization within program and languages, but the best programmers they can move from language to language and learn a new one within a few weeks if they need to. The basic principles translate for the most part and as long as someone who's a sophisticated thoughtful engineer, it shouldn't matter what language they come in the door with. The question is can they do the work well and are they a good person to work with. It's really just that simple and so we have very defined processes for different questions we ask and then we always try to have one software developing tool available for them that they can just download install for all the major languages. If we don't have that, we chat with the candidate beforehand and see if we can figure out an option for them that will work. And we try to really help them use their own laptop when they come in. They should be using, a sort of—or not there are too much whiteboard activities. Sometimes a whiteboard activity can be nice, but the truth is that the goal is to understand how someone thinks and if you're creating friction for them because it's not the way they normally would work, I don't know many programmers who program on a whiteboard. It can be counterproductive.
Vivek: Yes. So that's been an interesting debate for—this is what I want to touch on. So do you, have you said— I mean, even Stripe does a lot of lower level things on infrastructure and payment.
Michael: Absolutely
Vivek: It's pretty hard. Do you say, “Hey, for these rules it's okay to use them” and do you have a rubric defined for each of those roles? How do you actually set it?
Michael: There are always rubrics. Always, always, always.
Vivek: Can you give a sample.
Michael: So one that I run for my team, so developer advocates it's kind of an interesting position because it's very left brain/right brain. You have to be good at the engineering and the building the technology and also at the storytelling and the communication of it. And so, my favorite exercise when I built my developer advocacy team at ReThink because we had this sort of grassroots open source evangelism process, and then at Stripe we've done the same thing is, one of the best parts as a take home exercise. So we just say hey, “Here's the prompt. Essentially it's build simple web app and we give them very clearly defined terms and say uses API to build it and we leave it very open ended and we say, “We expect that it will take roughly three hours to work on this. Please don't spend a lot more time on that” so that people don't commit too much to a building for a day and a half and it's really the interview process. And people will sometimes be a little bit confounded by the open-ended nature of the problem but that's the point is that in this role you're supposed to be able to figure out what are the needs of the audience, to find your audience, to find the story, build the software. And then we have a rubric that grades them on five or six categories and just identifies how did they do on documentation, on the number of bugs in the app, things like this. And then, we look at the grades and the thing is consistency in a recruiting process is critical because sometimes what happens is that you end up with getting excited about a candidate, but now you've introduced bias, and it makes it very hard to be able to scale a recruiting process if you don't have rubrics defined. So we're extremely precise about the rubric and then we will go back and we'll actually have a candidate review process or we look at the candidates who maybe didn't pass our interviews either onsite or before coming in and we say, “Why didn't they pass? What could we have done to improve the process to actually expose the weaknesses of our recruiting processes?” And so it's sort of endless cycle where we're looking constantly at how to measure and then how do we actually perform against the measurement and that's what's allowed, I think, a really scalable recruiting process for Stripe and a lot of consistency.
Vivek: Just pushing that, extending that a bit further, do you think we could get to a point where you don't need to do technical interviews.
Michael: No.
Vivek: Why? What's the signal do you think you’re getting?
Michael: The signal is—
Vivek: I'm just talking about purely technical.
Michael: Absolutely.
Vivek: And you and I worked together well. That is super hard to figured out. I can probably write an essay. Yes, I think we'll work together well, but that's not going help, but just on the hard technical skills.
Michael: Yes. So I mean sometimes you can look at someone's body at work and say, "This is an excellent developer.” And then they come in and do an onsite process and then they don't do well. And then you have to ask, what happened. Clearly they're a good developer maybe they don't perform well within the sort of narrow window or maybe they got stressed because there was someone else in the room and that's why for example a take home exercise for me is really great as an early litmus test because it allows them to be as comfortable as possible in an environment before doing an onsite interview. But the truth is that just like you want to find out how someone, the human part— we're just talking earlier about how humans will not go away— AI will not replace us, that you need to have that sort of face-to-face communication. There's something else about seeing how someone structures their ideas and builds it and then takes that abstract concept and then turns it into code in front of you. And that process, it's not just about sitting and staring at them with a timer and being like, “You've got to get it done, you have five minutes left. Pencils down.” Sometimes the best interviews can be about actually just conversationally talking to them as they code and discussing what maybe this doesn't work, why doesn't it work? Let's do it together. And so one exercise we have is pair programming where we will assign an experienced Stripe engineer who was interviewing with the candidate and if they run into a problem it's not an issue, that's how software development works. The first thing everyone does when they have a problem is they go to Google and we’re like “Well, what’s going on?” While we want to emphasize that in an interview setting, you have to have some latitude for the process and the goal is just to see can we build things together.
Vivek: Yes, yes. And the reason I asked that is, I tell this even when during our team meetings on recruiting, I think it's very similar to what you touched on, “Hey can we identify the best version of this candidate.
Michael: Yes, that's a big deal.
Vivek: That should be— in my view, that should be the principle of what's the best version looks like because everybody has weakness. Like we mentioned, everybody is a human here. Nobody’s an AI – robot. And it's very easy doing a debrief to say oh this person didn't do well in this, are we going to not hire or make an offer.
Michael: It's a very safe position to take.
Vivek: Yes and you will be right.
Michael: Yes.
Vivek: You can debate on that. Oh yes, I mean this person has a weakness and the rubrics held, but at a high level if you think about if you want to get the best version of the candidate, then how do you meet the environment of the interview less intimidating. And less intimidating is whatever is the most comfortable for you is they give me as much time, give me a real world problem, I work in my environment, I showcase my code. But the moment you come and start doing an interview with a Stripe engineer or any company, it's intimidating.
Vivek: Yes. It is intimidating. How do you balance that? I mean there's going be definitely a bias there. I mean there are pros and cons in every aspect I'm pushing you more on that.
Michael: Yes. I think that one of the failure modes for recruiting teams can be to turn it into an adversarial process. A recruiter should be an advocate for the candidate. They brought them in. They believe in the candidate. So if that's the case then if we're not giving them the best possible chance of success that means the recruiting operation isn't working. It means that we're not respecting the candidate and so you really have to work to be there for all of their questions. And it's not just about what would the interview be like or what should I expect. On the day of, having someone who's a really friendly warm face, it can be, “Hey, I'm going to take you to your room. How was your day? How was your week? Let's talk for a bit. Let's reduce the friction of just walking in coals and feeling judged.” I find sometimes that with candidates because I often was the people check. I would come in and talk to a developer and just ask them about something they've built and ask them to explain to me and I would just kind of try to understand what is this person like to work with.
I always found and I still find this today when I do these interviews is that it helps to be vulnerable yourself in the interview because if you express your own vulnerability someone else feels comfortable doing the same. That seems like a very kind of odd thing to do in an interview setting except if you just remove the pressure from the situation, it makes it more fun to interview people and it makes for a really positive process. In fact, we find that an extraordinary number of people who we turn away refer their friends to come for interview with Stripe and I think that is a metric to pay attention to is, how many referrals are coming from the people that you rejected.
Vivek: if you think about the broad applications when you're a full stack developer building a web app and things on those lines do you believe that there needs to be a level of understanding of these fundamental concepts and how far do you take it. Would you still reject if I'm unable to reverse a linked list at Stripe or a front end developer, let's say, you're not going to use linked lists on a day-to-day basis but let's say you're not able to reverse, would you say no or would you give them another chance?
Michael: For a front end developer, I would look more to their ability to effectively build on the front end. That’s one question I would ask a front end developer. I think that it's very important to tell your process to the role. Full site developers are kind of a little of a unique animal in that respect which is why they're considered to be unicorns, you have to be good in a bunch of different respects but everyone has their strengths and weaknesses. If you want to build your team, there’s like a couple of ways to build a team, you can build it so that you have lots of different people who are specialists and you can have order of magnitude generalists. It’s really more a question of what's right for your company. Every company is unique, it's kind of what's the—I think it's Tolstoy which is, “Every happy family is alike in the same way. Every unhappy family is unique in its own way.” And it's the same thing with companies in that every company is absolutely unique. And so you have to figure out, do I want to build a team of specialists who all have really good communication skills because that’s going to be critical if you have a lot of different people talking to each other or don't want to hire these order of magnitude individuals who'll be harder to find, who will have to be compensated more and are going to-- you have this question of it's kind of a grim term which often comes in the department but there's the bus factor which is how many people for your team would you be able to remove and still be able to continue if something really horrible happened. And so the point is that if you want to build your team so that you have more redundancy and that people don't have to feel they're the only ones able to get over the line sometimes it helps to build a team of different skills.
Vivek: Yes, got it. So we just have a minute. So maybe you can— any closing thoughts on how do you align recruiting and hiring managers aligning on skills, expectations, the general relationship, how do you strengthen that?
Michael: For me, recruiting is the fundamental engine for companies. If you’re not bringing in candidates, it's very hard to be able to accomplish your goals. There was this study that Stripe recently funded which is called The Developer Coefficient which showed that it is the limiting factor for companies trying to build you projects and products, is hiring developers. Granted there's not a talent shortage but it is the limiting factor. And so I think that immense communication between recruiters and engineering managers to be ruthless about tracking metrics and figuring out exactly when you're deviating from, is your rubric good, are you getting referrals, are you bringing in the candidates? The metrics that I came with personally was 100 candidates—my startup was 100 candidates comes down to ten people who bring on site, to 10 that you do a phone screen, three that you bring onsite and one person you hire. And the better you can make those numbers, meaning the better your processes, the more efficient and effective your company is going to be and that's going to drive that engine to be able to actually accomplish your team goals and plans.
Vivek: Cool. I think that's all we have time. Well thank you so much for coming. Great seeing you again.
Michael: Absolutely.
Vivek: Thank you everyone.
