How to Tackle Coding Interviews

A 7 steps bulletproof framework to ace your next technical interview round.

Jul 11, 2025

Hi Friends,

Welcome to the 130th issue of the Polymathic Engineer.

Coding interviews can be intimidating. You are asked to answer a difficult problem on the spot and write code that works while also explaining your thought process to the interviewer. It's not surprising that a lot of smart engineers have trouble with this style.

There is good news, though: if you follow a structured strategy, you can very much improve your results. In this issue, we will see a seven-step plan I made that has helped me and many others do well.

Cut Code Review Time & Bugs in Half

Code reviews are critical but time-consuming. CodeRabbit acts as your AI co-pilot, providing instant Code review comments and potential impacts of every pull request.

Beyond just flagging issues, CodeRabbit provides one-click fix suggestions and lets you define custom code quality rules using AST Grep patterns, catching subtle issues that traditional static analysis tools might miss.

CodeRabbit has so far reviewed more than 10 million PRs, installed on 1 million repositories, and used by 70 thousand Open-source projects. CodeRabbit is free for all open-source repo's.

Get Started Today

Thanks to the CodeRabbit team for collaborating with me to this newsletter issue.

1. Listening

Listening carefully is the prerequisite for any coding interview. Pay close attention to every detail the interviewer gives you when they talk about the problem. Every piece of information could be very important for getting the optimal answer.

For example, if the interviewer says that the input array is sorted that's usually a very important hint. It could mean that a binary search would work better than a linear search. Also, if they say there are limits on the number or range of values that can be input, this can help you choose the algorithm and data structures you use.

Don't start coding or even just thinking of ideas right away. Instead, take your time to make sure you fully understand what is being asked. A not so common mistake is to think you know what the problem is asking for, only to find out later that you've been solving the wrong problem.

A helpful technique is to rephrase the problem in your own words, since it both helps you understand better, and shows the interviewer that you are actively thinking about the problem.

Don't hesitate to ask clarifying questions. This isn't a sign of weakness, but it shows that you're thorough and careful. Good questions might include:

- "What's the expected input size?"

- "Are there any constraints on the values in the input?"

- "How should I handle edge cases like empty inputs or negative numbers?"

Remember, a good interviewer wants you to succeed and not trick you. However, they may intentionally leave some details vague to see if you'll ask for clarification.

2. Create an Example

Creating an example that can represent the problem well is a step which has multiple purposes.

First, it helps you double-check your understanding of the problem. If you can't come up with a good example, you might have misunderstood something. Second, it makes you think about what you could do. It's much easier to solve a concrete case than to think about the problem abstractly.

The examples that interviewers give are often small or only show simple situations. They are meant to let you know what the problem is, not how to fix it. So, create an example that is:

Big enough to represent the general problem
Complex enough to push your thinking toward a solution
Not too focused on special cases (you'll consider those later)

For instance, if the problem is finding duplicate numbers in an array, don't just use [1, 2, 3, 2] as your example. Create something more substantial, such as [3, 1, 4, 2, 5, 3, 6, 2, 9], to help you think about how to handle multiple duplicates efficiently.

You can always verify your example with the interviewer. A simple "Does this example make sense for the problem?" can save you from going down the wrong path.

3. Brute Force

Most interviewers don't expect you to come up with the most efficient algorithm right away. The best approach is to start with a brute force solution and explain its time and space complexity.

Finding a brute force solution means that you have a working answer to the problem, which is already a point in your favor. In addition, as we’ll see in the next step, many improvements can be made starting from this basic solution.

Don't worry if your brute force approach is inefficient. The goal here is to show that you can solve the problem correctly, even if not optimally yet. Just be clear about the limitations of your solution. For example, if you're using nested loops, acknowledge this directly: "This approach will work, but it's not the most efficient because it has O(n²) time complexity."

In some cases, a brute force solution might be enough if you clearly explain the trade-offs involved. Not every problem needs the most optimized solution, especially if the input size is guaranteed to be small.

4. Optimize

Once a brute force answer has been found, it's time to look for ways to make it better. The most effective approach is the BUD optimization:

Bottlenecks: Identify operations that are slowing down your algorithm
Unnecessary work: Find operations that can be skipped altogether.
Duplicated work: Look for calculations that are done more than once.

For example, if your brute force solution uses nested loops to compare every element with every other element, that's a bottleneck. You might optimize it by using a hash map to cut the time complexity from O(n²) to O(n).

Time-space tradeoffs are another helpful way to improve performance. Think about: "Can I use additional space to speed up my algorithm?" For instance, using extra memory to store data can often cut runtime by a huge amount.

Don't forget to consider common patterns and data structures that might simplify your solution:

Would a hash map be useful for lookups?
Would a stack or a queue work well for this problem?
Is this a graph problem in disguise?
Could dynamic programming avoid recalculating results?
Would a divide-and-conquer approach work in this case?

One more helpful method is to solve a problem by hand and then try to figure out how you came up with the answer. How did your mind think about the issue? Can that be turned into code?

Using recursion can sometimes make hard tasks easier to solve. Step one is to solve the problem's most basic case. Then, move on to the next case. This way of thinking can help you find elegant solutions to problems that appear challenging at first.

Lastly, look for information in the problem that you haven't used in your brute force answer yet. Interviewers often include details that point to better ways to do things.

5. Walk Through

Before writing any code, take time to walk through your optimized algorithm step by step. This helps you clarify what you're going to write and can keep you from making a lot of code mistakes.

Think of this step as creating a detailed plan for your code. In the same way nobody would start building a house without blueprints, you should not start coding without having a clear picture in your mind of what to write.

As you walk through, talk out loud about what you're thinking. Phrases like "First, I'll initialize a hash map to keep track of..." or "Then I'll iterate through the array and..." help the interviewer follow your reasoning.

By the end of this step, you should have a clear idea of what your code will look like. You should know which variables you'll need, what your main logic will be, and how you'll handle any special cases.

6. Coding

It's now time to write code. Your solution should be both correct and well-organized.

Keep your code modular and organized. Use variable names that make your code self-explanatory. For example, instead of using 'i' and 'j' everywhere, choose names that describe what the variables represent like 'startIndex' or 'currentSum' .

A good approach is to code from the bottom up. First, build the high-level structure that solves the problem, and then add the details. For example, you might use helper functions that you will implement afterward.

Don't stress about getting everything right the first time. It's better to get something that works and you can improve than to get stuck trying to make everything perfect immediately.

It's fine to say that you're not sure about a certain part of your code. You might say, "I'm not completely sure if this syntax is correct, but the idea is to iterate through each element and check..."

What's important is that you keep talking through what you're writing so that the interviewer can follow along and give you hints if you're heading in the wrong direction.

Do not forget that style, spacing, and indents are important. Even in an interview, code that is well-formatted shows that you are professional and pay attention to details.

7. Testing

Many candidates think they're done after coding, but testing your code is equally important. It shows that you pay attention to the little things and care about quality.

The best thing to do is going through your code line by line, as if you were doing a code review. Check for syntax errors and common errors like:

Loop conditions (should it be < or <=?)
Array indexing (off-by-one mistakes?)
Edge cases (what happens with empty inputs or extreme values?)
Mathematical operations (are your additions, subtractions, and increments correct?)

After your code review, run through your solution with a simple test case. This helps you test what your code actually does, not what you think it should do. You can catch subtle issues only if you follow the execution path exactly as written.

In case you find a bug, don't panic. Bugs happen even to experienced engineers, and how you handle them is more important than the fact that they happened. When you encounter a bug: