Season 2, Ep. 9 – Getting top talent takes top talent, with Director of Developer Relations, Deividi Silva

Faith (00:06):

Deividi, welcome back to your podcast. It feels like it’s only been been a couple days since we last had you on.

Deividi (00:13):

Right? I feel good to be back.

Faith (00:15):

Well, we’re gonna talk about something kind of different today. I know that we chatted before about kind of your professional history and experience and how you got here, but I think what we wanna dig into today is technical vetting and interviews, because I think this is kind of the crux of why a lot of folks come to us with help with technical hiring. So to start, let’s talk about you. If you wanna introduce yourself, share a little bit about what you do here, and then we can get into it.

Deividi (00:49):

Of course. Yeah. I think this is an interesting topic, and thanks for inviting me to talk about that. My team is bread and butter and I’m head of the developer relations team, and we spend our days vetting developers and making sure they’re great to talk to our clients.

Faith (01:05):

And you’ve had quite a bit of experience doing this same thing before you got to Gun.io. So in addition to vetting, I mean, how many folks are we up to each week that we’re vetting and improving?

Deividi (01:19):

Going through our pipeline at the top of the funnel, we have about 400-plus people every week coming into the platform, and then we have few steps that we vet them, and by the time they are approved and they’re able to talk to our clients, it’s roughly—well about 10% of them are able to at least talk to our clients and then go to another round. But again, I can get deeper into that. There’s layers of layers of interviews and vetting by our team, which is pretty exciting. We make sure only the right people talk to clients.

Faith (02:04):

(Teja: Turtles within turtles.) Right. Yeah, we’ll talk about all those levels. Turtles within turtles—or Russian nesting dolls. So obviously vetting for technical hires is much different than vetting for other kinds of hires for teams. So I guess to start, I’d love to hear your take on why it matters to do vetting well when you’re hiring a developer—and what’s the risk of doing it wrong?

Deividi (02:35):

Hiring is time consuming part of the work for a hiring manager. So if you’re a hiring manager for a small or big company, and your company is growing really fast, you’re going spend at least 30% of your time trying to attract the best people to your team, right? So if you have a service like Gun.io that streamlines that process and does that heavy lifting for you, you can look at yourself saving a bunch of that time, hours per of week, phone calls, screening calls, and then going into another round and other round of technical interviews, so it can save all of that just by coming to us and talking to people that are already being vetted. And so this is why it’s so important to get a partner that is able to do that right for you, right? If you don’t do that, you’re looking at yourself wasting a lot of time reaching out, code messaging people on LinkedIn, trying to find out the people there even going to answer you. ‘Cause most of them won’t. If you’re hiring manager saying you have a very special role that developers get every day, five of them, and you wanna be special among them, you’re probably not that special, and people are not gonna talk you. So it’s very time consuming to do that by yourself. (Faith: Right.) 

Teja (04:15):

So, you know, it’s interesting, like I think we articulated this assumption that hiring a technical person or hiring a developer is different than hiring another role. Is it different? And if so, why is it different?

Deividi (04:28):

Mostly it’s different because the market is so favorable for developers that they can choose and they can ignore you as much as they want, because next day there’s going to be an offer better than yours on their inbox, and they just can keep ignoring everyone. As for other kind of roles, it’s not so common to have that big flow of opportunities coming right to you. Right? It puts the hiring people on a different position where they’re trying to find good technical quality there. They’re just one in many. It’s kind of reversed, the logic there.

Teja (05:13):

It’s a lot like executive recruiting. And they’re really similar in that to be a good developer, you either—I mean, you have to have exceptional aptitude, like intellectually, and then you have to have a whole shitload of on-the-job training and experience, you know, that’s the same thing as a high-end exec, who you know—let’s say gets dropped into a private equity back through or some sort of professional operator and, you know, you have to wonder that there are, you know, few people actually, you know, maybe there’s like 3 or 4 million devs worldwide, I think. But, the point is there’s not that many, you know, there’s not that many. And so like you said, the supply-demand seems to be really in the demand side, like outstripping the supply. And then the second, I think, is that to be able to gauge who’s good and who’s not, you have to be one of those devs that are good, which is already a small pool. 

Deividi (06:22):

Oh, yes.

Teja (06:22):

