Uber Freezes Hiring of U.S. Tech Staff as It Seeks to Cut Costs
bloomberg.com
bloomberg.com
1. laid off 400 "marketing" staff(global)
2. hiring freeze in U.S.(& Canada) for engineering(software) & PMs, due to reaching hiring quota for this year
3. $5.24B net loss(biggest ever)
4. hiring continues for logistics, autonomous-car etc..
Interesting facts indeed.
Why does Uber(& the likes) need to continue hiring engineers/PMs really? Unless they are opening new products every year, can't their existing engineering handle all of the existing products? Given how well they pay(heard info), am curious whether engineers still leave after a while, needing constant replacement every year?
Am not demeaning anything, am really curious. I assumed places like Uber/ABNB/Lyft don't lose staff easily.
Even to the UK, where tech salaries top out around $100k.
Citation needed.
I work in a FAANG in London. I am a middle-performer in a non-senior position and not even a "real" software engineer (I code, but its not my main job responsibility) and I am £84K/$101K basic, £149K/$180k total-comp. If I were a proper engineer, I'd expect to get at least 15-20% more than that, and if I were promoted to a "senior" position I'd expect a similar 10-15% pay rise too.
There is money to be had in London.
* 150k cash base
* 80k cash bonus (between sign-on & EOY performance)
* 225k vests in the first year? 900k over 4 years?
* What's an RSU guarantee? Does it convert to cash if some price is not met by the time it vests? I couldn't find anything on Google about this, but I am probably looking in the wrong place
Plus there's a very large financial tech consulting market where you can make loads more as a contractor.
Consulting is definitely lucrative.
That only works if you're building a new team and product from scratch. Even then if management if in the US the communication issues will cause problems. Trying to outsource an existing live product is very expensive (ie: better get those massive retention bonuses ready so your whole US team doesn't bail the second it's announced) and error prone (ie: rebuilding all that knowledge about the product and market takes time).
Anyone working in tech there needs to polish up their resume and hope that the many scandals at Uber hasn’t tainted them too.
Yet the same can be said about most large companies though. Even large "real" tech companies. Googles revenues wouldn't drop a bit for years if 50% of engineers were gone. That's just the reality of large enterprises.
Yes, even with the best will in the world you can't escape Amdahl's Law. And when an engineer finds him or herself working on some fun project that isn't clear how it relates to the bottom line the mindset should always be "enjoy it while it lasts".
A great way to disillusion your management hierarchy (flat or otherwise) is to have them constantly juggle supporting their reports’ needs and the business asks when functionally understaffed all year. Having some “extra” headcount while remaining ROI positive is good for the humans even if it doesn’t make 100% accounting sense.
It’s also a good way to make space for deep work and interesting innovations you get by having the luxury of unlimited ping pong time... Er I mean water cooler chats.
It depends how many that is. Operating a system like that at scale with zero downtime takes a surprising number of people. Projects at that scale tend to be harder and more complex, so they take more people. Things like pickup optimization are complex multivariate problems that can have a real business impact. So maybe, maybe not, but the tech operation at Uber is non-trivial.
It isn’t easy, but there are dozens of companies that have been doing it successfully for 40-50 years. Credit cards, airlines, telcos and more. Those challenges are a matter of meticulous application of well established best practices, and none of those are “tech companies”. I mean, Interflora probably has as good or better uptime than Uber!
It’s not just real time but streaming data. Handling millions of concurrent trips, and processing all those trips in real time is not something that any of the industries you’ve mentioned do.
Of course not, but I do believe - because it’s demonstrably true - that those challenges are not unique to Uber, and that they have been solved many, many times over.
For example sure, Uber handles a lot of trips. But every one of those trips is backed by a credit card processor, without the latter even breaking a sweat. I guarantee that Mastercard or whoever barely even notices the additional workload they get from Uber.
1. Authenticate the transaction (is this ‘uber’ Company ok and is it reasonable this user is using it for fraud detection)
2. Check that the users balance + the cost of the trip < the users credit limit
3. Post the change to a transaction log
4. Some hours/days later, finalize the pending transactions.
That’s a whole lot simpler (outside of fraud detection) than what Uber has to do to get you from A to B.
*edited for formatting
We already had figured out how to move people around in cars in a way that doesn't require software at all, it's called a market and taxis have operated in it for a really long time. Uber is going to figure out shortly why there wasn't a giant taxi monopoly on the planet before they existed.
Here's an example: the stock exchanges also need to handle huge amounts of concurrent and real-time data (with much greater constraints on latency and correctness and linearizability than Uber's customers demand). They're not running on literally unchanged 50-year-old tech any more, but they're also not doing the sort of technology innovation that Uber's doing, and they're doing just fine.
Actually, the opposite is true. To apply best practices you need people with attention to detail who can follow a runbook precisely. You need relatively few to keep the runbooks up to date. Traditionally the former were referred to as “operators”.
This is one possible interpretation.
The other possible interpretation (which I favor) is that good engineers like working on hard problems, and will gravitate towards places where they can work on hard problems—whether or not the business actually fundamentally requires hard problems. There could be simpler architectures. (Remember that pre-Uber, nobody really said that the problem with the taxi industry was that you had to call a dispatcher on the phone and that system couldn't scale. Dispatchers were bad at things, sure, but we didn't think that phones were fundamentally too low-bandwidth to handle the request rate.)
Some recent posts on Uber's tech blog:
- A zero-downtime migration from a payments architecture with eight microservices that needed a code update every time they launched something like Uber Eats, which was "an unsustainable use of development time," to one that was generic across new businesses Uber might launch in the future.
- A tool to automatically generate an iOS app with the same build structure as their current app or a slightly modified one, to see if certain approaches would speed up their build times.
- A new web interface, with feature parity to their mobile interface, based on the JavaScript framework previously developed by Uber Engineering and also using fancy new web platform features like service workers.
- A new framework for automatically submitting data analysis jobs to their scalable computing environment with the ability to update configs to match changes to which databases exist, which computing clusters exist, how to access them, etc.
- A conversational AI platform.
- An AI ant that walks around in better ways.
None of these, I think, fall into the category of Uber really needing tech. They're all cool, they all have long-term business value, but you could just declare that you're tech-skeptical and don't want to make platforms for platforms for platforms and still deliver Uber's core business - matching users with cars and moving money around - just fine.
5 9s of uptime is five minutes and fifteen seconds of downtime per year. That's difficult to hit reliably no matter what, because pretty much anything that causes any amount of downtime can easily cause more than five minutes of it.
Uber is present around the world, but I don't see much reason Uber India needs to interact with Uber North America in real time. Operationally, they're completely independent -- no one is going to connect a ride in Canada to a ride in India -- so why do they need to be strongly coupled in terms of the software service? What would go wrong if Uber India only handled one timezone and didn't really support French?
Their costs, downtime, and tech debt spiralled out of control, mostly due to this architecture decision, and then spent a year or more rebuilding to try to get it under control.
Uber probably have the better approach, at least I don’t hear bad things about Uber’s tech where I have heard multiple horror stories about Hailo’s.
There were some good things to come out of it, from what I understand. I believe Hailo were avid Cassandra users and many of the team went to Monzo who have deployed Cassandra very effectively.
People travel.
That aside, you'd have 100+ different deployments that need to be independently updated, debugged, managed, etc. That takes people and effort and is still going to cause issues. For example, each country speaking French might have a different deployment so updating language files needs to take into account every single version running live.
So? People traveling to India are still going to be in India's timezone, and French covers virtually no one that English doesn't also cover.
(Lyft requires a US phone number, which I don't have, and local competitors I would have to research, install, sign-up for all individually.)
What this forces you to do is to get really good at configuration management and orchestrating deploys, so that when something goes wrong, you can fix it for all your customers at once. You can't treat any single instance as a thing that it's meaningful to log into (you might still want to log into things to debug problems after a customer report, but making changes is infeasible, and ideally you notice problems before the customer report so you have to be aggregating logs/events/metrics). So many of the same maturity lessons as required for building a single scalable instance continue to apply to you. The distinction is that you don't have a giant distributed system, and you don't have the corresponding operational burden of a giant distributed system, so you avoid outages like https://monzo.com/blog/2019/09/08/why-monzo-wasnt-working-on... . (To be clear - this isn't meant to shame Monzo, that was a genuinely difficult problem and a genuinely good incident response. But there are advantages in not having a single company-wide database that runs everything from your core business function to your customer support chat.)
One of the engineering lessons I've been learning of late is you really want to avoid distributed systems wherever possible. They're cool, but the amount of engineering / operational effort required to get to a certain level of consistency or availability is way more than the effort required to get to that level of availability of a non-distributed system. It's fun as an engineer to solve hard problems, but it's better for the business to not have hard problems in the first place.
Uber’s operations are orders of magnitude less complex than the supply chain and logistics of any major manufacturer. Or government or military. Or the post office or the phone company. Even McDonalds keeping its restaurants supplied and ice-cream machines working. All the cool tech Uber developed they did for fun. Because they had nothing better to do.
Hope this helps you understand.
That's actually "for thousands of users in one city" executed a few hundred times, and map/PoI/pathfinding parts can be (are?[0]) outsourced to a third party.
--
[0] - I don't use Uber as a matter of principle, but the competitor I use utilizes Google Maps for these parts. So do food delivery companies I use.
They were called mytaxi until a couple of months ago, and absorbed Hailo and many other ride hailing services over the past few years.
This compares to Uber at 90 million passengers and 3.9m drivers: https://expandedramblings.com/index.php/uber-statistics/
Now unfortunately it's hard to assess Free Now's methodology as they're not a public company (they're owned by BMW and Daimler) so we only have their marketing claims to go on.
Also the majorly divergent passenger:driver ratio is likely down to mytaxi operating primarily in markets where taxi drivers are licensed and Uber's disruption not tolerated. This means they're pulling from a smaller pool that is more likely comprised of full time drivers.
No it doesn’t. For a start there is no overlap between cities, so that’s easy to shard. And secondly that’s not what SLA means - how many 9’s do you think would be in a sub-second SLA? Thirdly Uber offloads it’s payment to third parties, unless I blinked and it’s issuing its own credit cards now.
You seem to be incredibly impressed by Uber’s tech but have you considered that everyone else’s tech works so well that you just take it for granted? No Uber ride comes close to the complexity of sending a package internationally, and orders of magnitude more packages are sent every day than Uber does rides.
https://www.cnbc.com/2019/03/01/lyft-plans-to-spend-300-mill...
We may yet see this if the share price tanks. A PE firm like TPG can buy a large stake (or even go private), ruthlessly force efficiency, and then sell out.
I'm not as concerned with how it's been devastating to medallion holders and the state of the gig economy. Bad government policy was responsible for those problems, Uber just took advantage of it.
Uber and Lyft really are better experiences than random cabs most of the time but their culture still managed to turn off a lot of people who worry about such things.
For the passenger yes, but not for the drivers, and they are people too.
Though, that was mostly a few years ago when a lot of the drivers came over.
Lately I’ve heard a lot of complaints about their commission percentage, but fewer drivers who used to drive cabs, so I’m not sure how they feel in comparison.
Hiring freezes don't help morale, it makes for a stagnant mood, you miss out on new talent, and attrition leaves you with (typically) worse talent. It only really makes sense to juice the next quarter's numbers.