Study basic algorithms and data structures. The purpose of this is not to pass a leetcode test, those are obnoxious and those companies that conduct them should

Study basic algorithms and data structures. The purpose of this is not to pass a leetcode test, those are obnoxious and those companies that conduct them should be embarrassed. The purpose is to learn how to analyze systems and their performance on two primary metrics: time and space. This isn't all there is to understanding larger systems (simplistic counting the steps of a loop is not sufficient if you're swamped by IO access times, for instance, but it's a start). But you need to be able to examine a system and understand tradeoffs. When deciding between different data structures you're often faced with a situation like: X is faster at A, but slower at B; Y is the opposite. Which do you choose? I can't tell you, you have to know your intended use-cases. Will A dominate in your application, or B? This is the kind of thinking that scales, too. A database that's better at random access reads and writes is better for some applications than one that's optimized for sequential reads but lousy at random writes, so choose the suitable option based on a reasonable expectation of your system's needs. Study parallel programming (that is, actually having two or more threads/processes/whatevers running simultaneously). This will help you understand the limits of parallelism in speeding up programs, but also the potential for some programs. You'll learn about how to divide work across N processors, the limits of performance gains, and where you will get performance losses (critical ones: synchronization and communication). Study concurrency so you can see how to make use of asynchronous patterns. I don't mean strictly async/await style, just how to use whatever language/OS facilities to avoid unnecessary blocking. Like, if you're making a network query it can take seconds or longer to resolve (depending on location, size of the data, remote server load, etc.). Your program shouldn't wait if it still has other things it can do (if it doesn't, then let it wait). Use a profiler, study your real systems and see where they spend their time. What functions get called the most, what functions or syscalls consume the most time. Is there a file/resource that's constantly being used? I once sped up a program by around 60x just by realizing that the previous coder was repeatedly reading from the same file. It wasn't needed, he could have read from it once (optimal), or at least cached it in memory (though memory wasn't so plentiful then, it would've been a tight fit on a mid-00s desktop, but fine today). Apply the ideas above to analyzing it and improving it.