How to prepare for Technical Interviews

Technical interviews or phone interviews are one of the most common interview formats you'll find en-route to a tech job.

Given the technical nature of the interviews, many people are intimidated by data structures and algorithm problems.

How do I prepare for such interviews?

Which Leetcode questions should I practice?

What's the number of questions I need to be able to solve before I'm confident enough to go for a technical interview?

Being strategic about how you spend your time is key - we all have school or work or other life commitments.

The first key is to realize that interview questions are variants of a few programming concepts: arrays, trees, heap, linked lists, stacks and graphs. Understanding the concepts and the way such concepts manifest in a solution will actually bring the best time-value benefit. The goal isn't to "complete" as many questions as possible, but rather to use them as a way to strengthen your understanding of the most common interview question topics.

The second key is to spend more time on topics you're not as confident with, and prioritize the more fundamental/common topics over niche ones. It's also important to tailor your prep strategy to how many days/weeks/months you have left before you anticipate interviewing.

For these reasons, I recommend Grind75 which I have personally used. Grind75 is designed for both limited-time practice (i.e. it can prioritize which problems you need to solve if you only have 8 hours for prep) and for prolonged practice (e.g. continued practice after you've passed a few interviews). It also groups questions based on topics, so you can drill down on topics you're not as confident with.

Where to start?

The most common mental block when attempting a question is often not knowing where to start. If you're at this stage, most likely it's because you've never seen this type of question. It is ok to look at the answer straightaway once you're stuck for more than 5-10 minutes. Once you feel like you're making progress (e.g. you're able to come up with example inputs and start piecing together an approach) then I think it's fine to spend up to 15-20 minutes per question. Leetcode usually has forum answers in code form, but ideally you can look at a more detailed writeup of a question (these usually exist elsewhere on the internet if not on leetcode), so that you don't have to spend time reverse engineering the approach from the suggested code.

Separate your solution into two parts: approach and code. You should always aim to walk away from a question having taken notes on the model approach.

For each question, separate your solution into two parts: approach and code. You should always aim to walk away from a question having taken notes on the model approach. Approach is basically something you can describe in English using a few bullet points - it doesn't even need to be as detailed as pseudocode. An approach can be as simple as "use a double hashmap" or "use a stack and a queue" or "radix sort then do binary search on each bucket". Only when you have understood the approach do you start practicing writing the code - otherwise IMO it's not a good use of your time.

If an efficient approach didn't immediately come to mind when you read a question, always start from the brute force approach. What's the dumbest way I can solve this problem?

Then ask yourself, which operation can be sped up? Which data structure natively solves that? Which algorithm speeds that up?

While you're coming up with these approaches, try to say these ideas out loud as if you're explaining it to a friend. Also figure out the time and space complexity and see if you can improve it any further. After you're sufficiently satisfied, come up with a few sample inputs (preferably with some edge cases) and run through your algorithm. Pay special attention to the state of the data structures you're using. How will it change when you step through your algorithm?

Mentioning your approaches out loud is also a best practice during actual interviews

Mentioning your approaches out loud is also a best practice during actual interviews! Why? It helps the interviewer to know where you're at. In a few cases, I've experienced how my interviewer give me hints once they see that I'm stuck.

For questions that you've had to look at the answer for, revisit them at a later practice session. Are you able to recall the model approach? Or, look at your notes for the approach, and see if you can write the code for it. Once you've gotten fairly confident with a certain topic, can you solve a question you've never attempted (both approach + code) in one sitting of 20-30 minutes? But do remember that solving questions wholly and passing all leetcode test cases is not a strict checkbox you need to tick. The process of attempting and then gaining understanding is what's valuable.

If you are short on time and still have a bunch of topics to cover, focus on understanding only the approach for those questions. If you have time, you can go back later to practice writing the code.

With this in mind, you can experiment and pick what style works best for your learning. For instance, one sequence could be:

Q1 approach, Q2 approach, Q3 approach, …

And then Q1 code, Q2 code, Q3 code, …

Or another version might be:

Q1 approach, Q1 code. Q2 approach, Q2 code. Q3 approach, Q3 code…

This is also a best practice during actual interviews! Validate your approach first by writing out your bullet points in english, discussing time/space complexity and working through a few examples, before diving into code.

This is also a best practice during actual interviews! Validate your approach first by writing out your bullet points in english, discussing time/space complexity and working through a few examples, BEFORE diving into code. Say to your interviewer "Should I start writing the code now?" and see how they respond. Don't try to work out both approach and code at the same time - that's a common pitfall that increases the chance of you staying stuck by the end of the interview.

Do I need to grind Leetcode?

But, but, why do companies test for this algorithm challenge? As a dev, I will never use it in my daily job and even if I need to, I can reach for a well-written library right? Well, you're most likely right. You'll never need to code how to reverse a linked list. But, for the companies which receives thousands of applications, algorithm challenge is simply a scalable way to filter candidates.

In the long run, algorithm challenges are just for the initial point of getting your foot in the door. After you got your job, it is more important is to pick up strong foundation and important skillsets.

That said, grinding leetcode isnt the only way. There are companies that give take home assignments. They are typically smaller companies and they don’t really do postings so you need to know them through networking, connections or experience from constantly applying.