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
