When preparing for data structures and algorithms interviews, it’s crucial to put in time reviewing concepts and solving practice interview problems. However, it’s almost equally important to practice the structure of the live interview itself. Here are some tips for communicating and organizing your thought process as you’re being interviewed.
Check your understanding of the question
After the interviewer presents the problem to you, restate the problem in your own words to make sure your understanding matches the interviewer’s. If an example hasn’t been provided, consider providing your own small input and the expected output/behavior.
Now is a good time to clarify inputs and outputs. Think through special input cases (ie negative numbers, duplicates, empty inputs) and ask the interviewer about them. What is the desired output/behavior in that case?
One step at a time
It’s easy to feel overwhelmed and not know where to start. Remember, you’re not expected to think for one minute and write down a bug-free runtime-optimized solution. Interview problems are expected to be solved in stages. The next few steps describe some possible stages for thinking through the solution.
Describe the naive solution
Describing the simplest/brute force solution and its time complexity is a great place to start. The brute force solution is often a seed idea for more optimized solutions, and defining the brute force complexity gives you a benchmark to beat and demonstrates that you are already thinking about efficiency.
Think aloud through the problem
Thinking aloud is one of the hardest aspects of the coding interview process – we’re not used to narrating our own thinking process. I’d recommend that you practice thinking out loud while working on practice interview questions at home.
If you’re not sure where to start on the problem, start simple and talk through elements you know the solution will have. Here are some things to think about (and describe out loud to the interviewer as you’re thinking about them!):
- What data structures could be useful?
- Is there a related algorithm?
- Out of common tools (for example, DFS/BFS traversal, dynamic programming, sliding windows, binary search), do you have ideas about which would be useful? Which ones won’t work, and why?
consider asking for input
If you feel you’ve stopped making meaningful progress in the interview, consider asking for input from the interviewer. Getting a hint and getting on the right track is definitely better than going down a path you suspect isn’t correct, or not making progress at all. Remember, the ability to self-correct is valuable as well! Asking for direction could look like this: “I tried to optimize the solution by keeping a list of already visited states, but I think I’m missing a more meaningful optimization. Is there an example input that might help me think of areas for further improvement?”
Before writing code
At some point in the interview, you’ll have sketched out an idea, and your interviewer will ask you to write some code. It’s super tempting to jump in and get started as soon as possible! However, I’ve often seen candidates jump into code for a complex algorithm, then get slowed down setting up initial data structures/frameworks they discover don’t work as they progress in the solution. I recommend taking the time to define some details before coding, for example (depending on the type of problem):
- What data structure will you be tracking visited states with?
- What data structure will you use to keep track of solution candidates?
- What are all the methods this class will need?
- What state does the class need to store?
- What is the stopping condition?
- How will you traverse the data structure?
Taking the time to lay out these details ahead of time, whether it’s in pseudocode, notes, or talking aloud, can help you avoid going down rabbit holes of unnecessary complexity.
Talk through the solution
After you’ve written the code, talk through the execution of your code on a small example input. This will help you catch bugs you’ve written or see areas of improvement.
Unit tests
If you have time at the end of the interview, think about unit tests you would write. Depending on the format of the interview, this could be verbally describing test cases, or if you’re using a coding platform, writing executable unit tests.
Remember, the coding interview is a flawed, probabilistic process, but with preparation, you can change the probability distribution. Good luck!
Comments