[e4e78a06]

I think you would be surprised how many 100k engineers at Fortune 500 companies can't do things FAANG engineers would consider very basic. It's not that there's a 7x and a 1x engineer but that there's a 0.1x and a 1x engineer.

For example I did a stint at a F500 company where 1) a data engineer did not know how to use multiprocessing to parallelize a multi-terabyte S3 upload 2) an internal tool that fired off hundreds of network requests did not use concurrency and hence had 30+ second latency 3) a certain other team was dumping hundreds of terabytes of logs that nobody even knew the schema of into S3 automatically, and none of it was ever touched. Also seen: "data scientists" who did not know Python and executives that spent more time talking about Scrum than any concrete execution.

[beebmam]

Exactly. Essentially, there are a lot of frauds in the industry.

[taeric]

To be fair, you'd also be shocked to learn how many top developers will rarely need any of those tricks. Even more shocking, to learn that FAANG developers are just as guilty of many of these "sins."

Take the uploading to s3 point. If you are saturating your network... going multithreaded will do nothing. If you are not, find out why.

The other examples are also lacking a lot of details. 30 seconds of latency can be bad, of course. But so can adding concurrency to a team that doesn't understand it well. (Really, this one sounds like it just needs more context. I'd normally push to remove extra calls moreso than jumping to concurrency. But, each has its place.)

Edit: And the logs... this is just a result of not putting cost as a tracked item for teams. Too many folks fall afoul of a hoarder mentality when it comes to logs.

[staticassertion]

FAANGs are full of terrible programmers. It's obvious. What they do have though is a higher number of good programmers, and they try to leverage them as best they can to make use of the bad ones.

[taeric]

I hesitate to call them terrible. Developing is a hilariously multi paradigmed skill that is tough to train. Such that a good programmer may make a terrible developer, without the appropriate supporting team.

Similarly, an otherwise great developer can be horrible in a team that doesn't know how to use them.

[carlmr]

>The other examples are also lacking a lot of details. 30 seconds of latency can be bad, of course. But so can adding concurrency to a team that doesn't understand it well.

It might also be that it's not worth spending effort on speeding up some script like this. How often does it run?

Do these 30 seconds matter? Maybe they do now but they didn't in the beginning, but then that's ok, too, and you refactor.

[devoutsalsa]

I’ve worked in demanding startups where I question my own competence and lethargic enterprises where I’ve never felt more under challenged. It’s hard to find a good job that strikes a nice balance.

[mym1990]

Fraud is a complete overreaction. A fraud might be someone posing as a doctor with no doctoral degree, or an electrician with no such training. Software is so broad and has no real, agreed upon training that it simply a gap between what an employer thinks someone can do and what they can actually do.

[david38]

No, there is fraud. People who know they can’t do the role, but memorize or cheat on the interview because the lure of money is too much.

[jandrewrogers]

Fraud is a bit strong, but there are many people that have mastered the art of beating that particular system. I've met engineers that have become exceptionally good at pattern matching to the FAANG hazing ritual but which otherwise have unremarkable engineering skill.

[tharne]

Did we work together :) ?