The Mental Hack That’ll Help You Solve LeetCode Problems 2–4x Faster Without Burning Out

If you're short on prep time for DSA/coding interviews because of work, family commitments, or you have an interview coming up soon and you need a faster way to grind LeetCode/NeetCode, this is for you.

The directions vs. journey analogy

Imagine Google Maps and other navigation apps don't exist for a moment, and you want to get from point A to point B, say from a train station in New York to a park.

Actually walking the full journey might take 20 minutes.

But giving or learning the directions might take 30 seconds:

Go straight. Turn left. Turn right. Stop there.

If you already know how to walk, turn, cross roads, and follow directions, then all you need are the directions.

Let's say you had 500 destinations, each from a different train station. All you need are the directions for each one. You don't need to make all 500 trips to prove you can. Learning the directions is more efficient than making every journey.

That's the mental model behind this technique.

A lot of LeetCode prep works the same way.

When you're still learning the basics of a topic, you should absolutely go through the full journey. Type things by hand, make mistakes, debug, and build the foundation.

But once you understand the foundation of the topic you're working on, the training goal changes.

At that point, the question is not just:

Can I type this code?

The question is:

Can I recognise the structure of the problem, figure out the algorithm, mentally build the implementation, check it, and adapt under pressure?

That's where this technique becomes useful.

---

When this technique actually makes sense

This is not a beginner shortcut.

You need to be comfortable with your chosen programming language. You also need enough foundation in the topic you're working on to know what the code should roughly do.

That does not mean you need to have mastered every data structure and algorithm topic.

For example, if you're currently focusing on arrays, you can use this once you understand the basics of array traversal, indexing, edge cases, and common operations.

If you're focusing on recursion, you can use this once you understand the basics of base cases, recursive calls, return values, and how the call stack works.

The key is:

Use this after you have enough foundation in the current topic to mentally picture the implementation.

You can use some of the resources here to help with building that foundation.

If you already have the foundations for the topic you're working on, this can be really useful in the interview-training phase. By interview-training phase, I mean the point where you're more focused on getting better at applying what you know under interview-like pressure.

One example:

You might be targeting companies like OpenAI, Anthropic, or Meta, which repeat questions a lot, but you have a large number of questions to get through, say 200.

At that point, you probably already understand the topic foundation. Now you're trying to cover their past questions so that if something similar comes up, the prior practice will boost your odds. There's nothing better than having seen a question before. The version of you who has practised that question has better odds than the version who hasn't, especially under interview conditions where thinking time is limited.

---

The actual technique

The short version is:

Write the directions. Mentally picture the code. Let AI do the typing. Then check your work. The fact that you did the mental solving is why you lose nothing from a learning standpoint. If you mentally solve it, that's equivalent to having the directions. Typing it out manually is the equivalent of making the journey in the analogy above.

Here's what that means in practice.

First, read the problem and craft the most efficient solution you can come up with.

Once you have the approach, write skeleton comments. This isn't skeleton code.

Skeleton comments are short, plain-English steps that describe what the code should do.

Example:

def get_largest_value(nums):
    # handle empty input
    # set max value to the first element
    # loop through the rest of the numbers
    # update max when the current number is bigger
    # return max value

At this point, there's no full code yet.

Just the directions.

That's on purpose.

The comments should be short, plain English, and specific to the implementation.

Quick test: if the comment doesn't help you picture the code underneath it, the comment is too vague.

---

The important mental step

This is the part people can easily get wrong.

"Mentally picture the code" does not mean vaguely imagining the solution.

It means you should be able to see the actual code you would type, including the syntax.

For example, if the code you need is:

items.pop()

then don't type it right away.

Mentally picture the full syntax first:

items.pop()

That mental picture might take a fraction of a second.

Typing it still takes longer.

The same goes for longer lines.

For example, under:

# loop through the rest of the numbers

you should mentally see:

for num in nums[1:]:

Under:

# update max when the current number is bigger

you should mentally see:

if num > max_value:
    max_value = num

Under:

# return max value

you should mentally see:

return max_value

That mental step is important because it proves the implementation exists in your head, i.e. you have the directions.

You're not asking AI to figure it out for you.

You know what code should appear.

You're just choosing not to spend all the time physically typing it.

The standard is:

If you can't mentally picture the code under the comment, don't let AI fill it yet.

That keeps the technique honest.

---

Then AI does the typing

Once your skeleton comments are clear and you can mentally picture the implementation, you let AI autocomplete handle the repetitive typing.

For example, you can do this in VS Code with GitHub Copilot.

The idea is not:

AI, solve this problem for me.

The idea is:

I've already written the directions. I know what code should go here. Now autocomplete the implementation so I can review it.

The AI is not the thinker.

The AI is the typist.

The final implementation might look like:

def get_largest_value(nums):
    # handle empty input
    if not nums:
        return None

    # set max value to the first element
    max_value = nums[0]

    # loop through the rest of the numbers
    for num in nums[1:]:
        # update max when the current number is bigger
        if num > max_value:
            max_value = num

    # return max value
    return max_value

---

Where the 2 to 4x speedup comes from

If you're practising on your own, a typical medium problem might look like this:

The key is that the thinking stays.

You still figure out the algorithm.

You still mentally build the implementation.

You still review and test the result.

What changes is that you cut the time spent physically typing out code you already know how to write.

That's useful if:

• you have an interview coming up soon
• you're prepping while working full-time
• you have limited study time
• you want to cover more company-specific questions
• you want more exposure to variants
• you're burning out from slow grinding

The benefit isn't just that one problem becomes faster.

The bigger benefit is that you can get more done in the time you have left.

If a problem normally takes 25 minutes, you might only do 2 problems in a 50-minute study block. If this technique brings some problems down to 10 to 15 minutes, that same study block might let you cover 3 to 5 problems or variants.

To put some numbers on it: if you study 3 hours a day for 4 weeks, the traditional approach gets you through roughly 200 problems. With this technique, that same time covers somewhere between 350 and 500 problems, depending on how efficiently you apply it.

---

When not to use it

This is not for:

• complete beginners
• people who aren't comfortable with their chosen programming language yet
• people who don't understand the topic foundation for the problem they're attempting
• people who can't mentally picture the code

Aside from AI-enabled interviews, you usually can't use AI in the real interview.

That's fine.

This isn't an interview tool.

It's a practice accelerator for someone with a strong foundation.

It also trains you to be comfortable crafting solutions mentally, which is actually beneficial in real interviews where thinking time is limited. Being able to do so quickly saves you a lot of time.

---

The practical takeaway

Used well, this technique helps you practise faster without turning your brain off.

If you found this useful, we have a lot more useful learning and interview-performance optimisation tips like this at Coditioning.

If you want to get truly interview-ready with hands-on guidance via coaching and mocks throughout your prep journey, our experienced FAANG engineers are available.

We can also help with: