An incredibly talented staff with way too much to do
Pros
As an engineer at Uber, you're presented with a unique opportunity to have a very high impact-to-unit-work, and to release products that go live instantly worldwide. The IC-level talent is phenomenal; you're working with bright engineers, designers, and data scientists who all have incredible drive and talent. It's a great place to grow and learn. This has been Uber's biggest value prop to technical members of staff to date, and it still holds true. You have the opportunity to work on world-class platforms and build product experiences from scratch, which is cool no matter how you slice it. Despite Uber's public woes, there's clearly an earnest effort by executive leadership to solve the company's cultural problems. Liane Hornsey has led a mighty effort to systematically address the many, many accumulated issues that Uber has accrued. Dara seems right-headed as well, and seems keen on addressing his (very accurate, I believe) read on the company's problems. The catered food is free and pretty great. There are some down days in quality, but anyone who says the food sucks is probably just accustomed to the likes of Google or Facebook's excellent free fare.
Cons
Managers who are supportive, proactive, and empathetic are unfortunately the exception, not the rule. I imagine some of this stems from scope problems (most managers simply have too many direct reports; my first had something near 20), but if you talk with engineers, there are a scant few who don't have a story about how their manager really let them down during a promotion cycle, review cycle, or project in a manner that was obscurantist at best or callous at worst. Teams often try to parallelize the product development cycle. This has repeatedly been the source of a lot of stress and thrashing on important projects. Engineers will be asked to work in parallel with product and design contributors, meaning that as the product design changes, engineers will need to follow along. It's often unclear when and how a design will change, or even whether it will change again; there's just not a good communication pipeline or standardized workflow on a number of teams. If you're an engineer, there's an immense onus placed on you to drive the success of your projects. Engineers are the last filter between a product's idea and its implementation, and so the responsibility falls on them to account for not only product edge cases, but gaps in design documentation (which is never formalized, and usually just a set of slides that requires a follow-up meeting or three to clarify), and team workflow. In short, the culture is that if anything gets in your way, if there's any blocker you hit, if anything at all is unclear, that is YOUR sole responsibility to surmount. This creates a lot of stress, because it is at odds with being thorough in an environment where productivity and throughput are first-class engineering values.