And, and so that’s like hiring an exec—like, how can you hire an exec if you don’t know—if you haven’t done the job, if you don’t know what you’re looking for, you know? It’s hard to do. 

Deividi (06:35):

It becomes too difficult, especially for when we see small companies, that they’re not quite there yet on technical excellence, but they see a field chart where they have a great idea and a number of the investors that are bought into that idea, but they don’t have the technical excellence to be able to know what good looks like. They haven’t done that by themselves. So they—how could they hire someone and trust someone when they haven’t been being through that process before? They don’t have anyone on the engineering team that have done that before. So that becomes really difficult, right? To have people on your side that have been true, that have worked on those jobs that worked on big companies and worked on ambitious projects before the huge systems and build those things to be able to vet those people for you, that’s the best way that you can approach this, creating a partnership like that.

Teja (07:41):

Yeah. You have to be able to judge high expertise, and that requires high expertise, which is not common. So you gotta either pay for it or build it. Both things take time and money.

Faith (07:52):

I mean, if we wanna stick with this archetype for a minute of founders who don’t have a technical partner or department built out, right—and they’re tasked with hiring a developer—I think one of the common misconceptions is, you know, any good developer is good for you. And that’s just not true, right? It’s not like hiring a CMO or a COO who you can just look at their experience and be like, ‘Okay, well they’ve done this job before, they can probably do it for me.’ There’s a whole layer of technical expertise underneath just their professional background that has to be vetted. And I think that’s where the crux of this difference comes in, right? Nobody’s ever asked me to take a marketing exam, right? But like, if I were to apply for a development role, I might be expected to take a code test.

Teja (08:47):

Yeah. I think it’s easier to get passable knowledge—and not technical business functions—than it is in technical business functions. I think so, because I think you can kind of look at a P&L you figure out, you google some terms, you sort of understand, okay, this is what they’re representing. Or you can kind of be like, this is a good flyer, this is not a good flyer, why colors and positioning. But you know, for me, for example, to learn how to get something up on Heroku, I had to go through the Odin project. I had to read a shitload of docs, and then I had to go to stack exchange to find answers. And it takes a lot more than googling and Investopedia on like what does gross revenue retention mean? You know, there’s a lot more investment to get maybe even the same level of experience, and therefore it’s a higher compensated skill. I mean, it’s more investment, more kind investment, and therefore the rewards are greater.

Deividi (09:48):

It all comes down to having real world experience with the subjects that you’re talking about, right? You can try to hack your way through and get into those companies, but getting into is just the first step, right? So one thing that you can read, cracking the code interview and memorize a lot of algorithms, and you can do a lot of that. And you can get extremely lucky that you get on an interview with someone that cannot go a level deeper and try to catch you if you are just BSing your way through the interview and you get a job. But once you get a job, then you need to convince people, you need to earn people trust that you really can’t do the job. So it becomes another set of problems. Right? And that’s still a big problem for the company, so someone that hacked their way through all of that process and still were able to go in, as in, if you have someone experienced enough doing the vet process and interviewing them beforehand, they’ll be able to catch BS really quick. They will always go deeper and deeper and deeper and asking more questions and trying to understand if you really are who you saying you are, you did all the things that you’re saying you did, then you are going to fail. You’re going to fail to convince them if you haven’t really done those things in the past in your career. So that’s one of the key things, right? To be able to go another level and try to really understand the past experience on any candidate applying for a position to understand if they really did the job that they’re saying they did. 

Teja (11:40):

As head of vetting, what’s your position on what if—like what if somebody hacks the vetting process here and like gets through, ‘cause it’s an engineered system. They hack it, they get through, maybe they don’t know the shit that they say that they do. What’s your position on that? Are you like, respect for hacking it, but you’re banned? Or are you like, you know, good job, but you need to kinda learn this shit?

Deividi (12:07):

