5 ms·

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 a

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.
  - BlargMcLarg 4y ago
    You're only tackling what you gain from your changes, not what you lose. Digging in requires people to spend more time. Most interviews are already massive and exhausting. Candidates in general aren't looking for longer interviews, they are looking for shorter interviews. Your changes propose even longer interviews when the number one complaint is the sheer length and volume of interviews. Most candidates are not amazing at interviewing or figuring out people, let alone when they spend most of their time doing other things at the day/week of interviewing. The majority of candidates are either tired, inexperienced, or both. Increasing the volume of information isn't a strict gain under conditions which are true far too often, and can even be a loss. Lying isn't uncommon, but I'd think twice about whether saying "no" is really that much easier than weaving an elaborate half-truth. At the same time, most candidates will be treading a fine line between not getting on the interviewer's nerves, and figuring out what is actually happening. Navigating social dynamics is difficult for a reason. >it could suggest a few things That's the entire problem. I reckon this is part of the reason why author is so direct in their questions. They don't want to deal with multiple possible answers and spending more time figuring out the answer. They want a 'is this company worth my time' checklist which doesn't take multiple hours to fill. For obvious reasons, that checklist isn't going to work for the majority of people (you named several reasons yourself). But changing the questions isn't going to help reach the intended goal either.
arcticbull 4y ago
> 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. The flag for me is that they routinely fail to get alignment from their co-workers before they begin potentially contentious changes. It's a sign of maturity to identify stakeholders, drive towards consensus and ensure alignment before beginning on any such project. I highly recommend this [1] as a framework for resolving such issues - and also it's a super strong answer if you're asked how you personally resolve such issues within an organization during an interview. The core principle is that people care more about the decision maker hearing out their idea, and understanding it, than they do about their idea being picked. The focus is on hearing people out. IME it's very effective even with, er, prickly personalities. [1] https://review.firstround.com/square-defangs-difficult-decisions-with-this-system-heres-how https://review.firstround.com/square-defangs-difficult-decis...

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.
- BlargMcLarg 4y ago
  You're only tackling what you gain from your changes, not what you lose. Digging in requires people to spend more time. Most interviews are already massive and exhausting. Candidates in general aren't looking for longer interviews, they are looking for shorter interviews. Your changes propose even longer interviews when the number one complaint is the sheer length and volume of interviews. Most candidates are not amazing at interviewing or figuring out people, let alone when they spend most of their time doing other things at the day/week of interviewing. The majority of candidates are either tired, inexperienced, or both. Increasing the volume of information isn't a strict gain under conditions which are true far too often, and can even be a loss. Lying isn't uncommon, but I'd think twice about whether saying "no" is really that much easier than weaving an elaborate half-truth. At the same time, most candidates will be treading a fine line between not getting on the interviewer's nerves, and figuring out what is actually happening. Navigating social dynamics is difficult for a reason. >it could suggest a few things That's the entire problem. I reckon this is part of the reason why author is so direct in their questions. They don't want to deal with multiple possible answers and spending more time figuring out the answer. They want a 'is this company worth my time' checklist which doesn't take multiple hours to fill. For obvious reasons, that checklist isn't going to work for the majority of people (you named several reasons yourself). But changing the questions isn't going to help reach the intended goal either.

arcticbull 4y ago

> 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. The flag for me is that they routinely fail to get alignment from their co-workers before they begin potentially contentious changes. It's a sign of maturity to identify stakeholders, drive towards consensus and ensure alignment before beginning on any such project. I highly recommend this [1] as a framework for resolving such issues - and also it's a super strong answer if you're asked how you personally resolve such issues within an organization during an interview. The core principle is that people care more about the decision maker hearing out their idea, and understanding it, than they do about their idea being picked. The focus is on hearing people out. IME it's very effective even with, er, prickly personalities. [1] https://review.firstround.com/square-defangs-difficult-decisions-with-this-system-heres-how https://review.firstround.com/square-defangs-difficult-decis...