Technical Interview Tips
So you know you have the right skillset for a job but you don’t do that great on interviews. The good news is that most jobs on the computer science fields put more value on technical interview than classic interviews. In this post I’ll go through a mock interview and cover some simple tips in how to bring those skills to the forefront and shine based on your technical skills.
A lot of these things most likely we all do at a subconscious level already, it’s a matter of doing them out loud and sharing your thoughts (a theme that will keep coming up). Some of these will be fairly obvious and it’s advice than anyone will tell you when taking about technical interviews so the purpose of this isn’t to give you some unique tip on how to succeed but rather take a pragmatic approach and show you how everything comes together.
Technical interviews aren’t a race to the finish, sure the faster you complete the problems the more time you’ll have to show your skills with more problems. However the most important thing about these interviews is to get the interviewer to know you and how you think. So you should take any chance you get to do that while answering those coding questions.
So with all that out of the way let’s go through the theoretical interview and explore things you can do along the way. And if you’re wondering, no, this is not a question I ask or would ask on an interview but it serves as a good example.
Implement a function that given 2 integer values returns the multiplication of those two characters without using a multiplication operator.
1) Understand the question and if you have any doubts ask. If you’re not given a signature that should be the first thing you write down and again ask to make sure you’re on the same page with your interviewer.
Why?
It ensures that you’re solving the problem that the interviewer really wants you to solve
Example:
int Multiply(int a, int b)
2) Make sure you understand all the constraints of the problem, and again, if you have doubts ask about that.
Why?
It lets them know more about what you’re thinking and an early insight about your problem solving skills.
Example:
Should the function handle negative numbers?
3) Write down what your test input would be. It doesn’t have to be a comprehensive list at this point; although the more interesting cases you have the better.
Why?
You’ll outline most if not all of the situations your implementation has to deal with which will give you a better idea of what your implementation needs to be and probably some code paths that didn’t originally came to mind at first when you heard the problem.
Example:
Personally I like doing this as a table with inputs and outputs but the format is up to you. I like this one because it’s pretty clear and you’ll have a list of both the expected and the actual results (think unit tests). I wouldn’t actually write the last column but it’s something that you could be talking about while you’re writing it and definitely worth mentioning why you’re choosing those inputs
| a | b | Result | Scenario |
| 1 | 1 | 1 | Multiplication by 1 |
| 2 | 5 | 10 | a greater than b |
| 5 | 2 | 10 | b greater than a |
| MaxSize | 2 | Error | Overflow case when a is Max int |
| 2 | MaxSize | Error | Overflow case when b is Max int |
| MaxSize - 1 | MaxSize - 1 | Error | Overflow when the result overflows |
| 0 | 1 | 0 | Multiplication by 0 when a is 0 and b is something else |
| 1 | 0 | 0 | Multiplication by 0 when b is 0 and a is something else |
| -1 | 1 | -1 | Negative a, positive b |
| 1 | -1 | -1 | Negative b, positive a |
| -1 | -1 | 1 | Both negatives |
4) Always write down (or at least mention) the first implementation that comes to mind, even if you get the feeling there might be a more efficient way. This includes handling all your special cases which you can add once you have basic implementation.
Why?
You’ll show that you know how to solve the problem. A lot of times there’s more efficient and elegant solutions than the first one that comes to mind. After implementing the simple one you can mention that there might be another and keep thinking about it (remember brainstorm out loud!) or you might get asked if there’s a better solution anyway.
Example:
int total = 0;
for (int i =0; i < a; i++)
{
total += b;
}
return total;
5) Run through your test cases and see if your algorithm holds, specially run through the most interesting ones. This is where they become useful!
Why?
You want to validate your algorithm; that was the whole point of having a list of scenarios earlier. If your test cases are good enough you might also pick up bugs on your algorithm and it’s always a plus if you find your own bug instead of having your interviewer point it out and having you figure out where it is.
Example:
Depending on the complexity of the algorithm I like to use tables here as well when running through loops (for this example this would be overkill and a waste but just to illustrate the point here)
For the scenario where a =2, b =5 and expected result = 10
| i | total |
| 0 | 5 |
| 1 | 10 |
If we tried with the negative test case, a = -1, b = 1, expected result = -1
| i | total |
| 0 | 1 |
| 1 | 2 |
| 2 | 3 |
| 3 | ... |
At this point you can see that it doesn’t handles negative very well.
6) Fix any bugs you might have found or make any optimizations (which might involve rewriting the whole thing so if that’s the case repeat the last step after you’re done).
Why?
If this one isn’t obvious as to why you’re probably looking for work in the wrong field.
Having bugs in your algorithm is not necessarily a bad thing so don’t get discouraged if you find one or if your interviewer points it out for you. Finding and fixing bugs if part of the software cycle so only panic if you still can’t see the bug after you get several hints of where it’s at.
Example:
The original code didn’t handle negatives so we’ll modify the code to handle that:
int v1 = Abs(a);
int v2 = Abs(b);
int negativeCount = 0;
int total = 0;
if (a < 0)
{
negativeCount++;
}
if (b < 0)
{
negativeCount++;
}
for (int i =0; i < v1; i++)
{
total += v2;
}
return negativeCount == 1 ? 0 – total : total;
Finally, be ready to explain any choices you made in your implementation if your interviewer has any question. The cliché there’s no right or wrong doesn’t completely apply here (as obviously code full of bugs is wrong) but other than that you should feel confident on your code and be able to explain why you went with that implementation. If you get a question like that don’t immediately think that there’s something wrong as this isn’t necessarily a trick question. It might just mean that you have a different implementation than what your interviewed expected and he’s curious as to your design choices and he wants to get more insight as to how you think (which is a good thing!).