This is a guest post by Kaustav Dey Biswas. He is a total tech geek and loves his computer and computing stuff like anything in the world. Programming is something as natural to him as sleep. He’s sharing his Microsoft Internship Experience here.

Last summer, I got an opportunity for an Internship at Microsoft – India Development Center (MS-IDC), Hyderabad for my summer training. Microsoft IDC provides Internship to several students from all over the country every summer. For this, many engineering colleges are notified and interested pre-final year students from CS & IT disciplines are asked to submit their CVs online. The CVs are then filtered (usually by the 10+2 & Semester marks) and shortlisted students from each geographical zone are called in a written technical round consisting of MCQs. The students qualifying this test have to go through two rounds of technical interviews to make it as an ‘Intern @ Microsoft’.

But for me, though, the case was slightly different. I had no information about Microsoft Internships. I had participated in an online Unix-based programming event at IIT Mumbai’s annual TechFest. I came second in it, and was thereby offered an opportunity for Internship at Microsoft (apparently, the event was sponsored by Microsoft). As a result, I didn’t have to go through the CV short listing and the written test. I was directly called in for the Interviews, and thankfully, there was no HR. In the first round, I was asked some OS related questions to start with. I had to explain semaphores and write a few code snippets to demonstrate their usage. Then I was asked algorithm related questions on a few problems relating to sorting, and was asked to devise a few efficient algorithms based on linked lists and trees. To finish it off, I had to solve a couple of puzzles. In the second round of interview, there were a couple of simple programs for me to write in front of the interviewer. But the programs had to handle all sorts of exception conditions and I had to write several test cases to verify my own codes. I cleared both the rounds and was selected for the Internship.

I went over to Hyderabad and joined in alongside several students from all across the country (about seventy of them, mostly from IITs, NITs, BITs and IIITs). The duration of the Internship was to be selected by the candidate (with a minimum of 2 and a maximum of 6 months). I selected mine to be 2 months (that was the most common choice).

Microsoft IDC is the second largest development center of Microsoft, next only to their headquarters at Redmond, US. IDC works jointly with the other Development Centers on several products, and has ownership of a few. Products are grouped into product sets, on the basis of potential target users and field of usage (e.g., IBOT is the product set targeted towards business farms and corporate office usage, consisting of MS Office (Office), Office Mobile (OM), Dynamics CRM (CRM) and Duet). Each product is headed by a Product Unit Manager (PUM) and is subdivided into smaller components or features (e.g., MS Office is subdivided into Word, Excel, PowerPoint, etc). Each of those features has a set of 3 dedicated teams – Development (Dev), Testing (Test) and Product Management (PM), each consisting of 5-10 engineers and piloted by a team Lead and supervised by a Manager. While the Dev team is responsible for the core development, the Test team is supposed to author and automate test cases to test functionality and performance, while the PM team coordinates activities of the Dev and Test teams and keeps the product heads informed of the progress.

Each Intern was to be placed into a separate Team. As such, I was placed in the IBOT CRM Collaboration Test Team. CRM (Customer Relationship Management) is a product mainly targeted to be used in corporate service centers for tracking service and maintenance orders. It has come across several versions and now supports complete sales management, office integration & automation, a very tight hierarchical security scheme to support the organizational framework and a variety of other useful features. Collaboration is an Integration feature, newly being added to CRM. Integration teams are responsible for optional integration of the current product with another, completely different product. As such, this Collaboration Team was integrating CRM with SharePoint (SP), a server-based product used to set up a Team Site for collaborative processes, where different users from different teams of different hierarchy can share stuff and interact with the members of other teams.

The IBOT teams mainly use Visual C# and .NET (on a Win 2K3 / 2K8 Server platform) for the development. Apart from that, most products have platform libraries bundled into SDKs. These libraries are prewritten modules which are used in further stages of development, and are often shipped with the mainline product to enable system administrators to tweak the deployment as per the organization’s needs. At Microsoft, code reusability is very much stressed upon. They believe that rewriting prewritten code wastes valuable time and pumps up the maintainability cost. As such, utmost care is taken while building the class hierarchy structures and writing new code so that it can be made as generic as possible and to facilitate portability. Before writing even a single module (however simple it may be), you must search the source tree to find if there is any compatible module already available, and use it wherever possible, without hampering efficiency. If you think that you have a better way of putting things than the prewritten module, you can’t just say “Do hell with the crap module, I will write it myself”. In such a situation, you need to contact the original writer of that module, discuss your suggested improvements with him and get it updated in such a way that codes already using that module shouldn’t break. You then use the updated module. In short, you must avoid rewriting code as much as possible, and try to rely mostly on SDKs. The Integration teams need to know the SDKs of both the mother product as well as that of the product it is being integrated with, equally well.

