For an Audio Summary, click the Play button below:

Back in July 2005, it was the last 1-1 with my manager David during the 11 week Software Development Internship when he offered me the full time role of Software Development Engineer on the Project team. And without even thinking about it, I knew a huge door of opportunity had just opened for me. I immediately accepted the offer and let David know that I will be glad to join the Project Team after I graduated from University of Toronto next summer. Looking back at it, years later I can now comprehend the huge impact this moment had on my life. I ended up spending the next two decades in this part of the world, working for two of the biggest tech companies of our time - Microsoft and Amazon. The journey that started with my internship is still going on, and with each new experience and challenge I have learnt an immense amount of wisdom from amazing people I met, wisdom about how to navigate your career in the Tech Industry.

After I completed my internship, I flew back to Toronto for a few days before flying back home to Kashmir to spend the rest of my summer with my family. They were excited to hear about all the fun stories about my internship at Microsoft. Above everyone else, my grandfather used to be the most expressive with how happy he was about all that I had accomplished. He would often talk to strangers and brag about his grandson working at Microsoft. I told my family stories about how all the interns at Microsoft that summer got invited to Bill Gates home and how I got to also see him and ask him a question.

A few days after I had arrived in Kashmir, I got a call from a Microsoft recruiter to go over the details of my Full Time offer. I remember taking the call in a room with a pen and diary jotting down the details. I still have that diary and those initial offer details. It was an exciting moment. The verbal offer that David gave me during my last 1-1, was now more formally presented to me by a Microsoft Recruiter. I conveyed my acceptance of the offer over the phone with the recruiter and didn’t negotiate at all. I was happy and really excited to start my career. Having experienced the team culture over the summer at Microsoft Project, I couldn’t wait to get back next year and write code.

Once I started back at University of Toronto, I decided to pick as many courses related to Computer Engineering as possible. I remember taking on Computer Networking, Operating Systems, and a few other related classes. I was still going to graduate as an Electrical Engineer, but given I was about to start a career in software, I wanted to prepare for it by trying to maximize my experience with computer related courses.

For my design project, I joined a group of four classmates and decided to build an application for mobile hand held devices for doctors and caregivers at the hospital. We called it the Patient Pocket Care. This design project was the most interesting and relevant thing I did during my fourth year. We started out the project with Palm’s Pocket PC device. One of our teammate got us a few Palm devices from someone he knew at Palm, and was willing to sponsor our design work.

Making the conscious choice of spending time learning about computers and software during the fourth year helped me get a bit more familiar with programming and learn about a few advanced concepts.

Tip #1: During your college, maximize exposure to courses that would be relevant to your future career. Learning at college is different from learning on the job, you will miss the immersive experience.

During the fall semester, we tried but struggled to build a prototype. The development environment and support for Palm OS was very limited and didn’t help at all. As we were approaching the winter break, we had barely made any real progress. Given my experience during the summer internship with C# and .NET, I felt confident about switching strategies and building for Windows Mobile instead. My teammates didn’t have a choice either, given we only had one more semester left and had to deliver something. I partnered with one of my teammates (let’s call him Fahim) to build the entire mobile app together. I had partnered with Fahim before, during my third year on another project, for the Digital Logic class, where we built a game of maze on the Altera Board. That project had a bit of hardware challenges with custom remote controllers using circuit boards and push switches. This was a totally different collaboration, with no hardware involved.

This early experience taught me the value of pivots in software engineering and how past experiences and the right skills can help in unblocking projects. Within a couple of weeks, our application was up and running on the Visual Studio emulator, and we had convinced the other two teammates to drop the idea of building with Palm OS and focus squarely on the Windows Mobile experience. The second semester was a smooth ride with lots of feature polishing and writing the final design document and demo. The project was very well received and we successfully demonstrated a working application during our final demo.

Tip #2: When blocked on a project, evaluate alternative options and be open to pivots in strategy. Evaluate the skill set you bring to the table, and change course with confidence.

I will remember the time I spent at University of Toronto for the rest of my life. This was the first time I had left my hometown and ventured out into the world, all alone pursuing a career. Along the way I met a number of amazing friends and teachers. There were times when I felt lost and didn’t know what the future would bring. At the same time, with each struggle came a learning opportunity to build skills for the future.

