Disclaimer: You've only given us a few paragraphs to draw on, so we need to fill in the gaps and make some assumptions. You'll need to test whether those assumptions actually fit with who you are.From your intro, my guess was that this would be a senior/junior mis-match.
With 10 years of experience, employers will think of you as someone who should be a senior engineer, and they are likely to be evaluation you based on that expectation. That might be your expectation too - you didn't really say what sort of roles you were applying for, but if you're applying to "senior engineer" roles, then each company will have an implicit set of expectations about what a senior engineer can do. Some of those expectation might be made explicit in the role description, but many won't be. The role might talk about "mentoring junior developers" but there's an implicit expectation about the content of that mentoring - you have to know certain things in order to be able to teach others about them.
Those expectations will vary by company, and even by hiring manager. Some interviewers will think "A senior Java engineer must know spring+hibernate", but if you've spent your career working in the Hadoop ecosystem, then that's not likely to be true. Or "A senior engineer must understand the trade-offs of unit-testing vs integration-testing" (and be able to give the answer that they want to hear) but that's a question that is more relevant for certain project types, and not every engineer is going to have an opinion on that.
A likely problem here is that your 10 years of experience haven't given you the right set of skills to be able to answer their interview questions in ways that satisfy their (probably unreliable) interview filter. Maybe you really don't have those skills, or maybe you have them in some form, but not in a way that matches the interviewer's expectations.
Some time ago, when I was hiring into a medium/large bank, my expectations for a 10+ year engineer would be that you could be given a loosely defined problem, work your way through the details to understand the real task to be solved, design a solution (typically changes to be made to an existing system), implement and unit test that solution, assist in developing a system testing plan, assit in implementation, and understand the implications for support/operations. Each of those steps has a bunch of further detail that varies greatly by workplace, and interviews have "right answers" that assume you've done this enough times under similar enough conditions to be able to reach the same conclusions as they've reached.
As an anecdotal example. I remember hiring for a particular role, and one of the questions proposed a scenario where a particular business function was currently being driven from a spreadsheet, but they had outgrown that, and wanted to automate more of the workflow, and wanted to run a project to build a web-based internal system for that. How would you approach that? One of the candidates said something along the lines of "If they have a working spreadsheet, then I wouldn't want to change that. There's lots of risk in reimplementing it, so I would look at tools that could be used to put a web front end on top of the spreadsheet, and automate it that way." That was the wrong answer. It was a valid answer, and they explained why they wanted to take that approach, and "because risks" is somewhat reasonable, that team was not big on risk-taking. But whatever that candidate's experiences had been, they had led him to propose a solution that didn't fit with our expectations, and made what we considered to be the wrong trade-offs (and he persisted with that proposal even when we prompted him to go in a different direction). It's quite possible that some other company would say "Yes, that's exactly what we wanted to hear, you're hired!", but he wasn't the right person for us.
So - what's the solution?
You might try angling for a less senior role. It's hard when you have seemingly relevant engineering experience, to pitch yourself as a mid-level engineer, but you might need to find a way to do it. Then the expectations are lowered, you can get in the door, find out where your previous experience was leading you astray, and then be promoted to a senior role (or switch to a new company, now that you have the skills you need for the interview). You might need to trim your resume in the process so that you only mention the last 5 years of experience, and don't look too senior.
Alternatively, it might just be an interviewing issue. You might just need to translate what you do know from "small company" to "big company". Try something like https://interviewing.io/ and learn how to explain the skills you do have, in terms that big companies like.
--
edit: s/prompted/promoted