I get that Big Tech jobs are glamorized the way high-paying jobs in Big Law, High Finance, etc. have historically been glamorized, but unlike professions like law and finance, there are lots of opportunities for people with even decent development skills to make really good money today even if they don't work for Big Tech.
As an example, my friend's son is making well over $120,000 annually as a freelance PHP developer with a few years of experience. He's in his late 20s, doesn't have a comp sci degree and lives in a lower cost of living city where he's probably at least in the top 5% of earners.
On the flip side, I know people who are hiring for developers and they're more and more flexible, especially in regards to location and remote work, because the demand for decent developers greatly exceeds the supply.
Why someone should feel compelled to pretend that they problem solve differently to ace a whiteboard in this market is beyond me.
There are lots of people working in tech-related jobs at/for companies not named Facebook, Amazon, Apple or Google who earn well above average incomes.
How to make this look like underachievement? Claim that these people are fewer in number than they actually are and suggest that there are hoards of 20-something FAANG engineers making $500,000/year+ such that a freelancer pulling in $120,000 is somehow a loser compared to his peers.
> There are other routes to moderate wealth but few as easy and reliable.
If it was as easy as showing up with a comp sci degree and a heartbeat, why is prepping for whiteboarding interviews even a thing?
> "Why someone should feel compelled to pretend that they problem solve differently to ace a whiteboard in this market is beyond me."
and I'm making observations that I feel adequately explain why someone might want to pass a whiteboard interview at a big tech company. It's completely valid to not want to do that as well, but you said that you couldn't understand why someone would want to, and I've explained why someone might.
> If it was as easy as showing up with a comp sci degree and a heartbeat, why is prepping for whiteboarding interviews even a thing?
I didn't say it was easy. I just said there are not other routes I'm aware of that are easier.
I was only pointing out that there are a lot more people who earn really good incomes in tech-related fields who don't have formal STEM educations. This isn't as uncommon as your comments seem to suggest.
Frankly, a lot of web and mobile app development doesn't require a computer science degree, nor is a formal computer science education the only form of "training" there is. Heck, assuming computer science curriculums are the same as when I was college-aged, I wouldn't even consider them "training" for a typical development job today.
> I didn't say it was easy. I just said there are not other routes I'm aware of that are easier.
I've dated both a lawyer (who worked at a Big Law firm) and an investment banker (who worked at a bulge bracket firm) in the earliest stages of their careers. Frankly, I don't think making a really good living in these professions is any more difficult than "FAANG worker". Different people have different aptitudes and when someone aligns his or her aptitudes to his or her career choices, everything sort of looks "easy".
That doesn't match the reports of work life balance I have heard from practitioners of those professions vs. practitioners of programming. But I don't have any reliable, objective evidence to share on this point of view.
Personally, I like to continuously implement and clarify in small tight loops. It might look something like: implement a rough structure with lots of empty functions and very basic control flow. Ask questions. Restructure. Ask more questions. Restructure again and add implementation detail. Etc etc.
This way of working is tied with my thinking. It reveals the problem to me over time instead of all at once. I get a deeper understanding this way.
There is an assumption by some people that my process is wrong. They would argue that I should instead break the problem down on paper, or in my head, or using test driven development, or with design documents etc etc. But this is the process that I've found works best for me.
I can enforce a particular process to please interviewers (and I have). But solving the problem becomes much harder.