Coding interviews are an exciting yet challenging part of the interview process for engineering roles, with lots of content written on how to crack and ace them. There’s almost too much information and too many platforms out there, which makes it difficult to know what to focus on.

Recently, I have been reflecting on my experience with coding interviews, thinking about all the lessons I’ve learned: from positions I missed, to interviews that resulted in an offer, and everything in between.

I’ve been fortunate throughout my career to land 100+ interviews at big tech companies, startups, AI labs, and also chat with lots of interesting people about how they got to where they are and what worked for them.

I am in no way an expert on this subject, and there are still parts of the process that puzzle me. For example, recently I interviewed with a popular big tech company in San Francisco California for a Machine Learning Infrastructure team, and went through 6 rounds (3 coding, 2 system, and 1 cultural) meeting all the senior engineers that work in the team - yet didn’t get an offer?!

In this blog post, I am going to summarize the things that I found worked for me, or things that I learned from my network that I also think would be useful to share. This is a list of 20 lessons I acquired over the process, hope you find them useful. Feedback is always appreciated!

List of Lessons

  1. Speed: While practicing for coding interviews, I try to aim to solve medium/hard LeetCode questions at a speed of 15 minutes/question. This might seem like a tight timeline, but it’s like sports training - you have to keep pushing yourself to outperform the competition.

  2. Optimality: Although for some questions optimal solutions might not be expected, I’ve found that always starting with the brute force approach and continuing to iterate on its weaknesses until I get to the optimal solution works. That way my interviewer will see my thought process and how I got to my solution.

  3. Coding Style: First impressions matter, so I always try to write code in the cleanest and most expressive way. Using coding styles like camelCase or Hungarian makes the interviewer engage better with every line of code I write.

  4. Communication: Coding interviews are like a pair programming session, you want to show what it feels like to work with you on a technical problem. Therefore I try to explain every line and function that I write, with the motivation behind it.

  5. Pressure Resistance: I used to not really understand why some companies include this in their job descriptions, especially startups. But after a funny story that happened to me with an interview for an ML role at a startup in London, I think I now get it. The interview was supposed to start at 11am, but the interviewer apologized and said he’d be 20 minutes late. As soon as he joined the call, he started grinding me with challenging technical questions and math puzzles all during 40 minutes - knowing that I had another call at 12pm and can’t be late.
    Later during the day he said that they would love to move forward, and that they liked how I was able to focus “under pressure” and get things done. Because getting things done under pressure is valuable for startups with strict deadlines.

  6. Competitiveness: A+ hackers want to work with A+ programmers. If you’re in an interview with someone that says let’s have some fun and types with 100+ wpm without looking at the keyboard, the interviewer is probably a hacker. How would you get someone like that to vouch for you? You beat him or show him that you can compete at their level.

  7. Repetition: Questions are repetitive, so practice makes perfect. Questions like inverting a binary tree, regardless of whether it’s right to ask such questions, should be something that you’ve practiced to solve a couple of times.

  8. Patterns: Some companies have a pattern of focusing on specific types of problems like OOP or trees. If you know someone that already has the job you’re interviewing for, try to reach out and ask what to expect. Also, information like this is also often available on sites like Glassdoor, or LeetCode.

  9. Foundational Knowledge: Lots of literature has been written about coding interviews preparation. Popular books like Cracking the Coding Interview (CTCI), are useful for practicing questions. I personally don’t think any of them is necessary to do well in an interview. If you’re a book person, then go for it. If not, there’s lots of different ways to practice. What’s important is building that foundation because companies love to challenge candidates on them.

  10. Mock Interviews: I actually found this to be the most rewarding of all to do while prepping. Using platforms like AlgoExpert, or Interviewing.io which have features where you can do mock interviews with random people for different levels of questions is very handy in sharpening your interview skills. Especially when I get to be the “mock interviewer”, I start to understand what makes a candidate’s performance shine.

  11. Cheat Sheets: I always try to consecutively build cheat sheets for different parts of the interview, like data structures, and systems design fundamentals. That way if I missed a concept once, I’ll research it and make sure that I won’t miss it again.

  12. Programming Languages: Most companies are usually flexible in terms of what language to use during the interview, therefore if you know Python then it might be a good idea to use it if it makes your life easier and helps you focus on the core algorithmic side of things. Rarely have I encountered a company that has a “hard requirement” to use a particular language, unless it’s something like Rust and they need an expert with it.

  13. Systems Design: I used to assume that this type of knowledge is only for senior roles. Talking with my peers and also from my personal experience, even intermediate roles sometimes involve a design portion - therefore I’d try to practice this as well. For example, full-stack or back-end roles involve systems-design questions sometimes even for junior positions.

  14. Independence: A lot of interviewers expect you to read the questions all by yourself, understand, ask clarification questions, and solve them all on your own. It might not be the case with all interviews, but I think it’s a good habit while practicing questions to not look at solutions and try to solve them independently without any hints.

  15. Practice: This is obviously the most important part. LeetCode or HackerRank? Honestly both work, you can use any platform that you find yourself most productive with. I personally prefer LC because you can filter for different tags and seems to have a bigger community of users. You can take a look at this list of 75 questions on LC from Blind. But some companies like Amazon for example use HackerRank for some early coding rounds.

  16. Offer Collection: Having counter offers is a great position to put yourself in, therefore one hack is to try to collect your offers during the same time frame. A peer of mine from Toronto once told me a story of how having a counter offer from his employer’s competitor, his employer finished all the interview rounds the same day and sent him a written offer over night!

  17. Referrals: Having referrals is like buying a VIP ticket. It greatly improves the odds in your favor. Applying to a job through an online post is probably not the best way to get the job. As a friend of mine that works for FAANG says: you should get to a stage in your career where you find new jobs via your network. Applying online definitely works, but due to sheer amount of competition these days, you’ll often be one of 200+ applicants for a given role when applying online. Sometimes you’ll want to find a better way to get recruiters attention which leads me to the next point.

  18. Cold Emails: The traditional way of applying for a job online and doing interviews isn’t always the best way to get a job. For example, cold emails to high profile people with a link to something you’ve built can take you so far. Or finding bugs in a company’s product with an attachment to a solution will do wonders. Being creative in this part has led a lot of successful founders to build products and great companies, let alone finding a job!

  19. Networking: Attending meetups is also a smart way to get a job. I was once watching a live demo by a ML platform startup, and asked them a question during the meetup. After finishing the talk, I got an email from the CEO asking if I’m interested in working there!

  20. Background Research: Usually you’ll know ahead of time who’s going to be doing your interviews. I always find it useful to google the heck out of the person’s technical background and their LinkedIn: where did they work, what type of tech stack did they use, what algorithms, what did they do research on, what papers did they write, etc. The reason is that most of the time interviewers will try to ask you about things they’re good at and have experience in - thus this gives you an edge over what to expect in your interviews.

Conclusion

There’s alot that goes into landing software engineering jobs, and this list is only a fraction of it. Don’t ever feel discouraged or late for preparing, a lot of successful people that “made it” all started in the same position.

Acing coding interviews is a skill that you can improve over time with practice and experience. I hope you learned something new from this article! Feedback appreciated!