Then do it again, preferably with a small company.
After that, do whatver you want. You've learned from the scars of veterans with the big boys, you've dug trenches with the new kids, now the world is your oyster.
Go choose your fate.
At large companies, you often end up working on a tiny piece of a module, and then you work you way up. You don't learn much that way.
There are companies that try to give you more control, but no one is going to throw you into the deep end at those companies. That's exactly what you need if you want to turn a bunch of academic training into practical experience.
At large companies, you end up working on a stack written by someone out of college 10 years ago when the company was a startup, cursing them and wondering wtf they were thinking. :-)
Maybe the learning there is a meta-lesson instead of some direct technology. Understanding that a large codebase has a life of its own; how to resist rewriting stuff if it doesn't benefit the business; how to test legacy code; etc.
At a big company, you write a tiny piece of software that has to fit a number of constraints that have evolved over years. Things like "This has to work in Chinese" and "This has to work in Arabic" and "This can't be O(N^2), you'll burn a million dollars in CPUs" and "This will crash the whole server if something goes wrong" and "This is a race condition. You're going to have a helluva time debugging that" and "Nobody else will be able to read this in a month". It can take you years of trial and error to amass that experience on your own, or you may never if (as is likely) your startup never takes off. If, ten years into your career, all you know how to do is cobble open-source programs together, you have a big problem on your hands.
At a startup, you get to build the whole stack yourself. You face problems like "What database should I use to store this data? How can I measure and improve its performance? What's the best front-end technology to deliver the data to the client? How do I setup my build?" So you learn how to, very quickly, get something up and running from nothing. If, ten years into your career, all you know how to do is make little tweaks to already-existing programs, you have a big problem on your hands.
You really need both, but I would recommend doing the big company first. (Disclaimer: I did it the other way around, doing startups first.) Why? Because the big company also gives you a brand-name boost and some context about what decision-makers in the industry consider important, which makes it much more likely you'll pick a good startup when you move to do that. While if you screw up in picking an initial startup, it can be very hard to un-do that and qualify yourself for big-company jobs later in life.