среда, 8 апреля 2009, Александр Краковецкий

Каждый год компания Microsoft проводит отбор студентов и аспирантов со всего мира на летнюю практику в Редмонде. В этом году я также решил воспользоваться предоставляемой возможностью и отправил свое резюме в украинское отделение Microsoft.

Этап первый: отправка резюме в Редмонд и ожидание ответа.

Ответ может прийти через неделю, может через две. Моему другу ответ пришел на неделю раньше. Причина в том, что резюме попадают сразу нескольким рекрутерам, которые рассматривают резюме в порядке очереди и не обязательно привязываются к конкретному региону.

В ответе приглашение на предварительное (preliminary) интервью.

Этап второй: предварительное интервью

Целью первого интервью является знакомство с потенциальным кандидатом. Проводиться интервью с помощью Skype (!). Проверяется общий уровень человека (общие вопросы), знание английского языка, задаются некоторые простые технические вопросы, например:

1. Why Microsoft?
2. What is your favorite Microsoft product?
3. Why did you choose computer engenering?
4. What is your favorite programming language?
5. What is the difference between ArrayList and array?

Если вопрос не понятен, интервьювер повторит его столько раз, сколько вы попросите, поэтому фразы типа "sorry, repeat please", или "not understand", в принципе, не несут за собой автоматичесткое прекращение разговора и вычеркивание из списка потенциальных кандидатов.

Еще добавлю, что интервью на данном этапе проводят, в основном, девушки, поэтому здесь важно показать свое желание и интерес ко всему, что связано с Microsoft :-)

Обещали вскоре сообщить результаты по электронной почте.

Этап третий: предварительное техническое интервью

Так получилось, что предварительное интервью мне назначили независимо друг от друга два рекрутера, как потом я уже понял, первое было общим, второе - техническим. Тут уже по времени было дольше (около часа), и вопросы посложнее - с примерами кода и т.д.

Среди вопросов были такие:

1. Что такое инкапсуляция и полиморфизм?
2. Что такое абстрактные классы и для чего они нужны?
3. Что такое виртуальные методы?
4. Что такое стек, и как он работает?
5. Как работают generic классы?
6. Когда лучше использовать ArrayList, когда просто List?

Как видите, вопросы не слишком сложные, ответив на которые меня пригласили на следующий этап в Варшаву.

Этап четвертый: техническое интервью в Варшаве

Для прохождения технического интервью нужно было ехать в Варшаву. Скажу сразу, что вид транспорта можно было выбрать самому, причем компания Microsoft берет на себя всю организацию по покупке билетов, размещения в отеле, транспортные услуги и т.д. Кроме того, она же их и оплачивает.

Интервью включает в себя 3 части по 30 минут с разными специалистами, по трем позициям:

1. The Software Design Engineer in Test (SDET)
2. Software Design Engineer (SDE)
3. Program Manager (PM)

Все, что нужно было - получить визу. Вот как раз с этим у меня возникли проблемы. Все дело было в том, что посольство требует оригинал приглашения, которое с Редмонда пришло за два дня до того, как нужно было уже улетать :( Спасибо FedEx'у.

Потом конечно, я писал моим рекрутерам о том, чтобы перенести интервью но они ограничились еще одним десятиминутным телефонным интервью в стиле первого этапа. После этого стало понятно, что на этом мой путь стажера в этом году закончился...

Но, несмотря на все, я:

• получил реальный опыт прохождения нескольких этапов собеседований
  
• нашел и переварил кучу новой и полезной информации
• потренировал свой английский
• пополнил свою библиотеку на 3 новых книги

Кроме того, сделал следующие выводы:

• проходить собеседования можно и нужно!
• не доверять Fedex и писать самому заранее с просьбой высылать документы как можно раньше
• если в польском посольстве вам говорят принести факс, но принесите им факс :) так как распечатку электронного письма они не пропустят, даже если она на польском (который я не знаю) и вам действительно прислали ее с Польши 

Ниже хочу привести информацию о том, как нужно готовиться к интервью и как это все происходит:

A)  The Interview Day

The goals of the Microsoft interview process are for us to get to know you and for you to get to know us. We pride ourselves on an in-depth experience that allows that to happen. The process includes actually having you "do the job" during the interview. Expect that beyond asking questions about your background, we'll also have you test features and write code. If you don't feel comfortable with that, please let me know.

You will be interviewing for both Software Design Engineer (SDE) and Software Design Engineer in Test (SDET) positions in your interviews.  To prepare for the interviews, you'll want to brush up on your programming skills, including algorithms and data structures. You can expect that you'll be asked to write code during your interview.  Our interviewers like to ask questions related to linked lists, loops, arrays and pointers.  Be sure to test it before you say you're done!  You'll also want to get into a testing mindset, so spend some time thinking about how you'd test something.  For example: what kind of cases would you try, how would you organize those cases so you're sure you've covered everything, and which creative processes would you utilize? Remember, the basic responsibility is to make sure the feature works. Then, consider all the factors that could cause problems. What are the security implications of the feature? Will it work in another country? How can I stress this code? What are the boundaries and error conditions? We've attached a host of resources at the end of this e-mail should you want to review some information on these topics.

Beyond practical questions, we want to learn more about how you think, so you may come across some problem solving questions like puzzles and brainteasers.   These tend to be ambiguous, so when in doubt, ask plenty of questions to be sure you fully understand the problem.  SDET need to be able to articulate their opinions, how the issue they've identified will affect a customer, and what is the "right" thing to do.  And for any situation, you should be able to put yourself in the position of the customer - how would you expect this product to work?  The better candidates we see tend to:  diagram the problem, ask clarifying questions before trying to solve or write code, and check their work without being prompted.

During your interview day, you can expect to meet with three-five people for one hour apiece, so be sure to get a good night's sleep - it's an exhausting day!  Bring your questions as well – like what do you want to learn about the position, testing at Microsoft, the company in general, or even the Seattle area. Your interviews will be with other SDET and SDE managers, so you'll have the chance to have those issues addressed by the people doing the job. By the end of the day, we want to make sure that you have a good understanding of the role, team, and company.

B)  Know the Positions: 

1)  The Software Design Engineer in Test (SDET) Position:

The SDET position is one of the three core engineering positions at Microsoft, along with Program Manager and Software Development Engineer. All three positions leverage strong computer science engineering skills, with SDETs leveraging their technical and analytical skills as the primary drivers of quality.  Good SDET candidates help shape our products by:

• Participating in design and code inspections.
• Writing infrastructure tools and code to exercise our products.
• Understanding in exquisite detail how customers will use the product.

Not everyone is cut out to be an SDET; you need to be structured enough to make sure nothing is missed, creative enough to think like millions of customers, technical enough to write code and design algorithmically beautiful solutions, and articulate enough to let people know what you think!
In most SDET positions, you start by learning about your product and your customers - how else will you know how the product should work? From the beginning, you'll be an integral part of the team that designs and writes the code, providing feedback on its design and anticipating everything that could go wrong.  To prevent those possible disasters, you'll be writing code that automatically verifies that if anything does go wrong, your code will tell us. That means that you potentially write more code than the developers. You might also write code for tools to help find new problems or prevent bugs from happening in the first place. You might have the opportunity to work with "beta" customers before the release to make sure that any issues they have are addressed. As we near our ship date, all eyes will turn to you to make sure that the release of the product that your team created is ready for customers around the world to use!  Whether it's an established product that the world relies on or a new technology that could change the face of software, your work will ensure that Microsoft delivers a quality product.  SDET’s own the complete product cycle for the tools they build, so there is a high sense of end to end code ownership. 

Longer term, an SDET career can lead you down a management path or deep into technical engineering (or both!). Microsoft has a road map for success in both arenas, whether it's leading the teams that create products, managing a project and all the parts of it, or understanding patterns in the problems we encounter and engineering solutions that prevent them from happening again. We even have test architects, who help drive the testing vision of Microsoft across products; for example, implementing the standards we set. At Microsoft, we understand the value of a true testing discipline with a solid career path - something that many companies don't have.
We are looking for candidates that like to write code for the SDET role. They like to read and dissect the code and the underlying algorithms. They like to analyze what has and hasn’t been tested in an automated manner. We are NOT looking for black-box testers. SDETs are good at targeting specific coding problems and writing code to solve those problems.  During the interviews, some areas to be sure to test in your code will be: functionality, stress, performance, boundary, error, security, localization, etc.  The interviewers will be looking at your ability to categorize the various test cases you come up with, so try to be structured in your cases. However, the most important thing will be for you to come up with as many cases as you can think of, even when you think you are done, try to think of more cases and feel free to be creative.

2)  Software Design Engineer (SDE)

You’re the keeper of the code.  SDEs put all their technical talents and creativity to the test as they develop next generation applications, operating systems and tools, just to name a few.  Using C, C++, and C#, you will be building products from the ground up, writing code that turns concepts into new technologies and next-generation services. Your code is secure, robust, scalable, and efficient. It’s an opportunity to explore new technical realms and leave a lasting technical legacy.

3) Program Manager (PM)

As a Program Manager, you’ll drive the technical vision, design and implementation of next-generation software solutions. Managing feature sets throughout the product lifecycle, you’ll have the chance to see your design through to completion. Program Managers are advocates for end-users, so you passion for anticipating customer needs and creating outside-the-box solutions for them will really help you shine in this role. As a Program Manager you will have the ability to lead within a product’s life cycle using evangelism, empathy, and negotiation to define and deliver results. You will also be responsible for authoring technical specifications, including envisaged usage cases, customer scenarios, and prioritized requirements lists.

Responsibilities: Construct data structure and algorithms; write quality code; explore innovative technical solutions; test and debug code; contribute to feature definition and design; examine feature feasibility and estimate development time; work with team to meet deadlines.

