A few weeks ago a good friend of mine interviewed for a Software Engineering position on my team. We have a very high bar when it comes to interviewing — our interview sessions usually include a lot of whiteboarding and tough programming problems. We didn’t end up making my friend an offer, and a few days later he texted me asking for advice that I could give him that he could use to improve his interviewing skills. Here’s what I ended up sending him:
1. Pick 5 hard problems, and know them well. I would suggest starting with 5 good programming problems, maybe even problems you heard while interviewing here or others you’ve come across. Make sure you understand the problem very well. Spend time thinking about the problem.
2. Practice in an environment that simulates the interview setting. Grab a friend and have her/him ask you questions that you’ve prepared in advance, and allow them to ask their own questions. Practice in front of a whiteboard, if possible in a meeting room or office, to simulate a real interview. Envision in your mind being at an actual interview, at the company you plan on interviewing with.
3. Restate the problem to the interviewer, and make sure that they know that you understand the problem. Part of this may be repeating or restating the question back to the interviewer. Doing this shows that you can communicate well. It also helps make sure that you are sure of what they are asking. At this point you want to clarify any assumptions you are making before you move forward. Getting an assumption cleared up or removed will help you tremendously — if they aren’t cleared up you can end up in left field real fast, solving a problem that is either not the problem the interviewer had in mind or is considerably harder than what was originally asked. If you clear up assumptions, you make the problem set very clear in your mind, and more often than not the problem becomes easier than it might have been.
4. Don’t ‘sign off’ too early. What I mean by this is many times interviewees tell the interviewer that they are done with their solution, when they haven’t double checked their work. When you feel you are done, take a deep breath and run through your code a couple of times. Test your code (see point 5). Don’t be too eager to be done with your solution. You’ll appear much better if you relax and take a second to revise and thoroughly inspect your code. You most likely have a problem that you’re not seeing. Fix the problem and repeat this process.
5. Test your code. In particular, boundary conditions. For example, if the problem being asked involved operations on a list, I would make sure that test cases I run through included lists with the following properties: null list, empty list, list with 1 item, list with a many items (or maximum depending on implementation/structure), list with mixture of null and non-null items, etc.
6. Think about memory and big O. More often than not, I’ll ask the interviewee, “Is there any way you can make this algorithm more efficient?” What I’m looking for is an understanding from you that you know there are tradeoffs of time and space when designing an algorithm. Can you reduce the amount of memory your solution uses? Can you improve the time complexity. What is the time complexity of your algorithm? Be prepared to answer these questions. Bonus: take a look at Wirth’s law and understand its implications.
These are just a few of the observations I’ve made while interviewing Software Engineers. Do you have any to add? Leave your suggestions in the comments below.