Check out a free preview of the full Enterprise Engineering Management 102 course:
The "Interview Panel & Process" Lesson is part of the full, Enterprise Engineering Management 102 course featured in this preview video. Here's what you'd learn in this lesson:

Ryan stresses the importance of being prepared for interviews and emphasizes the need to create a panel and outline the responsibilities of each interviewer. He also discusses different types of interview exercises, such as live coding and take-home exercises, and the importance of providing a suitable coding environment for candidates. Additionally, discussed is the importance of setting expectations in job descriptions and providing additional information to recruiters and interviewers to help them understand the role better.

Get Unlimited Access Now

Transcript from the "Interview Panel & Process" Lesson

[00:00:00]
>> All right, so we have our job description people are flooding the gates. There's so many people excited to apply to your role. You need to now start being prepared to interview folks. So I call this out, is like don't take it for granted and you need to think about this.

[00:00:16] Every company is different. Some companies are very specific on like this is how we interview. At Netflix, we haven't taken that approach. It is really up to the manager to set that tone on how they want to interview. You can adapt and change it for like, I might be hiring a UI engineer.

[00:00:35] Maybe I'm hiring a back engineer, maybe I'm hiring a TPM. They're going to vary. And so I want to think about what's the most effective way, what do I need to get out of the for the role and evaluate that. So I think about that is important to think about how are you going to interview this person, what's important to evaluate.

[00:00:55] So think about creating a panel. Put together a plan. This is super helpful, do it. It's not only helpful for you to think about reflecting on what you want to evaluate. But it really helps set others up on your panel, up for success. And make sure that they're evaluating for the right things.

[00:01:16] Be explicit on that, make sure that they have that understanding. There's been so many times I've been thrown on interviews, and I'm like, what am I supposed to cover? Because nobody told me, I can ask questions. But then what if like, three other persons people ask the same question on that panel, not the greatest candidate's experience, but also that managers who's hiring just got ,didn't really get as much depth that they should on evaluating.

[00:01:43] So I like to also outline what each interview panels responsible for. Obviously, you know there might be for interviewing for engineers there's going to be technical panels so what's the technical exercise they're going through what's it evaluating? What should the engineer on my team be looking for? Those are good things to highlight.

[00:02:03] But then maybe I have someone like Jem, who's a partner team that I work with. I'm like, Jem, I want you to focus on how will this person collaborate with you and your team? Here's some types of things I want you to look for. It makes his life easier, but then I also have a better understanding that he's evaluated for that

[00:02:22]
>> What's your take on live coding exercises interviews?
>> That's a good question, I personally like to give options. So there's, you know, especially when I think of that early technical screen, some people really actually like the live one, others do not. I want to try and give people the option to like what's going to be best for them to show up.

[00:02:46] It could be a take-home exercise and that can be helpful and people will opt into that. But also, I've been in the scenario where if I'm interviewing a lot, I don't want to spend eight hours on a take-home exercise. That's a lot. And so if I've got five of those, that's a lot.

[00:03:02] But if I can jump on a call for 45 minutes to an hour and we can do something live coding, that works. I've not liked coding in a Google Doc. I've had to do that. That's daunting. I don't didn't feel good on that. I don't like it just feels out of my nature to code in a Google Doc.

[00:03:22] And also you have someone watching you just as you're typing and it's awkward. So I think thinking about those types of things is really important to. It's like what tools are you giving for someone.
>> One thing I would add, if you do do it, make sure your environment that you're having them code in is working.

[00:03:37]
>> Yes.
>> Because I had an interview where the environment wasn't working properly.
>> Yeah.
>> And that prevented me from being able to code properly.
>> Absolutely. And I think sometimes even if you use things like code pen or there's a lot of different ones that you can kind of set something up where it's at least giving them a coding environment.

[00:03:55] Give them that ahead of time to, so you can have your recruiter or yourself or someone who's getting in touch with them and is like you'll be using code pen. And like letting them know ahead of time, here's a link to it, just so that they can actually get that set up and feel comfortable.

[00:04:11] Nobody likes entering an interview or they're having technical difficulties. That sucks. It throws people off their game. And that's you want them to be set up for success. So that's a really good question. Also have alternatives for your interview panel. This is an important one too, even especially on the engineers on my team, I think about it's like I don't want to overload one person with a ton of technical interviews.

[00:04:41] And often I mean that too is like you usually have like split up where it's like technical is usually going, a lot of candidates are going to go through a technical interview, they may not make it to like a round two. But you don't want to overload one engineer.

[00:04:55] Maybe one engineer loves doing that. That's a different story and if they want to do that great, but I often like to try and have two or three engineers that are alternating, and that if recruiting setting that up, it's clear in my plan. It's like Joe, Sally and Mark are all here available.

[00:05:12] You can pick and choose by the calendar who's available. And you're trying to sequence them, so that they're not all getting bombarded with one, or one of them is getting bombarded. Jim,
>> As a still a newer manager, I'm still getting hiring. It's a lot of work.
>> Yes.

[00:05:29]
>> It's way more work than I ever expected. A mistake I made very recently was not getting my filters right. So, what I did was I sent home, I did a lot of take homes, and like take homes are great. I think they're the better experience for, for candidates, but take homes, take a lot of time to grade.

