How to approach tech interviews

Why I wanted to write about this topic

I’ve wanted to write about this topic for a while and promised myself a couple of months ago that after landing a new job, I’d finally sit down one weekend and write down everything I know about tech interviews and how I prepare for them.

And now, after two months since I started my new job at Netflix as a senior software engineer, I’m keeping my promise. While this topic is still very fresh in my mind, I thought it wouldn’t be hard to gather all my thoughts and past learnings and combine them into one blog post. I’ve been through interviews so many times that I feel I have something valuable to share.

Interestingly, even though technical interviews are a widely covered topic among tech bloggers, I feel that most of them are overly technical and focus primarily on technical questions. I don’t want to undervalue the technical aspect of interviews, but I don’t think it’s the most productive heuristic when providing guidance on how to be successful when interviewing for engineering jobs.

That’s why, when I started working on the first draft of this blog post, I knew that I wanted to write more about my mental models on this topic and not focus so much on the technical preparation side of interviews.

Who am I?

I’ve just recently interviewed for, and accepted an offer from, Netflix. I joined Netflix as a senior software engineer to work on developer tools and productivity. Before Netflix, I worked at Buffer and Twitter. I had offers from other big tech companies, including Amazon.

Apart from my work experience, I was also employed as a graduate teaching assistant, teaching Computer Science I and II to undergrads at RIT. The program required me to teach students data structures and algorithms in Python and Java. It was a short, though very fulfilling, endeavor.

During the course of my career I helped many students to prepare for tech interviews and paired with them to solve problems. I have attended almost 100 interviews for technical roles—and learned a lot about the process too.

How I view being interviewed

Here’s the thing: if you feel like you’re the only person who dislikes interviews, then you’re wrong. I don’t know a single person who likes the process of being interviewed and looks forward to it. It’s stressful. People in our industry sometimes end up staying in one company for a very long time because they hate interviews.

Knowing how to interview well is a skill and has almost nothing to do with how good a programmer you are. You can be an excellent software engineer but bad at interviews. That’s why, if you fail, it doesn’t mean that you’re not a good engineer and that you can’t have a successful career in engineering. Each interview is a test, and whether you succeed at that test is mainly determined by how well prepared you are at the time. I wish we could create tests that could also measure your future potential and learning skills, which I consider to be better metrics for gauging success in any role.

I bring up this point because many people get discouraged when they don’t succeed at one or two interviews. Those who don’t get discouraged and find the courage to fail over and over are the ones who end up securing their dream jobs in “FAANG” companies (described below). Most Google engineers failed their first two attempts before getting into Google. Personally, I failed so many times that I lost count. Was it hard? Of course, it was. Did it discourage me from applying again (and again)? No.

Interviewing at startups vs. big tech (FAANG) companies

First of all, what do I mean when by big tech? Wikipedia defines “Big Tech” as the most dominant IT companies in history of the US. Later in 2013, Jim Cramer coined a new term—“FAANG”—which refers to the five prominent American technology companies: Facebook, Amazon, Apple, Netflix, and Alphabet (GOOG).

Interviewing for a job at startups is usually different from interviewing for those big companies. Since startups are smaller and more agile, they often redesign and change the interview process to better suit their needs. This makes interviews at startups curated and more relevant to your actual job responsibilities.

The tricky part when interviewing at startups is that you don’t know what to expect, and sometimes that makes it harder to know what to learn. The good news, though, is that startups move faster, which means they have a more accelerated hiring process and tend to move more quickly when making decisions.

Big tech companies (apart from Netflix) hire for a general software engineering role and then help you to find a team that suits your interests and skills. Facebook has a bootcamp where you talk to a bunch of teams and then decide which team you’d like to join. Google hires for a general role but if they offer you a job they will help you to find a team within the company.

Netflix hires for a specific team. The hiring manager who’s usually the engineering manager of the team drives the process and coordinates the interviews. At Netflix, each team has full autonomy in terms of devising the interview structure they see as most appropriate. The good part is that you interview with your future teammates and you can ask a lot of questions about the role you’re applying for.

When to change your job

Software engineers are fortunate even to have the option of changing jobs. Since we live in an age when the tech industry is booming, and tech jobs are well compensated compared to other industries, this privileged position allows us to be flexible when it comes to job opportunities.

First up, you don’t have to change your current job if you like it. What’s been hard for me is figuring out exactly when I should seek out new opportunities. What questions should I ask myself to determine whether it’s time to start searching for a new position? Here’s how I think about it.

• Am I learning new things in my current job? I like to put it differently. Do I feel overly comfortable in my current position? Comfort is dangerous because it might be a gateway to stagnation, especially in the field of engineering, where things change so fast and your skills are at risk of becoming redundant.

• Do I feel motivated at work? When I lack motivation, it could be because I’m burned out and need to rest or it could be that I just don’t enjoy my work anymore. It’s usually the former, but when the absence of motivation lasts months, then the latter could be the root cause.

• Am I working in a domain that interests me? To some extent, I feel this is relevant to my previous point. If you find a domain that you like, it’s easy to motivate yourself because then work doesn’t feel like work as it’s more fun and you get more satisfaction (out of it). You find meaning in your work.

Study yourself

I believe it’s imperative to start from this step when you begin your study process for interviews. To find a job you’d like, it’s important to understand what you want in your next role. Sit down with yourself and ask questions that will help you work out your requirements. Unfortunately, many candidates ignore this step, thinking that it’s not as crucial as technical preparation. But this step is vital for all sorts of reasons. First up, your recruiter is very likely to ask questions about yourself, your interests, and what you’re looking for in your next role.

What are your interests? What type of work do you find most fulfilling? Are there any companies that you’re particularly passionate about? Do you like consumer or business products? Asking yourself these questions will help to narrow down your search.

