Skip to main content

Interns at Microsoft

One of my favorite times at work is when the interns in my organization present the projects they have been working on for the past 10 or so weeks. It is amazing to see what they have accomplished during that period, and its impact on the business.

 

In my groups, I always make sure that everything the interns work on makes it to production and has visible business impact. The interns enjoy that quantifiable sense of accomplishment and seeing that their work lives in a launched product and improves some aspect of it.

 

After the interns demo their projects, I schedule follow-up 1:1 meetings with each of them. During the meeting, we go over their experiences during the internship, what they have learned in the process, and how can we make the experience better the next time around.

 

Their suggestions are always on point, constructive, and actionable. The conversations invariably drift to learning more about Microsoft, and what advice would I give them to have a successful engineering career after graduating and joining the workforce.

 

I always give them the same advice I give to seasoned software engineers be curious, collaborative, and develop your communication skills.

 

In our field, curiosity is very important. The field changes very fast, and curious engineers adapt and learn new skills that help them in their career. Technologies that are hot today are obsolete tomorrow, and curiosity and learning guards against that.

 

I have hired many an engineer that had no formal education in machine learning, distributed systems, or language runtimes, but were curious about the area, and their curiosity drove them to do the legwork, and learn from textbooks, online courses, open source codebases.

Curious engineers are also not shy at asking questions and using these to elevate their knowledge about the subject matter, or help others articulate a design or idea better, which is a big win for the whole team.

 

In our field, collaboration is also very important. Software development is a team sport, and today’s large codebases are seldom developed in isolation by a single developer. They usually involve multiple engineering teams, and multiple disciplines such as design, product management, testing, and operations. Learning how to navigate that maze and collaborate within and across disciplines is a valuable skill to have and pays off later in one’s career.

 

Finally, we come to communication skills. Most engineers dedicate an inordinate amount of time to learning new technologies, and forget to develop, and exercise their communication, presentation, and influencing skills. These skills are important even at the beginning of one’s career, and become deal breakers as the career progresses, both for individual contributors and managers.

 

After our conversation, the interns spend the rest of the week off-boarding, and go back to school. I am always pleasantly surprised when they reach out to connect later, and doubly happy when they decide to join my teams after graduation.

Comments

Popular posts from this blog

Kindle Paperwhite

I have always been allergic to buying specialized electronic devices that do only one thing, such as the Kindle, the iPod, and fitness trackers. Why buy these when technology evolves so fast that a multi-purpose device such as the phone or a smart watch can eventually do the same thing, but with the convenience of updates that fix bugs and add functionality? So, I was shocked when this weekend I made an impulse buy and got the newest Kindle Paperwhite—a special purpose device for reading eBooks. I was walking past the Amazon store in the mall and saw that the newest Kindle Paperwhites were marked down by $40 for the holidays. The device looked good in the display, so I went in to look at it closely. The Paperwhite is small and light, with a 6” screen that is backlit and waterproof.   The text was crisp and readable, and in the ambient light, it felt like I am reading a printed book. I was sold and bought it on the spot. At home I have struggled to put it down. The bo...

A paper a day keeps the doctor away: NoDB

In most database systems, the user defines the shape of the data that is stored and queried using concepts such as entities and relations. The database system takes care of translating that shape into physical storage, and managing its lifecycle. Most of the systems store data in the form of tuples, either in row format, or broken down into columns and stored in columnar format. The system also stores metadata associated with the data, that helps with speedy retrieval and processing. Defining the shape of the data a priori, and transforming it from the raw or ingestion format to the storage format is a cost that database systems incur to make queries faster. What if we can have fast queries without incurring that initial cost? In the paper " NoDB: Efficient Query Execution on Raw Data Files ", the authors examine that question, and advocate a system (NoDB) that answers it. The authors start with the motivation for such a system. With the recent explosion of data...

A paper a day keeps the dr away: Dapper a Large-Scale Distributed Systems Tracing Infrastructure

Modern Internet scale applications are a challenge to monitor and diagnose. The applications are usually comprised of complex distributed systems that are built by multiple teams, sometimes using different languages and technologies. When one component fails or misbehaves, it becomes a nightmare to figure out what went wrong and where. Monitoring and tracing systems aim to make that problem a bit more tractable, and Dapper, a system by Google for large scale distributed systems tracing is one such system. The paper starts by setting the context for Dapper through the use of a real service: "universal search". In universal search, the user types in a query that gets federated to multiple search backends such as web search, image search, local search, video search, news search, as well as advertising systems to display ads. The results are then combined and presented back to the user. Thousands of machines could be involved in returning that result, and any poor p...