It takes more than just Leetcode
Unveiling the holistic approach to coding interviews
Software engineers have a love-hate relationship with big tech coding interviews. Some swear by how effective the data-structures and algorithm based questions are. Others argue they don’t have anything to do with the job itself.
Love ‘em or hate ‘em, they’re here to stay for the foreseeable future. They tend to focus on two broad topics - problem solving (whether you’re able to come up with ideas for the algorithm), and data structures (are you picking the right data structure for the job?).
Leetcode is great!
Leetcode (or Hackerrank/Hackerearth etc) is a great tool to prepare for coding interviews for the following reasons:
It helps practice thinking on your feet and recognize patterns (graph traversal techniques, sliding window, dynamic programming etc).
It makes it easy to practice several problems on the same topic until you have a good understanding of it.
It is a great way to get a feel for coding outside your IDE, which is what you will need to do in the interview.
But how many leetcodes do you need to solve before you’re ready for the coding interview? I’ve heard some people claim that their number is upwards of 300! 🤯
While there’s nothing wrong with being prepared, it might save you some time to understand that you aren’t expected to immediately know the answer to the coding question you’re asked in a big tech interview. In fact, Google marks any of its coding questions that have been leaked online as “banned” internally, ensuring its interviewers use questions that no one has seen before.
This is because your interviewers want to see how you approach a coding problem from scratch. Remember, your interviewers are there to support you. They want to see you succeed.
With this in mind, let’s go over all the skills you’re assessed for at a coding interview, so that you can become a well rounded interviewee that can tackle any problem in the interview, rather than brute-force solve 100s of leetcodes and hope you’re asked a question you’ve seen before!
The holistic list of skills for a coding interview
⁉️Embrace ambiguity
Interviewers want to see how you deal with an unclear problem. As basic as this seems, many candidates miss this simple trick - asking questions! Ask as many questions as it takes for you to understand what the problem is. Call out assumptions.
💪 Brute force to start with
Start by describing the most straightforward, brute force solution, even if you think it is awful. This shows that you have considered your options, and that you don’t prematurely optimize. Then consider what you want to optimize for. Space? Time?
⭐️ Bonus: this also buys you some time to think of an efficient solution.
🗣️ Talk through it all, even if you’re stuck
At all points through the interview, you should be speaking your thoughts out loud. Long pauses are the enemy. Describe your algorithm in words before you start coding.
If you’re stuck or confused, say so, but be specific. For example, “I’m wondering how I can maintain state while making this recursive call - currently the counter will get reset every time my function is called”.
🆘 When offered help, take it
Interviewers want to know if you’re open to and capable of taking hints and suggestions as you’re working through a problem. This is, after all, an important trait in a software engineer - you should be open to hearing and applying other people’s ideas rather than being wedded to your own opinions.
🛡️ Quality-control your code
This is one of the most important skills to demonstrate in a coding interview. Show you care about the quality of your code by manually running through it with an example that is not too simple and not too complex. Fix any bugs on the way.
Take the time to talk about and handle edge cases. You could even talk about the test cases you would write to test your algorithm.
🅾️ Explain space/time complexity
Finally, describe the space and time complexity of your solution, preferably using the Big O notation. Briefly explained how you worked it out, don’t just give them the answer.
Conclusion
Hopefully you now see that coding interviews are not just about quickly coding the perfect solution as soon as you see the question. It’s ok to not know the solution immediately - you can work it out during the interview.
Ensure you’re working on the above broad range of skills rather than just be narrowly focused on the algorithm/coding aspect.
In conclusion, if you have the time to do 300+ Leetcodes, more power to you.
On the other hand, if you have a fairly good understanding of the basic patterns and data structures, and are comfortable with asking questions and figuring your way through a problem on the spot, feel free to stop Leetcoding at 30, 50 or whatever your number is!
❤️ My favorite things this week
I’m excited to introduce this new section starting this week. This section will include the things I think are worth checking out. Be warned - they can be related to any topic, not just software engineering!
Tim Ferris interviewed one of my favorite authors, Cal Newport on his podcast in this episode:
They talk about Cal’s new book, Slow Productivity. I’m definitely planning to read this book soon.
Some interesting job openings to check out.
Bingeing this week: The latest season of The Durells was recently released to Netflix and I can’t get enough of it!
Beautifully distilled into the holistic skills - <3 all the aspects you call out here!
It is always impressive as an interviewer to find a candidate especially open to feedback (a.k.a. take the hints!) and having a good understanding of basic algorithms (e.g. by all means use that .sort() method, but only if you can describe to me its complexity and how you could potentially improve it if needed). I'll add one more skill to think of - brevity. Getting to the point quickly + succinctly is a huge benefit in a time-constrained interview scenario, and being open/offering to follow-up with more details if the interviewer needs is a great way to demonstrate that you can expand on it more, but aren't belaboring something unnecessarily.