Hacker News Reader

Comment by colinrand | Hacker News Reader

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.

View on HN

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).

Happened to me recently. I had no idea what the person wanted.

Turns out this was the core problem for me.

I actually care about customer acquisition and marketing strategies. Product positioning is important to me and it deeply effects how the product is designed. The aspects are a conversation, not a dictation and battle between departments.

Business and marketing is how you wrap and present your technical achievements to communicate their value to the public. If this isn't part of the gestalt, then we're just a scattered swarm. Anyway, yeah, passion.

A company that thinks there should be 10 people and 500 miles between these things and who actually builds the thing isn't right for me. (Apple for instance)

This is how companies come out with spastic messes that only sell because of the existing momentum of the brand.

I would be eternally frustrated that not only me, but everyone else is in these stovepipes.

So that flaw, I realized IS the purpose. They aren't testing knowledge as much as boundaries.

It's Designed so they don't accidentally hire otherwise technically competent people who want to bombthrow their administrative apparatuses

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.

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.

In my interviews, I lay out two explicit expectations for the candidate upfront..

See, I've never once gotten that without asking for the detail. I'm convinced that most companies have pathologically bad interview practices.

Most companies do have pathologically bad interview practices. The usual thing it to cargo cult off of other companies interview practices or be based off of some idea that has been seen before.

>>1. Please don't bullshit an answer. Confidently incorrect is considered a red flag.

Unfortunately BSing works pretty well for a lot of people. It may not work with you, but it will probably work with some other employer.

> (they're unlikely to ask clarifying questions, because that would look the same as stalling to disguise the shallowness of their knowledge)

This feels backwards to me. If you have comprehensive knowledge, you almost have to narrow down the question!

Or just talk continually until you've exhausted every single detail of every single aspect. The latter is rarely going to be what you want to do.

There's a level of "this is also a test of your communications skills" in every interview question, and it's a valuable thing to look for. So if you don't treat it as a 2-way street... you probably should.

They might, for example, decide to demonstrate one aspect of their communication skills without asking clarifying questions by showing that they can, on the fly, produce a high-level summary of what happens when you load a URL followed by orderly expansions of each of the steps involved in increasing levels of detail.

I've been listening to people expound their theories of interviewing for decades now, and very often they have some pet idea which involves asking the candidate for something and then trying to deduce information indirectly from how they interpret the request.

I think these theories are pretty much all bad ideas, because what the candidate is actually doing is trying to guess what the interviewer wants to hear.

A lot of what you're describing is better solved by training interviewers on a standardized process, and having both the recruiter and interviewer set explicit expectations around communication. It's true there are good and bad interview questions, but candidates should be encouraged to ask clarifying questions. To alleviate a candidate's fears about doing so, this encouragement should be made explicit throughout the hiring process.

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.

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.

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.

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.

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?

> 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.

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?

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

Reply on news.ycombinator.com