How to practice technical interviews
a guide for mock interviews by Nikunj Agrawal ’19, computer science & mathematics
1. Help the interviewee fully understand the question:
- Do they understand what all the terms in the question mean? For example, if the problem is ‘find the height of this binary tree,’ do they understand what height of a tree means?
- Are they thinking about the right question and not solving the wrong problem?
- Are they thinking about inputs outside of the example you provided?
2. If they come up with a solution that’s not as space/time efficient as you would have wanted, ask them follow up questions:
- What would you say the space/time complexity of our solution is? Can we maybe do better and use less space?
- Is it possible to sacrifice space usage to get a better run time?
3. Before they start coding, be sure you understand the approach they’re taking.
- Do they have a clear idea of how they’re going to solve the problem? Or are they starting to code before having a concrete solution?
- Will they be going down a complicated rabbit hole that will be too hard to fix/debug later?
- Is their approach not going to work because of some cases they didn’t take into consideration?
4. After they’ve coded up a solution, give them an input that hasn’t been tested/mentioned yet and ask them them to trace through their code to see what the output would be. This helps both parties solidify their understanding of the solution.
5. If you see a certain problem in their code, try to give them a sample input that would help point out the bug in the code.
As an interviewee (the UMPIRe method):
1. Fully understand the question (Understand):
- Avoid trying to solve a different problem.
- Ask clarifying questions, such as:
- Is <x> input possible?
- Is it guaranteed that the input will be in <x> order?
- Will there be duplicates in the input?
- Will the input fit in memory, or do we have to worry about space?
- Come up with your own test input for the problem and confirm with the interviewer that the test output is what they’d expect, too.
- Before getting bogged down in code syntax, it may be easier to first have a plan of attack:
- What data structures may be needed?
- Can you stub out some helper functions?
- Are there edge cases that you didn’t consider?
- ‘This solution seems like a good start, do you have any feedback before I start coding?’
- ‘My current idea for a solution has a time complexity of O(n^2) and space complexity of O(n). Should we proceed with what I have or try to optimize more?’
- ‘My current solution is optimizing on space, but we can optimize on run time instead if we do <x>?’
- Be sure to name helper methods and variables appropriately. This will help the interviewer understand your code, and it will also help you if you need to go back and debug anything.
- It may also be helpful to write comments as you code. Again, this can help the interviewer understand your code and help you debug it later on.