I think you could turn the responsibility the other way around quite as easily, and I think you're mistaken grown complexity, one that is inherent in a company's system (accidental or not), when you outline what you mean as "framework" here.
Frameworks are documented building blocks, so are programming languages and libraries - those things are meant to be used as foundations and are designed with the thought that anyone could ramp up with progress easily. If they wouldn't be documented in a somewhat usable form, then there is a high chance that they wouldn't be used as building blocks in the first place. Companies are nothing like that(!), be it because their inherent system has not been designed as useful tool (that's the focus of their products after all), be it because their projects haven't been created out of passion and just need to bring in some money, or be it because of multiple other reasons I could mention.
In every company I've had the pleasure to be joining so far, I've always encountered that something (even sometimes more) gets written from scratch and will just stay undocumented (even untested). If a company is anything but a hobby project there is always this overload on tooling, because someone wanted to dabble in domain A but didn't want to learn building block A, so they just put building block B also into domain A, or even introduced their new interest: building block C - NIH[0] is also a real thing. We humans have a very short attention span and are surprisingly overconfident when it comes to the design of complex systems. It's also significant harder to read code than it is to write code yourself, and if you had the luxury to grow with the codebase of a company, then you'll also show a natural tendency to just overlook some of its inherent complexity. And those are just the technical aspects of it all, mind you. There are social, cultural and economic changes in each company that affects its complexity just as well (going from MVP to sustainable product, CRMs, outsourcing etc.).
> Every business, but some more so than others, has time pressure. [...] If you come into a company unfamiliar with the languages and tools that they use, you are essentially coming in handicapped.
The true capital of a company is its people. If you have the chance to bring someone in that you'll trust wholeheartedly, then that's a huge gain for the whole team and even outlives any visionary business prospects of any kind.
> All problems are people problems.
Agree!
> It's not that the company needs people who know how to code in the language or tool ... they need someone who has worked on enough different projects with that tool that they can navigate the completely fucked up ways that THIS company uses it.
Here's the interesting bit: If this candidate would have already learned that their tool of choice is used in a fucked up way in THAT company, then what incentive would the candidate have to join THAT company in the first place? Is that company even fully aware of its fucked up usage of that tool?
Tools need to be learned for problems to be solved. This hypothetical candidate might have learned enough already and would like to focus on the problem at hand, but now has to deal with the annoyances of "making the fucked up state visible" instead. Or, considering the fucked up state is already well recognized, now just needs to do what feels like chores before it gets interesting again, but doesn't want to live with the fucked up usage in THAT company.
> The company doesn't need someone who can write the Hello World tutorial in the language or framework, they need someone who can evaluate the good decisions vs the bad ones in an existing codebase.
Agree, and that somehow contradicts everything you wrote previously.