As an interviewer, one of my favorite interviews was one where the candidate didn't finish the problem. This interview is memorable because of the dialogue. I understood their thought process, they asked the right questions, and they were receptive to feedback. After interviewing a hundred or so candidates in the last 3 years, it's clear that there's more to a technical interview than the code challenge. And it can be daunting if it's your first time going through this process. I wanted to share seven pieces of advice to help you ace your first technical interview. These tips are what I've seen from strong candidates as an interviewer. And also what I've followed as an interviewee in the past. At the end of this post, I've added a note on how I practice for coding challenges. Without further ado, tip #1.
After I hear the problem, I'll repeat back what the interviewer is asking me to do. From there, I'll ask questions to clarify the scenario. Some example questions could be:
- Asking to understand different cases. For example, if asked to sort items based on a property - "what would the ordering of items be if the property is the same for two items?"
- Asking about constraints. For example, "What is the max amount of items I need to process?", "Would I assume this input is valid, or do I need to do validations?"
- For system design questions, you could ask "how many users are we expecting on an average day?" or "how would we want to use the data coming from x?"
These questions help me understand definitions and constraints. It also defines the direction of the solution, e.g. how you solve a problem with only one user can be very different to how you solve it for millions of users.
Finally, don't go overboard! You don't want to get too in the weeds. Aim to get to a place where you're able to make an informed first step.
As I start to think about my solution I'll verbalize what's going through my head. I find that talking through my thought process clues the interviewer into how I think. While this strategy works for me, I know that it can be hard to think and talk at the same time. It's totally fine to let the interviewer know you're pausing to think. Either way you never want to leave the interviewer in the dark wondering what the candidate is thinking.
Know the limitations and the benefits of the tools and technology you use everyday. Generally speaking, questions about tradeoffs revolve around situations. Why would you use this piece of technology? How does it scale? How would you mitigate failure? Why is framework x better than y or why use a framework at all? The answers to these questions require context about the situation.
When talking about tradeoffs try to stay away from "stake in the ground" claims without evidence. In other words, don't be overly opinionated about the tools you choose. Every tool will have its place. One way to learn about tradeoffs is to build side projects. Side projects give you concrete examples of how a technology works in certain situations. They let you explore tradeoffs hands on.
During an interview, I will always plan out my solution. I'll either write pseudocode or draw out some steps on a whiteboard. I write my plan in the beginning of the interview as I'm verbalizing my thought process. Also, I sometimes try to make the problem easier to solve. One way I simplify the problem is to reduce the problem set. For example, instead of solving for an array of many items, can your solution work for one item? Making it easier to solve helps me get started.
Once I have a plan, I try to stick to it. Unfortunately, more often than not, my plan will start changing as I work on the problem. If you need to deviate, communicate why with the interviewer. As an interviewer, it's hard to keep track of a candidate's thought process if they're constantly jumping around a solution.
If I get really stuck on a problem my brain stops working. I start to panic as I'm wasting time. And this panic causes me to not think clearly. And so starts the downward spiral. When I realize I'm stuck, I try to take a deep breath and slow down. Getting into a calmer state of mind helps me think through the problem. If need time to calm down, I'll let the interviewer know that I'm thinking about the problem and need a minute.
If you get stuck, don't be afraid to ask questions. Try to be as specific as possible. Once you get an answer to a question, take your time to process it. Try and figure out the next step on your own. It's sometimes hard to process the answer to the question if you're in panic mode. If you're panicking revisit tip #5 and slow down.
Interviewing is a 2 way streak. Be sure to note how the interviewer interacts with you. Ask them questions about their experience at the company. Are they someone you could see yourself pairing with daily? Are they someone you could learn from and grow as a developer? Do you have a good idea of how the engineering team works? Your goals and needs are not less than the company. Make sure the company is a good fit for you.
Interviewing is stressful, and it takes practice to get good at. One way to improve is to do a lot of interviews. That is easier said than done though. So I also practice with timed coding challenges. HackerRank and LeetCode are popular sites. I also like Code Signal which has a nice code path for challenges. I'll also treat these coding problems like a real interview scenario where I talk through my problem. There's also Youtube videos of mock interviews or of how other devs break down coding challenges. Some of my favorites are by interviewing.io and CS Dojo.
Technical interviews are far from perfect. It can be hard to judge someone's ability through a 1 hour coding problem. Hopefully, armed with these tips and resources you should be well equipped for your interview. Good luck!