Hacker News Reader

Comment by dannyw | Hacker News Reader

“As a SWE, I seek to understand important context first, before jumping to build or code. First, I’d like to ask if you’ll guess randomly and fairly, or adversarially?”

“Secondly, when significant money is involved, I make sure to verify any inputs. I’m considering the situation, not you personally, untrusted. How can I verify it, or do you want me to proceed assuming that’s verified?”

Those are great questions, but it’s also about how you ask it. SWE is not pure engineering. Communications is vitally important.

View on HN

wat

"as you, my interviewer, are a capable SWE I assume you gave me all the context needed to solve the problem".

The interviewing game of asking clarification questions is silly and should stop. In the system design portion I can understand it, but not when asked a direct technical question.

It's perfectly fine to ask followup questions with added constraints or just directly say that the specification is fuzzy and needs to be clarified first, but having that dance around the basic specs in nonsense (as if you wouldn't know if you're dealing with a 10PB array or 1kb at work).

> but not when asked a direct technical question.

This is anything but a direct technical question though.

> It's perfectly fine to ask followup questions with added constraints, but having the guessing game to figure out those constraints is nonsense.

You say that. I say people being able to ask the right question is one of the most important skills to be a productive developer. So of course as an interviewer I want to know if they can do it.

I don't know how it works where you are, but we don't have a big book of perfectly defined specifications for our work. I guess if we could get one of those that would improve our productivity. But until we obtain one we will keep testing candidates on their ability to ask questions.

Sure, and there's a way to test the ability to ask questions that isn't some "gotcha" type question. As in interviewer you can just say "the specifications aren't clear, what questions would you might want to ask to clarify them?".

It's not like in the day to day work you go around defining specifications for every tiny function - the default specification are clear from the work environment.

Let's say you had to implement a "find dups in this array" at work, you probably won't go around collecting requirements for that, so asking that in an interview and having the silly dance of "Oh, the interviewee didn't ask if the array fits in memory or not" is silly imo - and doesn't show anything other than whether the candidate memorized the need to ask that or not.

and like I said before, fuzzy specification are more suitable for the system/product design part, and can also be part of the coding part, but they shouldn't appear as some "gotcha".

> As in interviewer you can just say "the specifications aren't clear, what questions would you might want to ask to clarify them?".

I do say that, yes. Not necessarily with those words, but I tell interviewees that they are free to ask questions and in fact recommend that they do rather than they go start coding immediately and accidentaly solve the wrong problem. (Heck! Some people solve a harder problem than we intended to ask from them!)

> but they shouldn't appear as some "gotcha".

1000% agree with you on that.

> I say people being able to ask the right question is one of the most important skills to be a productive developer.

But you never know if by asking the "right" question you'll jeopardize the entire interview problem. Some interviewers may have only prepared 75% of the problem and haven't went through all the posibilities. If you ask a question that may pose itself as a "treat" (e.g., making half the problem non-sense and therefore there's no need to implement it) your interviewer may simply consider you a no-go.

And it's not about malice, but simply that you may be better prepared than the interviewer and some times that leads to a no offer. I wouldn't mind working in a place like that, so I don't usually ask "too clever" questions.

> But you never know if by asking the "right" question you'll jeopardize the entire interview problem.

Yeah. That can happen. As an interviewer i would tell the interviewee that they are right and it is because the example is a bit contrived and would ask them to pretend it still makes sense. If they are polite about the thing it would actually count in their favour.

But i understand it is a risk.

Reply on news.ycombinator.com