5 ms·

To me, the fact such a question is seen as 'bad' feels very strange, when interviewers routinely ask questions of similar intent (read: questions which can be v

To me, the fact such a question is seen as 'bad' feels very strange, when interviewers routinely ask questions of similar intent (read: questions which can be very open-ended, require the opposite party to be vulnerable and can be interpreted in many ways). If you as an interviewer would consider it a bad question, I would hope you hold the same standard for the questions you ask yourself.

majormajor 4y ago
I haven't personally been in any interviews where I was asked something so opinionated, like being asked "do you write bad code?" straight-up. These questions are very leading and direct, not open-ended at all - look at how limited the set of "right answers" is for most of them. A question like: > "Does this team or any of the related teams have a person who actively rejects proposals to improve the code base?" is a flag because it implies that the person asking the question thinks their definition of "improve the code base" is the only one that matters. It also is asked in a way that suggests a lack of maturity around disagreement and communication. "If someone sees something they think would improve the code base, what should they do to try to get that done?" would be a much improved version. > "Suppose the team needs to start a new web service like a private Gitlab, add new type of CI to the testing pipeline or something similar. Could you explain the exact steps needed to get it fully operational? Please list all people who need to do work to make this happen (including just giving authorization), and time estimates for each individual step." This one is less of a "bad question" if you're OK with filtering out places that don't work that way (a place that spins up random new infrastructure shit in a couple days super frequently seems like a terrible each-service-is-a-special-snowflake hard-to-maintain/hard-to-debug/hard-to-improve sort of hell, IMO) but if you're just more interested in process and bureaucracy, I'd suggest something more like "what are your thoughts on standardized shared infrastructure and tooling vs specialized things per-project?" EDIT: actually, to borrow a page from some frequent advice for interviewers - for bonus points you can rewrite both of those "better" versions to ask for specifics, along the lines of "can you tell me about a time someone on the team proposed a code improvement change that was controversial." Only ask for the vaguer "philosophical approach" part if they can't give you a specific story.
- BlargMcLarg 4y ago
  I don't agree with the question, but take away the reason the author is asking them, and the question is far more open-ended to the one being asked. That's the problem: it's a direct question which has too many possible answers which helps neither the party answering (because what should they answer?) nor the party asking (because even the answers not 100% on the mark can be interpreted in many ways). Plus, it's a horrible premise to set the other party up for failure to begin with. When you view it from that angle, the majority of questions in interviews are pretty similar. You can't tell whether the opposing party is expecting a perfect answer, or is lenient enough to take a chance with anything which isn't perfect. The problem with your changes, however, is that you take away the very thing that the author puts in for a reason. Removing the directness means the opposing party is now given more of a chance to provide a complete nothingburger of an answer which is likely half-true, and half-"what the world is this place actually?" That's not necessarily an improvement when you take into account all other aspects of interviewing. The only definite benefit you gain, is not causing bad blood by appearing combative over collaborative. Ultimately, what people want is transparency. That transparency is very hard to tell from the side of candidates. Formulating questions to allow 'best case answers' doesn't work as it allows the company to oversell itself. Formulating questions directly doesn't work because the interviewer gets a bad taste in their mouth. But the silly thing is, lots (the majority?) of interviewers certainly have their fair share of horrible practices which continue to exist today. The only reason they exist, is due to their power in the market.
  - majormajor 4y ago
    Where I disagree with you there is about the utility of directness vs concreteness. "Does this team or any of the related teams have a person who actively rejects proposals to improve the code base?" This leaves an unscrupulous interviewer a too-obvious answer: "no." They aren't going to want to admit someone "actively reject improvements" and lying in interviews is not uncommon. Asking for a specific story raises the skill bar for an effective lie. If someone is smooth enough to come up with a convincing, compelling story on the fly you sadly will struggle to catch them out with any questions. Fall back to a more open-ended discussion if they don't. This is less good, but a longer discussion, similarly, should make it easier to spot a liar than in a single-word "no." Every word the interviewer says is opportunity to gain more insight on what it would be like to work with them. Even that fallback is information you gain, though. "Can you tell me about a time someone on the team proposed a code improvement change that was controversial?" If the answer is "I can't think of anything immediately, but I'd probably do something like...[whatever]" then that's curious - it could suggest a few things. Maybe the systems are so simple that nobody thinks its worth bothering with changing. That could be bad for a candidate looking for a challenge. Maybe nobody on the team is empowered to make suggestions and all design is coming top-down from the boss. That would also be bad. (And the original yes/no question misses this case too: nobody on the team might do that, because only the boss is making the calls, and nobody else has made those suggestions, but gives you less answer to follow up on.) You can try to dig in more with additional questions, depending on which of those (or other) impressions you get from their answers.
geofft 4y ago
The blog post makes it clear that there's an intended single correct answer to this question, "No, a person who does this specific thing does not exist." It doesn't give room for "Yes, and I think they're right to do so, and here's why" - or even "No, but there's a person who ships their own stuff without review all the time." I think you could ask it in an open-ended way (though maybe phrased more like "What's the most difficult part of getting code improvements shipped" or "How does your team tend to balance the merits of making big changes" or "What is good and bad about your code review process") and it'd be a fine question.
- throwyawayyyy 4y ago
  To expand on why I think it's a bad question, "Yes, and I think they're right to do so, and here's why" is probably the best response I could come up with, and makes the interview adversarial for no good reason. It becomes an argument about the premise of the question. Putting the interviewer _or_ the interviewee on the defensive helps neither. Added: I realise I'm being adversarial myself here too :). You are correct, in that the questions could be reworded in better ways. Agree on that!
