I've been back and forth between startups and corporations. I think I know what you mean in technical terms; that corporations use more advanced (rigorous) processes and tools and so it feels like you're learning more (it feels more precise/correct) - That said, I think that a lot of the stuff that you learn in big companies are anti-patterns when you consider the big picture; a lot of the time, you learn technical solutions to problems which don't really need to exist to begin with.
For example, one reason why many corporations push really hard on having 100% unit and integration test coverage is because they have such high employee turnover that they can't rely on their engineers to maintain their own code; corporations have to assume that engineers who work on their projects are completely unfamiliar with the code - In this case, automated tests are the only way to maintain the integrity and stability of the code base. The time cost of maintaining all these trivial unit tests is ignored (even though the cost is actually very significant; not to mention that these tests lock down the code and thereby discourage refactoring and experimentation).
Corporate processes are designed around the assumptions that engineers don't care and can't be trusted. This is a very inefficient approach to building software.
Personally, I'd rather my project have code with 0% unit test coverage written by a team of involved engineers than code with 100% test coverage written by a team of indifferent engineers.
> For example, one reason why many corporations push really hard on having 100% unit and integration test coverage is because they have such high employee turnover that they can't rely on their engineers to maintain their own code
I'm in a similar situation as yours and have switched between big corporations and startups and now at a big co again. I used to have the opinion that unit tests are a time sink, but what changed my mind was the iteration speed unit tests gave me. Without them, to test that my code actually worked, I would either deploy to a test environment (or prod in the worst case) and if it didn't work, then that just meant a longer feedback loop. What I realized after starting to have solid unit tests was that I catch issues much earlier in the pipeline and when I finally release code to test, it works 99% of the time. The only time I've had bugs in test env was because of some implicit assumptions in my mocks in the unit test. If you think about it, that lets me iterate faster by pooling in lots of changes and releasing with confidence.
I think its natural to be biased towards testing in a real environment as opposed to unit tests, as it is more rewarding to see your code work and do what its supposed to do versus seeing it work in a stubbed out environment.
Unit tests to me are more about iteration speed and release confidence, than about corporations not trusting engineers (which is also true).
I would only write unit tests for very complex classes whose logic cannot be simplified into something readable.
Personally, I rarely introduce bugs at the unit level, almost 100% of my bugs are related to how classes/functions interact with each other - I find that bugs at the unit level are easy to track down (and often they will be caught by integration tests anyway).
I prefer integration tests because they traverse more code paths and don't need to be updated so often.
The main complaints I hear about integration tests is that they're slow and brittle but this is only the case if they rely on external microservices (or external data stores) and if test cases aren't properly isolated from each other. I use integration test cases as part of my development flow.
(disclaimer: I've worked at two mega corps and a startup and generally favor my experience at the second mega corp so far)
I think your example points out a factor, but not the only factor and probably not the biggest factor. You can also say that startups don't live long enough for their code to grow organically from their original, pristine design and develop deep seated code "cancer" like mega corp code does. Also, even without turnovers, some features just go through enough code modified by enough engineers that Murphy's law happens and things break in creative ways that E2E tests catches or could have caught. And finally, just because I remember my code today doesn't mean I'll remember it in a year or two... I don't assume that my coworkers have perfect memory either.
For example, one reason why many corporations push really hard on having 100% unit and integration test coverage is because they have such high employee turnover that they can't rely on their engineers to maintain their own code; corporations have to assume that engineers who work on their projects are completely unfamiliar with the code - In this case, automated tests are the only way to maintain the integrity and stability of the code base. The time cost of maintaining all these trivial unit tests is ignored (even though the cost is actually very significant; not to mention that these tests lock down the code and thereby discourage refactoring and experimentation).
Corporate processes are designed around the assumptions that engineers don't care and can't be trusted. This is a very inefficient approach to building software. Personally, I'd rather my project have code with 0% unit test coverage written by a team of involved engineers than code with 100% test coverage written by a team of indifferent engineers.