The Interns are given a very short time to ramp up on the SDKs. Now this is one big problem for the ‘googlers’ like me! If you fail to understand things and try to google up in search of a solution, you will, in most cases, draw a blank because you are probably the first person to be working on it! The SDKs are not adequately documented and suffer from several frequent versioned and sub-versioned changes. Actually, with the tight schedule that people are put into, they barely finish their work in time, and are least bothered about documenting their codes elaborately or updating the central documentation resources. As such, in many cases, you need to study the codes and the inline comments to understand how things work.

At Microsoft, an incremental development methodology is followed. The whole product is subdivided into several Features, and these features are grouped into Milestones as per priority level. The initial Milestones deal with the core level features, while the later Milestones gradually give way to optional features, add-ons and enhancements. At every Milestone, key areas and feature upgrades are highlighted. Implementation policies are then set up by the PM team, and are audited and finally agreed upon through several conferences with the Dev and Test teams. Once the feature design (called Specs) has been locked, the Devs set to work and come up with a pseudo code for the implementation (called the Dev Design), while the Testers work parallel on identifying key fault areas, stress points, performance bottlenecks and Spec bugs, if any. Whenever the Testers detect a glitch, a Bug is opened with a unique ID and is assigned to the concerned person. Once the Spec Sheet and the Dev Design are finalized, Testable Units (TUs) are identified and assigned to different members of the Dev team, with a deadline. These TUs are subparts of the features that can be tested independently; this allows the Devs and Testers to work in parallel. While the Devs work on delivering the TUs in time, the Testers are individually assigned Dev ‘Buddies’ (i.e., the Developer whose work he will verify) and they start off Authoring and Automating Test Cases (TC). In the Test Authoring phase, the concerned Tester identifies the code paths and potential error-prone regions from the Dev Design, and writes TCs to exploit them thoroughly in an attempt to break the code (“A successful test is one which fails the program”). Then, the minimal set of TCs required for verifying the basic functionality of the code are identified and isolated as ‘Scorecards’. In the Test Automation phase, the concerned Tester writes down automation scripts (which provide inputs to the program, calculate the output in a way different from the way the program works, and tally the results) for the authored TCs. The Scorecards are automated as a first priority. When the TUs are delivered by a Dev, he first calls upon one of his teammates (also a Dev) to Review his code (this is done to ensure that things are looked at from different points of view and nothing is missed). After the code review is complete, the feature is first manually verified for basic functionality by his Test Buddy (called Buddy Testing) and the relevant Scorecards are then run on it automatically on several servers, environments and architectures, and failures are identified. Whenever the Dev code fails, a bug is opened by the Tester and is assigned to the concerned Developer, who needs to resolve and resubmit the corrected code on priority. After thoroughly rechecking the bug and verifying that it has been resolved, the Tester closes the bug. After all the TUs have been delivered by the Dev team, the Code Complete flag is reached. The process then enters Stabilization phase, wherein the Testers run all their TCs (called the Feature Verification Tests – FVTs) and bugs are opened and resolved. Once all the bugs are resolved and the features have been optimized for performance and stress handling, the code is ‘Handed-off’ and the Milestone is deemed complete. The next Milestone starts shortly thereafter and the cycle repeats until all the Milestones are completed. The product then moves into the Release Candidate (RC) phase. Thereafter, several alpha and beta versions are released and extensive testing and bug-reporting is carried out by vendors and real-world users until a stable (final) version of the product is released and shipped.

At every phase, several open meetings and conferences are carried out. These meetings can be scheduled by anyone in the team, and may even include people from other teams (if relevant) to obtain diverse opinions and suggestions on different issues. People schedule team meetings after taking every single step, to make sure that it’s the best possible foot forward, and to make use of the collective intellect of the entire team. Apart from these, there are weekly and monthly status report meetings at different hierarchies. One-to-one meetings can also be scheduled by anyone with anyone to close down on personal or less-important issues. As a whole, people spend almost half the time attending meetings and teleconferences! But it results in a very strong coordination within teams and provides enough freedom and encouragement for anyone and everyone to come up with brilliant ideas and novel solutions to problems (and more importantly, novel problems to solutions!). “Identifying problems is as important as solving them”! Utmost care is taken to identify and resolve issues at an early stage, so that after having invested months into a project, blocking issues doesn’t come up to render the project practically unfeasible, or requires to undo everything and start off from the beginning with a new plan.

