Startups have issues too, but they’re more often related to the technical parts, which you can actually do something with and learn from early in your career.
If you go to the large company what you learn is navigating their particular brand of process.
The only part that's missing is handling the enterprise processes, multiple stakeholders, chains of approvals etc. But those are easier to learn than building something from scratch.
Yes, I know how to optimize a database. Yes, I know how to build infra. Yes, I also know how to build a system used by 30k people daily.
Yes, I’m fairly certain that our system that serves 3k people does not need to cost us $30k/month when I could do 30k for $1000/month.
But nobody wants to hear that. They’re all secure in their little fiefdoms, and your boss will certainly not be rewarded for replacing their 30 people team with three of you.
I went from a startup to a big company, 25+ years ago. We buy startups. I'm kind of a jack-of-all trades. One of my roles is to serve on the technical side of taking a small company apart and figuring out how it works, so that it can at least be kept in production when the technical founders move on. Most of those products don't have a known theory of operation, until I write one for them. The term "house of cards" is overheard in the cubicles when the products have to be maintained.
I've seen the innards of those products. I've built those products, for my own side business. Being at a big company gives me a perspective from both sides, about what those products really look like when someone other than the founder has to build and maintain them.
I'm not touting the big company experience as idyllic. Most creative people bristle at bureaucracy, and can see through processes that are unnecessarily constipated. On the other hand, I think the biggest adjustment is just getting used to someone else being able to say "no" to your idea, without having a really great reason that you agree with. Over and over again. Keeping your creativity under those circumstances is hard.
Yes, absolutely this. I'm surprised to see recommendations to do a startup as a first job. That's not a good idea.
A new grad who has never worked anywhere might know how to code quite well academically but they have zero exposure to how to build a commercial product. Semester-long projects at school can't teach that. That's how you end up with codebases without source control, no code reviews, no architecture, tons of security problems and so on.
Go work a few stints at large respected companies (in whatever field you are in). Absorb everything you can about how and why they do things. Understand the processes and why they exist. There's a reason for everything.
Then go do startups. You'll know how mature products are engineered, and you'll understand which parts of the processes make sense for a startup (not much, but you'll know) and you'll know how and when to slowly start introducing more maturity as the startup grows.
By now in my career I've worked at every size company, from 100K+ people multinationals to 3 person startups and just about every size and maturity point in between. I would never hire a zero-experience person to a tiny startup, that makes no sense. It would be bad for them and bad for the startup.
Like, $PREVIOUS_COMPANY was a small shop. Not many customers, not many users. Handful of customer product deployments.
Even so, releases/deploys were broken most of the time.
First thing I did after I got responsibility was add dev/staging with an automated and clearly documented release process from PR -> Prod, including steps for QA etc. Nothing stupidly onerous.
Customers complaints stopped almost overnight.
People internally knew what to expect when it came to changes being released. People could see when things were released and where etc. People knew why their work might not be propagated out yet. Higher ups knew why things might take longer and why that was beneficial. We could also break down some very simple stats about how deployments/releases were going based on git tags.
Applying the limitations of a process can be useful when things have been going wrong, repeatedly, in exactly the same way.
However… there were absolutely cases where adding a process didn’t make sense and would have just been adding a process for adding a process sake.
For example, ee didn’t need tickets for every PR. If it was a ten minute fix just do it and explain it in the PR, that’s good enough.