Uber

My experience as a software engineer at Uber has been mostly positive. Uber provides high compensation and good benefits, the people are smart and supportive, and there is always work to be done. It is engaging.

Like with many big companies, there is more work to be done than can get done. This is generally a good thing. It helps to stay engaged and to continually grow.

The problem is when things try to move too fast and timelines, quality standards, and boundaries aren't managed correctly. Communicate well, and it's overall a good situation.

Sometimes projects and initiatives try to move too fast, and it comes at the cost of code quality and incidents. This isn't uncommon, so just try to manage it; that's part of the job anyway.

I personally don't have an issue with the 50% RTO policy and code diff expectations. Some people do.

Just gauge what type of situation you want and make a decision based on the facts.

There are pros and cons to the H1/H2 planning cycles.

On one hand, shorter planning cycles provide agility for a product and marketplace that is in many ways still figuring out what's optimal. On the other hand, continual planning cycles can take away from execution by providing arbitrary deadlines and adding overhead.

My advice is to try and maintain agility while allowing projects to fully wrap up and longer-term roadmaps to become more prominent.