How I Got Good at Coding Interviews

Solving 500+ LeetCode problems doesn’t mean that you can pass any coding interview.

For a long time, I focused on solving as many coding problems as I can to maximize my chances of success in interviews.

But when the interview came, I'd mess up.

My mind would go blank, or I'd make mistakes I never made at home.

After failing many interviews, I realized that solving problems under interview pressure is entirely different from solving problems in the comfort of home.

In this article, I’ll share the steps that transformed my approach to coding interviews and tips to help you optimize your solution.

I will discuss the mindset shifts and practical strategies you can apply to reduce mistakes and increase your chances of success.

1. Mindset 🧘‍♂️

First, let's talk about mindset.

I used to feel anxious and nervous during interviews, and that often caused me to mess up, even on easy questions.

But here's what I learned: most interviewers are friendly people who want you to do well.

Imagine you're talking to a friend. How much more relaxed would you be?

By thinking this way, you can feel calmer and more confident.

Remember, being confident doesn't mean you know everything; it means you're comfortable with trying your best.

For me, practicing meditation and deep breathing exercises (eg.. Wim Hof Breathing) before interviews made a huge difference.

2. Introduction 🎤

Next, let's discuss how you introduce yourself.

At the start of the interview, you'll usually introduce yourself. Surprisingly, many people don't prepare for this and end up talking too long.

Every extra minute you spend here is a minute less for solving the coding problem.

Prepare a short and clear introduction about yourself that can be delivered within two minutes. Practice it beforehand so that you can deliver it smoothly.

This shows respect for the interviewer's time and starts the interview on a good note.

3. Understand the Problem 🧠

Now comes the main part: understanding the problem you're given.

It's tempting to jump straight to the solution, but if you don't fully understand the question, you might end up solving the wrong problem.

Take some time to read the problem carefully and pay attention to unique details.

For example, if the problem mentions a sorted array, that's a significant hint.

Ask Clarifying Questions

If anything is unclear, ask questions. Interviewers appreciate when you seek clarity.

Example Problem:

Given an array of integers, return the indices of the two numbers that add up to a specific target.

Clarifying questions you might ask:

• Can the array contain negative numbers?

• Can the input array contain duplicate numbers?

• Is there always exactly one solution?

• What should I return if no two numbers add up to the target?

• Does the order of the indices in the output matter?

Don’t ignore any part of the problem statement and don’t assume anything that’s not explicitly stated in the problem.

Whenever you are making any assumptions, confirm them with the interviewer.

Input/Output Examples

Go over a few input and output examples to make sure you get it.

Draw them out if it helps, especially for visual data structures like trees or graphs.

Binary tree input examples

This can dramatically improve your understanding.

Try to take examples that cover different scenarios of the problem. Think about any edge cases that might come up.

For our example problem, here are some input and output examples:

Remember, it's not about being fast; it's about being correct.

4. Plan your Solution 📝

Once you understand the problem, it’s time to work on the solution.

Start Simple

Start by thinking of a simple approach (e.g.. brute force) to solve it, even if it's not the most efficient. This shows you have a basic understanding.

You don't want your interviewer to think that you're struggling to see even the easy solution.

Remember, you're not expected to find the perfect answer immediately.

Optimize

Once you have a brute force algorithm, work on optimizing it.

Here are few things you can consider:

• 📊 Leverage Unused Information: Don’t overlook any small detail. For instance, if the problem specifies that the array is sorted, this can drastically change your approach.

• 🔄 Reverse-engineer input/output examples: Sometimes, simply working through a few input/output examples can reveal hidden patterns. Start with basic examples, but then challenge yourself with more complex or edge case scenarios.

• ⏱️ Precompute information: If certain calculations are repeated multiple times, consider precomputing them. For example, prefix sums or frequency counts can help you avoid redundant calculations later.

• ⏳ Make Time vs. Space Tradeoffs: Sometimes it's worth using additional memory to speed up your solution.

• 🔍 Use a hash table: Hash tables are widely used in interview questions and should be at the top of your mind.

• 💡 Data Structure Brainstorm: Think about different data structures or algorithms that might help. Run through the popular data structures and try to apply each one to the problem at hand.

• ✅ Keep it Simple: Avoid overcomplicating your solution. At every stage ask yourself, "Is there a simpler way to do this?". This will not only make your solution easier to understand but it will also reduce the chances of errors during coding.

If the problem seems big, break it down into smaller parts and solve each part step by step. This makes it easier and shows the interviewer how you think.

Before diving into coding, discuss the time and space complexity of your approach.

Get a clear understanding of the overall structure of the code and the sequence of steps. You should feel confident about how each part of your solution fits together before writing a single line of code.

If it helps, write out the steps of your solution.

If you don't understand exactly what you're about to write, you'll struggle to code it. It will take you longer to finish the code, and you're more likely to make major errors.

5. Write the Code 💻

Now that you have an optimal algorithm and you know exactly what you’re going to write, it's time to code.

Pick a programming language you are most comfortable with unless the job requires a specific language. This will allow you to focus on problem-solving rather than syntax.

Early in my career, I used C++ for coding interviews, but now I use Java since most of my industry experience has been in Java.

As you write your code, explain your thought process aloud. This not only keeps the interviewer engaged but also helps you stay on track.

Keep It Clean and Modular

Use clear and meaningful variable and method names to make your code easy to understand for both you and the interviewer.

Avoid single-character variables like x or y unless they’re loop counters. Names like currentMax, sortedArray, or calculateSum(..) make your code more understandable.

Write clean, modular code that’s easy to follow. Break your solution into functions or methods wherever appropriate.

Prioritize the Core Logic

If you're pressed for time, focus on coding the most critical parts first—the core logic that solves the problem. You can always come back later to add extra details (eg.. utility methods) if time permits.

If you finish early, take a moment to refactor your code. Simplify where possible, improve readability, and ensure it adheres to best coding practices.

Test Your Solution

Once your code is complete, test it thoroughly.

Use the examples and edge cases you considered earlier to verify that your solution works as expected.

Dry run the code manually with different inputs, checking for correctness and handling of edge cases like empty arrays, null values, large inputs, or unexpected values.

6. Finish Strong 🏁

At the end of the interview, you’ll often be given the opportunity to ask questions.

Prepare some questions about the team or the work you'll be doing. This shows you're interested and engaged, signaling to the interviewer that you’re serious about the role.

But remember—interviews don’t always go perfectly.

Sometimes, the questions are unusually difficult, or you just weren’t at your best that day. And that’s okay. Everyone has off days.

What truly matters is that you treat every interview as a learning experience. Reflect on what went well and identify areas where you can improve for the next time.

Each interview, whether successful or not, is a stepping stone to becoming better and more prepared for future opportunities.

---

Hope you enjoyed reading this article.

If you found it valuable, hit a like ❤️ and consider subscribing for more such content every week.

If you have any questions or suggestions, leave a comment.

Checkout my Youtube channel for more in-depth content.

Follow me on LinkedIn, X and Medium to stay updated.

Checkout my GitHub repositories for free interview preparation resources.

I hope you have a lovely day!

See you soon,

Ashish