Nailing Coding Interviews: Mindset Matters
Hey there, awesome readers! This time, my newsletter is taking a detour from the usual. Itβs also going to be a tad longer, so bear with me. π
Usually, my posts focus on selecting a problem, like the below
elucidating the solution approach, sharing code, and analyzing time and space complexities. But coding prowess is only part of the equation. There's more to it than code β yup, mindset matters too! π§ π‘
This will be the first of a multi part series where I'll delve into the strategic approach for acing coding interviews, the right way! π―
Granted, preparing for coding interviews is multifaceted, and it's infeasible to cover every aspect in a single post. In this article, my aim isn't to discuss pre-interview preparation but rather to discuss how to approach coding interviews when you're in the hot seat.
Let's get into it. When presented with a problem, the instinct might be to jump straight into coding. But hold on. βΈοΈ
An all-too-common blunder is to skim through the problem and instantly start coding, or even dive into implementation specifics.
Avoid this pitfall π«
Ask yourself a question - Do you want to appear as a leetcode monkey π or a problem solver π§ ?
Set your nerves aside, and treat the problem as a dialogue with your interviewer. They're evaluating various skills: problem exploration, communication, coding, problem-solving, debugging, and more. π¬π€π»
So, don't stumble upon the solution; instead, deliberate and reach it!
Approach the problem systematically and thoughtfully. Read the question, internalize it, walk through examples, ensuring you grasp its nuances.
Now, what's the game plan?
Try rephrasing the problem, ensuring you and the interviewer are on the same page. Got doubts? Ask 'em. Questions like "Is the input array already sorted? Can it have duplicate elements? Is the input graph directed? How's the output represented?" are perfectly reasonable.βπ€
Identify relevant constraints and edge cases. Considerations such as "Are all array elements unsigned integers? Will the collection fit in memory? Can the string have empty characters?" are apt queries. π§π
If you've made it this far, you've mastered the art of resisting the urge to dive straight into the solution. Instead, you ensure you explore the problem, identify constraints and edge cases, and engage with the interviewer π
OK, now what?
Coding problems often offer multiple solutions: some efficient but memory-intensive, others slower but memory-friendly. It's ideal to discuss various approaches, progressively moving towards an optimized solution. Let's illustrate with an example. π€π‘
Scenario - Given an array of elements, return the `k` smallest elements.
OK candidate - I will use a heap to solve this π
Reader of my newsletter - Well, there are several ways we could solve this problem.
One way would be to sort the array and pick the first `k` elements. That would be an `N log N` operation since sorting an array takes `N Log N` time when done efficiently.
Alternatively, I could also use a max heap of size `k` and push all the array elements onto the heap. Max heap ensures that the largest element in the heap is always at the root. When inserting elements onto the heap, swap array element with heap root if the array element is lesser than the heap root. By the time we have pushed all the elements to the heap, the heap would contain `k` smallest elements. We can then pop each element from the heap one by one and return the smallest `k` elements. The time complexity for this approach would O(N Log K) because we attempt to insert `n` elements onto a `k` sized heap. Each insertion costs us O(K) time, and that operation across `n` elements cost us O(N log K) time. However, this approach does require us to maintain additional O(K) space.
I am leaning towards the heap based approach considering it is faster since O(N log K) < O(N log N) and memory requirement isn't too high since k << N
Does that make sense? Do you have any questions? π€©
Does that make sense?
The interview is your audition for your knowledge about data structures and algorithms. You want to showcase your knowledge in a methodical manner with a clear structure behind your thought process.
Things are going good so far. You have explored the problem thoroughly, suggested several approaches, picked an optimal approach and are on the same page as the interviewer along the way.
Now, onto coding π¨βπ»π©βπ»
While you are coding, itβs always a good idea to voice over what you are doing. You donβt need to be a chatter box, just explain your approach enough for the interviewer to follow along. Be sure to handle those edge cases. Interviewers are often coached to look out for edge case handling in their interview training. Pick reasonable variable and function names. `cellVisitedCount` beats `i`. `buildAdjList` trumps `func`.
Though this post doesn't dive into coding guidelines, some best practices are recommended. Just know that while you do have some wiggle room in terms of code quality when coding in an interview as opposed to your production service codebase, incorporating some general best practices is always nice.
Feeling confident about your interview? You've crafted the solution and success is within reach. Now, the final stretch. ππͺ
Once you have coded the solution, itβs always a good idea to walk through the solution with a few examples. Pick a diverse set of examples - some that invoke your edge case handling logic, some that go through your core algorithm etc. Track your program execution, capturing state variables and loop transitions, explaining how the code yields the right result.
Hopefully, your code works alright. If it doesnβt debug it methodically. Donβt just fix one bug only to cause another in a hit and trial fashion.
Talk about the worst case time and space complexity analysis of your solution and invite any questions the interviewer may have. Depending on how much time is left in the interview, the interviewer may decide to challenge you with an extension to the current problem or a new problem altogether.
Do the above in all your coding interviews and watch out for that job offer in your inbox π€π€
Remember, interview preparation entails much more, from basic strategies to company-specific insights. Future posts will cover this and more.
If you enjoyed this read, consider these four wishes: like, share, comment, and subscribe to keep the magic alive! β¨ππ¬π¬
See you in the next one! Oh and btw, check out previous editions of this newsletter if you are interested.