My First 2 Years at Microsoft ✨
In this article I want to share a breakdown of how my first 2 years looked like at Microsoft, and few tips on how to ace the start of your journey as a professional Software Engineer.
In August 2021, I wrote an article on the strategy I followed to get a job offer straight out of college, into Microsoft, and seeing that it has helped at least a few folks to hone their preparation strategy to ace interview and internships, makes me energized to write this one!
I’ll break this article into 3 parts:
- The First Month (getting to know your team, ramping up on the organization’s tech stack, learning about the organization and its business)
- The First PR Completion and the Next 1 Year
- The First Promotion
The First Month
In the first month, what’s primarily expected is for the new joiner to ramp up on the tech stack which is primarily used within the team and the organization your team is a part of. For me it was C#, .NET Core, Typescript, React.js and Azure. Based on previous experience, you might have already worked on the tech stack, while its great if you already know it, don’t stress out at all if you haven’t had any experience in the tech stack, cos that’s what this time is for🙌.
The tech stack, tools used, designs, all will definitely keep changing but what stays the same is the fundamentals, and as long you’ve had your hands dirtied with some projects and have the basics of Software Engineering ironed out, you’re good to go! Some of the things I mean by the fundamentals here are Data Structures and Algorithms, Time and Space complexity, how computers work, Networking, OS, Logical thinking, Version Control Systems (example: GIT), basics of Cloud Computing etc.
I took almost 2 weeks for ramp-up and started working on few minor deliverables in the same tech stack while continuing the ramp up process. It's perfectly fine to take longer but very important to get the basics right if the tech stack is new to you.
It's important to think of the Tech stack and Developer tools used like tools in your toolbox. You might upgrade to fancier tools but what lasts is your understanding of the field (aka fundamentals), expertise in how and when to use the tools (aka experience) and ability to understand the solution to be built and how to build it using the tools (aka the software engineering process)
The next item to cover in the first month is to understand the line of business your organization/company is in. For me, it was CRM software, and I was majorly going through pre-recorded meetings explaining the business, reading up on docs explaining the software and understanding who our customers are, and how they use the product. Now, understanding this is also a very important part of being a good Software Engineer. If you’ve mastered the art of developing great and innovative solutions but the end customer doesn’t use it or understand it(aka low adoption metric), then in overall it's likely that it's a loss for the organization in terms of revenue.
💡Easy checkpoints to consider when designing/engineering the solution factoring in the customer’s point of view: You are the customer, how will you be empowered by the feature/product? Are you going to love it? How easy will it be for you to use? Are you going to come back to use it cos you love it or because it makes your life simpler?
Use this time to also form connections within your team and the organization and other peers throughout the company who’ve joined with you. Having good professional connections will definitely help!
The First PR Completion and the Next 1 Year
This is the part where you hit the ground running and try to do your best in the tasks and deliverables you get to work on. While it's no doubt that the level of depth and knowledge you have in your domain will help you stand out amongst your peers, your soft skills also play a significant role which help distinguish you as a leader, which will add more value to you, and what you bring to the table.
I’ll highlight few soft skill characteristics of a great Software Engineer that I found to be the most valuable:
1. Showing ownership
When you’re starting out, it’s crucial to actively demonstrate ownership of the tasks and deliverables assigned to you. This shows that you are responsible, and it helps to build a trusting environment with your teammates and stakeholders, who will begin to count on you to achieve goals. What I mean by ownership here is taking full responsibility for the outcomes of the feature you developed, being proactive in problem-solving, and driving initiatives forward with dedication and commitment. For example, going the extra mile to ensure that your feature/project is rolled out to the end customer promptly, and iterating on it if it’s possible to enhance the overall user experience.
2. Being Customer Obsessed
It's very important to be focused on the customer experience, factoring this in from the very start helps shape technical and non-technical decisions that lead to adding the most value possible.
“You’ve got to start with the customer experience and work back toward the technology, not the other way around.” — Steve Jobs
An example of this approach is to not be satisfied once your feature or project is available for the customer to use, instead, analyze the usage metrics and ensure that any pain points that your customer experiences are discussed and appropriate changes to fix it are made. Ensuring a feedback loop is in place also demonstrate this ideology, and, by staying invested through continuous improvement enhances the overall user experience.
It’s not enough to make a product that works; instead, build something that delights your end customers and stay invested in it to ensure the adoption metric (example: user engagement, retention etc.) keeps increasing. This level of customer obsession drives continuous improvement and ensures that your product truly resonates with its users.
3. Prioritizing the right way
Its highly likely that after a few weeks or months, there will be so many tasks and deliverables assigned to you which call out for your attention every day. Some of these will be minor tasks requiring just 5 mins of your time, but some will be deliverables which require days of planned effort. And also likely is that while you go through your day of completing the already planned tasks, it's possible that a sudden high priority task comes your way. All of this can leave you overwhelmed and that's perfectly normal, but there’s an easier way to balance them, this it to order them by their priority. Yes! This seems so simple, but we often fail to do this regularly, and when new tasks come in during the day, we might not stop to re-access and re-sort them by the order of priorities.
These are some things I do to ensure I focus my attention on the most pressing tasks for the day:
- Start your day by identifying your top 3 tasks which you want to make progress on. These 3 should be sufficiently important that if you manage to make good progress or complete them that day and don’t get to do any of the other tasks, you shouldn’t feel bad about your efficiency. Focus on these 3 primarily and try to squeeze in any minor things which can be quickly closed off, when you’re blocked on some things to get completed before moving ahead (e.g.: you could be waiting for a build to get completed or PR to get completed or your teammates to review the document you’ve made on your new feature)
- Estimate the effort required to complete any task (this could be ranging from few hours to few days) and communicate this effectively with the stakeholders to ensure that both parties are on the same page.
- Avoid working on ad-hoc tasks which are lower priority before the top 3 unless it's for helping out a teammate.
4. Picking out areas of work that make the highest impact
Pick out areas of work that have high impact. Impact is mostly weakly correlated with the difficulty level of the work.
It's important to focus on impact delivered (better engineering solution/product capability to the customer/ running costs reduction etc.), not on what you’ve implemented. This requires, taking a step back and doing an analysis on the impact you can create and the effort it requires.
5. Bonus: Not a soft skill but a great to practice which helps a lot!
When starting out with a feature change or new project, the first part here is to get clarity on the problem statement you’ll be working on. Sometimes it might be ambiguous so you might need to keep redefining the problem statement as you progress.
Starting with a one or two pager documentation on the problem statement, objective, possible solutions, implementation details, estimated timeline, impact to other services etc., is very important as it helps to easily communicate the feature change/addition that you’re working on. Once you have this handy, get it reviewed by your teammates to get a second opinion on what they think of the design, implementation etc.
It's important to not rush into the implementation/solution before you’ve ensured that you’ve explored different solutions, their pros and cons, and only then made a conscious decision to select one. Make sure to communicate this to your teammates or manager if this decision can have larger scope and you think this needs to be approved upon first. I personally did not follow the practice of documenting my feature changes for a long time and I can definitely tell you firsthand that not following this leads to miscommunication which ultimately leads to regression or duplicate efforts.
The First Promotion
Ok, this is the last section and I want to end with this. I feel that I’ve taken significantly longer than few of my peers to get this level up, and on retrospection, while it's easy to assume that it is because of the global economy downturn and lower funds in the organization, which led to a delayed promotion for me, I feel like there are few things I picked up late, which could have effectively helped me achieve this sooner.
- Not asking for regular feedback — Getting feedback on the things you’re doing well is important and required, but also being open and positive to receive hard feedback about the misses you’ve made lets you know what not to do and how to optimize your own process of development.
- Shying away from talking about the impact you’ve made — Try to be visible in the company and don’t shy away from visibility.
- Not doing a better job at prioritizing tasks based on the impact it will create- It's possible to get swayed by a feature/project which interests you more but if there’s another feature which would be creating more impact, then that's where you should focus more.
- Not writing documents on the proposed feature changes — Lack of a written agreement, to easily go through and review to ensure that all stakeholder requirements are covered, leaves some part of the agreed upon details hazy and its likely few are missed entirely.
- Ensuring maintainability of the codebase -While it's very important to be agile and get to a working state of the product for time sensitive deliverables, putting in that extra effort to make sure you write clean, extensible and modular code ensures that you can save a lot of time down the line during refactoring/feature additions.
I hope this proves useful to you and makes a difference😄
Feel free to reach out to me on LinkedIn.
