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.
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.
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:
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.
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:
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.
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…
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.
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 Thank you to our sponsor Devmountain: https://cutt.ly/GrrbLDE
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