Several internal tools are used to aid the development process. The most important of them is the Source Depot (SD). As the name suggests, it is a centralized system which holds the entire source tree for a project (product), including core product source codes, test automation codes, built binaries and documentations, all arranged in a proper modular way. This huge storage is split across several servers in the Redmond HQ, and is also locally cached in the servers of the Development Centers working on that particular project. It has extensive support for maintenance and versioning, parallel modifications and resolutions and very stringent, inbuilt checks to verify that updating of codes doesn’t cause other dependant codes to break. SD has a hierarchical access corresponding to the department and role of the enlisting person, and as such, people in CRM project have access to only the CRM codes. Several commands and options are available under SD’s build window to compile code fragments, sync to changes, edit or add new code and submit modifications to the main source tree. Mainline sub-versioned builds are automated and scheduled at the end of each day, so that after each day, you have a complete build with the latest changes incorporated. Whenever a new code or a change is submitted, it is put through ‘Gauntlet’, an automated gatekeeper that compiles and builds the code, verifies rules based on good programming practices, builds the entire source tree from scratch with the change incorporated (to ensure that the change doesn’t break dependant codes) and runs various tests to ensure everything is in order. A change, no matter how small, takes about 4 hours of processing in the Gauntlet, and if (and only if) it passes all the tests, it is added to the SD (this is called a Check-in).

Other useful tools include the Product Studio (PS), which tracks submission of TUs and the corresponding automated TCs to be run against each of them, internally schedules the TCs to run once the corresponding feature is delivered and updates the results (pass percentage, logs, etc). Another tool widely in use is the CRM, for assigning and tracking jobs, verifying their status and remaining time, and automatically updating the overall progress chart. Apart from these, several products are internally modified to suit the particular needs of development teams (e.g., Microsoft Rascal, an internal scaled-down version of the Visual Studio, has replaced the more feature-rich but memory-hungry Visual Studio). Overall, everything is so much well-planned, integrated and well-maintained with everything else that you can seamlessly work between applications without worrying for inconsistencies. A perfect blend of centralization and distribution; update at one place, and it gets updated everywhere!

At Microsoft, you never fall short of resources. If you need ten machines to work with, the machines will be delivered to your cubicle (or dedicated to you via remote desktop connection from the central labs) within ten minutes. The work environment is awesome! The employees enjoy their work, and literally hate to leave office! If you get to any corner of the office, whether it is a cafeteria, canteen, passage, parking lot, or even a toilet, you will hear people talking of Check-ins and dlls and network protocols! There are no conversations on sports, music, movies or politics anywhere, and as such, no scope for diversion. There is no dress code, and there are no work hours; all that matters is completion before deadlines. Informal meetings take place on dinner tables and smoking zones. And if, at any point of time, you feel bored of your work, you have TT tables, Fusball arcades, pool tables, gyms and even football grounds to sweat it out or to relax, whatever be your choice.

Overall, at Microsoft, people do make mistakes and you can find rare instances of lack of coordination, but the elegance of design, the sophisticated development methodologies, the focused approach to close down issues on priority and the seamless integration of human innovation and automated tools make everything fall in place and help craft seemingly flawless products. “If you perfect every small step, the end product comes out perfect automatically”!

It took me time to understand all relevant things, learn Visual Studio and .NET from scratch and ramp up on the SDKs before going productive. But with the help of my Mentor (a team-mate) and my Manager (our team Lead), I got the hang of things very fast and adapted quickly. I developed several wrapper libraries (libraries wrapping up the platform libraries, so that changes in platform libraries can be easily accommodated by making the corresponding changes in the interface methods of the wrappers, rather than changing the actual codes at several places), and authored and automated several test suites relating to the security mapping between CRM and SP. At the end of my Internship period, I was given a fair review and was recommended for Full Time Employee (FTE) by my Mentor and Manager. Thereafter, I had to face two rounds of technical interviews. My first interview was scheduled with the Manager of my Manager (MOM), and I was given a design oriented problem: Discuss and design the entire test suite, including the base wrapper libraries, for testing Recurring Appointments in Microsoft Outlook. I had no idea on how that works, and so I bugged him a lot, asking for clarifications and assumptions at every step. At the end, we agreed upon a fair picture, and I was cleared for the final round of interview. This interview was scheduled with the MOM of another team. Here, I was asked some generic questions on my Internship experience, key learning and improvement points, some basic questions on C and data-structures, a couple of puzzles and a program to be coded on the board with as much efficiency and as little time as possible. I had a fair performance there, and at the end, I was selected as an FTE at Microsoft IDC.

It was an amazing experience all through, and I am looking forward to meet new challenges and enjoy my work at the Microsoft IDC.