- BlargMcLarg 4y ago
  I'll articulate. The question is indeed asked with intent, but to the one answering, it comes across as something that can have a lot of answers as GP shows. At the same time, any answer can likely be interpreted in many ways, too. It opens up a lot of potential variations which, if you're looking for a specific answer and aren't very adaptable, sets the other party up for failure. It's the same issue which many traditional questions asked by interviewers have. They are at best "okay" when asked with an open mind. At worst, they are beyond worthless and create bad blood, as the other party is set up to fail.
throwyawayyyy 4y ago
It's a fair point -- and there are plenty of standard interview questions which fall squarely into that bucket. E.g. "Tell me your greatest weaknesses" is a horrible question that I for one never ask.
filoleg 4y ago
Just because "interviewers routinely ask questions of similar intent" doesn't mean that it is acceptable or should be treated as the norm. It all heavily depends on how your company designs their interview process and guidelines for it. At every company I've worked so far where I was involved in interviewing, leading and ill-intended questions like that were explicitly prohibited, and that was stressed plenty of times during the interview training. There might have been other things about the process as a whole that I thought could and should be definitely improved, but the "disingenuous questions from the interviewers" was never one of them. But on the flip side, I've interviewed at plenty of companies (as a candidate) over the years, and I definitely was asked those types of questions at more than one place. So you are correct, it is common, and it sucks to be on the receiving end of it. But doing that exact same thing back to them as a candidate isn't going to solve your problem. The solution is to not work for companies that are ok with their interviewers asking those types of questions (as much as you can afford to do so). Think about it for a minute, what are you trying to achieve by asking back those leading and ill-intended questions? If you somehow still want to work for the company, then asking those questions back probably isn't the smartest idea. And if you don't want to work for them after they asked you those questions, then why waste energy on arguing back and trying to make some point. A no is a no, your outcome of not working for them would be just the same, so why do the extra work[0]. It isn't like they are going to take that feedback earnestly and change anything for you. If you truly want to make something out of it, it would be much better to instead warn other candidates (aka your friends who might think of applying, if someone on HN asks about interviewing at the company, etc.) about it. 0. note: venting out your frustration is a valid enough of a reason.
- BlargMcLarg 4y ago
  Obviously I did not tackle it because of some ideal to fight fire with fire. I'm tackling it as people seem to forget something very obvious: Most red flags are entirely dependent on your position in the market. The less fortunate (people in careers with low demand, juniors, etc.) do not have the luxury to ask most of these questions, let alone vet for every red flag. My point is to illustrate the absurdity most people face and how normalized it is from the employer's side. If devs are already ridiculed as Prima Donna's by their peers merely for proposing such a list, I'd expect those same people to think twice and critique the status quo too. Yet, developers are more often tone policing each other rather than handling the same standards for employers, from my experience. Author wouldn't even be blogging this if they only had a portion of the power they have now.