The number one thing I would consider the University gave me was access to opportunity. The career defining walk that I took from the computer lab in the engineering department, to University College building where the career fair was happening, probably turned out to be that opportunity. Whether you are just starting out college, or have already completed studies, remember to keep looking out for opportunities and make the most of it. Even if you have a full time job already lined up after completing your studies, do not give up the desire to learn and prepare.

Tip #3: A professional career is a long journey where you will need to constantly learn and relearn skills to stay relevant. The only thing that will never come back is the time you spend, so spend it wisely.

As I wrapped up my final exams, I packed up and left my college dorm to spend a couple of days with a family in Toronto, who had helped me throughout my 4 years in Canada. This family provided me with the emotional support that I needed to survive the 4 years of college away from my home. I would often visit them during my winter breaks and weekends. They would also take me to a number of local community gatherings and events where I met a lot of people from our wider community in Toronto. They would treat me with kindness and always made me feel at home.

On my last day in Toronto, my friend came to pick me up from their home, as they were all at work, and dropped me to the airport. Before leaving their home, I left a letter on their dining table, thanking them for the immense contribution they made in making my time in Canada memorable and enjoyable.

For an Audio Summary, click the Play button below:

Interviews are a fundamental step in the process of getting any job. Having a direct conversation allows both the interviewer and the interviewee to understand each other better and make an informed decision about the future prospect of working together. Interviewing in the Tech Industry has changed very little in the last couple of decades. However, the Tech Industry’s hiring practices are a bit unique, in the way it attracts candidates from a wide range of diverse backgrounds and skills. While hiring interns, a common practice in Big Tech is to look for “Growth Potential” of candidates through the interview process. Having the technical skills to qualify the interview is important. However, there have been countless examples when the Tech Industry gave a chance to a non-tech student for technical roles, and years later this person had a great and successful career. The key reason why this model succeeds, is because a lot of the learning and skill acquisition in Software Development roles happens on the job. As long as you have the motivation and the desire to learn, you will succeed and thrive in your career.

The first person that you probably interact with as a student is the recruiter. Recruiters reach out to students in a number of ways, Career Fairs, LinkedIn, etc. When you get that first email from a recruiter, make sure to do your research and respond promptly. This message could turn out to be the door of opportunity that life just opened for you.

Once a recruiter finds the right candidate, they work to set up an interview. Interviews for entry level Software Development Engineer roles consist of a group of interviewers, usually called a loop, who take turns to interview the candidate. Your recruiter would work closely with you to schedule a series of about three to five interviews with current employees of the company.

As a first interaction with the company, make sure you are respectful in your communication and ensure you meet your commitments. It is okay to ask for some time to prepare for your interviews, but avoid frequent or last minute re-schedules. It takes effort and time to get a bunch of people’s calendars lined up.

In my 5th semester at University of Toronto, it was a single email from a recruiter (let’s call her Nancy) from Microsoft that opened up the opportunities for me. Nancy wrote an email to me after coming across my resume that I had dropped off at the Career Fair on campus. As days and weeks went by, I realized what a crucial role a recruiter plays in the hiring process. Nancy helped demystify the whole process for me and made sure I understood what the expectations were at each stage of my hiring process. Recently, I found Nancy after 18 years on LinkedIn, and sent her a quick note of appreciation for the important role she played in giving me a chance to work for Microsoft.

Tip #1: Communicate respectfully and promptly to the initial communication from the Recruiter. When asked for an interview schedule, give firm dates and commit to the schedule once set.

Read more

For an Audio Summary, click the Play button below:

Test Driven Development (TDD) has been around for a long time. For those unfamiliar with the term, the technique usually involves writing Automated Tests for the Customer Experience of your Software, before you even write the Software. You may naturally ask the question, but aren’t the tests going to all fail as the Software has not been written yet? That is exactly the point with Test Driven Development. You write failing tests, that capture all the Customer Scenarios your software is going to implement, and then you follow up with writing the actual software, to make each of those tests pass as you flesh out the implementation.

The practice of Test Driven Development, was made popular by Kent Beck, an American Software Engineer, who helped pioneer the concepts of extreme programming in the late 90s. Test Driven Development has a number of merits that enable software engineers to code confidently and produce bar raising software with low defect rates.

