My experience has actually been the exact opposite. Working with an engineering manager and an engineering team can be just as frustrating since they often want to build the "perfect product" instead of getting a working model up and running first or a decent prototype.
It can also mean that we have to use the engineers pet technology instead of something that may work better for the task at hand.
Right now I am in some trouble because I used an alternate and quicker technology(flask) to get a prototype up for some customers. It took weeks instead of the usual months to get stuff up and running. Business is happy and understand this is a prototype. Engineering manager is pissed because we should only have built it with our standard framework and not have had the prototype.
If someone asked that, I would probably consider that a red flag, that they are mistrustful of "business types" and probably difficult to work with.
I would not. I would assume they want to work under people with experience in their field and learn from them.
The thing about your advice (and mine, and most all interview advice) is that it's mostly useless. It's only beneficial to people interviewing you, and if it's beneficial to them, it's bad for you. After all, if they would ask that question, but they know not to, they are still that person you would mistrust.
The reality is, people should ask these types of questions. If you wouldn't hire them because of that question, it's likely the would not enjoy working at your company.
I experienced this personally when I architected a product, the team grew and the product grew and before long there were modules that I had never worked on.
I don't think the manager of engineers needs to be as strong as the other engineers on the team, but they have to understand engineering on a fundamental level, and be able to look at code code and comprehend it, even if they don't know the whole product, or all the details.
That is a good heuristic for future pain and frustration.
Managers who are good engineers don't always manage well. Managers who have never been engineers are usually worse.
> When you don't know whether a direct report is doing good or not because you don't understand what their doing, by definition you cannot manage them
Especially middle managers, if they are not the owner and have their own managers on top of them, who also don't know how engineering works, there will be trouble. Because they are stuck in the middle. They have to please the ones on the top, without understanding how the programming actually works. So they'll make promises then turn around to you and tell you to work 70 hour weeks.
> So long as the "people managers" are biz guys who don't understand engineering
It is hard. The more time they spend managing and coordinating the less time they spend writing code. The less time they spend writing code the further they move from understanding what is involved. They just forget, or practices and tools change.
Besides leadership is the key. That is as much learned as it is just a personality trait. It ties into how they relate socially to others, how they solve social and political problems. It requires empathy, but also harshness and coldness at times. I can be learned by I wouldn't discount it too trivial.