> When you’re a new employee at Apple you’re pretty much thrown into the deep end. There’s no orientation for projects on how to contribute to them or requireme

> When you’re a new employee at Apple you’re pretty much thrown into the deep end. There’s no orientation for projects on how to contribute to them or requirements to work within a certain set of guidelines. For the most part I was expected to learn things along the way. On top of that, generally there wasn’t any strict rules on things like code review or pull request requirements. I was given some tasks to complete, but from there it was up to me to learn how to integrate my changes into a massive project I had never seen before. I had to find the right people to talk to and learn a lot by trial and error. I had to do all of this while other teams were expecting my work to be done at a certain time, and even though a valid excuse of mine was “I have no idea what I’m doing,” you can imagine that wasn’t always acceptable to someone dependent on me completing my tasks. > Furthermore, when issues really started to occur where someone was unable to do any work until you completed a task, it was often threatened that things would need to be escalated to upper management. It was never put this way directly, but to me when people would say this it could be interpreted as “we are going to tell your director about your poor performance.” Because of that, individual contributors (i.e. non-management) would often do everything possible just to get the job done and avoid that escalation. This meant late nights, weekends, skipping lunch, or whatever it takes. Pulling in upper management was bad and should be avoided at all cost. While that wasn’t a written rule, I certainly observed it a lot during my time there. Seems about right.