Skip to main content

Creating an Effective Developer Interview Process

Lesson 16 of 16

Go Forth and Hire!

 

Creating an Effective Developer Interview Process

Lesson 16 of 16

Go Forth and Hire!

 

Lesson Info

Go Forth and Hire!

So we talked today about a of all the different steps of production, all these different steps of the interview process. So you know, you're very standard plug in called Broken Play Process is candid jobs in a resume or they get referred and then someone pulls out the resume Recruiter calls them, hopefully gives a a practical and gives an email advanced saying here, the things we're going talk about today. Recruiter gives McCall Talks them, get some hopefully excited, maybe asks a little bit of questions about their experience on the background, and then recruiter falls ups with another email. This is where you really want to lay out the process for how you know what the flow the day will be like. Or the flow of the interview process gives them idea of timelines. Ieave Wonder. Often I find some workers are great about this. Others don't give this information, and it's really not. Usually not. Recruiters faults, usually the company not doing this, and I have a strong suspicion that a lo...

t of why companies don't give this information about here's how long our process takes. Here's the kinds of things to expect is that they actually haven't figured it out. Ah, and that's really that's really hold up there. So if you don't have this information about what kinds of questions you were gonna be, interviews are asking and will to be, And two coding and one design. Will it be pair programming? That's probably you. Probably to figure that out and then put together this document and it could be really efficient document. Spend it, you know, a couple days team of people putting this together, and now you have something that could be given to everybody rather than being hugely variable. Which recruiter happens your cannons have been talking to? So you go to this planning prop you go, maybe get a code assessment, a homework project, um, then a phone interview or maybe the alternate order. Maybe they get a fall a phone interview if they have more concerns. And then on Sayed couple interviews, hiring decision, and then hopefully an offer. Which case? Now you are selling them. So we talked about a bunch of aspects of this. You remember that you need to align expectations. You need to figure out what your company is doing, what they should be doing get every on the same page and then make sure your Candace are on the same page. And those are things that you know. How many interviews who will be interviewing what kind of roles, How long with this process take, you should have figured this out and then make sure that information is communicated to candidates. You offline work is okay. You can have some. Uh, I think Odin assessments like Hacker, and I think those are great, um, big homework projects, you know, they just are you being 30 candidates and that's that's what we want. You want you to really think about it. Is it fair to How long are your home or projects taking? If the cancer spending 10 hours to do your project and you're gonna look it for 15 minutes, you know, that's that's a little bit unfair, and it creates his abuse situation because, hey, that can only taking 15 minutes to interview this person. And now you're sending out this homework project a whole bunch of people Maybe you're not that serious about, and that I just feel like it's a little unfair to candidates and canned its catch on to this and they can often get frustrated by these really large projects. And if you are giving homer projects and you can't tell me how much time it's actually taking people, that's data you need to start collecting. Uh, but you know, again, it's okay to do some of this just limited. And that's why I like code assessments a little better, Uh, actually efficient for you. And it's time it's time bound where it's not gonna take somebody five hours because you're setting a max of two hours but interviews nothing to different need to do. And Candice should know that, uh, just don't make the bar really, really low. But it should be basically the same kind of things you see on site, uh, again, as I said earlier, just no fancy diagrams. Um, Johnson interview. People should have roles. They should know that role. Ideally, people should be trained in that specific function. So So I'm going to have great hiring great trading process where not only do people go through interview training, you know it's engineering specific, but they actually go specific training on Here's how you do design questions. Well, here's how you do coding, coding album questions well, and people opt in to doing one or another type, and they get trained and certified in that exact process. Eso people should should clearly know another rolls. Get people through fast on the on site interviews, try to turn on your decisions as fast as possible. Good thing, obviously for the candidate and of course, for you. Because if you're taking a week or two, you know to return that offer, you're gonna be losing candidates. So get people through the door quickly and parlous. Also picking out people's resumes pretty quickly and trying to not let them sit in the pile forever. Ah, a lot of times people companies have processes that are relatively efficient. But you took you two weeks to actually get through that resume pile, and they're already at on site interviews with another company and about to get an offer. Be nice to Candace if you have to make that list of positive reappearing comments. It's cheesy, but anything you can say that's positively sure can. It's like that. That does not mean telling a candid how they perform does not mean telling them you did well. I don't actually suggest interviewers do that just means an individual point saying Good point, Good observation. Things like that, uh, do ask questions that challenge them eso But it's challenging from a conceptual level, not challenging us faras. They have to have a lot of obscure knowledge, so people should be able to do well in your process without having a CS degree. If you expect to see s degree, you're not just ruling out the people without CS. If you people have have CS degrees to be able to really do your go to your process, you're not just ruling out the people without CS degrees. You're ruling out people who don't have this really deep knowledge of an album's textbook. So not not a great thing. Eso hard questions, yes, but not hard knowledge. And really make sure that people are thinking if you look at your interview feedback from both your own interviews as well as other interviewers, and ask yourself, Did this question challenge the candidate? If you see problems that are not challenging candidates where the best can't best Canada, the good ones can get an optional answer. State the optimal answer in a minute or so of thinking probably too easy, and you probably to make it make a bit more challenging. UH, feedback. No centrally company, No discussion before something written has been has been taking down. I'm sensitive to the fact that written feedback takes a long time if it's thorough, but it does not take long when you throw yourself in a room for every jot down a number. Better there a written feedback before there's even better. But that does not you ever do that? So set a rule. No written feedback before discussion. Now one pushback will get on. This is. But what if I need my interviewers? What what if there's feedback? I want to push my another interview like that. You need to ask more questions about that. There's a trade off here, you know, When I was at Google, we we had a very firm feedback. Very firm rules absolutely fall with my office within my office, which is absolutely no feedback, a green interviewers. But we had this feedback. We had this form that went from one interview to the next. Where we just listed are questions, not feedback in any way. We only listed what we asked now, realistically, when I see the person has gotten when if I see that someone got two different questions and last interview in both kind of challenging I know they're doing well. So yes, it will happen, right? I'm gonna I'm collecting feedback. Even though that wasn't the intention. Just try to avoid as much as you can. Uh, if you have to give some instruction to the next interviewer and you know in that ends up inadvertently giving feedback OK, And that might mean things like, No, I didn't get a chance. We spend a long time algorithms. I didn't get a chance to ask coating that might give someone some signal that they struggled with algorithms. But I don't I can still avoid saying they struggled to album, so never got coating listening Biggest way. Maybe it's that we had such a great album discussion that we never got to that. Just try to limit the feedback as much as possible. Uh, hierarchies are great there. You know that they're great if you can pull them off. But they are also a very heavy weight solution that is difficult for difficult, impractical from majority of companies. Better you know better attorney lives. Bar raisers offers a lot of the same benefits as a lot easier to pull off out is a lot of the same debt. Ah, lot of same, you know, harms about hard. Me, uh, so do have information can. But bar raises is a really great alternative that doesn't go quite as extreme with the benefits, but avoids a lot of the cost of hiring committees as well. Okay, so you're just one person, Unfortunately, um, and I wish I could teach ever on your team about, you know, doing all the seven blessings, right? And one thing that's really important is having interviewers who know what they're doing. Go teach everybody else on. Which is why I, like the bar racers, is that their role is actually to instruct and teach the rest of people. But now you guys can all be ambassadors, and you can start teaching people about looking over that question saying, You know, I don't think that was really challenging. I think you are really just getting at. How did the person here? The question before Andi people can do poorly is just cause they got this 11 little thing you said or this question. Actually, I think maybe you're saying that people were just getting people intimidated by the question. And that's why they're doing poorly. S o. B. There to educate people about the questions and look through that question database. Make sure your questions. Actually, the solutions are correct. Uh, actually have away your question databases set up in a way that people can give feedback easily. That says, this actually isn't right. Um, create a training process. And a lot of companies don't really have engineering specific interview, press, interview, train process. And that's really, really important. Make sure you have an interview training process. Shadowing is a very standard part of that's very standard interview training is you have half day whatever work shopping technical questions on. And then people do a shadow in a mutual shadow overshadow. So you shadow that newly trained interviewer shadows more experience one. Then they swift switching amore experience person shadows, the new one very standard Great thing to Dio. I actually I haven't seen a lot of companies do this, but I really encourage them to make this a more continuous thing. The way shadowing processor set up right now is you shadow somebody when your brand new when you shatter some of that experience and that's great. And then when you have a lot of experience, you shadow people. No experience. It's actually a lot of value in having interviewers learn, like watch an experienced interviewer and experience interviews don't really get the chance to do that. They only watch in experience once. Have a process where people I don't want regular two on one interviews. I think that's a waste of time. But let interviews encourage interviewers who are more experience to sit and watch somebody else's interview because you'll get a much deeper perspective about different styles. And if it ways of handling issues when you're actually watching somebody else's experienced when you already have that context, so have this training be a continuous thing and not a one time shadowing. Then you're done. Use your interview Advocates bought bar raisers to spread these lessons. That's a great thing. It's really, really useful and be really self critical. Realized that look album interviews are great. They're also flawed coding interviews. A great they're also flawed. Whiteboards Great. They're also flawed. Pair programming is great but also flood. So be very aware of the weaknesses whenever process, you're at your using and when you can try to mitigate it. But I don't think you have to toss out of process because it has some flaw or you'll never really be able to interview people.

