Skip to main content

Creating an Effective Developer Interview Process

Lesson 15 of 16

Design Questions

 

Creating an Effective Developer Interview Process

Lesson 15 of 16

Design Questions

 

Lesson Info

Design Questions

So Zion questions are a great way of showing senior candidates and your lessons. Cancer. It's not all about you smartness. And can you develop the greatest algorithm? And also, you know, that's not all there is to being an engineer also like. Okay, well, how do you actually, Can you build something from scratch? Can you think kind of big picture about the kind of work that you do is a softer engineer, right? That's not always the little things you tested. 30 minutes. Can you think Big picture? It's a design. Questions are a great way of assessing you. Yes, there still problem solving exercises for their different. They're much more open ended. So can you take something from start to end? So gets a little bit like the technical leadership side as well, and that's great to see. It also looks at you know, a great way of looking at communication and teamwork, sort of skills that that that sort of thing and and one thing that's really nice to do it. One of the reactions that senior accounta...

nts have or experience counts have is when they go through the coding and our them stuff and all the stuff that you know they could have done. Justus. Well, a better with very little experience is they feel like they are not valued and that you didn't really care about the fact that they've been spending all this time building some really, really cool stuff and so more open in a design. Problems are something you can absolutely give to fresh grads as well. But they do a nice job of showing senior candidates that you really respect all that expertise. They bring it. And so even even if in some strange reason you didn't care about for some strange reason didn't actually about the performance, it's still value value, adding that sets and that shows that you respect them. Um, so with senior candidates, this is you foreseen accounts with the coding and Malcolm stuff. Pretty with albums. I wouldn't set a higher standard for them. I wouldn't have said it much lower standard, but albums. I'd say, you know, senior cans of fresh Brad around the same performance expectations in that a fresh grad? Yes, they have more algorithm. They've Dunmore album stuff. More recently, they've taken albums, classes. May isn't maybe, but they one part of doing better and interview questions is, you've just seen a lot more problems before, and you haven't seen that problem before. But you can start pattern matching more quickly, and you can do that more easily when you get more experience. So I don't expect senior cans to better and album questions. But nor do I expect investor lady work worse design questions, though. That's where you will kind of raise expectations first. You know, accounted eso both shows them that you value their experience and also starts to really assess that. So some downsides them. Some things we aware of is people, for better or worse thing, get this album thing basically, um, this when it comes designed questions, they are kind of unexpected. A lot people don't really know. How do they handle it? When I talk to Candace about interview prep, probably the most common questions I get are actually around the designs. Uh, they just they just don't know where to go from there. So there been unexpected for people. You have to be aware of insider knowledge here so it can be great. Teoh this value. You know there's pros and cons of any different approach and, you know, hope. That's one thing you've taken. You take away today that there are pros and constant these different things on the pair. Program heads benefits album interviews have their benefits. Whiteboard coating has benefits. There's also trade offs of all of these things, and one that's nice doing design interviews is you can pick questions that are kind of relevant to what your company does, so you can show them, you know, one these air, relevant questions. But to that, this is the kind of stuff you'd work on here. The problem with one kind downside of doing that. I'm not saying don't do understand. Be aware of this is that sometimes there could be in inadvertently insider knowledge. So a candidate might you been face one of two decisions a candidate might make a decision that is sub optimal, given your knowledge about that problem, given that you know, for example, that rights are a lot more a lot more common than reads. That was a bad decision, but they send their knowledge they actually made the right decision. So you really want to look at unless you care? Do they know about rights versus reads and the frequency of that for your company, which may be Mattis maybe doesn't Were you really wanna look as did they make the right decisions given their knowledge, not given your knowledge. So that's what you want to be aware of when you start asking questions that are more relevant. Where you have deeper expertise in them is that you might inadvertently end up biasing it because you have some insider knowledge. So just be aware of that, Uh, you want to when you're doing these questions, encourage cans to derive the problem. You're not gonna get as good of a signal with these problems. If you take over, too much is interfering. Do you really want to try to encourage them? T really show their thought? Process and show show that technical leadership, which is hard. Some cannons aren't like that. Some cancer going to struggle to really get that they should lead the process, so you know you can coach them a bit more. And this is also someplace where inner recruiters really need to be in sync with the rest. The interview process and you can give have make sure you recruiters are giving that advice how he can't stay, get designed interviews. Here's the kinds of things were looking for. We really encourage you to to be the one driving through the process. So give that kind of coaching on. And then beyond that coach canceling things as you're asking question. Encourage them, Teoh. One thing interviewers often look at these questions is, well, did the candidate just kind of make a bunch of assumptions? Or did they ask me a lot of problems at questions to clarify the problem? It might say something that the candidate ask you questions or that. Okay, that's somewhat relevant. The real world, right? Very relevant. Arguably. Does the candidate make assumption? Doesn't employees make assumptions about the problem, or do they make sure they clarify the requirements? That's that's useful data, no data to how about the candidate? But given that somebody didn't ask that question, asked a lot of questions to clarify. Maybe that's just that they didn't realize that that's a good thing that I kind of thought it was. Their problem figured out. Who knows? Maybe you can coach them, do that. They didn't ask questions, initially stopped and say, Hey, just F y I, you couldn't ask me clarifying questions. You want courage them to driving a coach them in all these different ways. If they start taking a deep dive into one thing that kind of going off in some little hole, maybe Kurds and just take a step back. So make sure you're really you know, this comes back to it's on you to get the information you want. You know, picture you're coaching Kansas dude through the problems and helping them do the best that they can. So some stuff that causes some false kind of positive or false negatives. Um, one thing here is when you have problems that require a reasonable knowledge, so you ask back and design questions. People are who are not back and engineers, and you're gonna end up requiring Expect the second knowledge that if you needed that back and experience, you probably shouldn't have interviewed the person the first place or you require them. Teoh. Even things like I've seen Canada to get asked questions like design a chess game and that's all well and good if you were interviewed somebody who happens to know chest. But if the person doesn't this explaining them The basic rules is not going to cut it. It's You might think that well, you you take something even more simple. Checkers, you might think, Well, it's fine. You know, I could just explain to them how checkers works. Yeah, but it still helps a lot if you really, really understand the game versus you are figuring out how this works on the fly. So be careful about what kind of knowledge your questions are expecting. And also, if you just want to be aware from a diversity perspective, that if you start asking questions that along certain lines Ah, you know a lot of question video games. You talk to a woman very recently who was asked, designed question. It was like design Super Mario brothers and she never played that before. And the interview was like, Oh, well, this is This house worked and she felt a little bit unfairly discriminated against, cause she's like, Look, I don't play Super Mario brothers. You don't care if I play this game now, I'm at a disadvantage, and frankly, women might be disproportionately likely to face a disadvantage. So be careful with what kinds of questions you're asking, uh, And then you can It's don't know often kind of flow if how to go through these problems. So they don't know, you know, that they can ask questions. They think that when you ask them, how did how you design, uh, Gmail, that you're literally asked them? How does Gmail working there like, I don't know, Matt produce. So they don't know that this is very much about the process. And they think that you're testing knowledge even if you're not, uh, so I really you know, this is a place where I think design interviews are great. You can ask them, you back in question, back in design questions like front and architecture, whatever it is pending the person's background. But when you go down this road, these are harder, much like kind of the pair programming stuff. These are harder problems to ask. They acquire a little bit more skill and asking. Then make sure your interviewers are well trained here, uh, and make sure that your cabinets are expecting these questions and they know the basic thing. This is this is where would be a really great idea for a group of engineers at your company to put together document about. Here's what are designed. Questions are like Here's some specific examples. A lot, Hence companies will say, Oh, we tend, you know, we front end questions can be architecture questions and and they use these very, very broad things like it's really helpful if you just say Here's through example questions that we've asked in the past, but we don't ask anymore. Give me, give me really good feel and create that document. And then everybody's on much more, even playing field. When you evaluate this, what you're looking at is thinking problems. All the skills that gut feel. If did it feel like they made good decisions, were they able to balance tradeoffs? I'm less concerned in a lot of ways about know how deep their knowledge is. I think that's useful, but I want to see Are they able to learn new things? So an example is interviewed. Somebody who you asked me back in question and he had no idea that he'd never done back and work early before. And he had no idea that doing joins on a large database was probably not a good idea. It just it just never you connecting them then know that he didn't never thought about that problem. But what I liked about this was he didn't know that. And then I said, Let's rethink this thing I was able to think about how would joins work, was able to realize on his own that that's a really bad idea. I was able to fix that problem, and then when a similar situation came up, he's able to fix. He was able to not to do that, even the first place. That is cool, right? Yeah, he didn't know this knowledge, but Hughes demonstrates the things that I want to see, which is that he's able to think in a big system. You, for the case of a back and engineer is able to think in a big system kind of way. I was able to learn new things that that's that he actually showed very strong skills, even though he's missing this knowledge. That said, if he were back an engineer and I expect that, you know and he's worked a lot with your large data sets, I might be a little more concerned that he didn't have this, so it's not just you. It sometimes it's Do they have the knowledge and youth and 1/2? But also your Do they have the knowledge? I would expect them back, uh, separate knowledge from attributes to separate someone's you knowledge of things like, Do they know this thing from Can they learn this setting? You adjust your expectations based on the amount of experience they have, uh, and also make sure it's really relevant to base amount of spirits they have with that thing. So sometimes with that focus area. So sometimes companies will say, Oh, this person is a back an engineer and they've 10 years of experience, Yes, but they don't have any experience in back end. The 1st 8 years was on front end, so you can't quite say that's equipment to 10 in 10 years of back and experience. So make sure that your expectations are well of our relative to their actual expertise on Ben makes you look at how they respond to feedback One of their ways. This was quiz that these questions valuable is that it's a back and forth thing. This is something where you need interviewers who are really well trained to do this and can deliver feedback, not telling a candidate you're not doing well in this area. But voicing a concern and seeing how the candid, what was once that if I interview somebody and I raise some concern and I've seen this happen a lot where I raised some concern with them about the design and they it's almost like they have this attitude that if one my questions and gets through and I'm right about this thing is a concern will be minus five points and they're not focused on getting a great sistemas Muchas like scoring the highest number points. And they're very defensive and dismissive. And that this kind of thing where that is great data for me to have on. I'm thinking maybe this isn't the person I want to hire. S o. I want to look at how do they respond to feedback That does not give me a license to be negative towards them in any way whatsoever because they're also evaluating me. But I do want to see do that. Can they take some concerns? I raise and really run with them, uh, and create something better from that feedback or they more concerned about defending themselves. Uh, and then is that you? Expectation. Or you can ask you so, fresh grads. Someone does not have to have experience, you know, particularly talking about, like a back end system designed kind of stuff. Someone does not have to have experience with that. To do it, you can ask a fresh grad, a college student that you need to do some system architecture, that your expectations need to be very, very different again. We should, especially someone has very little experience. What you're going to be evaluating is really their problem solving skills. So based on the knowledge that they have, can they put together this piece of knowledge to create a great system and they figure out how things might work. And don't worry so much about whether whether or not this person has read this paper is there that paper

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.