Well, I like to think that that that doesn’t happen too often. So there are a few things. So let me lemme go over the steps. So once you sign up to Gun.io, of course we have first layer of screening process and that’s more automated. And then you get—there’s some things like experience, there’s confirm experience. If you really did—there’s a way to find out that you really did what you’re saying you did, and a lot of other things like optimal location and skills that are actually on demand. And then another layer is when you’re onboarded to our platform, we are going to do the best that we can to talk to you and understand on a general level. And this is pretty interesting, because we’re not interviewing for a specific job. So on a general level, does your career make sense, right? We’re going to look at your resume, your work history on our platform. We’re going to understand, does this career have a good progression? Do we see them evolving and taking more meaningful roles and being practical on the things that they’re doing? If come into our platform and just list a bunch of frameworks and languages, there’s no way that you’re going get presented to our client and you’re going to get a job. It’s really, really difficult for that to happen. And let’s say you did all your homework and that looks good and you talk to someone on our team and you convinced them every time they went on a deeper level and tried to understand if you really did those stuff, you convinced them it’s great—ok, on a general level, you’re approved, you were able to cheat us. But now there’s the other piece of it, which is you need to convince us that for a job that you’re applying on our platform, you are a good match for the job, right?

There are some people that are such great matches, they don’t even have to apply. Our team is going to look at them and say, Hey, this is the perfect match. Let’s present you to the client right away, even without applying for a job. But some, when you are applying for a job and you write us a cover letter, you’re going to another vetting process where we need to see, okay, I’ve talked to the clients, I’ve heard their requirements, and I understand what they need. I have a list here of people, and these are the top people on my vetting process that I’ll be selecting to talk to this client. So it all comes down to then at that level much more specialized than on the first level—that you need to be a great match for that job. Like, is it for a specific kind of industry? Is this for health tech or pintech? Have you done this type of job before? Because all clients here, they’re looking for people that can hit the ground running, right? So to be able to trick us at that level—then you’re great, then I’m gonna tell you go ahead, do the job, because you can figure it out. If you don’t know, you can learn on the job— but all kidding aside—that’s all the levels of vetting, and we kind of redo steps a lot of times making sure that people are actually good for the job. (Teja: Awesome)

Faith (15:53):

Yeah, that’s a really good rundown of our formula for success, for how we vet talent—both generally, like here’s what we look forward to allow people even on the platform, and specifically, how do we actually vet people for a specific role or a specific company? I guess what I’d be curious to hear is if we kind of turn our attention to a hirer, and maybe they’re not working through us, they’re just somebody who’s tasked with charging the next technical teammate—what are some common mistakes you think people make? ‘Cause you’ve seen people hire developers for years. Like what are some common mistakes you’ve seen when folks are vetting developers?

Deividi (16:39):

That’s a very common thing, right? You make the bad decision of hiring someone and regretting it, right?And not actually realizing that the person not good for the job. One thing that is a wrong approach, or something that goes bad, is that you try to only focus on the technical, and you don’t get to a level where you understand that this person fits the culture that you’re looking for. That’s the most common mistake that I see people make. Ok, let’s see if you’re a good Python developer, and all that matter is that you pass the Python quality test. And you forget that in the end of the day you’re going work with a person, right? Especially nowadays that you’re working with them mostly remotely. And you need to understand that they have their own background and the things that they bring with them to this job. Can you accept that they’re on a different time zone? Can you accept that the communication is gonna be asynchronous? Have you figured out the details on which you are going work together? And did you agree about how the work is going to flow? Do you have any ceremonies on your team? Do you have other people on your team? Have you introduced this new person to other people on your team before making a hiring decision? “I know everything, I’m the hiring manager”,not sharing this with anyone—you should have new people coming in, interviewing with you, but also going on other rounds of interviewing, talking to other people so you make sure your team is welcoming this new person to the job. So the most common mistake that I see is people focusing too much on the technical. And another level of that is that you focus too much on the technical, you forget the culture thing, but also you forget to go deeper into how they use that technical expertise on other situations before. And what are their soft skills that they bring to the table, right? What type of ownership do they bring to the table? Do they care about their customer when they’re building a solution? Are they people that are going to take responsibility for the decisions that they have on your company? So all of those things are common mistakes that people forget to bring into the conversation when they’re having those interviews.

Faith (19:35):

I think that just, you know, begs the question, what is your—and thus our, as a dev rel team’s—approach to interviews? Because I know you have a really specific kind of opinion on how interviews should be conducted, what should be included. So how do you approach those?

Deividi (19:55):

First, bring on your best smile and be a good person to the person interviewing with you. Oh my god, so many times people interview, and the person interviewing is so rude.

