Comment by Jensson

Maybe the review tooling you use aren't good enough? At google it shows all test runs related to the change, it shows linter information inline in the file diffs, you automatically associate it with tasks it is meant to solve and you write a 100 word description to explain what it is doing and why.

If the change adds tests, has proper naming, solves the issue it says it is solving in a reasonable way, doesn't solve anything it doesn't say it is solving, and none of the tools complains then you just accept it after looking at the tests being reasonable and the code not looking strange. It takes a while to get new engineers where they do this consistently before review, and then review takes time, but once you know how to write changes that are easy to review then reviews are very quick.

Edit: Btw, optimizing the code you write to reduce review time is also another aspect of productivity. It isn't productive to give a lot of extra work to others, so you practice until everything is as obvious as possible. And as people get used to your changes being easy to review it gets even quicker.

No, its mostly how to structure the full computation flow for different things. If there were an easy set of patterns then it would already be in some book, these things are skills you can't put in a book.

For example, when is it useful to create a function instead of writing the code inline? Many times the amount of code grows exponentially with problem size unless you properly create good functions, so you need to learn to get good at that. Code reuse also greatly improves how fast you can write the solution and reduces bugs, so it is good even when it isn't absolutely necessary.

Where should the data be, who should own what data, how is the data supposed to be found where you need it? And so on. Many problems requires you to create quite elaborate data structures and relationships, finding the right data in a reasonable amount of time is one of the hardest problems to solve even in competitive programming.

Caching and lazy computations as well, it is used everywhere in competitive programming. The fastest solution is where you don't do anything at all, so you get good at understanding how and when to cache results, when to throw out caches in order to handle new data etc.

Writing proper tests, since you get no credit if your code fails for any case you need to write tests that stresses all parts of the code you are unsure about. This teaches you to get really good about understanding the weaknesses in the code you write, debugging and creating solutions that are bug free.

Stuff like that is really important to get good at competitive programming, you need to be able to get good answer those questions in minutes for complex problems if you want to compete with the best in the world. Now you might notice that many basic data structures and algorithms are just solutions to the above problems, the point is to learn many generic cases of the above so you can compose your own data structures and algorithms as everyone of the harder problems requires you to do that.

And as you can realize these things are very useful for any sort of program, not just competitive programming. Managing data layouts and when it is useful to create functions is the majority of normal programming, if you can do those really quickly then there isn't much left that will take time.

Now, the bad rep competitive programming has is mostly that people just do the easy problems that can be summarized as "implement this basic algorithm". Real competitive programming isn't like that at all. Of course you need to be able to do the simple algorithms, but knowing how to implement the algorithms is just table stakes.

"Don't I practice these things when writing normal programs?"

Not in the same way. Competitive programming is about doing these in their pure form. In normal programming there are so many other things that it is hard to focus on the code, while in competitive programming all you have is code and then a really good test suite you can do to verify your solution once you think you are done. This way you practice a huge range of programming chunks really quickly, compared to trying to test them out and learn them in real world codebases.

Edit: Btw, last time I checked Leetcode didn't have many questions that stresses these important points, its mostly just useful to learn algorithms used in these interviews, it isn't good to learn programming. There are many good competitive programming sites to use instead. Leetcode is good if you want to pass interviews with minimal effort right now, but it isn't good if you want to get good. Also you just get good at chunks, you will still need to practice writing and structuring larger programs and solutions. But practicing that is way easier when you have mastered these chunks.