How to Pass Leetcode Interviews: The Ritual That Works

  

434 problems, 1450 submissions — my journey to understanding how algorithmic interviews actually work

Introduction

Hey everyone! My name is Evgenii Matsiuk. I’m currently a Staff Software Engineer at X (Twitter), previously at TrustWallet, Careem, and Kaspersky. I’m a co-author of Kaspresso, co-founder at MarathonLabs, and an Android Google Developer Expert since 2020.

Over the past few years (2021–2025), I’ve passed coding interviews at X, Google, Careem, TrustWallet, Yandex, and many other companies. And you know what? I passed every single one. Even though during my Google interview in 2022, I didn’t fully solve the problem — nerves got the better of me. But the interviewer was satisfied, and the recruiter confirmed it.

How did that happen? It’s not about the number of solved problems (though 434 is quite a lot). It’s about understanding what’s actually being evaluated in these interviews and how to conduct yourself properly. That’s what we’ll talk about.

Three Coding Interview Formats

Before diving into Leetcode, let’s quickly run through the coding interview formats you might encounter:

Leetcode-style problems — the most common format. Classic algorithmic problems in a shared editor. This is what this article is about.

Code review + feature in a notepad — in my opinion, the most reasonable format. You do what you do every day: review someone else’s code and write your own. Minor mistakes are forgiven, you can write pseudocode.

Real project in an IDE — the most hardcore option. You need to write a working solution that actually runs. Usually takes 90+ minutes. Good news: you’re often allowed to prepare a project skeleton in advance.

Leetcode remains the most popular format, so let’s focus on it.

Myths vs Reality

Myth #1: You need to solve hard problems and dream about red-black trees

Reality: This was true 5–7 years ago. Now the industry has realized that the ability to solve hard problems says nothing about how you perform in day-to-day work, architecture, and communication.

I’m observing a democratization of the process: the focus is shifting to easy/medium problems and the candidate’s ability to communicate. In all my interviews (2021–2025), I never once got a dynamic programming problem — that “demonic” thing everyone’s scared of.

Myth #2: The result is binary — you either solve it or fail

Reality: Not binary at all. A problem almost always has multiple solutions. Brute force is obvious, and it’s important to verbalize it. An optimal solution is good, but not mandatory.

In that very Google interview, I didn’t reach the optimal solution. But I communicated properly, showed my thought process, and that was enough.

Myth #3: The main thing is knowing the algorithm

Reality: Knowing the algorithm is just one part, and I wouldn’t say it’s the most important one. You might not know the optimal solution at the beginning — that’s normal. What matters is the process: how you think, how you communicate, how you respond to hints.

The interviewer will almost always help you. Listen to them! The hints are usually pretty bold.

Myth #4: Coding interview requirements are different at all levels

Reality: This is true — requirements differ. At junior/middle levels, coding is your main section, and they’ll ask seriously. At senior/staff/principal levels, it’s more of a check that you still remember how to code. System design and behavioral matter more there.

Preparation

Resources

I’ve gone through tons of materials over the years of preparation. Most are either outdated or contain a lot of unnecessary stuff like logic puzzles about “how many manhole covers are in the city.”

For 2026, my main advice is Leetcode Premium. Yes, it costs money, but it’s a reasonable investment. It has:

• Structured courses by topic
• Problems sorted by company
• Quality solutions with explanations

You can start with the basic course. Then, the Learn section for diving deeper into specific topics and the Interview section for preparing for specific companies.

For quick algorithm review, I used a document with the reassuring title “I’ll sleep when I’m dead”.

Mocks — the Key to Everything

Now for the most important part: mocks. Mock interviews. As soon as you’ve mastered the basics, start doing them immediately. Ask friends, find partners online, use specialized platforms.

Until you’ve done at least 10 mocks — don’t waste time on real interviews.

Why is this so important? Mocks give you a real simulation: stress, limited time (15–30 minutes), the need to think out loud. It’s a completely different experience than solving problems alone.

The Problem-Solving Ritual

This is probably the most important part of the article. The right ritual is what separates a successful interview from a failure.

Step A: Listen and Clarify

Listen to the interviewer until the end, don’t interrupt. Then ask clarifying questions. Even if everything seems clear — clarify corner cases:

• What’s the maximum and minimum array size?
• What are the maximum and minimum element values?
• Can there be negative numbers?
• Is the data sorted?
• What’s the maximum string length?
• Can there be duplicates?

These questions show that you think like an engineer, not just a coder.

Step B: Show the Brute Force

Verbalize and show the obvious solution. Actually show it — don’t just say it in words.

Calculate time and space complexity. Ask the interviewer: “Is everything clear? Do you agree with the solution?”

Step C: Discuss Optimization

For medium-level problems and above, there’s usually a more optimal solution. Discuss with the interviewer — do you want to look for it now or implement brute force first.

If you don’t know the optimal solution — don’t panic. The interviewer will give hints. But even if you never reach the optimum — you can implement brute force. That’s better than nothing.

Step D: Implementation

Ask: “May I start coding?” Once you get the go-ahead, start writing.

Verbalize what you’re doing. Literally: “Creating an array for the result. Setting up a variable for the sum. Iterating through the input array…” What I see — I say.

