I will take a brief step away from globalized speech applications today and talk about some tips for interviewing. These tips may or may not help you when interviewing at Microsoft because I differ sharply from many of my colleagues on how to interview a candidate.
As many of you might know, the traditional Microsoft interview involves asking a coding question on the board combined with possibly a 'puzzle' question. I abhor asking people to code on the board and generally only do it when my manager makes it very plain that I must ask such a question. The following are my reasons.
1) If the person is very nervous, he/she will likely blow the question.
2) There are only so many coding questions that can be completed within the standard time of an interview. A candidate that does his/her research can therefore be ready.
3) Coding questions tell you nothing about how the non-technical aspects of the job, that generally make the difference between star performers and those that must be let go.
I prefer to divide the interview between two roughly equal halves. In the first half, I will ask situational questions that will tell me a lot about how the person works. I learned this from an interview course I took at Microsoft, though it still seems many here do not follow it. During the second half, I will ask a technical question that I know he/she has not seen.
Although I will not of course divulge the technical questions I use here, I will not make a secret what situational questions I ask. The following are typical questions.
Give an example of the most creative idea you ever had
This really is a loaded question because I am expecting you to impress me with something very creative. Remember, you are giving your most creative effort - not just something that was cool. If your most creative effort was rather lame, I will assume that everything else must have been even worse. I will also get a good idea of your technical skills by how you describe the project. As you discuss the project, I will drill down into the details. Basically, the philosophy here is I can tell a lot more based on what you have done than what you can draw on the board for the standard technical question.
This question also has many forms. For instance I might ask instead the most successful project you ever were on or the most challenging. You get the picture.
Give an example of a time where you made a mistake
This question also takes many forms but the basic pattern is to look for counter evidence. Everyone makes mistakes, but not everyone learns from them. Another form of this question is "Can you think of anything you could have done better?" when drilling down into the previous question. The first key to answering this question is to always answer it. I will never give a thumbs up for an interview if he/she cannot think of anything. If a person thinks he/she has no faults then this person will be impossible to work with. When interviewing, you must be confident but also humble. I will also drill down to see how you learned from the mistake and how you avoided making the same mistake in the future.
Why do you want to work here?
This sounds like a very easy question but I have seen a number of people blow it. I ask this question most often to external candidates, because I want to see whether it is Microsoft they want to join or my particular team. I will often include questions such as why they find speech interesting. This is (was) the Speech Server team (now OCS team) and we are looking for people passionate about our product, not just people who want to work for Microsoft. One time I even made the question obvious and asked what one team the candidate would like to work on most within Microsoft. The answer was not our team, which in some ways I can understand - but then the candidate starting listing a number of groups and ours was not in the list!
Not everyone here interviews the same way, but the following suggestions will help you when interviewing with someone who does interview like I.
1) Be confident - you are interviewing for this position because you belong here. You are proud of your skills and your accomplishments and know you can succeed.
2) Be humble - you are a top notch developer or tester but you do have your faults. You are constantly improving and look to learn from every mistake. Do not pretend to be infallible because no matter how well you answer my technical questions I will not give a thumbs up to someone who I wouldn't want to work with.
3) Show team spirit - I don't know how many times I have heard something like "I had this great idea but my boss and everyone else didn't like it so I went and did it anyways and they saw I was right". This shows someone who is unwilling to work with others and I will give a thumbs down 100% of the time when I hear this, regardless of technical abilities. If you work here you will work on a team. There will be times you do not agree with other team members and you should strongly voice your opinion - but you should strive to come up with a compromise when you do not agree. Very often in our business decisions are technical in nature and can be proven/disproven with enough data. Try to show your point empiracally and get others to agree with you, rather than walking all over them. If you do not succeed in convincing them, give in and follow the team. If it turns out you were right the team will remember (without you reminding them) that you were against the idea and will respect your opinion more in the future. If it turns out you were wrong, it will look better for you that you went along with the team.
4) Show passion - You are interviewing because you really want this job. Not just a job but this job. Do talk about how this particular position interests you.
I will not of course divulge the standard technical question I use, but in general it is the type of question that is open ended and how well you answer it will determine what level I recommend you for. A more senior candidate will answer it in a way I hadn't thought of while a junior candidate will overlook important details. There is really no way to prepare for this question because it involves designing a solution to a problem, though experience in the field and knowledge of design patterns would help.
Personally, I will give the following advice which will likely flow counter to the advice of others at Microsoft.
1) Brush up on algorithms and data structures - OK, this one everyone would agree on but you should not spend a huge amount of time here. The idea is not to learn algorithms you previously did not know, but to brush up on ones you are already familiar with.
2) Learn to write better quality code - Do read books such as the Framework Guidelines book and Code Complete. Implement strong code at your current job and strive to always improve here. If looking at code you wrote just a few months ago makes you cringe, you are doing a good job.
3) Solve real world problems - You will get this with experience, but one other way is to design your own applications at home and pretend to 'ship' them. Give yourself a completion date and then write a specification for what you want to complete. You will find that you have to solve a number of technical problems in a cost effective way. Sometimes you will not have time to complete the elaborate solution that endless time would allow. Make sure your code is testable and that you test it. Create a 'Beta' for your application where others use it.
4) Don't despair if you are hit with a difficult coding problem on the board - I have learned this the hard way here but if you interview with a team that hits you with nothing but technical question after technical question that team is likely not a good one to join because you will likely find the work environment to be very poor. I know this sounds harsh but in my experience I have found the most success in teams that were interested in the more non-technical aspects of the job. Of course, you should try to answer the question as best as you can, but remember that you are interviewing the team as the team is interviewing you.