[nunez]

On one hand, I think the problem space of the leetcode interviews is helpful, yeah. At that scale, implementing an exponential-time solution where a logarithmic-time solution would work can be costly. Knowing how to optimize the kernel and application call chains to get every ounce out of your resources instead of scaling out endlessly is also helpful, since at this scale scaling out would be incredibly expensive and likely limited by physical space.

On the other hand, a lot of these problems are solved at the FAANGs. For example, at Google, if you need a database that can span to petabytes of data with sub-second queries, you use Dremel and call it a day. If you need a super-fast library for sorting maps, there are probably handfuls of libraries to choose from. So there isn't a guarantee that you'll work on a team that requires this amount of knowledge.

That said, making interviews super difficult and all-encompassing upfront should make lateral transfers really easy, since theoretically you're capable of doing anything.

[xiphias2]

While you are right that these libraries are super optimized, even adding a few features to the machine learning model added significant latency to the ad serving system (about 0.1ms at 99%-ile, which was a blocker for getting into production).

What the more senior engineers showed me that the trick is to understand other parts of the request and find optimizations that I can apply at those stages, and put in the same experiment that I want to launch instead of hyperoptimizing my own code.

Of course you are right that I myself was looking for more technical projects (the only problem was that my team was the one working at night and weekends as well, which I refused to do at that point in my life, as I wasn't in my 20s anymore).