majormajor 4y ago

I haven't personally been in any interviews where I was asked something so opinionated, like being asked "do you write bad code?" straight-up. These questions are very leading and direct, not open-ended at all - look at how limited the set of "right answers" is for most of them. A question like: > "Does this team or any of the related teams have a person who actively rejects proposals to improve the code base?" is a flag because it implies that the person asking the question thinks their definition of "improve the code base" is the only one that matters. It also is asked in a way that suggests a lack of maturity around disagreement and communication. "If someone sees something they think would improve the code base, what should they do to try to get that done?" would be a much improved version. > "Suppose the team needs to start a new web service like a private Gitlab, add new type of CI to the testing pipeline or something similar. Could you explain the exact steps needed to get it fully operational? Please list all people who need to do work to make this happen (including just giving authorization), and time estimates for each individual step." This one is less of a "bad question" if you're OK with filtering out places that don't work that way (a place that spins up random new infrastructure shit in a couple days super frequently seems like a terrible each-service-is-a-special-snowflake hard-to-maintain/hard-to-debug/hard-to-improve sort of hell, IMO) but if you're just more interested in process and bureaucracy, I'd suggest something more like "what are your thoughts on standardized shared infrastructure and tooling vs specialized things per-project?" EDIT: actually, to borrow a page from some frequent advice for interviewers - for bonus points you can rewrite both of those "better" versions to ask for specifics, along the lines of "can you tell me about a time someone on the team proposed a code improvement change that was controversial." Only ask for the vaguer "philosophical approach" part if they can't give you a specific story.

BlargMcLarg 4y ago
I don't agree with the question, but take away the reason the author is asking them, and the question is far more open-ended to the one being asked. That's the problem: it's a direct question which has too many possible answers which helps neither the party answering (because what should they answer?) nor the party asking (because even the answers not 100% on the mark can be interpreted in many ways). Plus, it's a horrible premise to set the other party up for failure to begin with. When you view it from that angle, the majority of questions in interviews are pretty similar. You can't tell whether the opposing party is expecting a perfect answer, or is lenient enough to take a chance with anything which isn't perfect. The problem with your changes, however, is that you take away the very thing that the author puts in for a reason. Removing the directness means the opposing party is now given more of a chance to provide a complete nothingburger of an answer which is likely half-true, and half-"what the world is this place actually?" That's not necessarily an improvement when you take into account all other aspects of interviewing. The only definite benefit you gain, is not causing bad blood by appearing combative over collaborative. Ultimately, what people want is transparency. That transparency is very hard to tell from the side of candidates. Formulating questions to allow 'best case answers' doesn't work as it allows the company to oversell itself. Formulating questions directly doesn't work because the interviewer gets a bad taste in their mouth. But the silly thing is, lots (the majority?) of interviewers certainly have their fair share of horrible practices which continue to exist today. The only reason they exist, is due to their power in the market.
- majormajor 4y ago
  Where I disagree with you there is about the utility of directness vs concreteness. "Does this team or any of the related teams have a person who actively rejects proposals to improve the code base?" This leaves an unscrupulous interviewer a too-obvious answer: "no." They aren't going to want to admit someone "actively reject improvements" and lying in interviews is not uncommon. Asking for a specific story raises the skill bar for an effective lie. If someone is smooth enough to come up with a convincing, compelling story on the fly you sadly will struggle to catch them out with any questions. Fall back to a more open-ended discussion if they don't. This is less good, but a longer discussion, similarly, should make it easier to spot a liar than in a single-word "no." Every word the interviewer says is opportunity to gain more insight on what it would be like to work with them. Even that fallback is information you gain, though. "Can you tell me about a time someone on the team proposed a code improvement change that was controversial?" If the answer is "I can't think of anything immediately, but I'd probably do something like...[whatever]" then that's curious - it could suggest a few things. Maybe the systems are so simple that nobody thinks its worth bothering with changing. That could be bad for a candidate looking for a challenge. Maybe nobody on the team is empowered to make suggestions and all design is coming top-down from the boss. That would also be bad. (And the original yes/no question misses this case too: nobody on the team might do that, because only the boss is making the calls, and nobody else has made those suggestions, but gives you less answer to follow up on.) You can try to dig in more with additional questions, depending on which of those (or other) impressions you get from their answers.

