How You Practice With Leetcode for Interviews Is Probably Bad

How You Practice With Leetcode for Interviews Is Probably Bad

I’m writing this article because I never want to have someone put in 100s of hours into Leetcode and have them get this false sense of confidence that they can pass any coding interview.

Image for post

Photo by Pexel

I’m writing this article because I never want to have someone put in 100s of hours into Leetcode and have them get this false sense of confidence that they can pass any coding interview. Then, they get rejected from all of their interviews because they don’t understand the technical interview process or the criteria being assessed. That feeling of remorse when you tell yourself, “I wasted 100s of hours and/or 100s of dollars on Leetcode or other similar websites that I could have used for (insert any activity here)’ is a pretty painful experience and I’ve experienced it firsthand.

I think that it’s great to practice your problem-solving coding skills with Leetcode or even AlgoExpert, especially if you are unfamiliar with data structures like stacks, queues, heaps, tries, etc. In the past, I’ve purchased monthly subscriptions for both when I was actively interviewing for internships in college. However, I think there is a lot of value in understanding what interviewers are expecting in a technical interview. Even if you were to get the most optimal solution for a given problem, that’s not all we are looking for (which surprises many people).

From an interviewer’s perspective, we evaluate candidates on five different axes during a coding interview. Some of the specifics may vary from company to company, but the overall criteria remain the same. I’ll use a trivial coding question as an example, but you can imagine that the same concepts apply as the questions get harder or more complex.


1. Clarifying Ambiguity

Suppose I gave you a question like, “given a collection of numbers return the largest number,” in an interview. Do you immediately start coding, or do you spend some time (5, 10, or even 15 minutes) asking some questions upfront and try to identify some of the edge cases? Over time, you will get better at asking questions and identifying edge cases. If you have never done this before, next time, when you are solving a Leetcode problem, start thinking about some of the test cases, Leetcode may be running against your solution behind the scenes. Clarifying questions you may want to ask for the problem above (I purposely left the question vague since you may face 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 you need to ask, but it shows that you have some understanding of the limitation of memory).

I find it super useful to spend even ten minutes of your time upfront thinking about your solution. You never want to be in a position where you are in a 45-minute interview, and for 30 minutes you have been coding out your solution. Once you finish coding, the interviewer may say something like, “your solution doesn’t seem to work for this edge case, how can we change your solution to work with this case?” Maybe it’s a simple fix, but what if your algorithm is fundamentally wrong? You will then only have 15 minutes left to rethink your whole solution, which can be super stressful, and you probably won’t be passing the round.


2. How Do You Respond to Feedback?

If you start coding out your solution, and I say something like “instead of using this data structure, do you think we could solve this question with this other data structure”? There are kind of two ways to respond. Either you can say something like:

  • “No, I think you’re wrong” or,
  • “Sure, let me think about how we could use that data structure.”

The actual response I gave may sound a bit exaggerated, but the overall premise is to make sure if the interviewer offers some advice, you don’t immediately disregard it. The interviewer probably knows about 95% of all the different solutions for the problem, so they may be helping you by steering you away from a solution that might not work for a couple of edge cases, which will save you time.

Sometimes when interviewees don’t know the answer to something or get frustrated because they can’t figure out the solution, they may take that frustration out on 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 act like a d*** in the interview, your interviewer may wonder how you will respond when working on a real project or new feature when there isn’t a lot of clarity around what to do.

interview programming technical-interview software-engineering leetcode

Bootstrap 5 Complete Course with Examples

Bootstrap 5 Tutorial - Bootstrap 5 Crash Course for Beginners

Nest.JS Tutorial for Beginners

Hello Vue 3: A First Look at Vue 3 and the Composition API

Building a simple Applications with Vue 3

Deno Crash Course: Explore Deno and Create a full REST API with Deno

How to Build a Real-time Chat App with Deno and WebSockets

Convert HTML to Markdown Online

HTML entity encoder decoder Online

Software Developer vs Software Engineer — Differences: Bogus or Real?

In this article, see if there are any differences between software developers and software engineers. What you’re about to read mostly revolves around my personal thoughts, deductions, and offbeat imagination. If you have different sentiments, add them in the comment section, and let’s dispute! So, today’s topic…

My Advice After Interviewing 100+ Software Engineers

This awkward and stressful thing between emerging a hero after completing the 12 labors of Hercules and the pointless successive hula hoops jumps of a circus trained animal, which we lightly call job interviews. We all hate them, yet they are an unavoidable fact of our professional lives.

How to Build a Pipeline of Software Engineering Interviews Without Relying on Referrals

The best way to get hired by a company is always with a warm introduction. But what if you’re new to software engineering (I have less than 2 years of professional experience) and don’t have a large network of people who can refer you into the company?

Top 5 Technical Whiteboard Interview Resources with Senior Software Engineer Dylan Israel

Top 5 Technical Whiteboard Interview Resources with Senior Software Engineer Dylan Israel Thank you to our sponsor Devmountain: https://cutt.ly/GrrbLDE

How to Interview Your Interviewer

How to Interview Your Interviewer - It’s near the end of the interview and it’s time for you to ask your interviewer questions. Figure out if this company is worthy of you