How You Practice With Leetcode for Interviews Is Probably Bad

I believe that practising problem-solving coding skills with Leetcode or even AlgoExpert is beneficial, especially if you are unfamiliar with data structures such as stacks, queues, heaps, tries, and so on. When I was actively interviewing for internships in college, I used to buy monthly subscriptions to both. However, I believe there is significant value in understanding what interviewers expect in a technical interview. Even if you find the most optimal solution to a given problem, that is not all that we are looking for (which surprises many people).

During a coding interview, we evaluate candidates on five different axes from the perspective of the interviewer. Some specifics may differ from one company to the next, but the overall criteria remain the same. I'll use a simple coding question as an example, but the same concepts apply as the questions become more difficult or complex.

1. Clarifying Ambiguity

In an interview, suppose I asked you, "given a collection of numbers, return the largest number." Do you jump right into coding, or do you take some time (5, 10, or even 15 minutes) to ask some questions and try to identify some of the edge cases? You will improve your ability to ask questions and identify edge cases over time. If you've never done it before, the next time you're solving a Leetcode problem, consider some of the test cases that Leetcode may be running against your solution behind the scenes. Clarifying questions for the above problem (I purposefully left the question vague because you may encounter this type of wording in an interview) are:

• “How will my input be given to me, will it be in a list, set, etc., of numbers?”
• “What should I return? The largest value or the index of the largest value”?”
• “If the list is empty, what should I return?”
• “Can I assume that the list of numbers will fit into memory” (Not a super crucial question, but it shows that you have some understanding of the limitation of memory).

I find it helpful to think about your solution for ten minutes. You never want to be in a situation where you're in a 45-minute interview and have spent 30 minutes coding out your solution. When you finish coding, the interviewer may say something like, "your solution doesn't seem to work for this edge case; how can we modify your solution to work here?" It could be a simple fix, but what if your algorithm is fundamentally flawed? You'll then have only 15 minutes to rethink your entire solution, which can be extremely stressful and almost certainly means you won't be passing the round.

2. How Do You Respond to Feedback?

If you start coding your solution and I say something like, "do you think we could solve this question with this other data structure instead of using this data structure?"

There are two possible responses. You can either say, "No, I think you're wrong," or you can say, "Sure, let me think about how we can use that data structure."

The actual response I gave may appear exaggerated, but the overall premise is to ensure that if the interviewer offers advice, you don't dismiss it right away. The interviewer probably knows about 95 percent of all the possible solutions to the problem, so they may be able to save you time by steering you away from a solution that may not work for a couple of edge cases.

When interviewees don't know the answer to a question or become frustrated because they can't figure out the solution, they may vent to the interviewer by giving snappy answers or ignoring feedback. The problem is that the person interviewing you will likely be working with you if you were to get hired. If you behave badly during the interview, your interviewer may wonder how you'll react when working on a real project or new feature with little guidance.

3. Communication

Do you tell me (the interviewer) your entire solution before you begin coding, or do you begin coding your answer in silence? I've been in interviews where the interviewee doesn't say anything for 45 minutes (or however long the conversation lasts) and then tells me that their solution works and the time/space complexity. You can imagine how awkward that can be for interviewers, because we don't know what you're thinking and don't know how we can assist you if you get stuck. You don't have to sound like you're teaching me anything, but make sure you give some audible cues about what you're doing or if you're stuck on something every minute or two minutes.

It's perfectly acceptable to ask the interviewer, "Can I take a couple of minutes to think about the problem?" when you're first given the problem (or even throughout the interview). Just make sure you say something before you stop talking for three minutes or more. When discussing your solution aloud, you may not know how to implement something, and it is acceptable to stub out the functionality. You could say something like, "I'm not sure how to implement this specific portion of my algorithm, but suppose I had a function that returns this output and has this space/time complexity when given this input."

4. Coding Ability

This can encompass everything from:

