If you're thinking of joining big tech, try to join a team that develops an internal tool.
You have as much impact and are exposed to as much scale (maybe not in terms of TPS but in terms of data, etc.), but you usually have much lighter development processes and a much more frequent release cycle. Your ops will also be a lot lighter.
I'm an early career software engineer and am curious - why do people say working "at scale" like it's a good thing? Why is that desirable? What are you doing differently from someone who doesn't work "at scale"?
Making software work for single use is relatively simple, making software that runs at 100% uptime, with large numbers of "users"/"tasks"/etc is an entirely different level of development and design.
The actual functionality is a very small part of software development.
Making it work within its constraints (memory/CPU/network/storage in the small scale, ability to handle peaks while maintaining uptime at a larger scale), as well as dealing with the "non-functionals" like AuthN/AuthZ, obervability, performance, etc is actually the "hard part".
Then add in business "non-functionals" like "minimize CapEx/OpEx", "meet external SLAs with measurable and reportable KPIs", "meet corporate and regulatory standards and requirements" etc.
All of that is much larger than the actual function being developed.
it just means they deal with some obvious and non-obvious problems having to do with being A Big Deal. (there's only a little bragging involved.) the most usual example is scaling up. say you have a website which you run on a server, and it's humming along serving users. everything's great. but then you get popular, and your one lil server can no longer keep up. So you swap that in for a bigger server and everything's great again. but then you get even more popular. and suddenly there don't exist bigger computers. so then you split up the programs on that one computer so that you can use two big ones and serve more people than you could before with one. and then three servers. and so on.
Someone who's dealt with websites at scale before is going to be able to skip the first 20 of that process, so if you're a startup dreaming to get big, you find someone that's worked "at scale" eg Amazon or Google to design and build your systems and avoid some pain points like the website going down because the system can't keep up.
If you look at tools in general as something that's intended to help other people solve some problem - and derive some enjoyment from that aspect of your job as a tool writer - tooling that operates "at scale" usually also helps more people.
You have as much impact and are exposed to as much scale (maybe not in terms of TPS but in terms of data, etc.), but you usually have much lighter development processes and a much more frequent release cycle. Your ops will also be a lot lighter.