Name variables properly. Not a, b, i, but currentSum, leftPointer, resultList.

If the code isn’t perfect somewhere (and under stress, that’s normal) — leave a comment: // TODO: refactor later. This shows you understand where improvements can be made.

fun calcSum(input: List<Int>): Int {
    // TODO: handle empty input
    var sum = 0
    for (elem in input) {
        sum += elem
    }
    return sum
}

Step E: Debugging

This step is often neglected. But it’s critically important.

Debugging is not “scanning through the code.” It’s writing comments with intermediate values at each step.

More on this in the tips section below.

Tips and Visualization

How to Explain an Algorithm Without Code

When I started preparing, I was stumped: how do you explain how an algorithm works without writing code? Words get confusing, especially if neither of you is a native speaker.

The solution: explain in writing, directly on the data structures.

Working with Arrays

Use indices and pointers as !:

[2, 4, 6, 8, -1, 3][0, 1, 2, 3,  4, 5] !

For two pointers (sliding window):

[2, 4, 6, 8, -1, 3][0, 1, 2, 3,  4, 5] !
          !

When explaining, just move the pointers and show each step. Write out variables:

sum = 1
tempSum = 5

Working with Trees

Draw the tree visually:

        6
    2       8
  1   3   7   9

Use ! as the current position pointer and * as a marker for processed nodes:

        !6
    *2       8
  *1   !3  7   9

Here you can see: started at root (6), went left (2), further left (1), processed 1, processed 2, now at the right child of 2 — that’s 3.

Visualizing Recursion

[1, 2]    !
[4, 5, 6]    !
[7, 8, 9]       !

Each line is a recursion level. The pointer shows where we are.

Debugging in Code

Here’s an example:

fun calcSum(input: List<Int>): Int {
    var sum = 0
    var threshold = 0
    for (elem in input) {
        if (elem >= threshold) {
            sum += elem
            threshold = sum / 2
        }
    }
    return sum
}

Let’s say input = [1, 3, 5, 7, -1, 2, 9].

Debugging looks like this — for each step, write values directly in the code:

// input: [1, 3, 5, 7, -1, 2, 9]//         !
fun calcSum(input: List<Int>): Int {
    var sum = 0       // 0
    var threshold = 0 // 0
    for (elem in input) {        // elem = 1
        if (elem >= threshold) { // 1 >= 0? true
            sum += elem          // sum = 1
            threshold = sum / 2  // threshold = 0
        }
    }
    return sum
}

Moving to the second element:

// input: [1, 3, 5, 7, -1, 2, 9]//            !
fun calcSum(input: List<Int>): Int {
    var sum = 0       // 1
    var threshold = 0 // 0
    for (elem in input) {        // elem = 3
        if (elem >= threshold) { // 3 >= 0? true
            sum += elem          // sum = 4
            threshold = sum / 2  // threshold = 2
        }
    }
    return sum
}

And so on. This is clear for the interviewer and helps you catch errors.

Helper Functions

Sometimes solutions get bulky — 100–200 lines instead of 20–30. Use helper functions that you’ll implement later:

fun someSolution() {
    // main logic
    val diff = calculateDiff()
    // continuing logic
}

private fun calculateDiff() {
    // will be implemented later
}

This lets you stay focused on the main algorithm and show the big picture faster.

One Line Rule

One line — one action. This simplifies debugging and code reading. Don’t write:

if (a > b && c < d || e == f) return doSomething(x, y, z).also { process(it) }

Break it into clear steps.

Corner Cases at the End

First implement the general solution, then add corner case handling:

fun calcSum(input: List<Int>): Int {
    // TODO: handle corner cases (empty input, single element)
    
    // main logic
    ...
}

Pros and Cons of the Leetcode Format

Let’s be honest.

For candidates, there are almost no advantages. Except for the fact that these problems will help you find a job. Algorithm knowledge rarely comes in handy in day-to-day work. You should know data structures and operation complexity anyway — that’s basic. But preparation time adds up significantly.

For interviewers, there are many advantages:

• Interview fits in 30 minutes
• Not much code, easy to evaluate
• Clear checklist
• If desired, you can fail any candidate with a hard problem (no one does this, but the option exists)

Despite the format’s controversial nature, it remains the most popular. But the situation is improving: the focus is shifting from “solved/didn’t solve” to communication and thought process.

Conclusion

Let’s summarize the key points:

1. Myths are outdated. Hard problems and exotic algorithms aren’t as important anymore. Communication matters more than knowing the optimal solution.
2. Mocks are mandatory. At least 10 before real interviews.
3. The ritual matters. Clarifying questions → brute force → discussion → implementation with verbalization → debugging.
4. Visualize. Show how the algorithm works on data structures, don’t just explain in words.
5. Debug in code. Write intermediate values directly in comments.

These rules helped me pass every coding interview over the past 4 years. I hope they help you too.

Good luck with your interviews! 🦫

Share your experience and questions in the comments. What myths about Leetcode have you heard?

More about interviews, mobile development, startups, and life as an engineer in the UK — on my X: https://x.com/e_matsyuk

---

How to Pass Leetcode Interviews: The Ritual That Works was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.