In 2006, I wrote this guide "How to Prepare for a Software Engineering Interview". Since then, I've been frequently asked: "How do I prepare specifically for the coding questions?"
Today I will answer that. Below are my tips, culled from my experiences interviewing around 500 engineering candidates for Microsoft, Google, and Minted.
My goal is to elicit your best performance during the interviews. To use an analogy, if you were getting ready for a 400-meter dash, my goal is to enable you to run your fastest time and prevent you from freezing up during the race. The tips are not going to turn someone who runs a 10-minute mile into a track star overnight.
1. Practice mock-interview coding questions in these areas:
- String operations. Implement strlen, strcat, strchr.
- Data structures. Hash tables, arrays, binary tree.
- Running time. Determine the big-O of algorithms.
Note: The point is to get you warmed up, not to tell you exactly what's going to be asked. Your interviewer wants to ask you a question you've never heard before, and may skip questions (and concoct new ones on the spot) until one that's new to you. So there's no point trying to scour the internet practicing all questions so that you can recite the answer.
2. Avoid extended silences during the coding question. A major reason for the coding question is to observe your thought process, not merely whether you arrive at the perfect final answer.
If you are silent, the interviewer has no idea whether you are analyzing several plausible solutions (a good sign), or whether you are completely at a loss on how to tackle the problem.Even if you are stuck, here are some things you can do that are better than being silent:
- Describe algorithms you're considering and then discarding ("Dynamic programming won't work in this case because...")
- Enumerate edge cases that your algorithm needs to cover ("I'll need to make sure my solution handles an array with duplicate values...")
- Talk about the part of the problem that you cannot solve ("I need to find a way to split the input into two halves, but all hashing functions seem too uneven...")
Basically, just open your mouth and issue a stream of your problem-solving thoughts. Even repeatedly going over the same conundrums is superior to a long silence.
3. If you see a brute-force solution right away, say it first, and then hunt for the more optimal solution. At least you've demonstrated that you have one potential solution, even if it's not efficient.
If you don't get the refinement, you can always implement the brute-force method, and impress the interviewer with your quicky-written and correct (albeit inefficient) code.
4. Practice writing code on paper, without a syntax highlighter. I mentioned this in the 2006 guide and it is worth re-iterating.
It is going to feel foreign at first. You will suddenly forget how to write for-loop syntax when you are using a pen or whiteboard. That's why it's even more important that you practice beforehand.
Good luck and godspeed to you.