This post contains affiliate links meaning as a Bookshop Affiliate I earn a small commission on qualifying purchases at no additional cost to you. If you would like more information please visit my disclosure here.

Most of you who are reading this have probably realized that you’re going to have to go through a tech interview at some point. It can be really scary if you’re unfamiliar with what to expect or but it doesn’t have to be!

I’ve interviewed with a variety of different companies and also sat on the other side of the table as an interviewer. Each place, role, and interviewer is different but here are a few general tips for preparing that apply to just about any technical interview.

Related | Acing the Technical Interview

The most important thing to do is to research what you’re getting yourself into. The more you can find out about a specific company’s hiring practices, the better. I spend hours reading blogs and Glassdoor posts documenting someone’s personal experience interviewing with a company. Walking into an interview knowing there will be 3 rounds with 2 people in each round will make you feel much more confident and prepared. On top of researching the details of the interview, take some time to look into the position and the company. Figure out if this is a place you’re really interested in working at and why. These questions will still come up in a technical interview so be ready for them. Sometimes when I was trying to answer this question of ‘why’ I realized that I didn’t really want to work there. It’s a good thing to figure out before you’re sitting in front of two employees and admitting you don’t really want to work at their company.

Now, if you’re reading this article and you don’t own Cracking the Coding Interview *… definitely try to get your hands on a copy before your interview! This is the BIBLE of prepping for a tech interview. If you can only purchase one book for the rest of your career it should be this book!! (Ok, that is definitely an exaggeration but I still maintain it is one of the most helpful books when learning how to land a job in tech).  It covers EVERYTHING from how to interview to the ins and outs of the big data structures and algorithms. Plus, I’ve had a lot of interview questions come straight from the book or as a slightly modified version. Don’t be too intimidated when you get it because it’s huge, heavy, and has incredibly small font - over half the book is filled with solutions/explanations. You don’t literally read it cover to cover (you could if you had a lot of time) for the most part you use it to brush up on your weakest areas cause let’s be real most of us had at least one CS class they just sat on Facebook the whole time and learned nothing.

// Side note: if you’re looking to prepare for a PM interview, the same author wrote a much more manageable book: Cracking the PM Interview: How to Land a Product Manager Job in Technology*. I read it cover to cover in a weekend and found it incredibly helpful in understanding what I needed to do to ace the interview.

Depending on when you read this article (5 minutes, 5 days, or 5 weeks before the interview) you’re going to need to adjust based on how much time you have to prepare. Cracking the Coding interview gives a great prep plan based on how much time you have and I highly recommend following some modified version of it. In my opinion the best way to prepare is to do a little every day. I recommend making a schedule of which topics you want to cover depending on what role you’re interviewing for (this is part of your research!) and how you want to break them up over time.

Even if you code on a daily basis for school, it’s not quite the same kind of coding as you do in an interview. A lot of the questions you’ll be given in an interview are testing to see that you understand fundamental concepts and write clean code. For continued daily practice, I recommend signing up with a site such as HackerRank, CodeWars, or LeetCode. You’ll get daily email reminders and their coding challenges tend to be pretty short so you can do them without needing to set aside a huge chunk of time each day. A lot of companies have started sending out mandatory HackerRank challenges as a first round so with any luck you could get a question you’ve already solved. Looking at this material on a daily basis for even 15 minutes will make an enormous difference when added up over weeks or even months. My advice is to work it into your daily routine -- I made it part of my morning routine so before class I completed a coding exercise with my morning coffee. It only added 10-15 minutes to my routine but in the long run it was incredibly helpful to be exposed to the material on a consistent basis.

**Side note: I’ve found LeetCode particularly helpful for interviews. If you’re more worried about the interview than a coding challenge you might want to take this into account. That being said, make sure you’re familiar with HackerRank because a lot of companies have started using coding challenges as a first screening round. You don’t want to miss out on a job just because you didn’t know you could complete the challenge in Java rather than C (a lot of times there will be a default language).  

If you can only do one thing that I talk about in this article before your interview I’d recommend that you know your data structures and algorithms like the back of your hand. We’re talking time complexity and space complexity. You should have covered this in a basic data structures course but a few minutes on YouTube and Wikipedia will also cover it pretty well. These are easy questions you should be able to ace in the first few minutes of an interview and use as a confidence booster. Conversely, it’s not the end of the world if you forget the average case runtime of QuickSort but it’s definitely not going to do you any favors. If nothing else, make a Quizlet deck and flip through it every so often to make sure you don’t need to second guess yourself. If you have lots of time on your hands and want to *really* make sure you understand these -- I’d recommend coding them from scratch in the same language you’re going to interview in. It’s a good way of reminding yourself of little oddities of syntax that you may have forgotten about.

This brings me to my next tip: don’t code in an IDE before an interview. You’ll be shocked how much more you’ll remember about syntax when Eclipse can’t helpfully underline it in red or worse, autofill it. It’ll be a great opportunity to remind yourself how to define a constructor or an import statement while working on class assignments. When you’re white boarding code in an interview you won’t get helpful IDE suggestions and it can be pretty embarrassing when you realize you don’t know how to define a main method without Eclipse doing it for you.

The last thing you can do to prepare is to practice, practice, and practice some more. Some schools will do mock tech interviews that you can sign up for through the career center. What works just as well is booking a room with a whiteboard and picking your scariest friend to act as your interviewer to make it as realistic as possible. Of course you can take turns trading off which will help you to learn what looks good from the perspective of an interviewer too which never hurts.

In my next article I’ll be going over what you should do during the interview and what things you can practice in advance. Technical interviews are far from intuitive and it can take a couple tries to feel comfortable in one. Getting the hang of it before the real deal can mean the difference between a coldly vague and generic “we’ve decided not to move forward with your application” and an amazing offer full of lots of commas and zeros landing in your inbox.

Follow me on Instagram where I’ll keep you updated with my newest posts and day-to-day tips! Or subscribe to my newsletter so you can stay informed of new posts!

Next up: Acing the Technical Interview

*This is an affiliate link which means as an Bookshop Affiliate I earn a small commission from a qualifying purchase at no additional cost to you. For more information please see my Disclosure.