Sep 27, 2020
Solving an Algorithm in a Technical Interview: The Problem-Solving Approach
Technical interviews can be conducted in many ways. Some companies will send you a coding assessment to complete at home. Others will have a pair programming session with you to build an app using the languages and frameworks you claim to know on your resume. Most of the time, however, you will be expected to solve an algorithm.
Interviewers choose algorithms because it is a great way for them to get an understanding of how you think. Keep in mind that there are many ways to solve an algorithm. Usually, the interviewer doesn’t care about the actual answer you come up with, but rather your approach to coming up with that answer.
This is why it is important for anyone preparing for a technical interview to come up with a systematic approach to problem-solving. There are many resources online that teach you ways on how to solve a problem. The examples and problem-solving approach detailed in this blog comes from a Udemy course taught by Colt Steele.
The problem-solving approach
1. Understand the problem and start communicating
This sounds like a no-brainer, but it’s the most crucial to start with. When the interviewer asks you a question, they aren’t expecting you to blurt out the answer right away. Remember, you are interviewing for a position on their team. That means you are expected to clearly communicate what you will be working on so that they know they can easily collaborate with you on a project.
This step is your chance to ask clarifying questions and clearly state out-loud what you think the interviewer is asking of you. Here are some questions to go over that can help you understand the problem:
- Can I restate the problem in my own words?
- What are the inputs that go into the problem? How about the output(s)?
- Do I have enough information to solve the problem?
- What are the important pieces of data the interviewer has given me? How should I label them in my code?
Use these questions to help you start communicating with your interviewer. The interviewer will be glad you asked these questions and will guide you in the right direction to start solving the problem.
2. Concrete Examples
To further cement your understanding of the problem, come up with a few examples of your own. These examples should have different test cases so that you can cover a wide range.
To start, look at the example you were given. Usually, your interviewer will give you one or two examples with inputs and an output. You can start with one of those examples and go through how you would expect the given inputs to return the expected output.
Then you can ask aloud “what are some use cases I should consider?” This will give you the opportunity to explore examples such as “what if I was given an empty input” or “what if the input was an invalid one?” Another example to consider is “what if the size of my input increased?”
Coming up with more examples will let the interviewer know that you are thinking outside of just the given problem and bringing in real-world cases that may come up during company production.
3. Break It Down
Break the problem down into smaller pieces. This is the best opportunity for you to clearly communicate what you’re doing. Draw out the problem and walk through your logic. This will force you to think about the code you’ll write before you write it out.
Consider this problem: Write a function that takes in a string and returns counts of each character in the string. A break down of this problem may look something like this:
Notice that these are not step-by-step instructions in how you’re going to start writing your code. The problem was broken down into smaller pieces that map out the logic. Explicitly writing your steps is the only way the interviewer can see how you think.
This is also another opportunity for them to guide you in the right direction and correct you if they see any mistakes. Don’t worry, it’s okay for them to correct you. You’re going to make a lot of mistakes in production and this is a chance for them to see how receptive you are to feedback. Gracefully accept any and all feedback throughout your interview.
4. Declare the language you’ll use and solve the problem
At this point, the interviewer should have a good idea of whether or not to consider you for the role. If you have a solid problem-solving approach, the interviewer should get an idea of how you think. They should then feel comfortable working with you on a team. Nonetheless, the code should still be written out.
First, let your interviewer know which language you feel most comfortable using. Then, if you followed the first few steps, writing the code shouldn’t be too difficult. You clarified all the important information you need to know. You came up with examples that gave you a clear direction on what to expect. Then you broke down your steps. You already have the answer, you just have to write it into code.
This is an opportunity for the interviewer to see how comfortable you are with the language you chose. It’s okay to forget syntax and to ask your interviewer. It’s easy to forget how to write an ‘if statement’ when you have someone watching you. In the real world, you’d probably just look it up anyway.
The hard part is done, just focus on writing good code and don’t be afraid to ask for help when you need it.
5. Look Back and refactor
Yay, you did it! You successfully wrote the code needed to solve the problem. However, the interview is still not over. Take a look at your final code and be 100% sure that it works. Revisit the examples you came up with earlier, do they still work? If it does, and if time allows, go over the code again and start a different conversation with your interviewer — how can you make it better?
See this as an opportunity to understand how you and your interviewer can work together to refactor your code and come up with a more efficient answer. To start, ask yourself: “what is the time and space complexity of your solution?” Come up with the worst, best, and expected case. Keep working with your interviewer to see if you can come up with another solution.
Wrapping it up
Having a solid problem-solving approach is essential to a technical interview. After all, this is an interview, not a test. The interviewer cares more about how you solve the problem and less about the actual answer. They want to know that if they hired you on, you would be able to solve problems with them.
Hope this helps! If you have any tips that you found successful during your technical interviews, leave them in the comments, I’d love to hear them!
Happy coding 😄