[00:05:47] And I was taking so much of my team time, like hours and hours reviewing these take homes when really I should have done. Probably like a live coding first, because that's much faster, and then do the take home. And I just didn't think about how much time was my team taking and how much time my partner is taking to review all these people.

[00:06:06] So, learn from my mistakes, get your filters right early, otherwise it's just really expensive to review like, dozens of people.
>> Yeah, I love that color but I also love you like surfacing the mistake, because you make those mistakes and you iterate and adjust and learn. I love it.

[00:06:21] Mark.
>> Hiring can be hard to fit in with the busy schedule. What percentage of your time should be spent on?
>> Yeah.
>> Hiring and recruiting.
>> It depends. I do often say, or I've said it many times, I feel like hiring is a full-time job, on top of your job.

[00:06:44] And I'm not saying that you should work double hours or anything, but it is exactly what Jem said. Is it takes up more time than you expect, and it's really important. You want to hire the right person, you want to spend that time. It is a lot of work, but it's also very rewarding.

[00:07:01] And also when you get it right, that's the good thing. It's also expensive doing all that interviewing. If you get it wrong, it happens, don't beat yourself up about it. But you have to go back to the drawing board and start over and that's, you know, that's expensive to you and the team.

[00:07:15] You might have onboarded them and then they, two, three months, they didn't work out. You're having to go back to the drawing board and that's, that's tough. I don't know how to say it, like my percentage of it. I do think about hiring, all the time. Even if I'm not hiring I do want to have some bit of like percentage of my time thinking about like even just staying in touch with people.

[00:07:39] I talk about it later on the sourcing side and networking of, I want to be of always be networking type mentality .Where you are thinking about like well what happens if someone leaves tomorrow? I want to have that pipeline of people that I'm thinking about that could be potentially good for the role.

[00:07:59] Also, they might not be ready to leave their company, and so just keeping a pulse on that can be really helpful.
>> Yeah, I put it in chat, but I just wanted to share. I had an experience not too long ago with a company called Brilliant and this outsourcing company they used to call Woven.

[00:08:16] It's by far the best candidate experience I've ever had on live coding exercises. There was a PR review that was given about 30 minutes to complete. A bug-finding exercise in a live coding environment that was given about 30 minutes to complete. And then a function coding exercise that I think was given about 60 minutes to complete.

[00:08:36] And they were all very well-scoped. They were setting clear expectations ahead of time of, like what's achievable and what's not. And also what's expected of you, like it's okay if it doesn't pass every test. These are kind of the like, good, great and excellent brackets of what achievement would look like and it was paid

[00:08:55]
>> So I just-
>> That's a good one.
>> I have considered looking into Woven for our company as well, because I was blown away with how amazing that process was. I thought it was really well all-encompassing of like what a technical exercise like what does a technical contributor do?

[00:09:12] And kind of capturing all of those different skill sets and they give great feedback also of like, here's what you did. Well, here's what we would have liked to have seen differently.
>> Man, like I love all that. I've never done the paid part too. But like when you're asking someone to spend eight hours on an exercise.

[00:09:32] That's time is valuable to all of us. Time is such an important thing. So I like that call out. And I like setting expectations. I do talk about like, how do we make a great candidate experience. That is absolutely said is like, setting expectations. Let people know and understand what they need to do to show up well.

[00:09:51] Do you want to set them up for success? You're not telling them exactly what to do, but just giving them great instructions. Goes a long way
>> Yeah this kind of goes back to the job description aspect, is there a difference or do you have to the process of how you would write your job description for a prospective employee versus the recruiter?

[00:10:11] Cause the recruiter kind of has to digest that job description and then, obviously, filter down candidates for you.
>> Yeah, that's a really good question. So even in that interview plan that I talked about, I will often have a lot more internal thinking that's maybe not in the job description, to just even help a recruiter or others like Jem being a partner team.

[00:10:33] They can read that and kind of understand some of the things. It might even be talking about upcoming projects or something on there that I don't want to necessarily blast to the whole world. Not that it's, like, bad, but it's just like, I might talk in person or have a recruiter even say like, yeah, Ryan's team, they're going to be starting to invest in this project called X, Y, and Z or whatever.

[00:10:57] And they can have a little bit of verbiage to speak to that and go, it's like, yeah, it's like. A react code base, they're leveraging TypeScript, or just giving some more insights. Might be in the job description, but they have a little bit more information. And you're helping set the recruiter up for success to be able to answer questions, or any of the partnering teams, or anyone on your interview panel.

[00:11:19] So I think, yes, thank you, good call out. Is like, that's why having that. You know, like I said, have a plan. It just helps everyone on your panel.
>> You answered.
>> Perfect. I love that when that happens. Here's an example of just like this would be a really.

[00:11:34] I actually probably even have more to a simple section, but let's say it was that collaborative partnership one. Am I tell Jim like try and get like I don't want to, I don't care if someone like Jim writes his own questions, but giving him an idea of what I'm looking for is really helpful.

[00:11:51] And so I might even have suggestions for questions but like, definitely, I don't want to be prescriptive on that. But these are things that I'm looking for that I want you to try and tease out and be able to answer in the feedback. Like, how did they do on these things?

[00:12:07] And if there's gaps that helps me. I can evaluate that if they're not the best partner, but they're not going to the park on everything else. Maybe that's okay, and that's an area that I can help coach. So that's why it's really important to try and think through this.

[00:12:20] And like what are you trying to get out of each section?