Microsoft Internship, part 2: The On-campus Interview « SterlingPorter.net

Microsoft Internship, part 2: The On-campus Interview « SterlingPorter.net

Honestly, I was shocked when I got an email inviting me to an on-campus interview with a Microsoft recruiter. I won’t lie and say my resume is junk, but I sure didn’t take pains to make my resume presentable (in part 1, I described how I folded up my resume and threw it in the raffle box, hoping to win a digital camera).

All the same, I decided to give the interview a try. My friend, Mike, suggested that I read a book about programming interviews to prepare. The one I read was Programming Interviews Exposed: Secrets to Landing Your Next Job by Noah Suojanen. This is probably the most helpful book I’ve ever read besides, of course, the Bible and the Book of Mormon. In the interviewing book, the authors take you through computer science basics like data structures and technical terminology, specifically those topics that frequently come up in programming interviews. In addition to this, the book provides a bunch of sample programming problems and puzzles to help you get your mind ready for whatever the interviewer might throw at you. I think the puzzles were the best part of the book because if you don’t know data structures already, a brief overview in this book or any other isn’t going to save you in an interview. Finally, the book offers really good advice on how to conduct yourself during the interview. It says that while solving a programming puzzle, make sure you “think out loud” so that the interviewer can understand your thought processes. This is just as important as solving the puzzle (sometimes more important). Honestly, this was the hardest part for me. Like a lot of people, I think better in a quiet place where can just sit and think. Talking through my solution as I’m coming up with it is very difficult.

Anyway, I had my inteview in the career placement department at BYU. I dressed up in slacks and a colored shirt (no tie)–this was suggested by the programming interviews book. My interviewer was an experienced software engineer that usually spent his time on small team in Redmond developing something secret, that is, something that hasn’t gone public yet. We chatted a little about my experience and my interests. Then he gave me one programming problem. He asked me to write a function in pseudocode that takes four points (x,y coordinates) and returns a boolean signifying whether the points form a rectangle.

From the book, I knew that I needed to talk my way through the problem, so I started with a simple case and described the associated naive solution. From here, I pointed out possible mistakes in the algorithm that someone could make (but not me!). I think inteviewers like it when you point out pitfalls and error prone approaches. Anyway, I’m not trying to toot my own horn. I actually had a little trouble recalling some good old trigonometry, so I’m sure I wasn’t impressive there. Overall, though, I thought I did okay in the interview.

After semi-solving the problem, the interviewer asked me which “position” would like to apply for if I was chosen to move on in the interviewing process. The options were the following:

• Software Design Engineer (SDE): you design, write code.
• Software Design Engineer in Test (SDET): you design, write test code to test what SDEs write.
• Program Manager (PM): you write specifications and requirements documents and kind of manage the SDE and SDET efforts.

I was asked to rank them, so I put 1) SDE, 2) PM, and 3) SDET. Looking back, I would have put SDET before PM. I explain later…

I found out that about 15 other candidates interviewed that day. I didn’t really think I had a super-great chance of moving on in the interviewing process, but hey, why would I be writing this series if it ended here?