Good technical folks, who don't necessarily have people skills, are often promoted to management. This leads to poor managing and often hampers the success of their employees.
The common understanding at Microsoft is that employees have to create their own "visibility" in order to stand out and get promoted. Just doing really good work is not enough. To be recognized, you have to give presentations, fix urgent customer bugs (and be sure someone in management sends mass e-mails acknowledging you), and make sure that everyone knows who you are and how great you are. Unfortunately, this often fosters an environment of individual competitiveness, in which you must focus solely on your own success, without regard for that of your team or coworkers.
The advertised "Mentorship" program (when a more experienced employee mentors a relatively new one) is played up as a strong positive, but most of the so-called "mentors" are too busy (or lack the needed people skills) to have any effect.
With such a large organization, the exact whats and hows often come down from upper management, leaving the individual contributor to simply execute commands given to them. They often have almost no say in what should be done or how best to do it. (This, like many of the other cons, depends on the specific product group, but it is very common and prevalent enough to be of concern to anyone looking to work for Microsoft).
Certain managers make 100% of the decisions around the whats, whens, and hows of employee work without being open to any feedback from the employee.
Teamwork takes a backseat to individual success.
First, it is important to favor people with mentorship ability, people skills, and leadership skills over technical ability when promoting individual contributors to management.
Second, recognize which employees thrive on individual competition and which on teamwork. Make sure that there is a success path for the latter group.
Lots of brain puzzles and escalating interviews with different people on the team. Read the books on brain puzzles asked at MS interviews. They're not wrong. Most people interview with multiple teams. However, if all your interviews are with one te
The interview process was good. The interview was mainly based on coding. There were no specific testing questions. The interview covered: * A question on arrays. * A question on Linked Lists, specifically how to insert a node. * A question o
Initially, I was contacted by a recruiter. I had a quick phone screening and then was called for an onsite interview. The onsite interview was horrible because one of the interviewers was jumping randomly between questions. I believe the interviewer
Lots of brain puzzles and escalating interviews with different people on the team. Read the books on brain puzzles asked at MS interviews. They're not wrong. Most people interview with multiple teams. However, if all your interviews are with one te
The interview process was good. The interview was mainly based on coding. There were no specific testing questions. The interview covered: * A question on arrays. * A question on Linked Lists, specifically how to insert a node. * A question o
Initially, I was contacted by a recruiter. I had a quick phone screening and then was called for an onsite interview. The onsite interview was horrible because one of the interviewers was jumping randomly between questions. I believe the interviewer