In the summer of 2010, I got my first opportunity to mentor an intern, Jamil. Before Jamil started on the team, I thought about different projects that I could ask Jamil to work on. I also thought about how to enable Jamil to implement his software while using the practice of Test Driven Development. This was a radical idea at the time, and I really appreciate Paul, my manager at the time, who supported me in this direction. An intern’s time is limited, usually around 12 weeks, and for a Software Development Engineering intern, writing working software is crucial for assessing their ability to succeed as an intern. My idea was to have Jamil, spend the first couple of weeks of his internship to learn about the Customer Experience of the software he was going to produce, and write automated tests that would fail to pass at the beginning.

As Jamil started on the team, I explained the ideas to him and referred him to some of the written material on the concept. Jamil was excited about the idea and started learning about the concepts. I also introduced Jamil to the XML based Test Automation Infrastructure, that I had created for the Scheduling Engine of Microsoft Project. The automation infrastructure was crucial in allowing Jamil to write the automated tests upfront, and then follow up with writing the actual software to build the desired customer experience. Jamil, understood the concept, and had the necessary automation infrastructure to build his software, working backwards from the Customer Experience.

Tip #1: Test Driven Development only works if you have a good Automation Infrastructure to begin with, that allows you to extend the behavior of your Software. Before you jump into using the technique, evaluate the readiness of your Automation Infrastructure.

Read more

For an Audio Summary, click the Play button below:

Getting the internship offer is a great accomplishment and a stepping stone to a career in the Tech Industry. The internship role gives you a glimpse of what working within a Tech company looks like. You are able to experience the technical as well as the cultural sides of engineering. So, if you find yourself with this opportunity, and really like what you experienced as an intern, how can you ensure you are able to come back as a full time engineer. Let me take you behind the scenes and share a couple of decades of experience in observing both successful and unsuccessful internships, and how you can ensure that you are able to deliver your best work and secure the return offer.

I was hired as a Software Development Engineer Intern and the expectations of the role involved a good amount of technical work. For my intern project, I had to follow the complete lifecycle of a typical Software Development Engineering project - review Business Requirements, create an Engineering Design, identify Task Breakdown, write the Code, Validate and Test, present the Final Demo. I remember authoring 3 engineering design documents for my project, one for the design changes I made to the datasets for backend business logic, one for the API design for Project Server, and the last one for the Project Web App (PWA) UI and how I integrated with the APIs.

The bulk of my time was spent coding and integrating my changes with adjacent components. In the development phase, there were some issues that required me to dive deep and go into uncharted territories and unblock myself, sometimes with limited help.

The Final Internship Review would involve your mentor and manager taking a close look at the technical deliverables you produced, whether it is the engineering designs you wrote or the code changes you implemented. Raising the bar on the technical level is the single most important factor in determining whether you would get the return offer or not. During your internship, keep documenting your work and remember to review it with other engineers to raise the level of quality of the artifacts you produce. This will help you demonstrate the key competencies of a Software Development Engineer.

Tip #1: Demonstrating key Technical Skills, both design and implementation, is the single most important factor in determining the outcome of your internship. Focus on writing bar raising engineering designs and solid code.

Read more

For an Audio Summary, click the Play button below:

Automated Testing techniques have been around for as long as people have written Software. Very early on in the Software Industry, as more and more code was written and the lifecycle of software extended beyond multiple releases, it became evident that Software Engineers had to protect the existing functionality, while building new features. This requirement to protect code against bugs, that may get introduced as a side effect of the evolution of the code base, is what led to a huge amount of innovation in the Automated Testing space of Software.

When I started on the Project Team as an intern back in 2005, the dominant project management methodology across Microsoft was still the traditional Waterfall Model. Software releases typically spanned multiple years, and in the case of Microsoft Office it would generally be about every 3 years, that a new version of Office would be released to the world. Behind the scenes, during those three long years, Software Engineers would make massive changes to the existing code base that had shipped with the previous version. With the dominance of Microsoft Office, and the wide adoption among customers, it was crucial to not break existing features that were released in the prior version.

When thinking about Automated Testing, there are several techniques that you can apply to validate your software. The most basic form of automated testing, that is applicable to most software projects, is “Functional Testing”.  

One of the most common forms of Functional Testing is “Unit Tests”. Unit Tests generally refer to the type of automated tests that are written right alongside the Software that is being tested. The primary aim of Unit Tests is to validate the implementation details of the classes and methods written for a feature. With Unit Tests you can instantiate internal classes and call methods within them, just as you would while writing your code. 

