5 ms·

I ask this question from time to time and look for different responses depending on the type of candidate. When I ask an engineer, I am looking to see if they c

I ask this question from time to time and look for different responses depending on the type of candidate. When I ask an engineer, I am looking to see if they can grasp the problem space and ask clarifying questions about what I'm looking for. When I'm interviewing for an engineering manager I am looking to see if they can grasp the problem space and ask clarifying questions about what I'm looking for. Since I tend to work on technical products, when I interview a product manager I tend to look for... So much of the engineering mindset jumps to solutions instead of clarifying problems. I'm guilty of this constantly.

MichaelMoser123 6y ago
What is more important to you - the clarifying questions of the candidate or the actual answer?
TurkishPoptart 6y ago
Can you clarify as to what kinds of clarifying questions you're looking for? Not trying to be ironic here, just need help with interviewing.
- rendaw 6y ago
  For example, what does "load" mean? Type it into a browser url bar and press enter? Or just what happens when you press enter (excluding the typing)? Via curl? Or does load refer to just a single HTTP request?
- colinrand 6y ago
  Certainly. I like to have the candidate ask follow ups like, are you interested in the networking aspects? the brower's behaviors? the way the website handles the request? all of these above? If I phrased the question slightly differently, engineers would have a very different reaction. Q: Can you write a test for me that demonstrates I can load a URL successfully? That could drive the engineer down a different mode of thought. Business stakeholders won't ask for a requirement to implement a test, and the engineer needs to translate the business request into an engineering solution. From what I've seen, different levels of experience in engineer will have different responses and illustrate for me where they are in the engineering journey. A young engineer, perhaps a new college grad or intern, will tend to react to this with a very open mind and lean on their recent academic background, showing excitement with the question and identifying the challenges in it. They usually do pretty well. The mid career programmer often stumbles. They want to show the expertise so latch on to the part of the problem they are most familiar with do show technical prowess. They can often lose the forest for the trees. The senior engineer, will want to know why you're asking and what you're trying to accomplish. Perhaps I'm looking to optimize one part of the problem, perhaps make a step more resilient, more extensible, etc. They will want to know why this question is important for the problems at hand, and hopefully they'll ask about that directly! Hope this gives some insight for you.
  - fancyfish 6y ago
    This is great. It's critical to bucket engineers into levels with a checklist like this. Are they eager to explore every corner of the problem, from networking to the browser backend. But not in too great detail - not focusing on one topic too much. But you also don't want them talking too much - a great engineer asks questions as much as provides answers.
deleted 6y ago
[deleted]
mjw1007 6y ago
The trouble with doing this in an artificial situation like an interview is that you're leaving the candidate to guess your purpose. If they correctly guess that what you mean is "please engage in a simulation of a planning conversation, based on this arbitrary prompt", they'll do well. But if they guess that you mean "please use this arbitrary prompt as an opportunity to demonstrate the depth of your technical knowledge", they'll do poorly (they're unlikely to ask clarifying questions, because that would look the same as stalling to disguise the shallowness of their knowledge).
- Karunamon 6y ago
  Believe it or not, the last couple interviews I did, I just came out and asked for, and got, this level of clarification as to what they wanted here. Some companies solve their problems differently, value different characteristics, and so run their interviews differently, and in my (admittedly limited) experience, it's not a faux pas to ask. A few employers ago, giving a "best guess" rather than admitting you don't know the answer to a question was an instant no-hire. They wanted to be sure that you were sure when you put an idea out there without qualification, and so it was with the day-to-day SRE-ish work where short outages caused by speculative changes that weren't fully understood were wildly expensive events. At my most recent one, I was actually encouraged to speculate if I didn't know the answer to a tech question, or was asked why I answered what I did if the answer was wrong; they were more interested in my thought process than the end result, even if the end result wasn't technically correct.
  - fractionalhare 6y ago
    I might be nitpicking, but this: > A few employers ago, giving a "best guess" rather than admitting you don't know the answer to a question was an instant no-hire. and this: > At my most recent one, I was actually encouraged to speculate if I didn't know the answer to a tech question aren't incongruous to me. In my interviews, I lay out two explicit expectations for the candidate upfront: 1. Please don't bullshit an answer. Confidently incorrect is considered a red flag. 2. The interview is designed to find the ceiling on your certainty and knowledge, and to see how you deal with ambiguity thereafter. I encourage candidates to guess; I just want them to make it very explicit when they're guessing, and demonstrate self-awareness in doing so. As ever, a lot of interview problems on both sides of the table are resolved with more communication. It is good to set explicit expectations for candidates throughout the process, and to revisit particular expectations in the first two to three minutes of an interview.
tptacek 6y ago
If you're guilty of something constantly that generates poor results in interviews, why on Earth are you using it as part of your interview screen? I agree: this is a pessimizing question. What's the point of a process that sets candidates up to fail? You can do the opposite thing: set a high bar, and then have a process that does everything it can to set candidates up to succeed.
the_arun 6y ago
Also in the interview - you expect the interviewee to answer what you are expecting them to answer - instead of acknowledging/accepting their point of view. Are these expectations playing any role in your observations?
chiefalchemist 6y ago
> So much of the engineering mindset jumps to solutions instead of clarifying problems. I'm guilty of this constantly. This is because it's easier to rely on knowledge, but it takes extra work to develop understanding. It's also a culture issue. A close friend of mine works for a web dev agency. Numerous times she's told me how they're discouraged from asking questions. They're told they are experts and experts have _all_ the answers. Nearly as often I hear stories about something going sideways because knowledge isn't enough, they're short on the necessary understanding. Despite the pattern, the leadership doesn't change the culture.