Class Description


In this workshop led by Gayle Laakmann McDowell, former Google software engineer, interviewer and the author of the bestselling book Cracking the Coding Interview, you'll be hands-on, covering all the specifics you'll need to know about coding interviews. It will start with an overview of the hiring process and dive into more detail about types of interview questions (behavioral, knowledge, algorithms/coding, and design). You will learn how to create a hiring process that is efficient, sets a high and consistent bar, and attracts strong candidates.

Although sections of the workshop will be highly technical, non-technical people are encouraged to attend. You will learn:

  • Differences between assessing senior candidates and junior candidates
  • The goals and limitations of technology-specific questions
  • Selecting and asking appropriate algorithm questions
  • Mechanisms to evaluate coding skills, including whiteboards, laptops and code assessment tools
This class is your comprehensive guide to hiring the right developer for your company. 

In Partnership with Greylock Partners 


Reviews

Megan
 

What an awesome opportunity to learn from one of the best on the topic! This course has value for anyone who's looking to hire or work with technical talent! I've attended tons of talent conferences and this course succinctly and tactically address how to effectively interview engineers. Highly recommended.

Kevin Scott
 

Terrific class with unique eye opening content. This class applies for any Dev. hiring team, whether startups or large, established companies. I recommend this training tool to anyone wanting to help others improve their own interviewing skill set and build dynamic hiring processes / plans.

Ellen
 

This class was exactly as billed - I received in depth knowledge of how to create great developer interviews. Gayle was very organized and presented her info in a dynamic, inter-active environment. It was really great to be part of the studio audience.