Pour commencer, Microsoft est une énorme entreprise, suffisamment grande pour que les grandes équipes au sein de Microsoft aient quelque chose qui s'approche de leur propre culture. Il'est difficile de faire des déclarations sur le travail d'ingénierie logicielle chez Microsoft qui soient vraies partout. Je'travaille sur Microsoft Office depuis environ 7 ans, donc mes réponses seront basées sur cette expérience.
Beaucoup de gens imaginent Microsoft comme une bureaucratie sans nom où des drones de développeurs travaillent dans des cubicules jusqu'à toute heure de la nuit.
Rien n'est plus éloigné de la vérité. Microsoft était autrefois une entreprise pleine de jeunes gens qui travaillaient effectivement jusqu'à toute heure. Cependant, ils'ont fait un assez bon travail en accrochant leurs employés (jusqu'à récemment) et beaucoup de ces mêmes personnes sont encore dans l'entreprise - sauf que maintenant ils'sont d'âge moyen, mariés et ont des enfants d'âge scolaire. Résultat : l'entreprise se sent beaucoup moins comme une startup et beaucoup plus comme une entreprise typique.
Je n'ai jamais travaillé nulle part où l'on accordait si peu d'attention à mes horaires de travail. On peut avoir un succès diabolique chez Microsoft sans faire 35 heures par semaine ; on peut aussi avoir de mauvais résultats même en faisant 70 heures. Le moment où vous travaillez (et, dans une moindre mesure, le lieu où vous travaillez) n'a aucune importance. Microsoft est une méritocratie, et les résultats - en particulier la visibilité de ces résultats - sont primordiaux. Si vous travaillez efficacement et que vous n'avez pas envie de gravir les échelons de l'entreprise, vous pouvez travailler des semaines très raisonnables (~40 h) sans sacrifier votre carrière.
Le code est gardé assez étroitement en raison du fait que nous'avons eu beaucoup de fuites, et l'entreprise est si grande que vous'êtes obligé d'avoir quelques pommes pourries si suffisamment de personnes ont accès à la source. Par défaut, vous'êtes susceptible d'avoir un accès complet au code de ce sur quoi vous'travaillez et de tout projet associé, et il'y a un processus d'approbation assez facile si vous avez besoin de voir le code d'autres équipes.
Il'est immensément satisfaisant de travailler sur un code qui'est utilisé par des millions de personnes. En tant que développeur, la balle s'arrête vraiment avec vous - les gens vous diront à quoi l'interface utilisateur devrait ressembler, les gens marteleront la merde de votre code et de votre fonctionnalité et vous diront de faire des changements, mais vous'êtes finalement celui dans la pièce avec le plus de pouvoir - parce que vous'construisez réellement les bits qui se retrouveront dans les mains des clients&apos ;. Nombreux sont les développeurs (passifs-agressifs) qui ont utilisé le "veto de poche" pour empêcher un changement, ou qui ont codé une fonctionnalité le week-end même après s'être fait dire qu'ils n'avaient pas le temps de le faire. Ce genre de techniques de codage de cowboy est officiellement désapprouvé, mais vous donne une idée du pouvoir qu'un seul développeur peut avoir sur ce qui finit par devenir du code d'expédition.
Microsoft a été fondé par un développeur, et c'est toujours une entreprise très centrée sur le développeur. Vous entendrez des plaintes sur les réunions interminables et la politique. Celles-ci ne viennent probablement pas des développeurs. Les personnes qui ont créé l'entreprise ont compris que les développeurs veulent simplement écrire du code. Les développeurs sont généralement libérés des distractions (des bureaux privés sont mis en place très tôt dans votre carrière), de la collecte des exigences et de la conception (généralement gérée par la direction du programme avec une certaine collaboration de votre part), des tests laborieux et du travail d'automatisation (il y a une équipe de test), et dans certains cas même du travail de maintenance. Vous devez passer une grande partie de votre journée dans le code. Il y a de bonnes discussions pour savoir si cela a créé ou non une sur-spécialisation, et il't toujours une quantité abyssale de frais généraux impliqués dans l'écriture du code qui'est utilisé dans tant de contextes pour tant de buts, mais dans l'ensemble, c'est un endroit très heureux pour quelqu'un qui veut juste coder.
(C'est un peu dur pour les non-développeurs, honnêtement. Les testeurs là-bas, en particulier, affichent souvent un intérêt pour passer à un rôle de dev et écrire du code d'expédition en raison du sentiment d'être des citoyens de seconde classe.)
Bien que les développeurs aient leur mot à dire sur ce qui se passe au niveau des fonctionnalités, l'entreprise est suffisamment grande pour qu'il'soit très difficile d'avoir un impact en dehors de sa propre équipe. Changer d'équipe est possible mais entraîne beaucoup de frictions (vous devez généralement compléter la même boucle d'entretien d'une journée entière qu'une nouvelle embauche) et il'est très peu d'infrastructures mises en place pour que les devs contribuent aux produits d'autres parties de l'entreprise.
La plus grande surprise pour moi ici est et a été la culture jeune malgré la réputation de l'entreprise'comme un mastodonte ennuyeux. Il y a encore des guerres de nerfs dans les couloirs. Les gens sont encore très, très excités par les logiciels. Nous avons notre propre laboratoire d'incubation pour les logiciels et le matériel (The Garage, cherchez) et c'est assez génial. Nous nous moquons de nous-mêmes probablement plus que la presse ne le fait (l'une des valeurs de notre entreprise est censée être "l'autocritique" et c'est probablement celle à laquelle nous adhérons le plus). Les gens aiment toujours cet endroit. Il n'y a vraiment aucun endroit comme ça.