But that's also pretty divorced from the topic of what makes good interview questions. There's no way that a VP who spent a week to push out a color change to a button in prod would have any meaningful insight into how to change the coding interviews. That should also be left up to the engineers themselves to decide.
As a former engineering manager, if someone on my team walked me through why getting PRs out to prod was an insane nightmare, I'd take note, work with them to gather evidence, and present it to my director and try to escalate it to the point where we could take action to improve it. If the VP is any good at their job, they'll listen and work with us to fix it.
As an example, I joined a company with ~8k employees recently. They over communicate on email. I get 50+ emails a day. I filter heavily. My inbox is still unusable due to the volume of automated junk. I raised this issue in Slack and the majority of responses were just "well, that's how it is".
I am sure the development process has very similar deficiencies that I am blind to because I participate in it everyday.
In your example, you rely on them to be even better: you assume that they'll be a competent engineer and be able to understand the complexities of day-to-day software development by making a toy PR when many of them haven't done it for years for decades. That's a much stronger assumption than the one that I'm making: that a good VP will listen to their subordinates.
I agree with the rest, but I don't agree with this part. Engineers should have a lot of input into the hiring process, but fundamentally management is accountable for business performance and one of the biggest drivers of success is getting the right people in the door rather than just more people like the ones you already have (which is what happens almost always if you don't deliberately shape the hiring process).