I think you're overcorrecting here. I've been on the other side of the table for questions like that, and the intent is to ensure that you have been in the appropriate situations before. At most multinational companies, resolving conflicts between two engineering teams is an everyday occurrence, and any new hires above entry level are expected to know how to do it.
That some people manage to escape the requirement by lying doesn't mean lying is the intended strategy.
Can you blame a company for prioritizing people who have worked in similar environments before?
In large corporations technical responsibility is often more distributed than in startups just due to size, so your technical skills, while important, are typically less important than they would be in small-business/startup land. What fills in the gap is communication skills and your ability to navigate corporate social networks. If you can't conflict resolve issues between engineering teams, well guess what? That engineering team you can't work with is going to hold you up and cost the company money while your superior, who really has better things to do, has to take time out of their day to address the issue you should have been able to handle.
Not saying it should be a mandatory skill, but you can't blame large corporations for filtering for it. It's a factor.
Most companies smaller than multinationals are still large enough to have conflicts between teams. The most common failure mode I see is people who simply opt out of those conflicts, preferring to keep their heads down and write code rather than talking about what should be done and how. I'm not familiar with how it works in older companies like IBM, but at the FAANGs of the world, participating in those discussions is what distinguishes entry-level engineers from more senior ones.
If your experience is only in companies with a handful engineers, yes, it can unfortunately be pretty hard to get a senior position at larger companies. It's not impossible, but people will have justified worries about whether you can handle the responsibilities.
> resolving conflicts between two engineering teams is an everyday occurrence
And how difficult do you think it is to learn this skill?
If it's an everyday occurrence in huge companies, and any new hires above entry level are expected to know how to do it, it sounds like something anyone and everyone will learn. Which sounds like a real easy skill.
If it's a real easy skill, why do you need to have it already when you join? Why can't you learn it on the job, like you learn a bazillion other skills?
This kind of thing comes up a lot with technical stuff... people think that X (something you can look up on wikipedia or SO and teach yourself in an hour or two tops) is really important, therefore they can't hire anyone who hasn't learned X. But whoever they hire must be a person who's super eager to learn new stuff.
I agree it's not tremendously difficult to learn. The problem is that many people don't have the instinct to learn it. If left to their own devices, they'll just write code satisfying whatever requirements they're given, without any impulse to discuss or question what the requirements should be. I've seen many times where another team said "oh you shouldn't do X, you've gotta do Y instead", and a junior teammate of mine just accepted Y as another requirement instead of thinking about whether it was the right way to go.
So you don't want to give people the level of independent responsibility a senior title carries unless they've already learned how to avoid that.
That some people manage to escape the requirement by lying doesn't mean lying is the intended strategy.