General Interview Tips
As you know, in the computer industry you have to anticipate how technology will operate five or more years down the road. To do that well means working through tough challenges no one may have even faced before. So our goal in your interview is to see how your mind works as you solve problems. This helps us get a better sense of what you're capable of, as well as what you've accomplished.
No matter what your area of interest, Microsoft interviews are designed to be challenging and thought-provoking. Here are a few basic tips to help you do your best:
• Dress comfortably. Wear whatever makes you most comfortable. The people interviewing you are likely to be casually dressed.
• Be open about your skills. Be up front about what you do or don't know. If you don't have an exact skill that an interviewer asks you about, don't panic! It's more important to us that you're a quick learner.
• Show your work. In other words, we want to know how you think. The process you use to arrive at an answer is even more important to us than the answer itself.
• Ask a lot of questions. Your natural curiosity is one of your biggest assets as a potential hire. Thoughtful, insightful questions will show that you're serious about making an impact at Microsoft. And, if you don't understand a question, don't be afraid to ask the interviewer to clarify.
• Try not to second-guess yourself. Don't spend too much energy trying to figure out how things are going and don't let one mistake get you down. Fact is, getting stressed out may inhibit your performance. Remember, what may seem like a big deal to you may not matter at all to your interviewers.
• Eat well and get enough sleep. Make sure you have the fuel and rest you need to stay relaxed and quick on your feet.
What kinds of questions should I expect?
• Technical Questions—If appropriate to your area of interest, technical questions will be asked that likely involve a technical discussion of projects you've worked on. Don't be afraid to stand up and write code on the whiteboard, draw your solution, or ask questions for clarification.
• Ambiguous Situational Questions—These questions can be hypothetical ("What would you do?") or reflective ("What have you done?") They're asked so you can show us what you've got. We need original, creative thinkers, and our interview process is designed to help us find those people. When in doubt, ask for clarification.
• Process Thinking Questions—These invite you to verbalize your thought process as you work through a technical issue, design question, or problem-solving puzzle. Remember, it's not always the end result we're looking for but the process you took to get there and your ability to clearly articulate it to others.
Will the interviews be in Mandarin or English
Our office’s official communication is English, but a lot of informal communication happens in Mandarin. Some of your interviews may be with native English speakers and some of them may speak little or no Mandarin. If you have difficulty understanding them, just try to relax and ask them to speak slower. We understand that you may not have the same level of English skills as native speakers, but we want to see you do your best to communicate in English because in your job you will often be using it. Occasionally an interview may switch into Mandarin to allow you to further explain yourself if something comes up that is hard to explain in English.
How many interviews will I have?
Most candidates have three interviews when they visit us in Zizhu. Sometimes we ask candidates to stay a little longer to meet with additional interviewers if we have more things to consider about the candidate but in most cases it is no more than five. You can expect that you might meet with people from a variety of disciplines and we often consider candidates for more than one job and team during the interview day.
Software Design Engineer (SDE) and Software Design Engineer in Test (SDET) Interview Prep
For SDE Candidates:
Be ready to code (a lot!). Brush up on your C/C++ skills, as our interviewers love to ask questions related to linked lists, loops, arrays and pointers, etc. When answering a coding question, think of the pros and cons of each solution. Then, once you decide to move ahead with a solution, be ready to explain why you chose that approach. Also, be sure to test your code before you say you're done.
In your SDE interview, be prepared to:
• Discuss coursework, projects, and work experience in specific terms.
• Share the practical application of any theory you reference.
• Demonstrate your technical knowledge (e.g. programming, design, or test).
• Talk about the projects, work experiences, or classes that you enjoyed the most and learned the most from.
• Discuss the most challenging project you completed in specific terms, including:
• Project scope (goals, customers, accomplishments, complexity)
• Technical skills you applied (gathered customer requirements, designed, programmed, or tested)
• Technical tools you employed (C, C++, C#, VB, SQL, Assembly)
• What you learned from your experience
For SDET Candidates:
An SDET's primary responsibility is to write code-often in the thousands of lines, usually built from scratch. In this role, you'll write automated testing tool suites and developer tools used only within Microsoft. Our SDETs write a lot more code than SDEs because, rather than tweaking a huge product code base, they're usually working in the realm of, "We don't have a tool. We need a tool. I'll write that tool." Our SDETs also own the complete product cycle for the tools they build, so there's a high sense of end-to-end code ownership.
In your SDET interview:
• Expect to be asked to test different features for the groups with which you interview. Be sure to test functionality, stress, boundary, error, security, and localization.
• Your ability to categorize the various test cases you come up with is important, so structure really helps.
• Try to come up with as many cases as possible. Even when you think you're done, push a bit harder and think of a couple more. Be creative!
The resources below come highly recommended from select managers across Microsoft to help you to become more familiar with our two primary technical positions and broaden your skill base overall.
• Essential .Net, Volume I: The Common Language Runtime. Box, Don. Addison-Wesley Professional, 2003.
• The Mythical Man-Month: Essays on Software Engineering. Brooks, Fredrick. Addison-Wesley Professional, 1995.
• Introduction to Algorithms. Cormen, T.H., Leiserson, C.E., Reivert, R.L., Stein, Cliff, eds. McGraw-Hill, 1990.
• Writing Secure Code. Howard, Michael, LeBlanc, David, eds. Microsoft Press, 2001.
• Code Complete: A Practical Handbook of Software Construction. McConnell, Steve. Microsoft Press, 1993.
• Writing Solid Code: Microsoft's Techniques for Developing Bug-Free C Programs. Maguire, Steve. Microsoft Press, 1993.
• Rapid Development: Taming Wild Software Schedules. McConnell, Steve. Microsoft Press, 1996.
• Modern Operating Systems. 2nd ed. Tanenbaum, Andrew. Prentice Hall, 2001.
You'll find helpful info in any or all of the above references plus:
• Lessons Learned in Software Testing. Kaner, Cem, Bach, James, and Pettichor, Bret, eds. John Wiley & Sons, 2002.
• Testing Computer Software (2nd Ed.). Kaner, Cem, Falk, Jack, & Nguyen, Hung Quoc, eds. International Thomson Computer Press, 1993.
• The Art of Software Testing. Myers, Glenford. John Wiley and Sons, 1979.
• Software Testing. Patton, Ron. SAMS Publishing, 2000.
• Building Secure Software: How to Avoid Security Problems the Right Way. Viega, John, McGraw, Gary, eds. Addison-Wesley, 2001.
Links to Online Testing Resources:
Program Manager (PM) Interview Prep
Microsoft's Program Managers have a rare ability to balance strong design skills with a talent for planning and organization. That said, PM interviews can be pretty challenging on design questions. When coming up with a solid design in your interview, consider:
• What is good design versus bad design?
• What is good software versus bad software?
• What are some examples of each and why?
• How would you improve or add to that product's features?
• What are the technical difficulties that arise?
• What are the tradeoffs involved- maybe how implementing one feature negatively affects another?
• How might you improve a device that already exists, or alter it to accommodate kids?
The resources below come highly recommended from select PMs across Microsoft to help you to become more familiar with the PM position and to broaden your skills overall.
• Programming Pearls: Second Edition. Bentley, Jon. Addison-Wesley, Inc., 2000.
• Design Patterns. Elements of Reusable Object-Oriented Software. Gamma, E., Helm, R., Johnson, R., Vlissides, J., eds. Addison-Wesley, 1994.
• The Practice of Programming. Kernighan, Brian, Pike, Rob, eds. Addison-Wesley, 1999.
See what our VP of Windows and Windows Live has to say about the role of Program Managers in our company in his blog at:
posted on 2007-03-20 21:37 w2001
阅读(1017) 评论(0) 编辑 收藏 引用