I really love these points as a North Star, but these would be mostly aspirational for teams I've been on.
I work on a team now where we get huge scopes of work and a couple people will tear that work down and would answer these questions as they do so. However, most teams I've been on deal with far more interrupts than the team I'm on now does. Those interrupts are lemented but justified by the business and definitely impact an engineers dedication to a given projects. Interrupt driven work is a sort of split brain problem that I think gets in the way of answering these kinds of questions because it removes the time that an engineer would otherwise spend entrenching themselves enough to know the answers and problemscape.
It sounds like you don't think these expectations are unreasonable in a healthy environment. Is that what you're getting at? I believe it's possible to hit 50/50, and I think I personally do (with the caveat that I don't do all of these things explicitly, every time, on every project), BUT I'm also on a high performing team in a healthy work environment.
> with the caveat that I don't do all of these things explicitly, every time, on every project
which is totally fine, most of those things don't need to be done explicitly. (as such they take less time than many commenters seem to think they would.)
being able to articulate something doesn't mean that you've taken the time to do so. just that you've generally thought about your task enough before starting it that if your boss asks you that question, you can produce a coherent answer in a timely fashion.
I think the expectations are fine. In a sense I actually judge the engineer less than Mike does according to these criteria. If you can answer these questions I think it says more about how your team organizes and accounts for work more than the diligence and knowledge of a single engineer.
I work on a team now where we get huge scopes of work and a couple people will tear that work down and would answer these questions as they do so. However, most teams I've been on deal with far more interrupts than the team I'm on now does. Those interrupts are lemented but justified by the business and definitely impact an engineers dedication to a given projects. Interrupt driven work is a sort of split brain problem that I think gets in the way of answering these kinds of questions because it removes the time that an engineer would otherwise spend entrenching themselves enough to know the answers and problemscape.