In addition to validating the inner details of the methods and classes within your code, it is also important to validate the external user facing features that the code implements. This is where the technique of “Integration Tests” comes in. With integration tests, you can validate the end-to-end customer scenarios that are implemented by your feature. The usual way you implement Integration Tests is by exposing software hooks that can be called externally from a different application to mimic customer interactions in an automated environment. 

Tip #1: Any Software you write must be accompanied by Automated Functional Tests, that validate the Business Requirements implemented by the Software. It is important to test the inner workings of your code with Unit Tests and test the end-to-end user flows with Integration Tests.

Read more

For an Audio Summary, click the Play button below:

There is a difference between writing code at College for your class assignments and how code gets written in the Industry by Professional Software Engineers. A lot of students are unaware of some of these simple yet important best practices of Software Engineering and may get started on the wrong foot when submitting their first code change. So, what are some of the best practices that you should keep in mind when writing your first lines of code on the job?

At college, we usually write code as part of small assignments or projects that are isolated and independently authored, without any significant dependencies. Additionally, once we are done with writing our code, it usually gets graded and becomes part of our historical record without any future ongoing development. This “fire and forget” model is a fundamental difference between code written at college vs code written professionally at work. In general, the code you write at work professionally is written on top of existing code bases, written over many years, and will likely be part of the product long after you have moved on to different parts of the code base or a different job. This inherent long term lifecycle of professional code requires professional software engineers to adhere to certain key Coding Style Guidelines when writing code.

There are a lot of different cultural aspects of Coding Styles that vary across multiple companies. Some companies have a central Coding Style Guidelines where the entire code base of the company has to adhere to a central Coding Style (e.g. Google). In other companies, there may be a different Coding Style Guideline for each product or organization based on differences that have evolved over many decades (e.g. Microsoft). Whether there is a company wide or a team wide Coding Style Guideline, it is important for you to reach out to your mentor or manager and start becoming familiar with it.

Tip #1: Understand the Coding Style Guidelines used by your team before you start writing your code. This is important to maintain your code long term.

Read more

For an Audio Summary, click the Play button below:

As you start to think about your first project, one of the best ways to gather your thoughts and collect feedback is to author an Engineering Design. In the Tech Industry, writing Engineering Designs is a standard practice that all Software Engineers are expected to master. This comprehensive document translates the Business Requirements, usually defined by your Product Manager, into an executable Engineering Plan, that anybody old follow and write the Software. So, what are some of the things to consider as you begin writing your first Engineering Design? Let’s dive in and understand the best practices for Software Engineering Designs.

Back at my internship, during the second week, after getting set up and getting to know a few people, I started to understand the project requirements and how to go about translating them into Software. This is when Matt introduced me to the concept of Engineering Designs and how the Project team used them to create in depth Engineering plans for all the components of the Architecture. Matt introduced me to a SharePoint Document Library that had a list of dozens of Engineering Designs written by different engineers of the Project Team over many years. I started to browse through this huge volume of designs and began to familiarize myself with the areas of the Project Server Architecture that I was going to be implementing my features in.

While going through the different designs, I noticed all of them were using the same template. Matt gave me instructions to use the same template as was used by other Engineering Designs to author the details of my project. I got up to speed and quickly started producing one of my first Engineering Designs, about the changes I was going to propose for the Datasets used by the Portfolio Modeler feature. I followed the template closely and used the instructions given in each section to provide as much details as I could about my feature design. I also used the Visual Studio’s DataSet Visualizer to capture images about the Schema of my DataSet design and added them to the Engineering Design to make the reader understand the proposed changes.

The Project Team had a great culture of writing Engineering Designs. As a newcomer to the team, I could instantly connect with the details about the Architecture of Project Server and author the incremental changes that would enable me to implement my features. Additionally, having a standardized Engineering Design template removed a lot of ambiguity around what the team considered important when describing their engineering designs.

Tip #1: Before you start writing Code, spend time creating an Engineering Design for your project. If your team uses a standardized template, use it to capture the essential details of your proposed Architecture.

Read more

For an Audio Summary, click the Play button below:

A lot of us are afraid of presenting to a big audience. Some of us feel unprepared and not sure if we will be able to present our work in the best manner. While you are busy with the details of the project work during your internship, remember that at some point you will be asked to present your work to the wider team. The Intern Demo is a great tradition followed by a lot of Tech companies, where usually the entire organization is invited, and the team’s interns are given an opportunity to present their work. The demo usually happens at the end of your internship as you are wrapping up your work. So, how should you prepare for this important milestone of your internship? Are there things that you could anticipate and prepare for that would make this a memorable experience.