MichaelMoser123 6y ago

What is more important to you - the clarifying questions of the candidate or the actual answer?

TurkishPoptart 6y ago

Can you clarify as to what kinds of clarifying questions you're looking for? Not trying to be ironic here, just need help with interviewing.

rendaw 6y ago
For example, what does "load" mean? Type it into a browser url bar and press enter? Or just what happens when you press enter (excluding the typing)? Via curl? Or does load refer to just a single HTTP request?
colinrand 6y ago
Certainly. I like to have the candidate ask follow ups like, are you interested in the networking aspects? the brower's behaviors? the way the website handles the request? all of these above? If I phrased the question slightly differently, engineers would have a very different reaction. Q: Can you write a test for me that demonstrates I can load a URL successfully? That could drive the engineer down a different mode of thought. Business stakeholders won't ask for a requirement to implement a test, and the engineer needs to translate the business request into an engineering solution. From what I've seen, different levels of experience in engineer will have different responses and illustrate for me where they are in the engineering journey. A young engineer, perhaps a new college grad or intern, will tend to react to this with a very open mind and lean on their recent academic background, showing excitement with the question and identifying the challenges in it. They usually do pretty well. The mid career programmer often stumbles. They want to show the expertise so latch on to the part of the problem they are most familiar with do show technical prowess. They can often lose the forest for the trees. The senior engineer, will want to know why you're asking and what you're trying to accomplish. Perhaps I'm looking to optimize one part of the problem, perhaps make a step more resilient, more extensible, etc. They will want to know why this question is important for the problems at hand, and hopefully they'll ask about that directly! Hope this gives some insight for you.
- fancyfish 6y ago
  This is great. It's critical to bucket engineers into levels with a checklist like this. Are they eager to explore every corner of the problem, from networking to the browser backend. But not in too great detail - not focusing on one topic too much. But you also don't want them talking too much - a great engineer asks questions as much as provides answers.

deleted 6y ago

[deleted]

mjw1007 6y ago

The trouble with doing this in an artificial situation like an interview is that you're leaving the candidate to guess your purpose. If they correctly guess that what you mean is "please engage in a simulation of a planning conversation, based on this arbitrary prompt", they'll do well. But if they guess that you mean "please use this arbitrary prompt as an opportunity to demonstrate the depth of your technical knowledge", they'll do poorly (they're unlikely to ask clarifying questions, because that would look the same as stalling to disguise the shallowness of their knowledge).

Karunamon 6y ago
Believe it or not, the last couple interviews I did, I just came out and asked for, and got, this level of clarification as to what they wanted here. Some companies solve their problems differently, value different characteristics, and so run their interviews differently, and in my (admittedly limited) experience, it's not a faux pas to ask. A few employers ago, giving a "best guess" rather than admitting you don't know the answer to a question was an instant no-hire. They wanted to be sure that you were sure when you put an idea out there without qualification, and so it was with the day-to-day SRE-ish work where short outages caused by speculative changes that weren't fully understood were wildly expensive events. At my most recent one, I was actually encouraged to speculate if I didn't know the answer to a tech question, or was asked why I answered what I did if the answer was wrong; they were more interested in my thought process than the end result, even if the end result wasn't technically correct.
- fractionalhare 6y ago
  I might be nitpicking, but this: > A few employers ago, giving a "best guess" rather than admitting you don't know the answer to a question was an instant no-hire. and this: > At my most recent one, I was actually encouraged to speculate if I didn't know the answer to a tech question aren't incongruous to me. In my interviews, I lay out two explicit expectations for the candidate upfront: 1. Please don't bullshit an answer. Confidently incorrect is considered a red flag. 2. The interview is designed to find the ceiling on your certainty and knowledge, and to see how you deal with ambiguity thereafter. I encourage candidates to guess; I just want them to make it very explicit when they're guessing, and demonstrate self-awareness in doing so. As ever, a lot of interview problems on both sides of the table are resolved with more communication. It is good to set explicit expectations for candidates throughout the process, and to revisit particular expectations in the first two to three minutes of an interview.

tptacek 6y ago

If you're guilty of something constantly that generates poor results in interviews, why on Earth are you using it as part of your interview screen? I agree: this is a pessimizing question. What's the point of a process that sets candidates up to fail? You can do the opposite thing: set a high bar, and then have a process that does everything it can to set candidates up to succeed.

the_arun 6y ago

Also in the interview - you expect the interviewee to answer what you are expecting them to answer - instead of acknowledging/accepting their point of view. Are these expectations playing any role in your observations?

chiefalchemist 6y ago

> So much of the engineering mindset jumps to solutions instead of clarifying problems. I'm guilty of this constantly. This is because it's easier to rely on knowledge, but it takes extra work to develop understanding. It's also a culture issue. A close friend of mine works for a web dev agency. Numerous times she's told me how they're discouraged from asking questions. They're told they are experts and experts have _all_ the answers. Nearly as often I hear stories about something going sideways because knowledge isn't enough, they're short on the necessary understanding. Despite the pattern, the leadership doesn't change the culture.