How to Win at Technical Interviews
For many, Technical Interviews are the gate preventing access to software jobs at great companies. Getting past them is a sort of tribal knowledge of those in the know. I aim to give you the key. 🔑
By now, you might have heard about how technical interviews are broken, and how they are not necessarily good predictors of who ends up being a good employee. Interviews often focus on things that are less relevant to the day to day task of being an engineer, and certainly not the parts of engineering that engineers pride themselves in being good at.
Smart companies are starting to recognize this dissonance and switch things up. For instance, Google no longer asks ridiculous puzzle questions. One of the reasons I joined Pinterest was because they had the courage to ask me to solve problems that were similar to the ones I would be asked to solve while working at the job.
But we are not there yet. Most job seekers are going to have to interview at a few places that are still doing “old school” technical interviews. Until they become enlightened, or an improved system arises, it’s best to face reality head on and prepare.
Once, when I was fresh out of college with my brand new Computer Science degree, I got an interview with Amazon. But it was different than any interview I had ever been on. They were going to call me. On the phone. “That’s new”, I thought. They gave me a call and began to ask me about programming concepts I knew about, but hadn’t looked at since my CS 141 class at UC Riverside. Needless to say, I did not do well on the interview. When I hung up, I sat on my bed and thought “Was I supposed to prepare for this interview?”
Preparing for the interview
You’ve gotten a call back, or an email reply with a company you’ve applied to. Great, now what? Now it’s time to get ready. One of the things you can ask is “What should I wear?” It sounds silly, but if you show up to the interview with a 3 piece suit on, while everyone else is in a t-shirt and flip-flops, you won’t be able to focus on the task at hand, because you’ll feel out of place. It’s important that you allow yourself to be as comfortable as possible, because the process of interviewing is stressful.
Another thing you can do is ask the recruiter who will be interviewing you. You might want to do a little research on them, just so you are not surprised at who comes in to speak with you.
You should also take another look at the job listing, to make sure you fully understand what they are looking for and can practice any parts that you feel less confident with.
What to Expect
If you are interviewing for a position as a Software Engineer, you’ll be expected to write code. You’ll be expected to talk about code, and pros and cons of different techniques. You’ll need to remember your data structures and algorithms. If you are a more experienced engineer, you should be able to do some architecture, and design a large scale system. Depending on the role, you might be expected to answer questions related to computer science theory or testing.
These interviews typically take a full day, even including lunch. You are likely to have several session of 45 minutes to an hour long with one or more interviewers asking you questions. I’ve heard it said to take every break they offer you, so you can stay calm and get a break from the stress of the process.
Practice
Practice is the only way to handle this. Just as asking about dress code is an effort to relax you, practicing the sorts of questions you’ll get is the most effective way to become comfortable with answering them. I’ve added some reading material at the bottom of this post.
Before my last job search, I had been at my previous company for over 7 years. I was wildly out of practice when it came to interviews. So I had to set apart 3 weeks and practice. Every night for 2 hours, I got to work.
I read. I wrote code. I memorized.
It felt odd, needing to spend so much time preparing to get a job that I was already qualified for. But the interview is NOT the job. It’s a completely distinct thing. In fact, it’s a lot more like the SAT, in that it’s not a measure of how smart you are or how good of a software engineer you are, it’s a measure of how well you take the test. For most software engineers, their everyday job doesn’t entail tree traversal or recreating regex (2 real questions I got when I interviewed at Google). It involves making things, and improving performance and shipping code. Until the industry finds a way to discover who is good at that, we are left with the existing technical interview. That’s ok. We just need to prepare for it, so we can come out on top.
Put your keyboard away
One of the many ways that the typical technical interview is unlike the technical job is that you are asked to write code, but not on a keyboard. I already mentioned my phone interview. Get a friend to call you and ask you a question.
You also sometimes get asked to write on a whiteboard. Find a whiteboard and write out a simple function. A nice thing about the whiteboard, is that you can use all of the space to write down little “notes”, such as expected output and input or helper functions.
You might end up writing code in a Google Doc, with no syntax highlighting. Sometimes, you might get a good interviewer who will have Codepen (or something like it) setup, but you need to be prepared just in case. Learn how Codepen works so you don’t waste time during your interview getting used to it.
You should also make sure you are having a dialogue with your interviewer. You can ask questions about what languages they want you to write in. In general, smaller places prefer candidates write code in their language, and larger places will let you pick. Choose carefully. Not every language is great for interviews. Choose one you are most familiar with.
Understand the question
Don’t start writing before you understand the question. Too many times, an interviewee begins solving a problem, that isn’t the problem they’ve been asked to solve. It’s like buzzing in before the question is finished on Jeopardy. Wait. Listen, and then ask questions to clarify the question. Questions about expected input and output are always helpful. State your assumptions. This is a little bit like elementary school math, where it’s better if you show your work and how you got to a place. An interview isn’t only a time for an employer to find out whether you can write code, but find out how you think.
Don’t be too clever, straightforward is ok for the first time you answer the question. A common technique that interviewers use is to ask a question, and then ask about space constraints, or speed constraints. If this happens, now you can get clever by searching from both the right and left at the same time or something like that.
Data Structures and Algorithms
This is the crux of it. This is what you need to review (or learn for the first time) in order to do well on these interviews. Here are some data structures that it helps to know about.
- Arrays or Lists (obviously)
- Maps or Hash Tables or Dictionaries
- Sets
- Graphs, Heaps
- Binary Search Tree
- Stacks & Queues
Here are some algorithms it’s helpful to know.
- Sorting algorithms (quicksort or mergesort)
- Tree Traversal
- Recursion
- Binary Search
Big O Notation
It’s good to memorize the Big O of things. If you don’t remember, Big O notation is a way to describe the time complexity of a function in the worst case. For instance, finding an item in an array is O(n), but finding it in a Hash table is O(1). Going through 1 loop of items is O(n) but if there is a nested loop, it would be increased to O(n²)
A really helpful site for this is Big O Cheatsheet.
Testing
You would never write code and commit it without testing it. Similarly, you should always run through your code at least a few times to make sure it works in the way you intend to. Make sure to do the happy path, but the bad path too. One way to do this is to take note of “bad” inputs, such as null, or -1 if you are dealing with integers. It’s easy to go overboard with this so make it a conversation with your interviewer as you go through the code out loud.
Architecture
More experienced engineers are often asked questions about software architecture or system designs. Things like “how would you create a system to send messages back and forth to users” or something broad like that. When discussing your answer for this, make sure you analyze the trade-offs of size/cost/latency/etc as you make decisions. Consider the scale of the question, and take a look at the numbers. Don’t worry if you don’t finish, this is usually an open ended question.
Other types of questions
You should also be prepared to answer questions about things outside of coding, such as:
- Why do you want to work at this company? Prepare for this by doing research on the company first.
- Biggest/Best project you worked on? Have a story ready that paints you in the best light and showcases your skills.
- Where do you see your career going? Be honest about what you want. If it’s not a place you can see yourself growing, it’s not worth your time.
Questions for the interviewer
When the time comes to ask your interviewer questions, have some ready!? There is nothing stranger than sitting there awkwardly after the technical questions have been asked. An easy one is asking the interviewer about their work at the company. People love talking about themselves, and you should be able to gain an understanding of a typical work day in the organization. Here are some other questions to ask:
- What is unique about this company?
- How often do you ship code?
- What would my role be?
- Describe the culture
- Is there anything you are trying to change in the company?
- What is the work/life balance like? or What are typical hours?
Hopefully this has been helpful. Good luck!
Reading Material
Glassdoor — https://www.glassdoor.com/Interview/Google-Interview-Questions-E9079.htm
Khan Academy — https://www.khanacademy.org/computing/computer-science/algorithms
Cracking the Coding Interview — https://www.amazon.com/gp/product/0984782850/ref=pd_sbs_14_t_0?ie=UTF8&psc=1&refRID=TFM33FC66DHFMG2BF3S2
Coursera — https://www.coursera.org/learn/cs-tech-interview
CoderByte — https://coderbyte.com/challenges/?a=true
This was written with lots of insights from Cynthia Lee of Stanford, Eric Yurko and Antoine Picard of Google, Jayson P Phillips of Pandora and Devaris P Brown of Floodgate Academy. My thoughts are my own.