During the heart of my summer internship at Microsoft back in 2005, as I got busy in implementing the multiple UI pages for the Portfolio Modeler, I remember printing out the final UI of each page as I finished it and hanging it on the cork board. In total I finished implementing about 14 Project Web App UI pages, and I remember creating this wall of screen shots of the full feature. Anytime someone dropped by my office, they would start looking at the screenshots and this would give me an invaluable channel of direct feedback and understand what resonated with the team. It also became immensely motivating to complete each new UI page and aim to stretch myself and complete the full feature.

In the second half of my internship, Matt introduced me to the idea of starting to prepare for the Intern Demo. He mentioned that during the demo, I will be able to present my work to the entire Project team and get to showcase all the hard work I put into my internship and receive recognition for my efforts. This felt like a huge opportunity and I instantly recognized how valuable it would be to demonstrate my work to the entire team.

Perhaps, this opportunity that I was going to get in the end, motivated me to go above and beyond the initial scope of the intern project, and deliver a fully functional Portfolio Modeler feature.

Tip #1: Presenting your work is an important part of professional life. It may feel overwhelming, but the recognition that comes with it, will make you feel valued and inspire you to do epic work.

Read more

For an Audio Summary, click the Play button below:

As you get started with your internship, you might wonder how to balance your time between working hard, while at the same time prioritize some fun moments. How do you meet the key objectives of your internship, and at the same time feel energized and enjoy the ride? To help you create this balance, all major intern programs across the tech industry offer Intern Morale events, as an essential part of the intern experience. These events are uniquely designed to instill a sense of community and provide a huge opportunity for new interns to connect and learn from one another. As you start on your internship, you will likely get added to a bunch of email lists, team groups or slack channels, dedicated to provide support to interns and help organize some morale events. So you might wonder how should you handle all the invitations of going out and having fun.

When I started as an intern at Microsoft back in 2005, there was a famous distribution list, called “ms-interns”. This email list was famous for an endless stream of emails from thousands of interns at the company. The initial perception I had of the group was to stay away and not get entangled in the flood of invites and events. However, I kept an eye out for some of the major events getting planned. One such event, was the famous “Lunch at Bill Gates House”. I would probably not go in the details of that event in this post, as it would require a dedicated article. There were other events like the “Hiking at Mount Rainier” with all the interns, which I did attend. Overall the company wide events were very well organized and had a huge participation from the intern community.

Attending a few of these events was really valuable as it gave me a good sense of the diverse backgrounds from which interns came at Microsoft, and got me a few early connections at the company. During these events, I also got to pick up a general sense of culture of the overall company. A number of these events used to be attended by a few leaders across the company and this provided a valuable opportunity to interact with them in these off work settings.

Tip #1: Attending a few company wide morale events provides a valuable opportunity to learn about the company culture. If this is the place where you will end up starting your career, it will benefit you to learn about the big picture.

Read more

For an Audio Summary, click the Play button below:

An internship is a short and impactful time that can be of huge significance to your future career. It is the one window of opportunity for you to start your career and enter the professional world. In today’s competitive landscape, if you have landed an internship at a company, you are indeed one of the lucky ones and should feel really happy and proud of your achievement. If you are still applying, don’t give up and remember that there is an opportunity still waiting for you. As you prepare for the upcoming challenges and think about how to maximize your impact as an intern, let me share some insights about one of the fundamental and key milestone of an internship, the Intern Midpoint Review.

Going back to my internship, while I was busy with implementing the initial tasks of my project, Matt provided me with great ongoing feedback during our regularly scheduled 1-1s. During one of these early 1-1 conversations, Matt gave me an overview of how my internship progress will be evaluated. There were a couple of significant milestones that were crucial in this process, the “intern final review” and a little less understood “intern midpoint review”.

Very early on during my internship, I remember having this very clear expectation about how my progress was going to be evaluated. I was super focused and determined to get an inclined message in the Midpoint Review. I created a plan with targets on what I wanted to achieve and deliver each week. Once I understood what to deliver, and what success would look like, I was able to motivate myself.

Tip #1: Identify how you will receive early feedback on your performance during an internship. Your time is limited, so prioritize taking actions based on the feedback you receive, to maximize your chances of getting a return offer.

Read more