This is the one thing I wish I could teach interviewers about interviewing – Gayle Laakmann McDowellFeatured

Gayle·May 07, 2019·9 replies

Signal. Signal, signal, signal. This is what all interviewing, of all types, ever, is about. Signal refers to what you’ve learned about a candidate and what that indicates about their potential job performance. Instead, what many interviewers look at is whether the candidate gave a “good” answer. Let me explain the difference. Scenario A: You ask Alex a problem solving question. Alex develops a solution which is good enough for the real world, but he/she is unable to develop a better solution. Would you hire Alex? Many interviewers say “yes”, because their solution was good enough for the real world. But that’s actually irrelevant. When you’re hiring, you’re trying to predict who will be good on the job. If Alex’s inability to get to the better solution reflects poor problem solving skills, then that is what matters. The *signal* is weak problem solving skills. Scenario B: In your cultural values interview with Bailey, it becomes clear that Bailey’s decision-making prioritized money over the customer experience. This directly conflicts with your company’s primary cultural value: “put the customer first.” Is this a no-hire? Not necessarily. It’s true that Bailey acted in a way that is inappropriate at your company. But the question is: Why did Bailey do this? What are you actually learning about Bailey? If Bailey’s company prioritized money over the customer experience, then it’s quite reasonable that Bailey acted in this way. In fact, I would be concerned if Bailey *did* put the customer first, as this shows a refusal to operate according to company values. So what Bailey did was a “bad” thing (by your company’s standards), but the *signal* is: “Bailey understands and operates according to Bailey’s company values.” That’s a good thing. This signal piece also has significant implications on what makes a good interview question. Many interviewers want their interview question to be “like stuff you do in the real world.” It’s not harmful to have realistic questions, but that’s not the primary metric either. The primary metric is whether the question is predictive about job performance. Does it show good signal? Suppose you’re interviewing new grad candidates for a software engineering job that uses Java and a bit of SQL. What kind of SQL questions would you ask? Most interviewers go with questions about SELECT, JOIN, etc. Sure, that’s stuff you do in the real world. It’s also stuff that a reasonable software engineer could learn in a few days. Knowledge about this topic isn’t predictive of job performance, despite how “real world” it is. What this means is that, generally speaking (there are some exceptions — I can get into those in the comments), an interviewer should never require “basic knowledge” of a topic. Either you want real expertise, or you shouldn’t care about it at all. So, signal. THAT is what all interviewing is about. Oh, and the candidate experience too. You need to treat candidates with respect and transparency. If a candidate doesn’t like their experience or the people they met with, they’re going to decline your offer *and* tell their friends (or strangers online) to not interview with you.Gayle Laakmann McDowell is the founder/CEO of CareerCup.com and the author of the best-selling Cracking the *interview books (Cracking the Coding Interview, Cracking the PM Interview, and Cracking the Tech Career). She consults with large and small companies on their engineering hiring process and teaches interviewer training workshops to improve hiring effectiveness. She previously worked as a software engineer at Google, Microsoft, and Apple. She can be found online at twitter.com/gayle, facebook.com/gayle, and gayle.com.

whitneycaneel·May 07, 2019
whitneycaneel·May 07, 2019
I loved reading this, thanks so much for sharing! This resonated with me, "Knowledge about this topic isn’t predictive of job performance, despite how “real world” it is". This rings so true. The traditional interview process needs to be disrupted and this is a great gateway to facilitating that change!

Miriam
Miriam·May 07, 2019·1 reply
Miriam
Miriam·May 07, 2019·1 reply
@gayle I was name-dropping you last week when I was talking to comp sci current students at UT-Austin :) I told them you were my classmate at Wharton and I wish I had your book when I was interviewing for CS jobs out of college. I told them they are so lucky to have access to so many great resources which didn't exist in my time.

cadran·May 07, 2019
cadran·May 07, 2019
doubling down here as a fan girl. I've said it before, but Cracking the Coding Interview was a game changer for me learning how to do white boarding interviews. Very excited to have your insights here on hiring, Gayle :)

ara206·May 08, 2019·1 reply
ara206·May 08, 2019·1 reply
"an interviewer should never require 'basic knowledge' of a topic." Never thought about this but it makes so much sense! Why would you want to interview someone in a way that only shows they were able to learn a couple day's worth of knowledge on a random topic?

Gayle·May 08, 2019
Gayle·May 08, 2019
Right?? It's so intuitive to people when you explain it, but they often don't realize this beforehand.(Now, there is an exception -- which is when it's a red flag that the person doesn't know something basic, based on their background. For example, a doctor who doesn't know how to apply a bandaid. But in that case, it's still not that you need basic knowledge. It's that the lack of basic knowledge signifies an issue with their general ability to understand topics.)

sgovindgari·May 08, 2019
sgovindgari·May 08, 2019
This was a very insightful post, Gayle. I wish more interviewers actively researched on interviewing techniques and improved their skill to look for signals in a candidate. And this comes with practice. I feel like at our current jobs as engineers we have to play so many roles that interviewing becomes an afterthought, something we are also not measured against in our performance reviews. I would love to chat with you more about how we could help interviewers become better at interviewing. Maybe a new book is underway?

atomasik·May 11, 2019
atomasik·May 11, 2019
Thank you for this! It's surprisingly intuitive when you describe it that way. I will be interviewing apprentice candidates next week and am excited to be able to put this in to practice.

jessziyuezhang·May 24, 2019·1 reply
jessziyuezhang·May 24, 2019·1 reply
Gayle this is super helpful! Great read. I'm actually struggling with this precise question at work at the moment - I'm redesigning the interview process, for data scientists.What I struggle with is how you judge whether a skill is a signal. Specifically:1. if an experienced hire cannot write simple SQL queries, that seems to be a strong signal that they didn't do well in their previous role, and would impact their ability to have an impact in their future role. However, this is also a basic skill. 2. The second set of "basic skills" are things specifically related to statistics. If someone trained in statistics cannot answer simple technical questions, this is also a red flag. Again, this is also a basic skill. What's your general advice on testing things like "can I doctor put on a bandaid"? When are these tests necessary and when are they not? How would you balance the interview day or pre-interview screenings?Thanks!

Gayle·May 24, 2019
Gayle·May 24, 2019
I think you can separate these things. Whether you need SQL on the job or not, it's reasonable to expect that someone well versed in SQL should in fact be able to do basic queries. That is, you could reject Person A from a job due to their poor understanding of SQL -- and hire Person B who has no knowledge of SQL at all. Person A *should* know SQL, but they don't, and that's a red flag. Person B doesn't know SQL, and that's fine, because you don't need SQL (or only need a basic level that's easily teachable).So that goes for SQL queries, possibly simple technical questions, etc. Whether it's needed for the job is a somewhat separate question.That said, in many cases, you don't need to design specific tests to do that. You can ask questions that are more challenging and in the process reveal if there are major red flags.