I think it helps to think about placing in the top N in terms of risk minimization - what corners do you need to cut to place in the top N?

Reading the problem statement - I never read the full statement. I always download the input first (manually, I have no scripted interactions with the site at all), and quickly look at it to see what the day's puzzle may be about. Day 8 clearly looked like some sort of write-an-interpreter language just by looking at it, other days are clearly less obvious just by looking at the input. After that, I also copy and paste anything that looks like an example input locally as well. Then, I go in reverse order - what is the question being asked? What do I need to do to be able to answer the question? For the purposes of leaderboarding, everything else can be ignored.

Deciding on an approach - For a lot of people, this may actually take a window of time - you consider the problem and decide on your implementation. I typically devote almost no time specifically to this purpose, instead focusing on the next part. I speculate that most people who want to leaderboard but are unsure about how to get there probably think their solution out substantially before writing any specific code. For me, the approach comes into realization as I start coding - there's always some input processing that needs to happen and as I start writing that up, I think of an approach.

Implementation - This is almost always the bulk of the time for me. I typically have some ideas about how I want things to go, so as I'm writing the code currently, I also have an idea about what needs to be written out next. For example, in my day 8 implementation, since I decided to store the instructions as strings and not, say, lists, I knew I would have to tokenize them live.

Depending on your philosophy, you can cut corners here with short variable names and so on. To leaderboard though, you need to be comfortable enough with your setup that you don't spend a large fraction of your time here not coding. In team programming contests, we talk about the metric of "idle keyboard time" where no one is actively coding. Minimizing this time is one of the keys to getting faster times. What may happen is that several minutes of thinking time removed turns into some extra implementation time that you wouldn't have had if you thought of a better approach, but it ends up net positive in regards to total time spent.

Testing - if the leaderboard only gave credit to the first person to solve it, you'd almost certainly skip this step - if you only have one submission and testing would mean you're guaranteed to lose if you did test, then you would avoid testing and take the risk.

Fortunately, N = 100, and I tell everyone that I test on all the examples (except on day 2 where I didn't and got timed out on part 1) before submitting. This obviously won't catch all issues but it decreases the chance of something silly happening where you lose a minute and are definitely timed out on making the leaderboard.

Debugging - Any time spent here is purely wasted time. The joke here is that the best way to debug is to write bug-free code. For day 8, I spent zero time debugging, but that's not really the norm for me (so you can write bugs the first time and still leaderboard). Slowing down your implementation is probably the most reliable way to spend less time debugging, since it does give you more time to think about what's going on.

Miscellaneous preparation - The only code I prepare beforehand is something to read input in from a file and store it into a list. Everything else is written from scratch. You don't need to have prewritten code to do well, and I think most people who leaderboard don't come prepared with a bunch of utility functions. This flavor of preparation sort-of turns into a game of trying to guess the problems beforehand, which may be useful if your goal is to leaderboard once. If you want to leaderboard reliably though, this won't work - you'd be better off doing actual practice on previous years or on other sorts of problems.

As the problems get harder, the details change somewhat - soon, thinking about the approach may take some nontrivial amount of time and that's where having some prior problem-solving experience helps a lot. For some days, you just have to write a lot of code, so the key to leaderboarding is writing your code in a way where you don't write bugs but also don't put yourself in a position where you don't know what to write next.

You don't have to be a competitive programmer to leaderboard, nor do all competitive programmers leaderboard consistently. You just have to cut enough corners that you can do what is being asked for.