И вот еще список литературы, по которой нужно готовиться к собеседованию:

Although we cannot guarantee a positive interview result, please feel free to utilize the resources below to explore the SDE, SDET and PM position and broaden the base of your technical skills.

Blogs

Here is the link to Microsoft’s Jobsblog- there is a lot of helpful resource about interviewing, etc:

• http://blogs.msdn.com/jobsblog/
• http://blogs.msdn.com/jobsblog/archive/2006/08/03/687832.aspx
• http://blogs.msdn.com/jobsblog/archive/2007/01/25/meet-mona-from-egypt-to-seattle.aspx
• http://blogs.msdn.com/techtalk/archive/2006/02/02/dev_at_microsoft.aspx - Steven Sinofsky's blog on the SDE role (Steve is the Senior VP of Windows and Windows Live at Microsoft)

Books

(SDET) testing book recommendations:

• Managing the Testing Process:  Practical Tools and Techniques for Managing Hardware and Software Testing (Author:  Rex Black)
• The Art of Software Testing (Author:  Glenford Myers)
• How to Break Software (Author:  James Wittaker)
• Building Secure Software:  How to Avoid Security Problems the Right Way (Author:  John Viega)

(SDE) book recommendations:

• Code Complete (Author:  Steve McConnell)
• Writing Secure Code (Authors: Michael Howard and David C. LeBlanc)
• Coder to Developer: Tools and Strategies for Delivering Your Software (Author:  Mike Gunderloy)

(PM) book recommendations:

• The Art of Project Management (Author: Scott Berkun)
• Programming Pearls: Second Edition.(Author: Jon Bentley)
• Design Patterns.  Elements of Reusable Object-Oriented Software. (Authors: E. Gamma, R. Helm, R. Johnson)
• The Practice of Programming.  (Authors:  Brian Kernighan, Rob Pike)

Other book recommendations if you have additional time:

• Essential.NET, Volume I: The Common Language Runtime (Author:  Don Box)
• The Mythical Man-Month: Essays on Software Engineering (Author:  Fedrick Brooks)
• Introduction to Algorithms (Authors:  T.H. Cormen; C.E. Leiserson; and R.L. Reivert)
• Writing Secure Code (Authors:  Michael Howard and David LeBlanc)
• Writing Solid Code: Microsoft's Techniques for Developing Bug-Free C Programs (Author:  Steve Maguire)
• Code Complete: A Practical Handbook of Software Construction (Author:  Steve McConnell)
• Rapid Development: Taming Wild Software Schedules (Author:  Steve McConnell)

Online Resources

• For general interviewing and how to prepare tips, you can visit http://www.microsoft.com/college/int_tips.mspx
• Visit:  http://www.microsoft.com/en/us/default.aspx to get familiar with Microsoft Products and Technologies. 
  
• Check out http://www.microsoft.com/college/meet_people.mspx#software to hear from Microsoft SDE and SDET’s about their roles and challenges 
  
• Software Testers Make the Grade - http://www.informationweek.com/756/testers.htm, Charles Waltner, Information Week
• Visual Studio Testing - http://msdn2.microsoft.com/en-us/library/Aa292484(VS.71).aspx 
  
• MSDN Testing .NET Application Blocks-Version 1.0 - http://msdn2.microsoft.com/en-us/library/ms998205.aspx
• Software QA/Test Resource Center - http://www.softwareqatest.com/qatfaq2.html#FAQ2_6
• Teaching Domain Testing: A Status Report  - http://www.testingeducation.org/articles/domain_testing_cseet.rtf, Cem Kaner, J.D., PhD
• An Introduction to Scenario Testing - http://www.testingeducation.org/articles/scenario_intro_ver4.doc, Cem Kaner, J.D., PhD
• A Course in Blackbox Software Testing - http://www.testingeducation.org/coursenotes/kaner_cem/ac_200108_blackboxtesting/, Center for Software Testing Education and Research
• The Grand Index of Techniques - http://www.testingcraft.com/techniques.html, Brian Marick, Testing Foundations 
• Microsoft external site for test/SDET discipline - http://msdn.com/testercenter
  

Misc tips

• Code, code, and then code some more – practice the languages you are most comfortable.  If you know C and C++, be sure to flip through some of the books recommended above. 
  
• Know your resume – inside and out.  Everything on your resume is fair game.  So if you noted down that you know a certain technology, you may be asked to demonstrate your knowledge.
• Revisit your CS fundamentals – flip through old CS course books, old projects etc from when you were at the University. 
  Practice problem solving questions – go to the internet, ask your friends and really practice.   When you practice with your friends – make sure to think out loud.  The interviewers care less about the answer and more about your problem solving and thought process.  One last tip - if an interviewer asks you a question you have heard before – let us know.  We typically can tell when candidates have heard of our questions.

Если будут дополнительные вопросы - задавайте в комментариях :)

---