I'm very sure that the GTA devs understand the difference between O(n^2), O(n), etc. They just didn't catch this particular way in which the compiler/standard library changed the complexity time dramatically. The reason for why they didn't catch it is up for debate, but it's surely not because they don't understand basic "Big O" concepts.

edit: actually, nevermind. I realize you're probably referring to the hashmap lookup part, rather than the strlen() part?

Most likely because the bottleneck for loading was somewhere else when they tested it originally quite likely the slow HDD of the consoles of the time.

GTA V came out 8 years ago, it had to run on the base PS4/Xbox One not to mention the PS3 and 360 these were the systems it was first validated on.

It also had much much less content at the time.

As the game released on PC and the amount of content grew the loading times didn’t regress but they also didn’t improve.

So when your benchmark is a console that loads a game in 5-10 minutes no one probably spent any time investigating what the bounds on a modern PC with PCIe storage should be.

I was writing about the person who couldn't ,,invert'' a binary tree. It's totally fine, he can be a great programmer, even a great CEO, he's just probably not the best fit to Google SWE role.

> The guy who decreased GTA loading time by 70% understands the difference between O(n^2), O(n*log(n)) and O(n). That's exactly what a big company is looking for, not a successful product.

I haven't been at any that have cared (none of my past jobs' have been FAANG, but several have been in the over 10k employees size.)

*SOME* potential colleagues care, and a VERY FEW managers care that you know that, but I have found that to be the exception.

I was working on the Google Ads backend, and we had a strict 20ms timeout. The managers didn't care about the algorithms themselves, but my change had a 0.1ms impact on latency in the experiment arm, for launching that you need director level exception approval.

My tech lead actually helped me by saying that the trick is that instead of trying to speed up my own code base (which was really hard), it's easier to find something to improve outside my change to balance for the 0.1ms impact inside the same experiment.