Subscribe
Share
Share
Embed
Some interviewing techniques can be pretty disrespectful of the applicant's time or humanity. On today's episode we talk about some ways of approaching an interview to put the person at ease and help them to do their best.
Show notes:
Show notes:
Creators & Guests
What is No Compromises?
Two seasoned salty programming veterans talk best practices based on years of working with Laravel SaaS teams.
Joel Clermont (00:00):
Welcome to No Compromises, a peek into the mind of two old web devs who have seen some things. This is Joel.
Aaron Saray (00:08):
And this is Aaron.
Joel Clermont (00:15):
I know it's come up on the podcast more than one time but, Aaron, you and I have different backgrounds, work backgrounds that is.
Aaron Saray (00:23):
Oh, okay.
Joel Clermont (00:24):
I mean, we could go into our personal lives too. But, you know, where you've worked on larger teams inside of larger companies and led those teams. And you know I've tended to work with smaller teams or kind of more in a solo role or small organizations. And the reason I'm saying all this to preface it, isn't to just make a random observation but to kind of set up the topic for today. Because I was thinking about this idea of when you're interviewing a developer. So whether it's to hire somebody or whether it's to bring on a subcontractor, or anything like that. There's different ways and different ideas on how to gauge, "What is this person's skill level?" Not like, "Are they a good person or not?" right?
But just like, "What do they know? Where are they at? Just so I can make a proper evaluation." So knowing that you've done this a lot in the past, done interviews, different types of interviews, I wanted to interview you today and ask you some questions. So I promise I'll make it specific. I guess my first specific question is, when you are interviewing somebody and you're kicking things off. You know, obviously you want it to be kind of a relaxed environment, you're not there to grill them or to trick them or anything. But what do you find as kind of a productive way to start a technical discussion to gauge somebody's skill level?
Aaron Saray (01:53):
Well, the first thing I do is I actually read their resume or I search them before the meeting. There's a lot of people that come into them blind, or they're like, "I'll learn what I need to learn when I'm there." Which is not setting you up to be successful. Talking about success is, first of all, I approach interviews success-focused. I approach every interview as, "I want to hire this person," not, "I want to find ways that they don't fit."
Joel Clermont (02:21):
Sure, great. Okay.
Aaron Saray (02:23):
Now, you think that is what we all do but if you're real honest with yourself there gets this blood-in-the-water sort of thing where you're just like, "Oh, yeah, I can't wait to be better than them," or whatever. There's a lot of these different things that can happen and we all do that. Or we might be a little self-insecure or all those different things. So I look at everything first of all and I say, "I want to be success-focused." In order to do that, I have to know a little bit about that person because I want to remove some of their guards. Because when I really know a person and we can break down some of these initial guards, then we can find out a lot more stuff about them and they can be more forefront and say these things.
So now this isn't just about like, would they fit in a team? This is about technical skill, so I do some research and I find out things they're interested in. Are they very commonly publishing stuff about programming? Are they in music or whatever? And I'll use something like that to kind of start out the conversation showing that even though I'm going to ask a bunch of technical tough questions, I'm not a robot so you don't have to respond back to me like a robot.
Joel Clermont (03:24):
Aaron Bot 3000 conducting this interview. Yeah, that's a good point because I can't imagine being on the other side of that interview. Yeah, it's a little stressful. They're applying to a job or they're putting themselves out there because they want some new opportunity. So I could see that fear of failure and coming at it in a constructive way. I was also thinking like, if you learn about them, their interests, their experience, the sorts of things maybe they've published. Other than just kind of like small talk, would you use some of that? I don't want to call it a softball question, but maybe a warmup question. Like, something you know they have experience with and they're going to feel comfortable answering to get started.
Aaron Saray (04:10):
Yeah. If they're applying for a Vue job, Vue Programming or something, but they published a bunch of React stuff I might say, "Hey, so first of all tell me a little bit about your React experience? What made you really get into that?" Because I know that React and Vue are similar enough that if they're really good at React they're going to be good at Vue after a little bit.
Joel Clermont (04:31):
Right, yeah.
Aaron Saray (04:31):
So I might ask some stuff that's not about pertaining to the job. But I empathetically try to come up next to them and say, "Hey, we're in this together. We both want you to work here, let's see if you're going to be a fit." So I'll use some of that background information. The other thing which... now I'm giving away my secrets.
Joel Clermont (04:49):
Do it.
Aaron Saray (04:50):
But I try to figure out... I'm not trying to say I'm awesome but you have to be a pro to use this technique. Is I try to learn from anything they have out in the world what kind of communicator they are. And whether they're an excitable person or very quiet person, or whatever. Because that tells me then how they're going to answer their technical questions. It helps me learn how to put the proper filter on there. So if I am interviewing a programmer who is always on Twitter, always talking, super friendly, whatever, I need to make sure that I don't fall for their charm when I'm interviewing them and asking them technical questions. Vice versa, if I find someone who maybe even sometimes has taken like angry... You know if they comment on stuff and then people think they're angry or they're never out there, maybe their answers are going to be a little bit quieter or slower, or they're not going to expand. Doesn't mean they don't know what they're doing, just means that that's maybe their style of communication. So instead of thinking that maybe they don't know what they're talking about, I just know that they need to be asked over and over until they expand further.
Joel Clermont (05:53):
Interesting, okay. Yeah, kind of having a baseline of their communication style, I can see how that'd be a useful thing. Now, I imagine the types of technical questions you ask would be different if you're hiring somebody for a junior position versus a senior position. But maybe kind of thinking more about the senior position... And let's assume that the company has some sort of basic vetting process, you know. So you don't have to... I really don't the "Got you style." You know, "Code this algorithm for me," type thing. So let's assume the person has proven a certain level of competency but you kind of want to get into their thinking. Like, how do they approach a problem? How do they deal with something that maybe has more than one possible right answer? Do you have any tips there for how to kind of tease that out of a person? Like, how they approach something without putting them on the spot with some giant complex problem they haven't had time to think about?
Aaron Saray (06:55):
Well, that's a good question. I think that's one that many people have. I'm going to sort of sidestep that but also answer it at the same time. Is one of the things that there's a challenge is, how do we measure technical prowess? Do we give them coding challenges or all this kind of stuff, right?
Joel Clermont (07:10):
Yeah.
Aaron Saray (07:10):
So there's been some very crappy companies, but there's also just been some stuff where they actually give you a coding challenge that's work that they need done.
Joel Clermont (07:18):
Oh, no.
Aaron Saray (07:18):
But I would never do that, right?
Joel Clermont (07:21):
Okay.
Aaron Saray (07:21):
But, you know, that's why people first of all get turned off by coding challenges a little bit. The next thing is like, "Well, if I'm applying to five jobs and each one has a coding challenge that takes two hours, that's 10 hours of extra work I have to do." And you think about it as like, "If they're doing those 10 hours, can they really be then doing their core job?" Even though I know they're shutting off on their core job, if they're going to leave my job I don't want them quiet quitting and spending 10 hours doing interviews. I want them to at least do the work until they're gone. So I don't want to do that to another company either. I feel like that stuff kind of what goes around comes around.
Joel Clermont (07:56):
That's fair, yeah.
Aaron Saray (07:57):
So what I'll do is a lot of times I'll find a project in a language that they're good at and I'll send it over to them and say, "We're going to walk through this code," usually a week ahead. And I'll say, "Tell me some good things about this, tell me some bad things about this. Or let's do a code review on a pull request," or something you know. I'll do that and I give them that week. And what that allows them is the flexibility to determine how they want to continue with the process. They can spend some time looking through the code or they can do nothing at all and only look through the code with me. And I'm not saying there's anything wrong with doing nothing at all, honestly I've done that a few times when I do the code reviews I'm just like, "Well, I guess we'll just do this now." But it allows them to work in whatever framework that they're going to do the rest of their job in.
So if they have a bunch of free time in their life because they don't have a family, whatever it is, right? They're going to have more free time to look at that code and review it and make notes and that's going to be the type of work you can maybe expect from them. Whereas, maybe if they're busy and they are from a family, they'll have a lot less time to work on your code challenge, which means they'll probably have a lot less time to do extra stuff throughout the week anyway. So it's just a different type of worker and I want to know what the type of worker is, what is their availability. Not that there's anything wrong, I just want to know so I can fit them into my team. Because I don't want all 10 developers to be crazy people who only program and only do that. But I don't want all 10 developers who don't have any other free time in their life, who couldn't possibly read a manual unless I gave them time to do it.
Joel Clermont (09:26):
Sure.
Aaron Saray (09:26):
You know, I want a nice mix. So when I give them that flexibility, I can then say, "Okay. Well, not only do I get to see, during our call when they review this, what they know but I get to see kind of how much... Where they are in their life versus their career."
Joel Clermont (09:42):
I like that. Would you give them some code to review that's actually from the code base that you're hiring them to work on? Or would you find an open source project? Where would you pull that from?
Aaron Saray (09:55):
That's a great question. Absolutely an open source project that has nothing to do with what we're working on. Because I want them to know clearly it has nothing to do with any of the programmers that they're going to work with so that they can be honest.
Joel Clermont (10:08):
Okay. That's still true, I didn't think of that. .
Aaron Saray (10:10):
Because like you can't come in... I mean, it's different for us because we're consultants usually we're brought in to give people the business. But when you're trying to join a team, it can be really delicate balanced. "Do I say bad stuff about this?" Well, I don't mean bad about the programmer. Or, then you have these situations where they find stuff and maybe the programmers are like, "Yeah, we know that's there. But, boss, you won't let us fix it." You know?
Joel Clermont (10:32):
Right. And I just think it'd be even worse, like I as the interviewer, "This is my code. Okay, now review it. Give me an honest opinion." So that'd be super awkward. Okay, I like that. And even that idea of giving it to them in advance. You know, not that you're requiring them and you're not throwing homework on top of them, it's just an opportunity. Like, "Hey, if you want to spend a little more time looking at this, great. If not, we'll look at it together on the call." That's super helpful.
Aaron Saray (10:59):
Yeah. I mean, I've went through all the different processes with asking technical questions, all those different things too. And honestly that just doesn't work. You rarely spend any of your day asking someone, "Real quick, what's the parameter list of array_string_match, or printr," or whatever.
Joel Clermont (11:17):
Right, yeah.
Aaron Saray (11:18):
You spend most of your time having communication with them, reviewing code, understanding how they think. So technical stuff can be taught if someone's open and willing. You really just need the open and willing people.
Joel Clermont (11:29):
Right. And like you mentioned before, the communication style. I thought it might be funny to pick whatever the Twitter drama of the week is and have them weigh in on that. You know, I don't know if you saw that recently. There's all this discussion like, should you ever use final classes in PHP? And I'm just like, "I ignore that stuff, I don't really care." But that'd be kind of a spicy interview question.
Usually after lunch every day, I take a short walk around our little neighborhood here. It's kind of a-
Aaron Saray (12:03):
And by walk do you mean nap?
Joel Clermont (12:05):
Oh no, that would be much better. No, actually walking. And I'll even do it in the dead of winter. But anyways it's good exercise. Mentally, I think it's good to get away from the computer a little bit and just kind of reset. But the other day I was walking and I think I counted. There's about 30 houses on the route that I walk. And I just started counting and 26 of them all had something in their driveway that just for some reason it struck me as weird. And I want you to guess, I'm putting you on the spot, Aaron. What do you think that was?
Aaron Saray (12:47):
A garbage bag?
Joel Clermont (12:49):
No.
Aaron Saray (12:50):
You?
Joel Clermont (12:51):
Yes, I was standing on everybody's driveway. No.
Aaron Saray (12:55):
No, I don't know. What?
Joel Clermont (12:56):
A basketball hoop. And here's why it's weird, okay?
Aaron Saray (13:00):
How's that weird? How is good old America with a basketball hoop... how is that weird?
Joel Clermont (13:06):
We've lived in this neighborhood over 10 years now so I know pretty much who lives in every house. And I would say there's maybe, of those 30 some houses, six that have kids and I can only think of one house where I ever see anybody using the basketball hoop. And you know what? I'll include myself. We have a basketball hoop. I'm like, "Why do we have this basketball hoop? Like nobody uses it." So I was just wondering if there was some secret charter in this neighborhood. Like, when you build a house, you have to... You know, sometimes they'll have the covenants in different neighborhoods. Like you have to have a certain color of shutters and maybe here it was basketball hoops. Like, big basketball hoop is running our neighborhood, I guess.
Aaron Saray (13:47):
Shaq owns the neighborhood and was like, "I need to have something to do at every house."
Joel Clermont (13:52):
That's right.
Aaron Saray (13:53):
I mean, I don't know if that's weird. I can relate to the whole watching or looking at patterns. I used to go walking downtown when I lived down there and I'd go to one section of town, which was a bunch of row houses. And I'd walk past them and there was 14 different houses on this block all lined up. And they were maybe different colors, but they were just two different styles. One had a gable on the front and one had a flat. And it alternated starting on the beginning. So it was like gable, flat, gable, flat. Until like the last three then it was flat, flat, gable. I was like, "Oh, why do you guys do this?" Like, it would bother me even as I'm walking past and I don't know why. I'm like, "This means nothing to me." But I'm like, "Ooh, if you guys would've just planned. Oh."
Joel Clermont (14:36):
Now it bothers me too. Thanks a lot, Aaron.
Aaron Saray (14:44):
Maybe you don't want to interview someone and hire them, you just want the project done. Well, we can help.
Joel Clermont (14:50):
Head over to nocompromises.io and book a call with us.