Having a rigorous procedure to approach a coding question is vital to nail your tech interview.
You can think about the interview coding question canvas as a checklist to go through each time you approach a new coding problem. I divided the canvas into different sections.
I always start answering a coding interview question by writing down my canvas’s skeleton on the whiteboard or in a text editor. I am a big fan of Markdown, as it is straightforward to structure plaintext.
We use this canvas when problem solving coding questions in our posts. For example, checkout this coding question related to Amazon AWS EC2. We have another post dedicated to coding interview tips.
The canvas
# Problem name
## Constraints
`Method signature: `
- Constraint 1
- Constraint 2
- etc.
## Examples
## Solutions
### Solution 1: Naive solution
Time Complexity:
Space Complexity:
### Solution 2
TC:
SC:
### Solution 3
TC:
SC:
## Code
Problem Name
Writing down the problem name forces you to read the problem correctly. Just in case you are too excited. Maybe there is an indication of what data structure to use or something like that.
Constraints
What is the input and output of the algorithm? Write your method signature.
List all the constraints you find in the problem statement. Also, include additional limitations you asked the interviewer.
Examples
Force yourself to write more examples than the one(s) provided. Write down an example as soon as you start working on the problem. For a typical onsite, you would have a whiteboard. Remote interviews are more challenging. In any case, start with at least one example.
I recently asked an array-type coding question during an onsite. The candidate came up with the following example: input = {1,2,3,4,5}. Can you identify what the issue is with that example? The numbers look exactly like array indexes! The candidate confused himself many times throughout the interview because of that. Choose your examples wisely. What about this other example? input = {190, 45, 78, 90}. Values should be small enough to compute them in your head! Except if the problem requires otherwise.
List all edge cases you can think of here.
An edge case may change your entire algorithm. Edge cases might include empty sets, single-item sets, or negative numbers.
Solutions
Force yourself to write at least two ideas about how to solve the problem. Don’t reject an idea because it seems absurd, lay it down and then judge using Big-O.
Solution 1: Naïve solution
The first solution you can think of will be very often the Naïve or Brute Force solution. Mention it before explaining it to make the interviewer aware that you do realize that it may not be optimal.
How did my brain do it? Try to solve the problem by hand. After all, algorithms are just an automated way of what you could do manually, hand-written (well, if you had an infinite amount of time!). Evaluate both the time complexity and space complexity.
Solution 2: optimized solution
Now that you came up with a brute force solution go over the bottlenecks and optimize that solution.
After she came up with a naive, brute force solution, a candidate I met conducting a mock interview on mocki.co told me she couldn’t optimize her solution further.
If you really cannot think of anything, say it. Your interviewer will likely give you a hint. Anyways, always back up your decisions with facts and data points. For instance: “I cannot optimize this further as you have to go through every item of the array anyway, so that’s O(array length) at the minimum.”
Code
Start with stubs, “I will add the stubs for now.” Writing down the empty functions will help you design your algorithm on the fly.
Examples:
public class MySolution {
public void set (int index, int item) {
}
public void append( int item) {
}
public void get(int bla){
}
}
Wrap-up
Like always, practice makes perfect. You don’t have to be perfect, work to be a good problem solver. I believe anything skill can be learned. Mistakes are allowed.
If you want to know where you stand before a real interview, request a mock interview on mocki.co.
There is an excellent post about Algorithm Design for Tech Interviews. Hihgly recommend!
Leave a Reply
Want to join the discussion?Feel free to contribute!