Skip to main content

Creating an Effective Developer Interview Process

Lesson 11 of 16

Knowledge Questions

Gayle Laakmann McDowell

Creating an Effective Developer Interview Process

Gayle Laakmann McDowell

Starting under

$13/month

Get access to this class +2000 more taught by the world's top experts

  • 24/7 access via desktop, mobile, or TV
  • New classes added every month
  • Download lessons for offline viewing
  • Exclusive content for subscribers

Lesson Info

11. Knowledge Questions

Lesson Info

Knowledge Questions

so I'm gonna switch gears a little bit and switching to kind of the technical stuff. And when I talk about is the knowledge questions. No questions are questions that are very particular to someone civic language or technology skills. So what, you haven't seen this and this? What does this key word mean in this language? Ah, classic test of Does someone actually have the skills that you need? And this is what? The things where Although it's not that hard in my mind, it can still go poorly a lot. A lot of companies really don't do a good job of this. So given example, a company, um, one company aware of was interviewing the whole bunch of therefore new grand rolls. They're actually seniors in college. And they were asking these candidates a punch. It was a team that was doing some database stuff. Um, it was just you know what? Not that there was exclusively databases, but you know, that Sequels one of the skills they need to know. And so they started asking these candidates to do you kn...

ow, some selects and joints and write up some code for selective joints. Andi, the problem is that doesn't actually did that really didn't do them any any good. Their argument was, Well, look, we do sequel in the job, so we need to hire people who know it, and that's actually not true. You don't need to hire somebody who knows everything. You need them to know three months and you can train people. And what was so flawed? What they're doing is they were assessing these candidates at this very cursory level. They're asking slacks and joints. Take someone who's reasonably smart. They can learn that in a week. So what they're doing is not hiring people. It's not. They're not picking people who'd be good a job. They're picking people who just so happened to have taken that data bases elective in college, which is not in of itself, a particularly useful thing. That's what. And there's this eliminating bunch of good candidates for almost no value and that that's a big mistake. So when you want to ask these questions is when you really need some skill set and when it's not something that is, you know when you need that thing, but also when you want to. There's another reason why you won't do it sometimes, which is that you want to assess that the person has the background. You should expect the so, for example, I'm hiring somebody. I don't care what language they know, as long as I know one of the major languages and whatever. That's good enough for me. However, I might argue that I want to their Java coder. So I want to test their knowledge of Java not because I need them to know Java, but because if they have been working with job before, you're too. I expect them to have a certain depth of knowledge. And if they don't have that depth knowledge, the problem is not They don't know enough about Java. The problem is they're not learning this stuff. They shouldn't death. And sometimes when they come to my company there, I don't trust him to learn these systems and death, and they're gonna take this very cursory knowledge, a national problem. So that's the other reason when you might want to assess knowledge is do they have the stuff you need them to have, well, it for the actual position. But also do they have the stuff that you should expect them to have given their background. The other reason why you might want to ask knowledge questions is to make the can it feel value. You know, it's when somebody values that their expertise in some technology or some concept, and you don't ask anything about them that can make them feel as a person not valued so something else just to think about their If you're gonna go down this road, uh, and you don't have to lots, especially with bigger with much bigger companies. And when they do much more company based hiring their thinking much for a long term. A lot of companies don't do or a lot of knowledge tests, and that's that's totally fine. But if you gonna go down this road, a couple things first is avoid quizzing. So is in an interview few months back and the candidate was asked and actually wasn't. He was actually asked a bunch of, like, data structure Malcolm questions, and it was basically a lot of what's a binary search tree. What's the right time of this? This This is this all factual questions and he actually did fine on those you know. He got one or two little bit wrong, but he actually pretty well, but it just gave this. He was just being quiz and one question after another after another. No positive enforcement and just a ton ton of them. Just not a great great experience to avoid this kind of factual cuisine. Play nice, give positive reinforcement as I've talked about a whole bunch. No, if even the can, it's not doing well when they don't do well. Some question. Act like it's totally not a big deal, even if it is given possibly enforcement. And then one of the major major things I really want to make sure that you're looking for in both your own questions and when you talk to other other interviewers is that if you're asking knowledge questions, they should be assessing it, either at a level that is actual heart actually hard to obtain. So if somebody could acquire that depth of knowledge in a week or two, you're not learning anything for them. Um, you because you are presumably willing to train some of more than a week or two at your company, so it should be assessing and no at a depth. That's hard to obtain or assessing at a depth that you know is a red flag if they don't have that. So I might not care that you know whether you know Java. But if you don't know how to write it. If you claim to know job and you can't write a class in Java, that's a that's a concern. So either no, it incessant adept that's hard to attain or that it's a red flag of you Lack that death Focus. Don't go through you. If you try to ask a 1,000, different skills, it's a there's not a good thing for you. You'll you probably don't need that money skills focus on the core things that you need, and it'll also turn off candids if you require too many different things. So focus on just a few core things questions that I do like if you gonna. If you really do think you need knowledge, I like you avoid the cuisine, questions asked. Things are more open ended thing, and you can anything into a lot more deaths. So asking like, how does this thing work in this language? Those are those are better questions to ask. It's kind of nice to ask you if a person doesn't know how it works. How do they think it works on that kind of cooks? Now, you can bring in a lot of their knowledge of technology or concept, with also a lot of their, like, your problem solving skills. How do you think it would be implanted? The other thing, you can ask that. That's kind of any question is have them just teach you some concept and, you know, and then then you actually get a lot about you're going to see a lot about how do they kind of work with other people? Because I'm to teach you some concept, Um, and you can see how deep they can go. I like these two gent generally staying to these more open ended questions. So this is a, as I said, a fairly quick kind of excites, Um, Habito open up to any questions? Yeah. Any questions here right now? If not, we've got some time to do another mock interview. If if anybody is interested in volunteering again, come on up. We leave the white board for Oh, yeah. You need the white part of here on either side. the candidate is kind of primed to not try to form of their best, necessarily. So don't judge their actual technical skills. Hi, welcome. A 1,000,000. Thank you for taking the time to talk to us today. What we want to evaluate is how it is to work with each other once, you know, once we become colleagues. So as it's a great experience for you to evaluate me as well. So let's try to solve a question I have for you. It's a It's a very, um, contained question. It's not a trick question. So what we want to do at the end of this interview is get some code written up and make sure that we saw the problem. So here's the question. Given a list of people with birth, their birth and death years, can you find the highest population in that year? So let me make sure you understand the questions. So if you wanna write up some information that can Okay, yeah. Um, so we have people and their year off birth and debt, birth and death, and I want to know what is a population. What was the highest population time like that which your population. Yes. Okay, So if this is time and then we have a bunch of berths and deaths Perfect. Uh, then we're going to get population. What was the highest population we had in which year? Uh, okay, so you said it's a list of people. Yeah. Uh, OK, so let's say that those air, um, pairs of births and deaths. Sure. Uh, okay. So for each person we want, let's let's take a step back here like, let's say we don't want to write code yet. Let's say we want to think about if we were just solving this list holders, Let's make a mark list here and then see how you would solve that just as a mental exercise. And then we'll go jump into code, if you don't mind. Okay, so we have a list of three people person, one person to person. Three. Um, and these are dates. Sure. Let's list. Let's make up some dates. So let's say we have John 1980 to 2010. Immune. Very short life spot, but and Jimmy Iss. Let's say this one's in order line like, you know, that's a 1999 and Susan and so we can make up some dates like this. So this is your leg. And ah, however, is the input. Let's do the mental exercise off solving this. And let's plan to get the pseudo code at least written for this. OK, so So maybe we could find the minimum and maximum years. So we know very good where where we want. So then So maybe instead of Iterating through the people we could iterated through the year. But I guess first, we have toe like find. Yeah, that's perfect. Perfect. So let's let's do this exercise for us. Like, how are we going to go through this list? This is great. You're doing great. Okay, so we start with the minimum year and we then go through all of the people. And we say, Was that person alive or dead in the year? So then for each year and Teoh to figure out if they're alive or dead, we need to write a function that, uh, well is alive and a person and a year so great. That's that's actually good thought is alive. So what are we planning to do with that information? Where do we How do we wanna think off. That s so let's still go through this in this. In this scenario, how would this like? How would we find the population for this list? If you will s So we have our maybe a map of years map. Great. And so let's let's keep that's That's a good good point. So, a map, What are we putting in that map? So it's gonna be a map from year to, uh, number of people. And so, as we go through each year, from the minimum to the maximum, we go through each person and check if they're alive and increment the number in the map, and then we can go through the map and find the maximum. Okay? And what about the debt? So we still need to handle if they're dead. Also, if I think if they're dead, not alive do you want to declaim in the map? Uh, well, that beer, like the next year onwards. So maybe, uh, the years are we do it for every year and is alive will tell us if that person was alive in the air, which will also mean that they haven't died before that year. Okay, so have your technical skills up there again. They were She was told to mess up. So employers, 10 years unearthing this. Don't don't joke about that. So a couple things happened here. One is that she was you almost off the bat. She's hard to try to start coding right, and that's this is a really common mistake as he can. It's make and I you know, I sit there and I coach them. I tell them, Don't code unless you're short right? But all the bad she went and she was do this intentionally to kind of screw up. But off the back, she tried to open starts, hurt start coding, and that can make candidates waste a ton of time and then I'll see interfere with walk away and be like, Yeah, they never wrote the optimal solution. Well, you didn't give him a chance to. And so I really like that. He stopped her and said, you know, pulled her back right and said, Well, let's let's go through the problem. Uh, and then she's hard to start writing example, and it was very bake, and he pushed her side. Let's let's go. Something more concrete, and he actually came up with one for her. And that's actually nice thing to do. You know, I don't think I have to do that off the bat. Um, you mean to say, Here's the problem Here is an example. But if the candidates struggling, But, you know, I don't think it really tells you much about their, you know, intelligence to see what they come up with, a concrete example or not. That's much more about you know how to behave effectively an interview. So if that's not giving you a good signal, whether they come up with effective example or not, help him out. Do it for them. Coach them through the problem. A lot of the stuff that my perspective on interviewing comes from being able to coach people over and over again, saying like, you know them writing p one p two p three as an example. Rather 1980 to 2005. That doesn't tell me anything about the problem solving skills that just tells me that they know how to act better. So given that coaching, and that was really great, um, one thing I always want to care for an interview is striking this balance with giving them hints and jumping in too much and interrupting their thought process. And so and it's a hard balance to strike and inquire, sort of reading the candle little bit. Um, did you feel nervous up there? Yeah. Um, yeah. And like, it could be hard when you're thought processes getting interrupted. So just be aware of that that you do want to give the candidate assistance and help. But if the thought process getting interrupted, that can actually make them stumble and have a harder time solving the problem. But he did a great job with giving a lot of positive reinforcement and giving that reassurances that she's doing well. I think there was, at the end my impression because I think there's a slight misunderstanding where you are explaining one algorithm, you're thinking something else, which which happens a lot, Um, and so it's like giving this hint that actually wasn't not was not actually to her album and very, very easy issued happened. That's why it's really useful to kind of let the candidate if there's a miscommunication like that, take a step back and look at the candidate. Explain things from scratch. But that was give us the great kind of lead into the next section, which is actually going through in a lot of detail, talking about kind of core of technical interviews, which is the coding and Albert and stuff.

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.