Microsoft

There is an opportunity to work on technically challenging, large-scale systems.

You will experience strong engineers and advanced infrastructure. There are interesting projects with real-world impact. Compensation and benefits are competitive. The company name and experience can be valuable for your career.

There was little to no structured onboarding. New hires may be expected to become productive almost immediately.

Team support can be weak, especially when ownership is unclear. There was significant ambiguity around requirements, constraints, and project expectations.

Important design context may not reach the engineers implementing the work until late in the project. Questions and requests for clarification can go unanswered for long periods.

Code reviews can be slow or effectively absent, including from management. Feedback may arrive after implementation rather than while there is still time to correct course.

Layoff and performance pressure can create an overly individualistic culture where people prioritize protecting themselves over helping teammates. Success can depend heavily on navigating undocumented organizational knowledge rather than simply doing good engineering work. Management may expect engineers to resolve ambiguity without providing enough guidance or escalation support.

A dream job that became an isolating experience

I started here feeling like I had reached a lifelong dream. Even before I learned programming, working here was something I aspired to, so I came in with very high expectations for myself, the team, and the company. At first, it felt like those expectations might be justified.

Unfortunately, the experience changed quickly.

There was effectively no onboarding. I felt like I was thrown into the deep end and expected to either swim immediately or sink. When I struggled, I received very little support from teammates or management.

The broader environment also felt unusually individualistic. My impression was that constant concern about layoffs and performance created a culture where people focused heavily on protecting their own position rather than helping others succeed. The old analogy comes to mind: you do not need to outrun the bear; you only need to outrun the person next to you. That was often how the environment felt.

Ambiguity was another major problem. Projects frequently had important constraints or expectations that were not clearly documented or communicated. Sometimes engineers implementing a project were not involved in its design, yet the missing context would only surface after much of the implementation was already complete. Clarifications often arrived far too late to be useful.

Getting answers could also be extremely difficult. Questions could go unanswered by teammates and even by management. Code reviews could sit without meaningful feedback. When expectations are unclear, communication is limited, and feedback only appears after the work is finished, it becomes very difficult to know whether you are succeeding until you are told that you are not.

That combination made the experience feel less like an environment designed to help employees grow and more like one where you are expected to independently navigate an unclear system and are then held responsible when you fail to anticipate information that was never communicated.

I joined with enormous respect for the company and genuinely wanted to build a long-term career here. Instead, I eventually reached the point where it felt like I had been hired without being given the conditions necessary to succeed.

Advice to management: Invest seriously in onboarding, documentation, timely code reviews, clear ownership, and earlier communication of project constraints. Managers should actively remove ambiguity and help engineers succeed rather than allowing problems to remain invisible until performance discussions.