P.M. @GetBuzz - Incoming SWE @Microsoft, ex SWE Intern @Microsoft, ex TeachLead at NDWebSolutions
The web is full of resources related to internship interview prep for Microsoft, Google, Facebook, and other big tech companies (just to name a few).
But when I accepted the offer for my summer Software Engineer internship at Microsoft, I was not able to find useful information about the onboarding process, timeframes, and general structure of the internship -- at least in terms of expectations, contributions, and approach to the team in big corporations.
In this article, I will summarize the onboarding process and core events that have characterized my internship, reflecting also on the growth given by this experience.
Once you have accepted the offer for an internship, it is highly recommended to ask the HR contact when the next step would possibly happen, and what to expect in the following steps.
This means that in case of offer acceptance during the winter, for the summer internship of the next year, before and after the Christmas breaks, the priority will be given to all the sprint interns (who will start so before you).
Is important to understand that in big corporations, multiple people even from different departments could work at the same time for your onboarding experience, and this is why is normal to wait weeks or months between each stage.
Below, you will find my personal timeline of key events that occurred between the interview process and day 0.
November 2020: interview.
December 2020: offer discussion.
March 2021: contract presentation.
June 2021: Met my manager.
June 2021: hardware or general asset received (the presence of hardware or any other asset could depend on different factors, for example, role, job location, type of work (remote or office), and benefits.
July 2021: Internship kick-off.
Once you’ve started your internship at Microsoft, you will get introduced to your mentor -- a key figure for your success.
The mentor will give you context about company policies, the team, the roles of each team member, and initiate you to the initial training and what is going be the project you are going to work on.
Most importantly, the mentor will be your first and probably one of your best friends in this new work environment.
Mentors are not usually people in charge of conversion (to Full-Time employee) decisions, but they are there to fully support you during your learning process.
It can be highly convenient in terms of personal and professional growth, to learn more about your mentor's background, asking general questions related to his/her career path, general experience and challenges faced when started in the same company, Microsoft in this case.
Especially if working remotely, the first stand-up meeting is the first occasion to meet your new colleagues and present yourself in the best possible way.
I remember spending the night before the start of the internship repeating some short but interesting presentation speeches.
Even if you will be braver than me, I suggest for you to invite all your colleagues for a 1–1 call, to properly introduce yourself and get to know your colleagues, their experience, and current responsibilities within the team.
Especially the last factor will help you to quickly redirect iterations and questions to the right person once you will start to work on your first task.
Please, do it during the first week.
While approaching new challenges, tasks, bugs, and things to learn, you could lose the conception of the time, easily finding yourself at the end of your first month, without haven’t had a chat with one or more team members. Not a match with your listed skill: “team player”.
Especially in big projects, like Microsoft Teams, is possible that you will need to interact with other teams focused on a different area of the project.
What you should do at the start of your internship is to:
Go through a few of the project-related communications channels/group chat, identifying the reason why that specific channel/group is used: help needed, UI/UX focused, identification and share of a new error, Pull request review needed, etc…
Monitor the Pull Request (PR) of your teammates. This will help you to identify a few of the most skilled people in specific areas of the project. An example: is highly possible that people that have worked from zero on functionality would review a PR that could partially alter the current behaviour of that functionality.
Orientating in this way will help you in the short term to be able to communicate with colleagues working even outside of your team, be more independent from your manager, and being able to start a task investigation or Pull request submission autonomously.
Even with year planning, a new product development policy or bug could come at any moment, and managers know that. But for you to give the best outcome, you should approach them as soon as possible.
Few mistakes that I have personally done lead me to the creation of the following unwritten rule that I am applying to myself:
Work in parallel with both easy-win and harder tasks. Do not go just to one side of the medal. Eliminating the easy one immediately will not allow you to get a break from the harder one.
A bug feature or bug investigation could lead to asking questions or fixes from other teams. This kind of iteration, especially if working with teams located in another time zone could be time-consuming.
That’s why is a key factor to analyze a new task as soon as possible, to at least start a conversation with the interested team or start to elaborate on approaches to fix the problem.
· Make sure to know the shortcut of the newline within the product that you are using to communicate with your colleagues and follow the rules indicated in nohello.com.
“We are not hiring good software developers, but great software engineers.”
This quote has been one of the most impactful things that my manager said.
Initially, I did not understand its meaning, but during my experience at Microsoft, I have been able to give a personal interpretation to it.
Even seniors or managers do not have an answer for anything, but a good Software Engineer is not a developer with a memorized answer or flow. Instead, a Software Engineer is a figure that is able at any cost (with the appropriate needed time and resources), to hack a solution.
Software engineers are not writing code to fix a problem. Are instead writing the solution to that problem in form of code.
This means that you do not have to feel less valuable than any other team member, because really nobody has an answer for anything, but you must be able to take action to fix that problem, asking questions, doing research, and showing the appropriate research and tests done.
Even as an intern or experienced professional, I suggest you keep track of the things you have done, and on Friday evening, usually, the Friday that corresponds to the end of the sprint, read what you have done, think about how you approached these challenges and how you would have addressed them differently to achieve a better result.
You will be amazed by how many mistakes you will do and how good you will become if you apply the solutions to your self-analysis.
You should be Curious, available, ready, and happy to learn, and most importantly, you must be ready to ask questions and ask for help.
Especially remotely, nobody really knows what you are feeling and experiencing.
Even your mentor does not know at which real stage you are in terms of preparation for a concept or technology used. That is why, to get the best outcome, you must openly communicate anything.
It is all for now. Another article will be shared after the end of the internship.
To my inspiring and supportive team, Catalin, Simone, Julie, Jan, Kyrylo, Elena, and the rest of the team: Thank you for your patience and support, you are the biggest source of inspiration, passion, and growth.
- Anna Sewell