Time for some truth you probably dont want to hear
twitter.com
twitter.com
The fact is, anyone giving "truth" on hyper success is full of it. There just aren't enough hyper-successful people out there to generate a large enough same size to discern meaningful patterns. Hyper successful people are, by definition, very rare, and any attempt to find broader patterns and commonalities is silly.
Most of us would do well to focus on avoiding a bad life instead of pursuing an epic one. Don't neglect your health, your friendships or your marriage. Don't hold grudges or give headspace to toxic people. Quit your job when you start to hate it. Do those things and you may not become a billionaire, but life will probably be pretty good to you.
Another one is the kids who think actually trying to "learn" things in an obviously padding in course for the bachelor's program is worth your time. For example, learning Assembly. My school is not an amazing school and unfortunately neither was my teacher for it. I did what I had to to squeak by an A with as minimal effort as I could because I knew I'd never touch that stuff again in my average job. Some kids took it very seriously as though it's what everyone learns.
The only thing important about school is to get the degree. You don't learn much in it at all. You learn more in what you're willing to do on your own to build a portfolio on github. That's one reason why I liked CS was because I could at least do that. Unlike Art though, it's a corporate job that usually pays the bills.
I'm not sure (since I don't have a degree myself), but focusing entirely on the degree and not at all on taking the opportunity to actually learn the material doesn't seem to be a good strategy for getting a job at a tech company.
I mean, sure, take the curriculum as outlined with a huge grain of salt, practicality often trumps theory, and by all means demonstrate your abilities through a portfolio of open-source contributions, but I certainly wouldn't go so far as to say that the certificate is the only thing that matters.
Frankly, students that more-or-less major in test-taking is the reason degrees aren't valued very highly by many folks in the industry. Encouraging this attitude is only going to devalue degrees further seems contrary to the interests of anyone who actually has one, but isn't any skin off my nose.
Job-seekers that specialize in interview-passing pose a similar challenge.
Those "kids took it very seriously" would get hired, not you.
Some people take padding classes like graphics programming, game programming, AI, Java, and web junk. I've seen more use for PL/M, Pascal, and Ada. Of course the worst padding is the mandatory non-major stuff. No employer has yet asked me to produce Marxist literary analysis or to analyze a poem, yet that was required in college.
If you want to go beyond the basics of CS, take some of the EE classes. You may need to communicate with an EE. It's good if you don't need to rely on somebody else to hook up and use your equipment. Practice with a logic analyzer, JTAG debugger, and oscilloscope. Learn to solder tiny things.
Plus, I highly doubt anybody in HR is gonna kid the kid with advanced skills in assembly the time of day when they need to know how to use ASP.NET or Javascript and kubernetes.
No assembly skills? REJECTED
It's literally in the interview. Most of the interviews that I've had, including all of the ones that led to employment, included questions about assembly. Even when I interviewed on-site at Amazon in Seattle, they asked about assembly.
Amazon wanted me diagnosing Linux kernel "oops" reports. That would involve looking at hex dumps and register dumps, then mapping that back to C source code to determine the problem.
There was a place that would have had me writing bare-metal software to generate high-volume network packets for testing network gear.
One place had me port some Linux kernel changes, including assembly code, to x86_64.
Currently I mostly write emulators for undocumented hardware. I use IDA Pro as my disassembler. I keep that running all the time. I can spot a security vulnerability as I look at the binary executable in the disassembler; this is an expected part of the job. Sometimes I need to write assembly code or even raw hex bytes in order to demonstrate how things can happen. At one point I had to write assembly code such that the 16-bit checksum of the binary code didn't exceed 0xffff, not counting the last 2 bytes. Another time I had to write code that didn't have any 0x00 bytes in it; this required modifying the instructions in a hex editor.