I had mentioned this in the Tips section, but some people on some sites might still get the wrong idea about studying for my recent Microsoft interview, so I want to write this post, which explains my opinion more (and it really is just my opinion–I have no idea what Microsoft’s policy or opinion is).
I want to make clear that cramming for a job alone will not get you this job. It didn’t get me this job, and it won’t get you a job at any place that really tests you. Thinking it will is a backwards approach.
The two books I mentioned, as well as the links I pointed out, are merely resources to help you focus your efforts. If you have to memorize the questions and answers rather than understanding them, you have a problem. If you didn’t do well in your CS algorithms class, chances are, memorizing the answers isn’t going to do much for you. If you don’t really understand pointers by this point, no amount of memorization is going to help you debug your C++.
Those resources are a way to reflect back on what you’ve learned through your entire career, starting in school. Let’s face it, how many times have you had to implement a hash table, or a heap sort, or even a binary tree? Those basic pieces are always provided for you–almost nobody writes them from scratch in production code. But should you understand them thoroughly? Yes. Should you know common gotchas? optimization techniques? how to write them? Yes, Yes, and Yes.
Even if the interviewer asks you to do some basic problem like writing a linked list function, and you’ve memorized it, then what? Ok, so you write it on the white board. Guess what the interviewer is going to do next? They’re going to ask you to analyze it, they’re going to say things like, now let’s make it circular. How do you detect a loop? Now it needs to bi-directional. Now it needs to be split in half. Now each node also needs to have children. Now it needs to be sorted. Now it needs to represent terabytes of data on disk, now it needs to be faster, smaller, smarter, better in every way.
And that’s only if you answer the problem perfectly at first, which is pretty hard to do.
You see where I’m going with this? It doesn’t matter how well you know the initial question, they will always get to a point beyond where you’ve prepared and you need to actually apply knowledge and skill and come up with something you haven’t thought of before.
I can’t remember where I read it, but someone said that Microsoft will deliberately ask you questions you can’t answer. This makes perfect sense–asking questions you know the answer to does not demonstrate the limits of your understanding. As an example, if I ask you only about basic addition, I learn little about your mathematical skills–only that you’re at an elementary level, which isn’t helpful. I have to ask about multiplication, division, fractions, algebra, trig, calculus, linear algebra, differential equations, etc. up to the point where you can’t answer anymore before I know what level you’ve achieved. It’s the same with programming.
Why did I work so hard for this job? A few reasons, I think. First, I’m a bit of a nutball. Second, I saw an opportunity I was not going to let go through any fault of my own. In the end, if they didn’t want me, so be it, but I was going to satisfied that I did everything possible to ensure success. Third, I expected the interviews to be harder than they ended up being, and I expected them to ask obscure questions about all sorts of data structures. Knowing what I know now, a lot of that preparation wasn’t necessary, but I don’t regret it–for the confidence alone it was worth it.
In the end, I thought they did a great job of discussing only basic data structures and algorithms, but really making sure they got you to think. No interview system is perfect, but theirs is really good.
Check out my latest book, the essential, in-depth guide to performance for all .NET developers:
Writing High-Performance.NET Code, 2nd Edition by Ben Watson. Available for pre-order: