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.
- If frontend: CSS, javascript, ajax calls, cross-browser compatibility.
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.
6 comments:
Nice. Finally a helpful blog entry.
wish i had read this post before bombing my interview for a dream job.
This post is really helpful to crack coding questions for any interview. But still there are more topics where I would expect some career articles.For start, a few below:
a) How to keep ourselves updated with changing technology trends - what skills are most needed for a candidate at least for next 20 years?
b) How to identify and master one's strengths as most of the candidates are now a days - Jack of all trades and master of none :)
The skills most needed for 20 years! There will be technologies invented over the next 20 years that don't even exist yet right now.
But I can write an article about a general process for keeping ourselves updated, sure.
Very good advice. As somebody who used to interview in better times :) I can subscribe to the suggestion of never staying quiet for a prolonged time. If nothing else it bores the interviewer. One does not want to do that! Also the questions asked during the interview are not set in stone, it is more of a dialog. If running into a question one does not know how to solve, it may be a good idea of saying it. I can't find a solution for this question because... (say what's bothering you) but I could solve this problem (put there some restrictions). This is even better than perfectly solving the initial problem because it opens a window to your thought process, exactly what they are looking for.
After having worked on software since the days of punch cards (and still doing software), I have realized that the one trait that distinguishes great developers from the not-so-great is what I call "completeness of thought", which is this ability to really think things through in design, in fixing bugs, in testing, in debugging, in whatever. I have never figured out how to tell if someone has this trait, and I don't know how to prove that I do. Coding questions don't do it -- the candidate is under stress, and yes, it does show how s/he tries to solve a particular problem, but it does not show how s/he really really thinks and works when it comes to a live production system. Anyway, everyone "codes by google" these days -- you google up some code and adapt it. It's not a crime. Just because one does not remember how to do something in CSS does not mean they cannot figure it out and do it well when the time comes to really do it.
Post a Comment