geofft 4y ago

The blog post makes it clear that there's an intended single correct answer to this question, "No, a person who does this specific thing does not exist." It doesn't give room for "Yes, and I think they're right to do so, and here's why" - or even "No, but there's a person who ships their own stuff without review all the time." I think you could ask it in an open-ended way (though maybe phrased more like "What's the most difficult part of getting code improvements shipped" or "How does your team tend to balance the merits of making big changes" or "What is good and bad about your code review process") and it'd be a fine question.

throwyawayyyy 4y ago
To expand on why I think it's a bad question, "Yes, and I think they're right to do so, and here's why" is probably the best response I could come up with, and makes the interview adversarial for no good reason. It becomes an argument about the premise of the question. Putting the interviewer _or_ the interviewee on the defensive helps neither. Added: I realise I'm being adversarial myself here too :). You are correct, in that the questions could be reworded in better ways. Agree on that!
BlargMcLarg 4y ago
I'll articulate. The question is indeed asked with intent, but to the one answering, it comes across as something that can have a lot of answers as GP shows. At the same time, any answer can likely be interpreted in many ways, too. It opens up a lot of potential variations which, if you're looking for a specific answer and aren't very adaptable, sets the other party up for failure. It's the same issue which many traditional questions asked by interviewers have. They are at best "okay" when asked with an open mind. At worst, they are beyond worthless and create bad blood, as the other party is set up to fail.

throwyawayyyy 4y ago

It's a fair point -- and there are plenty of standard interview questions which fall squarely into that bucket. E.g. "Tell me your greatest weaknesses" is a horrible question that I for one never ask.

filoleg 4y ago

Just because "interviewers routinely ask questions of similar intent" doesn't mean that it is acceptable or should be treated as the norm. It all heavily depends on how your company designs their interview process and guidelines for it. At every company I've worked so far where I was involved in interviewing, leading and ill-intended questions like that were explicitly prohibited, and that was stressed plenty of times during the interview training. There might have been other things about the process as a whole that I thought could and should be definitely improved, but the "disingenuous questions from the interviewers" was never one of them. But on the flip side, I've interviewed at plenty of companies (as a candidate) over the years, and I definitely was asked those types of questions at more than one place. So you are correct, it is common, and it sucks to be on the receiving end of it. But doing that exact same thing back to them as a candidate isn't going to solve your problem. The solution is to not work for companies that are ok with their interviewers asking those types of questions (as much as you can afford to do so). Think about it for a minute, what are you trying to achieve by asking back those leading and ill-intended questions? If you somehow still want to work for the company, then asking those questions back probably isn't the smartest idea. And if you don't want to work for them after they asked you those questions, then why waste energy on arguing back and trying to make some point. A no is a no, your outcome of not working for them would be just the same, so why do the extra work[0]. It isn't like they are going to take that feedback earnestly and change anything for you. If you truly want to make something out of it, it would be much better to instead warn other candidates (aka your friends who might think of applying, if someone on HN asks about interviewing at the company, etc.) about it. 0. note: venting out your frustration is a valid enough of a reason.

BlargMcLarg 4y ago
Obviously I did not tackle it because of some ideal to fight fire with fire. I'm tackling it as people seem to forget something very obvious: Most red flags are entirely dependent on your position in the market. The less fortunate (people in careers with low demand, juniors, etc.) do not have the luxury to ask most of these questions, let alone vet for every red flag. My point is to illustrate the absurdity most people face and how normalized it is from the employer's side. If devs are already ridiculed as Prima Donna's by their peers merely for proposing such a list, I'd expect those same people to think twice and critique the status quo too. Yet, developers are more often tone policing each other rather than handling the same standards for employers, from my experience. Author wouldn't even be blogging this if they only had a portion of the power they have now.