Breaking It Down: How to approach any technical interview problem
A safe go-to recipe to figure out how to make any problem more manageable.
1. When you get the question (before you write a single line of code)
The easiest way to make sure you understand the question is to walk through test cases.
Things to clarify with your interviewer:
What is the expected input? What is the expected output?
Any assumptions you may have about certain test cases
After walking through test cases, make a note of any variables you should keep track of and what kind of data structures would make the most sense for this problem.
Always think of ways you can break down the problem. Is there a smaller, easier sub-problem that you can solve? And if so, what would that solution look like?
2. Writing the code (and what to do if you get stuck)
After you figure out your algorithm and explain your logic, the next thing for you to do is translate your idea into code.
At this point, brute force is totally ok. Creating a working solution (even if its runtime and space efficiency isn’t perfect) is far better than being stuck on trying to prematurely optimize your code.
As you write your code, remember to:
- Speak clearly about what piece of code you’re currently working on and why you’re adding it to your solution
- Try to use obvious variable names and make your code friendly to read
- Talk with your interviewer through your thought process and what pros and cons might come with your solution
- Make your code modular when possible (helper functions are your friends!)
About handling that awkward silence if you get stuck or need some time to think …
It happens to all of us, and it is perfectly normal to encounter this during an interview. In my experience, for almost all of my technical interviews there comes a moment when I need to think to myself and am unable to keep talking with the interviewer. When this happens, I usually say something along the lines of:
I need a second to think over my solution and see if it makes sense
I am not entirely sure if this is the right approach, let me double check my work
It seems that maybe (insert part of your proposed solution) might not actually work for (insert some edge case)… I’m thinking about how to address that
The interviewer is usually on your side and wants to see you succeed — just remember if he or she gives you a hint, never ignore it!
3. Reviewing your solution and adding optimizations
Once you’re finished writing your code, trace through it with a test case to make sure your program behaves the way you expect it to.
At this point it is good to consider:
- Possible edge cases that you may have missed
- Any off by one errors (especially when indexing or using a loop)
- Is there any repetitiveness in your code that you can clean up?
Questions to ask when trying to optimize:
- What is the current run time and space complexity?
- Is there any room for improvement if you used a different data structure or slightly modified your approach?
When you reviewing your code, remember that it is entirely possible that you made an unintentional error — try to trace through your program as if it’s someone else’s work you’re seeing for the first time!
Wrapping it all up
Interviewing is a skill, and like any other skill it can be improved with practice! Working through technical problems, getting comfortable with your language of choice and data structures can all be work you do beforehand to increase your chances of a strong performance during the interview.
For a list of questions, data structures, and resources for review, you can see more here: 4 Week Plan to Nailing Your Next Technical Interview
Remember that each interview is a learning experience and regardless of the outcome you’ve gained valuable insight that you did not have prior. Staying positive and learning from feedback is a great way to continuously improve! Good luck!
If this guide was able to help you in any way please send a clap or two over :) it really means a lot to me — thank you and good luck with your journey!
