Getting an SDET internship at Microsoft
When you graduate from college with a CS degree, potential employers aren’t terribly interested with the knowledge you gained from your classes. I mean, they are, but what they care about more is how well you can meet project deadlines, how quickly you can start working with their codebase/algorithms/platforms when you start the job, can you communicate well with your teammates and managers, how fast can you pick up new knowledge, that sort of thing. These kinds of things are difficult to learn in class; doing projects helps but really the best way to improve is to actually have job experience. This is true with a lot of majors, but, in my opinion, CS more than most. Thus, during the Fall semester, most of us spend as much time worrying about getting a summer internship as we do about our classes. Don’t get one, and you’re behind. I actually applied to Microsoft last year, and made it to their second-round interviews. In case you’re not familiar with Microsoft’s interview process, they do first-rounds over the phone or in person at your school, and if they like what they saw, they transport you to Redmond (or occasionally other places, depending on what group you’re interviewing with) and subject you to the infamous back-to-back-to-back 45-minute interviews. Almost immediately after those, you find out whether you got the job or not.
Last year, as it turned out, the answer for me was “not”; I ended up spending the summer at Cisco, helping port some security appliance code to 64-bit (good times, hopefully more about that in a later post). This year my fortunes were significantly better: I landed the job. Starting at the very end of May next year, I’m going to be working with the online services division, specifically Bing. Hooray! Now I get to pass the secrets of my success unto you. There are already literally dozens of blog posts about how to prepare for, and what to expect in, Microsoft interviews, but I still felt it was a good idea to throw my two cents in for a couple reasons. First, because other blog writers helped me, and I wanted to keep up the chain of good will (giving back, y’know?). Second, a lot of those posts are written for people applying for full-time positions, and things are a little easier for potential interns. I mean, it’s not a cake walk, but they know you don’t have years of work experience to draw on, and they’re fair about assessing you accordingly. Third, because I want to boil down the several really vital tips I think you should know for the final-round questions. In fact, I’m going to do that right off the bat, before I describe the interview process and the kinds of questions I got, because remembering these things is so important.
The Three Things You Must Remember at a Microsoft Interview
- Ask Your Interviewer Clarifying Questions – This is so important it should be 1 and 2. No matter what kind of question you get asked— whether it’s “code this” or “test this” or “design this” or “how would you do this”— ask your interviewer questions to be sure you understand exactly what it is they want. Sometimes they ask questions that are vague on purpose to see if you get them to clarify, and sometimes it’s totally unintentional, but you will not get all the information you need the first time around, I guarantee it.
Asking questions not only helps you get closer to the right answer, but even more importantly, people who ask questions and know more precisely what it is they’re supposed to be doing, instead of jumping in and making mistakes which have to be corrected at great expense later, make much better software engineers.
- Show Your Work – And by this I don’t just mean write your code down on the board (that’s sort of a requirement). I mean, talk about your thought process, all of it. Everything that crosses your mind as you work out a solution to the problem should be discussed with your interviewer. For one question, when I was asked “How would you code this?”, I actually responded, “Well, the obvious way is to…”, and then tossed out a very bad, exponential-time answer, because that’s where my train of thought started. Of course, I immediately clarified that it was a bad way, and then explained how to go from my answer to a much better one. Even if you don’t go that far, always talk about what you’re doing and thinking.
The reason for this is, again, they’re not that interested in the extent of your programming knowledge or skills— they already know you’re good enough on that score, otherwise you wouldn’t have come out to the final-round interviews in the first place. What they’re trying to figure out is how you think when presented with a problem; that‘s how they find out if you’ll be an effective employee. Language syntax and even algorithms can be looked up on Wikipedia, bad thought processes can’t be corrected so easily. It has a more immediate advantage too: if you start going down a dead end on your solution to a problem, your interviewer might actually help you and say, “Is that such a great idea?”. If you silently puzzle away, they can’t assist you. Don’t be stoic, help them help you.
- Be Thorough – When you get asked to write down a piece of code, or even a test specification, you can be sure that your interviewer is going to try and come up with situations where it’ll break/fail. Microsoft writes code for the real world, not academic projects. You can stay one step ahead by making your solutions as robust as possible. Try to think of everything. What if a malloc() fails? If you’re iterating over an array, what if that array has so many elements that your loop index overflows? Does your string handle Unicode? What if the network connection goes down? If you’re using a random number generator, sometimes they block if there’s not enough entropy; what will your code do then? This can sound a little overwhelming, but you don’t have to think of all this stuff on the first draft of your code— just get it eventually. More than once I wrote down embarrassingly broken code at first (even though I had followed the first two steps), then corrected it to be bombproof over the course of the interview, and they like to see that: can you spot your mistakes and fix them?
If you remember these three things, of which 1) and 2) are the most important, you’re in solid shape. The overwhelming temptation when interviewing with Microsoft, or for any software job really, is to cram all manner of computer science information into your brain. This is a mistake, I think. Like I said, if you make it to the final-round interviews, they already pretty know you’re technically proficient enough, so don’t try to squeeze CS esoterica to get an advantage, it won’t help. What will help is problem-solving skills, not trivial facts. That being said, here’s the kind of before-hand preparation I think will help the most:
- You only need to know basic data structures but you need to know them backwards and forwards. Lists (singly- and doubly-linked, circular, etc.), list derivatives like queues/stacks, and trees are the must-haves. What you can probably count on is that you’re only going to be asked questions about simple data structures, but the questions themselves will be tough. For instance, any decent CS student can write a recursive function to iterate over every element in a tree, but can you write such a function iteratively? Pre-order and in-order traversals are a bit tricky, post-order traversal done iteratively is genuinely difficult (at least when you’re under the time and pressure constraints of an interview). I wasn’t asked this question in particular, but another interviewee in my group was.
In addition to making you write familiar functions in unfamiliar ways, Microsoft also likes to make you write functions with no special cases. Can you insert an element into a doubly-linked list at a given index with no special cases at all?
Doing lots of problems like this beforehand will help a great deal. Write functions like the two described above, and think of other brain-twisters on lists and trees (I’m not going to give you any; coming up with them is as helpful as solving them!). Questions about string manipulation seem to be a favorite too: write a function to test whether a string contains another string, or whether two strings are anagrams of each other, things like that. Do as much practice as you can for things like this.
- Practice testing things. This is a no-brainer if you’re applying for SDET, but dev applicants get testing questions too. You can be sure that you’ll be asked to test the code you just wrote, and you’ll want to know how to do that, but more abstract questions are equally common. For example, if your interviewer were to hand you the stapler on her desk and say, “Test this”, what would you do? You’ll want to be sure that you’re keeping my three guidelines above in mind, so I think a good start would go something like this:
“Who’s using this stapler?” – Remember, ask clarifying questions. “Who is the target audience” is a great one that they love to see, as it indicates that you’re thinking about target markets and how to meet their needs. In this case, a stapler for use in a kindergarden might have very different requirements and a very different construction, hence, different test procedures, than one in a university library. Some staplers are huge things that can staple hundreds of sheets, is the stapler one of those? If so, how should its tests differ?
“Well, since the stapler is for X, we should probably start by Y…” – Show your work. Before you even start coming up with test cases, talk about how you’re going to come with tests. Are you going to divvy it up by feature, or by type of test (fuzz testing, performance testing, security testing— I’m not sure how well these apply to a stapler, but you get the idea)?
This goes for actual applications too. Sometimes, they actually sit you down in front of an application and ask you to test it. (It happened to me last year, but not this year). If it does happen, not only will you want to explore every nook and cranny of whatever app they put in front of you, but you’ll want to think like a programmer: if I had been the one to write this app, what mistakes might I have made? Put negative values, or strings, in boxes that take positive numbers. Rapidly click the “Save” button a dozen times to see if it breaks the write to disk. Turn off the computer’s wireless card while the application is making a network query. Be Thorough.
The last thing I’ll do is talk quickly about some of the questions I got, and how I responded to them. These were last year’s questions (I think individual interviewers come up with their own questions rather than use anything company-prescribed, but even so, they might be a little miffed if I talk about the questions I got this year), and I’m going to speak in very general terms rather than give a total play-by-play, but they should help you understand the kinds of things you’re likely to see.
Write and test a function to see if a string contains another string
IIRC, this was part of my first interview of the four, really a warm-up question. I ended up coding it in Java (choice of language doesn’t really matter), using the straightforward solution of nested loops where you match the first character of the string to be found against successive characters in the enclosing string, then enter an inner loop if they match. Nothing too difficult here, but just don’t rush and make silly mistakes: for questions like this just make sure your loop indices are correct, and that you’re handling edge cases correctly, stuff like that. In this case, the testing involved coming up with lots of string pairs and checking whether my code returned the correct result. Again, at every stage in the process (maybe for every line of code you write), talk about what you’re doing and why.
*hands me her ID badge to get into the building* “Test this”
I badly botched this one, because this was my first time around and I wasn’t aware of my three guidelines. What I assumed she meant was that she wanted me to test the badge in isolation; it took a while before I realized she meant the entire system— card, card reader, the door locking mechanism connected to the card reader, the server the card reader connects to, the personnel database backing that server, and so on. She would’ve gladly mentioned this to me if I had asked, but I didn’t. I also just jumped in and start vomiting out a big list of test cases, another mistake. The way to go here would’ve been to draw (show your work!) a diagram of the whole system, and how the components interact, and then talk about testing each component in isolation, for each one enumerating the various kinds of tests (again: security, performance, fuzz testing, stress testing, usability testing, failure cases) and what cases would be necessary to perform them.
You’ve founded a company that sells pens. How would you design your website?
I still chuckle a little in admiration when I remember this, because it’s such a great question. “How would you design your website?” is just so vast, and is exactly the sort that can get you bogged down in a maze of unimportant details if you don’t handle it correctly. Again, the way to go is to ask questions first.
Who am I selling pens to? Home shoppers will probably only be buying one, looking at pretty pictures, and paying with PayPal; corporate users might buy ten thousand, want to know the pen’s specifications, and need your website to be able to charge to their expense account. Am I a local company selling to my county, or a multinational? This affects decisions like how robust your underlying application and database layers need to be, what kinds of third-party services you might need to tie into, and so on. Which parts of my company (shipping, billing, etc.) are being handled in-house, and which are being handled by other companies? If you make assumptions about the answers to these questions, and it turns out your assumptions are not the assumptions your interviewer is making, you’re going to design entirely the wrong site!
After that, I broke the website into parts (presentation, application, database), broke each of those parts into components, and then outlined a development strategy for each of those components. At one point I was actually asked how I would divvy up developer time among these various components, which surprised me a little as it seemed like more of a PM question. I took my best shot at it though, and that’s something you should also be ready for.
At the end of the day, though, the thing that’ll help you the most is if you just relax. The interviewers don’t grill you relentlessly: they’re easy-going and want you to chat with them. If you do a little beforehand preparation, take it easy and act normally, while remembering my tips above, you’re in a solid position. Good luck!
Filed under: personal | Leave a Comment
Tags: advice, interview, job, microsoft