Faith (20:10):

Right.

Deividi (20:11):

Be a good person. You can’t say that enough. Just be a good person interviewing people, right? Big smile, welcome them into the conversation, explain what they’re doing there. Step one. That’s the number one thing that we do here at Gun.io. And whenever someone steps into a conversation with me or my team, I strongly advise my team to have this kind of approach. Hey, everyone’s here to have a good time, right? Let’s start with that. Let’s start the conversation by assuming that this person is good, and let’s dive into the good stuff. And once you step into the conversation, you wanna start asking more general— just tell me about yourself. Tell me a little bit about your career. And you start understanding their communication style with that. You start getting hints of where this person is going to take the conversation on their next questions.

A lot of people are just going to start vomiting a lot of keywords, frameworks, and languages. And the next step, you can see how that’s going to go and how different you’re going have to leave it conversation. There’s a lot of responsibility on the person interviewing that you need to listen, right? You cannot be talking a lot. You are really there to give this person a chance to speak, and you have to listen to them, and you have to be able to listen, and by listen [I mean] guiding the conversation to where you want to go. And once you get past that first step of getting to know the person overall, you go into the technical discussion. And our approach, as we need to be more general, is a little bit different, right? So we are not going to, okay, let’s see your last experience and let’s talk about how you develop this feature in React. I don’t care about that. I will ask you, Hey, tell me about the most relevant project that you delivered in the last two years, right? And then the person is going to start explaining that, and if they’re good enough, if they understand what I’m looking for, they’re going be listing what the situation was like, what was the customer problem that were solving, what the actions did they they need to take, and what the results they bring to the table—what was the impact that they had with their customer? If they’re good. If they’re not good, the most common thing is they’re gonna vomit a lot of keywords and and frameworks and languages. I’m not interested at all. I’ll try to bring back the conversation to, Hey, that’s all good, but tell me what does that mean to your customer? What impact did that bring, right? (Faith: Yeah.) And that’s another opportunity for them to go deeper. If they can’t—again—then it’s clear that the communication is not at the level that we want it to be—that they’re not actively listening to my questions, and probably, that’s going to be end of conversation. If that didn’t happen and they’re good, we go a step deeper. That’s when, okay, you create an impact. Let’s talk more. Tell me a little bit more about the architecture of this solution. Did you think about this or that trade off? And that’s when my technical skill comes to the table, and I start evaluating if those trade offs, decision, those challenges, do, do they make sense? Are they delivering the right thing? If they don’t make a lot of sense, maybe there’s more context there, and I try to dig deeper. So it’s fun for me, because I like digging deeper like that. And I usually—what I tell my team is just have fun! Ask questions where you’re having fun asking those questions, right? And last but not least, we dive into asking people what they’re looking for, right? They come into our platform for a reason, and I really am curious about that, and I want to deliver a good experience to people interviewing on our platform. And that’s one of the most important things—asking them what they’re looking for. How can we get them the best service possible for them in our platform? Overall, that’s what happens.

Teja (25:00):

Awesome.

Faith (25:00):

I feel like that is entirely more simple than people think technical interviews have to be, right? Like what you described was just a really good strategy to have a conversation and understand what somebody is great at. And I think that’s relevant in, you know, all kinds of scenarios, not just technical interviews. So that’s awesome. Really helpful.

Deividi (25:21):

Well, expert people have a way to make complex subjects appear to be simple, right? So that’s how you can see that this is a very complicated topic, complex topic of trying to do all those technical decisions but making it simple— that’s what makes us, what I like to think, experts on vetting people and making sure great people are in our platform.

Teja (25:53):

So, true. (Faith: Yeah.) How should I say this? This is probably like, maybe not the sexy part of hiring, but I think it’s an important part and one that I think just, you know, I’ll big ups you for a minute. I think one that you’re really good at, Deividi, which is like, I think hiring is one part, but then offboarding to build a really high performance team is the other half of hiring well. Maybe you can talk a little bit about that, like your philosophy around offboarding—how you judge if somebody’s not a good fit. ‘Cause you know, an interview is building a framework for an educated guess of performance. So how do you assess, hey, maybe my hypothesis is not correct? 

Deividi (26:36):

Yeah, that’s a great question, because things are not going to go well all the time, right? And you have to define the criteria to be really clear what good looks like and what not so good looks like too, right? So the approach that I usually take—that I always take, actually—is I am going to define all the metrics that are going to make a person a good hire, and what are the successes that we’re going to see on each step, and if someone is able to deliver to what was expected, and if the metrics are looking good, then everything looks okay. But if something is not going so well, you need to have good metrics very early so you can then be very clear and quick in giving feedback, trying to assess this problem, and making sure they are understood, because you can think that you’re coaching and you’re giving good feedback, but  if the other part not actively listening—so a lot of this working with people comes back to listening, right? If the other part’s not actively listening, you have to be really clear in showing—you have to have that data to back it up to show Hey, this how I’m telling you things are not going so well and what I need them to be, what this company needs them to be, what our customers need them to be, so that we can keep you on our team, right? So you need to be constant about giving those coaching pieces of feedback. And again, and again and again, if you don’t see improvements, then there’s a natural flow that the person— you’ve taken those steps so many times and the person understands that, okay, I can see where I’m not being able to succeed and I’ve been given all of the chances that I could have been given to be successful. And me letting this person, this company making the decision on letting me go is not a surprise to me anyway, right? It should never be a surprise that you’re not a good fit. And it’s ok. It happens to a lot of great people. They are hired for a job, and they’re not that good, and they probably are great on another job. So it’s one of those things that you have to be really transparent with people so they’re not surprised by that.

Teja (29:31):

Hmm. Do you have, in your mind, an acceptable mis-hire rate? ‘Cause it can’t be zero. It’s like a limit, right? You have to approach like maybe 5%, you never quite hit it, but you don’t ever want it to be zero ‘cause maybe you’re not being aggressive enough with who you’re hiring, you know? 

Deividi (29:50):

I think it depends on the size of your company, right? If you working big company, on a big team, something that I’ve seen in the past being acceptable and even encouraged is that you are okay with that like 6 to 10% of your workforce is not going perform well and you’re always raising the bar, right? And someone is actually going to be behind, and you are going to have to coach them out and let them go. So the team is always growing on strength level. For smaller teams, the percentage is going to be higher to strengthen that approach. The thing to be focused on is you need to try to achieve a way to always elevate the standards of your team so everyone feels that they’re growing, right? So if you are okay with everyone staying in the same situation, you’re probably not doing a good service to your clients, your customers, or your business, right? So trying to find that level where, here’s the baseline of what we want to see, so anyone below that level is gonna be coached to either go above that or find a way out.

Teja (31:11):

Not the fun part, but it’s an important part. The other half of hiring. 

Faith (31:14):

Yes, that’s helpful.

Deividi (31:15):

It’s part of the job.

Faith (31:17):

It is, and it’s also part of having a job, right? Even if you found a company, that’s not gonna be your job forever, right? Like everybody is going to, at some point, leave. That’s just part of life. But I find those steps to be really helpful, Deividi, right? Like step one, happens even before you make the hire, is identifying those criteria for success. Step two is coaching against them and being really diligent in that, right? Like not letting them just slide once somebody’s onboarded, but actually revisiting them consistently. And then step three is, you know, making a plan for either offboarding or promoting depending on performance. So that’s really helpful. Well cool. I think we’re just about out of time today, so that was awesome. I think we’ll have to create a written asset as well, based on this conversation. I think there’s a lot of helpful bits in here. And obviously it goes without saying, if you do not have a technical hiring muscle within your business, come talk to us, because we do. Deividi can do your hiring as well. 

Teja (32:30):

Yeah. Or you’re working, you’re tired of building shit, and like, you need help. That’s okay. Right?

Deividi (32:35):

Yeah, come talk to us. We can, for some clients, and if they’re on a different kind of level and they wanna design something together and they wanna collaborate and they wanna find a partnership in a way  to build a high performance team, they can always reach out to us, find way that we can help them hire.

Faith (32:58):

Well guys, thank you so much. This has been awesome. Listeners, you can find us at [email protected], if you have any questions. So appreciate it guys. Thank you so much.

Deividi (33:08):

Thank you.

Teja (33:10):

Peace out, y’all. Peace and blessings.