So, I’ve unofficially been on blog-cation for the last few months. Don’t worry, it’s not that I’ve become less pessimistic about the world, or that I don’t have enough grading to complain about (trust me, I just finished CG1, and they are as awful as they were the last time I graded this course/project). I’ve just been, well, lazy. There you have it.
To the point, I just attended the Microsoft night-before-interview thingy at RIT, which was supposed to ease students’ worries about their interviews over the next few days. Unfortunately, the night seemed to do very little in that department.
I want to digress here for just a second. There is a certain type of person that you have all met, and it is the guy who asks a question just so he can tell you about himself. For example, take the question, “Does Microsoft have cubicles?” In the hands of one such egotistical annoyance, this becomes, “At my last co-op, at Thompson-West (the people who make Westlaw), we had cubicles, and I didn’t like cubicles. What is it like at Microsoft?”
You see, the person felt like adding both needless and self-serving information. First, he added the “at my last co-op”, which was to point out that he was, in fact, a superhero who had gotten a co-op already (just like every other 3rd/4th year CS major). The second part, where he worked and what they make, has no apparent link to the question (who cares which company uses cubicles? Most do!), and just points out that he had JAUC (Just Another Useless Co-op).
While I’m on this digression, why is it always the creepy kids who ask things like, “What is the male/female ratio?” Don’t they realize that their chances of getting a girlfriend would only improve with a facial implant and surgical removal of that creep-me-the-fuck-out characteristic? Just because there are more women doesn’t mean you are going to get lucky, buddy. Just be glad that somebody invented vasoline just for you.
Finally, onto the real point. Since the engineer at the talk didn’t give a very good story of the interview process, I’m going to tell you the story of my first Microsoft interview. Here goes.
I showed up 15 minutes early (as requested) to fill out a form. It has questions along the lines of:
- What position are you applying for?
- SDE – Software Development (or Design? I can never remember) Engineer
- SDET – Software Development Engineer in Test
- PM – Project Manager
- What business groups are you interested in? (You can find a description of each on Microsoft’s website)
- What are your computing interests?
- Miscellaneous other info (year level, blah blah blah)
The interview lasts about 30 minutes, and mine was split up like the following:
- 5 minutes – Hi, short resume questions, what do you like, what are you looking for
- 15 minutes – Coding question (see below)
- 10 minutes – Silly question (again, see below)
Coding Question
The coding question I received, and the type that is most handed out, was about linked lists. It was either inserting into a sorted link list or removing an item or items from a linked list, but it doesn’t really matter. The process works something like:
- Write the code on paper while the guy pretends to not be watching. Some people like you to talk to them while you do it, and others don’t. Feel free to ask about this, too (I always ask, “Do you want me to talk you through it while I’m doing it?”)
- The interviewer looks over the code to find obvious mistakes, and asks you what they are and to correct them
- The interviewer shows you some cases (graphically drawn), and has you walk through your algorithm, line-by-line, to see what happens.
- You go through normal cases and edge cases to make sure your algorithm works.
Like I said, this all takes about 15 minutes total, with the first 5-8 given to initially writing the algorithm, and the rest given to “hand testing” the algorithm. Remember that it is not important to get it right on the first try! It is more important to be able to recover from and correct mistakes.
One of the kids tonight made some comment to the point of, “Linked lists suck. Will you ask about them?” Of course they will. Links lists are the simplest test of understanding simple algorithms, multiple edge cases, the basics of indirection (pointers), and syntax, all without having to teach you about a complicated data structure. And don’t worry: everybody misses something writing a linked list algorithm the first time around.
Puzzle Question
The silly question I got was, “How would you test a Styrofoam cup?” I’ve heard others along the lines of designing a manhole cover and similarly non-software-related topics. The whole point here is just to make you think about the same basic principles that apply to designing and testing any product. I don’t remember all of my answers for the Styrofoam cup, but there were about 12, and I missed the last two. Here’s what I remember:
- Holds water
- Breakability
- Keeps hands from being burned / liquid at desired temperature
- Fits into cup holders
- Is recyclable
- Has necessary markings (type of plastic, etc.)
- Meets government requirements for materials
- Language markings are localized (I missed this one)
- Lids fit (I missed this one, but I think fits into cup holders should cover this as well)
I don’t remember the rest, but feel free to fill in the blanks in a comment to this post.
Things to remember
There are some general words of advice that I can think of (mostly in regards to coding questions):
- ASK ABOUT YOUR ASSUMPTIONS. Don’t be afraid to ask for clarification, especially in C/C++ questions (when I remove the element from the linked list, do you want me to delete/free/whatever it?)
- The three major “gotcha!”s in C/C++:
- Always check to see if a pointer is null before you check its contents, e.g. your “if” statements for linked lists should be of the form:
if(pointer && pointer->data == data) - Remember to null-terminate strings
- When copying a string, allocate the strlen + 1 (save space for null)
- Always check to see if a pointer is null before you check its contents, e.g. your “if” statements for linked lists should be of the form:
- One of the easiest ways to write correct code is to write linked-list code is to write the regular and edge cases down first. The person interviewing you is going to do it anyways, but you can beat him to the punch. For example, in deleting elements from a linked list, think about the following edge cases:
- Element not found
- Element is head (need to keep track of new head)
- Multiple elements in a row to be removed
- Element is last element
- head is null (probably the most missed)
- Try to be sociable – look the interviewer in the eye, talk to him, and smile/laugh/have fun. How would you feel if you had to interview lots of serious people? Writing software is supposed to be fun, and at least pretend like you enjoy it
You should also check out Wikipedia’s Microsoft Interview page, as it seems pretty close to what I experienced for the first-round technical interview.
That’s about all I have for now. If you think I’ve missed anything, let me know.
P.S. – It’s good to be noticed, and I’m thankful to everyone who has said something to me in person about my blog. If you guys have any requests for things for me to write about, just send me an email or grab me in the halls of Golisano.