You should always have a story. When you apply for an X company role, it should be obvious to your interviewers why you want to join them. It’s hard to show excitement and enthusiasm when you don’t have a story. Passion is a significant asset that can make a huge difference during interviews. Companies want passionate people. It’s hard to disguise passion, and that’s why—when you have a genuine story to tell about why the role excites you-your enthusiasm comes across as natural and contagious.

Aside from interviews, being alone with your thoughts and questions can give you the space to think deeply about your interests. As you progress in your career, you get busier, and finding time to contemplate big career questions becomes more complicated. I find that interview preparation can be a good time for doing just that.

What’s your timeline?

Before starting to solve any technical problems, you should have an exact timeline of when you want to begin the interview prep process and when you want to finish your interviews. You need this timeline to optimize your study plan.

Having a timeline is essential because your study plan somewhat depends on how much time you have on your hands. For example, if you have only two weeks to study, you should optimize your time accordingly. If I had just two weeks to spend on studying for technical interviews, I’d focus more on arrays and hash tables because, statistically speaking, most questions are from those data structures. You see the pattern here?!

So … be aware of your timeline and try to spend your time effectively.

Company research

When you apply to a company, take the time to consider why you want to work there. Is it because they use hot technologies or because you think the role is a perfect fit for your skills? Before the interview, I try to learn about the company as much as possible by trying their product or reading their blog posts. If they have a technical blog, I go and check it out to see what technologies they use and what interesting technical problems they might face.

I find it helpful to check LinkedIn or Twitter and see who works there. What I look for are just patterns. Is their team diverse? Do they hire engineers with no CS degree? Do they have engineers working remotely?

When I start applying to companies, I usually do so in one batch. If I’m in “interview mode,” I want to go all in and get it all done in the shortest possible time. It’s unlikely you’ll be offered an interview with every company you apply to. That’s why I find it useful to keep tabs on recruiters and friends who work in tech as a means of getting yourself introduced to people, which is the most reliable and productive way to secure interviews and learn about company cultures.

I highly recommend keeping in touch with your past co-workers, and if you get the opportunity to expand your professional network, this will have a compounding effect and is going to pay off eventually. If you ask someone to help you, just remember the rule of reciprocity. Be helpful, help others, and people will almost always be keen to pay it back.

Technical interviews

When you study, you’re most likely to spend the majority of your time solving technical problems. One piece of advice I can give you for this stage is to optimize for quality, not for quantity. I’ve made this mistake in the past, and I learned my lesson hard.

The number of problems you solve on is less important than how well you solve those problems. Your goal is to build up intuition and brain muscle when solving technical questions. When you get there, it becomes a very powerful weapon because you’ll find you can instantly find patterns in problem statements. If you see the patterns, you can easily associate them with the data structures and algorithms, and then all that remains is to code it up …

If you rely on memorizing info, you’re setting yourself up to fail because you can’t build a knowledge tree on a weak foundation. If need be, spend hours on a single problem and try to solve it by yourself. If you solve it, then try to come up with an alternative solution and then compare it with your original solution in terms of space and time complexity.

Go deep in arrays and hash tables. Most interviews include questions concerning arrays and hash tables. Since most technical interviews are 45 minutes at most, it’s quite rare that your interviewer will ask you a problem that has a long and complex solution.

I like hash table questions because we use them in many parts of software engineering. They are efficient and practical data structures. It’s beneficial to learn how they work under the hood. You should know about hash functions and what hash collisions are, along with ways to counteract them.

When you’ve extensively covered arrays and hash tables, you can go wide on data structures. Start from trees, stacks, and sorting algorithms. I think you should at least know how Merge Sort and Quicksort work. Most sorting algorithms in current modern programming languages use these algorithms.

While you’re working on technical problems, you should also learn about Big-O notations. It’s critical you understand these because you need them to weigh the complexity of your solution. It’s basically a tool that engineers use to decide whether a specific algorithm is good or bad.

Ultimately, the best way to get better at interviews is by doing interviews. You should aim to do mock interviews a lot. These will help with your time management and can boost your confidence at the same time. If you have friends in tech, ask them to interview you. You can also sign up for interviewing.io or Pramp to practice mock interviews.

Behavioral interviews

Most companies include one or two rounds of behavioral interviews as part of the interview process. I think Netflix might be the exception here because almost half of all Netflix interviews are culturally based, so behavioral-type questions are rather appropriate.

Companies do behavioral interviews to decide if you will be a good fit. I know some big tech companies can also use it as a way to measure your seniority level.

Generally speaking, most of your answers will stem from your experience. I recommend creating a table of all your past major projects and including a blurb for each item. You should be prepared to talk about each project, explain your contributions, and expect probing questions. The follow-up questions usually concern collaboration, conflict resolution, and feedback.

To give you a sense of what to expect, here are some questions that I’ve been asked during behavioral rounds:

• Tell me about the most challenging project you’ve worked on. Why was it challenging?
• Have you had any conflicts with a co-worker in the past? If so, how did you resolve such conflicts?
• Can you tell me about your weaknesses and strengths?
• Tell me about some difficult feedback you received and the actions you took afterwards.

I find that thinking about similar questions beforehand is very useful because during interviews, when you’re nervous, it’s hard to go back in time and recall things that have happened. By thinking about your past experience and finding examples, you can unblock yourself.

Final thoughts

Studying for interviews is hard and interviews can be nerve-racking. It takes a considerable time until you feel ready and confident to start interviewing. Sometimes you never feel ready but go for it—and that’s okay. My most valuable piece of advice, which I personally try to follow, is to make the studying part as fun and entertaining as possible. Find ways to motivate yourself so you can do well. My hope with this blog post is that I could help a bit with that motivation part. Get that job. Good luck.