As an interview candidate: I’ve interviewed at dozens of companies over my career (and gotten SWE offers at Microsoft, Apple, Salesforce, Google, Amazon, and others). In my experience, practicing the following structured format helps me succeed more consistently at tackling technical interviews at large tech companies. I’ve also shared this feedback with many others who’ve found it useful as well.
As an interviewer: I’ve interviewed over 50 candidates in my professional career, mostly for positions at Google but with some at Microsoft and a startup. As an interviewer, I’m often looking for a positive signal that a candidate has certain qualities, such as strong communication skills, problem solving, programming, and testing. I’ve found that candidates who approach interviews using a structured format have a much easier way showing positive signals than those who don’t.
This process is tailored for 45-minute tech interviews where most of the interview time is spent on one design or programming problem, potentially with follow-ups. You may need to use a shorter version of this process (or omit certain parts) if your interview is shorter, or if you’re expecting several short, unrelated questions.
The goal of a technical interview is to convince your interviewer that you have certain qualities they’re looking for. The goal is not simply to show that you can find an optimal solution to some esoteric problem. The biggest artefact of your interview is the impression that your interviewer has about your communication, problem-solving approach and ability to write code. If you have those qualities, you need to explicitly show them during the interview, so it’s worthwhile to invest in a good process that showcases these skills and gives you the best chance at success. I’ve described my process below.
Once you’re given an initial problem statement, the process is as follows:
[Timebox to ~5-10min]
Interviewers will often give a vague initial problem statement to see how well the candidate deals with ambiguity and verifies their assumptions. This is your opportunity to make sure you have a good grasp of the problem before you dive deep into solutions.
Do:
Don’t:
Over-focus on edge cases, especially for design problems.
Edge cases are usually good to understand when they’ll have an important impact on the problem or solutions. This is especially for programming questions. But for design questions, you need to also prioritize based on priority, and sometimes you may need to deprioritize solving for some edge cases if they’re less important.
[Timebox to ~5min]
Coming up with test cases early is the best way to ensure you’ve done the previous step correctly. Specifically, good test cases will help you identify the most difficult parts of the problem, give you a clear contract to design for, and show good initiative and critical thinking. If you delay test cases until after you’ve implemented a solution, you might realize that you’ve solved the wrong problem (or missed an important requirement) only when it’s too late.
Do:
Don’t:
[Timebox to 10 min]
It’s rare that somebody would come up with an optimal solution to a problem from the start. Usually, it’s better to brainstorm a few possible solutions (including a “naive” solution) before committing the rest of your time to implementing a specific one. Besides, once you have a few high-level solutions down, it’s easier to compare apples-to-apples.
Do:
Don’t:
[Timebox to 15-20 min]
Once you find a promising high-level solution, try to divide the problem into smaller blocks and implement those. If your code will be large or complex, it may be helpful to start by writing your solution in pseudo-code, then turn it into an outer function that calls other smaller functions which each implement a smaller piece of the solution. If your code is small enough to be implemented in one function, then just do what makes sense :-)
Do:
Don’t:
Spend too much time over-optimizing unnecessary details.
Instead, you should get most of your solution working first before you start optimizing small things.
[Timebox to ~10 min]
Once you’ve implemented your solution, take the time to look for any obvious bugs or mistakes, then start to run through the test cases you’ve written down from step #1. Be detail-oriented at least when running your first test case, and avoid skimming large parts whose answer you think you know. After that, you can go faster if needed.
Do:
Don’t:
Skip some parts of the code that you haven’t run through previously.
If there’s a bug you missed there, this shows as a lack of attention to detail.
A good interviewer is not out to get you, but wants to accurately record your best performance. In my experience as an interviewer, most people don’t utilize the interviewer enough, and as a result they miss opportunities for help (at best), or give off the vibe that you’re defensive.
Do:
Ask for a hint if you’re stuck.
If you do, make sure to clarify your thought process until that point, the ways you can go from there, and why you don’t think any of them would work.
Follow your interviewer’s lead where it differs from the steps above.
For example, your interviewer might want you to split your time over implementing multiple solutions.
Don’t:
Be lazy.
It’s okay to use your interviewer as a sounding board and get their thoughts every now and then, but make sure you’re still showing critical thinking and coming up with independent solutions.
Stay quiet for more than 2-3 minutes.
Even if you need quiet time to think, make sure to give periodic updates to your interview on what’s going on in your mind.
Most candidates I’ve interviewed probably would have solved the problem given enough time. The challenge is that they don’t have unlimited time – part of what you’re showing in an interview is that you have an efficient process to solve problems. Some companies (e.g. Google) even have an explicit rubric for efficacy with regard to time.
It’s almost always better to complete a solution that’s mostly good but could use small improvements, rather than perfecting some small or unimportant parts while leaving critical pieces of the problem unsolved.
Do:
Don’t:
Panic if you’re behind schedule.
Instead, work with your interviewer to prioritize the most important parts of the problem and skip others.
Entertain black-or-white thinking (e.g. “if I don’t get the optimal solution I won’t get an offer”).