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.
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-decis...
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.
"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.
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.
Adding an extra 15 minutes at the end of a 7 hour interview process to find out if this is a place you might actually enjoy working seems like a no-brainier. I've also seen it make leaving much easier.
If you did ask (in a more polite and helpful manner than proposed by the OP) questions like these and the hiring manager lied to you moving on will _feel_ much easier.
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.
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.
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.
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.
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!