Only big exceptions are TripleByte and Enova. They told me that I come across as too "junior" in giving explanations despite my years of experience. The smaller companies are probably holding me back in career growth.
This is a really useful factoid for you. You should at least try reviewing one of your past performances for "opportunities to have sounded like a senior engineer" and then, during your next performance, dial that signal to parody levels.
If how to do this is not obvious to you, a trick: explicitly verbalize more of your reasons for not doing obvious alternate approaches. Bonus points if you can make those reasons sound like they were won by working on systems operating at scale.
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
- It presumed that the existing spreadsheet would be flawless and bug-free. That is almost never the case; ad-hoc spreadsheets are often riddled with mistakes.
- It presumed that it would be a high risk/expensive task to replicate that spreadsheet in a technology that was more suitable for the job. Yet (if you assume that the spreadsheet was essentially correct in its function) it is one of the simplest implementations - you have a working specification for the behaviour you're implementing. If you are not confident in your ability to replicate a working spreadsheet, and then test that your new code behaves identically, then what are you going to be confident to build?
- It presumed that the technology used to automate the spreadsheet would replicate its behaviour faithfully. But that's only true if you use the same underlying application, so you'd only get the benefits if you automated Excel. If you used Open/LibreOffice, or Apache POI, or something similar then you still have all the risks that come with a reimplementation.
- It failed to account for the operational complexity of such a solution. Automating a spreadsheet is fragile. The resulting system would likely be a nightmare to operate.
- It failed to account for the long term maintenance cost of running a suite of business applications that are cobbled together from bits-and-pieces without any planning or cohesion. In that environment you should assume that an application will be in service for 7-10 years with the possibility of it running for 20 or more years. One of the biggest ongoing costs for that team was the number of bespoke applications we had, each using esoteric technologies and inconsistent design approaches. For example, a project to upgrade the underlying Operating System (or web browser, or database, or ...) would need to test each of those apps and potentially fix bugs. Which meant finding the source code, working out how to build it and package it, etc. Not to mention the cost of trying to stay on top of security patches for the underlying components and libraries. Consistency has massive value in that sort of environment.
You learn those lessons from experience - if your experience has been in a similar sort of working environment. I don't presume that every senior engineer has that same set of experiences and will agree on the same set of priorities and tradeoffs. But if I'm hiring you and paying a senior engineer salary because you have experience, then it needs to be experience that is applicable to the sorts of problems we face and the decisions we need to make.