• Do you type quickly?
• Do you have a good understanding of the built-in methods and libraries in the programming language you use, or do you continuously have to lookup documentation during the interview?
• Do you use meaningful variable/function names and create helper methods when some of your logic is starting to get complicated?
• Do you mindlessly click the run button every time you make a small change to your code, or can you write 20 lines of syntax free code and then click run to see what your program does?
• If applicable, do you use classes or some OOO concepts?
• Did you write tests (especially with edge cases) to test the function you created?

5. Understanding Tradeoffs

Every coding problem probably has many different solutions from the brute force way to the most optimal way. It’s always great to say things like, “One way we could solve this problem is by using this solution which will have this time/space complexity.” or “Another solution that would have a higher time complexity, but lower space complexity is … “. Like I said before, this is something that you will get better at over time.

My Specific Gripes with Leetcode and How To Optimize Your Time Using It

You may have noticed that the process of writing code is only one of the things we look for. When I conduct an interview, I want to hire someone who has excellent problem-solving, coding, and communication skills. Technical coding interviews are far from perfect, but when a candidate performs well in them, it demonstrates some talent. I'm on the fence about recommending Leetcode because of the following reasons:

• Leetcode doesn’t make you explain your algorithm out loud before you start writing code. I think this is important because if you can’t clearly articulate your algorithm, maybe you need to spend a couple more minutes thinking about it. I’d rather have a candidate do that then start naively coding up a solution for 30 minutes, hit a roadblock, and have no working solution at the end of the interview. Remember, the brute force solution is better than no answer. First, get a working solution, then a better solution.
• Leetcode doesn’t make you say what the time and space complexity of your algorithm is. You will be asked this question in any technical interview where you write code since that’s how we are objectively able to measure two solutions and say which one is better from time, space, readability, etc. perspective. Additionally, if you say something like the time complexity is O(n), tell me what n (and any other variable you use) means. Does n represent the number of characters in a list, the number of items in a list, or what?
• In Leetcode, you can run your code many times and not get punished, but in an interview setting, you probably will only be able to click the “Execute Code” button four or five times. So make sure you’re more critical of syntax errors or logic errors before testing your code. I think Google was the only company I applied for where they don’t even give you a button to run your code, since you have to write it all in a Google doc. You don’t have to be that extreme, but make sure you don’t rely too much on the run button when creating a solution.
• Leetcode doesn’t force you to think of edge cases or ask clarifying questions since all of that information is given to you in advance.
• Leetcode doesn’t ask follow-up questions like “how would your solution change if we introduced this new requirement,” or “what’s the bottleneck in your algorithm.”
• Leetcode doesn’t penalize you if you have lousy variable names or have 100 line methods. Readable code is something you don’t see very often on the Leetcode submissions for problems.

Conclusion

To summarise, Leetcode is not inherently harmful. Leetcode, I believe, is analogous to riding a bike with training wheels, and in an interview, you will not have those training wheels for support.

It's always beneficial to practise in an environment that closely resembles the actual situation. Most of the time, the people interviewing you will be the same people you'll be working with if you get the job. Interviewers want to know you're smart, but they also want to know you don't have a big ego and are easy to work with.

Furthermore, it is entirely acceptable if you are unable to solve a LeetCode problem and must consult the solution. At the end of the day, we're practising for a real technical interview, and I'd like to show you what to expect.

Data structures and coding questions haven't changed much in the last couple of decades, and they're unlikely to change anytime soon. Any effort you put in today to prepare for technical or behavioural interviews will benefit you later when you interview again (or even at your job/working on side projects).

Try remembering some of the points above the next time you practise Leetcode questions and start treating practise like an actual interview. When I was doing Leetcode, I used to record myself to see how I sounded. When I didn't know the answer, I had a bad habit of rambling or making stuff up (saying "Ummm" or "ugh"). I've gotten better at it over time, but I wouldn't have noticed if I hadn't recorded myself. It will most likely be awkward to watch yourself, but self-reflection is arguably one of the best ways to improve at these things.