Uber Freezes Hiring of U.S. Tech Staff as It Seeks to Cut Costs(bloomberg.com)
bloomberg.com
Uber Freezes Hiring of U.S. Tech Staff as It Seeks to Cut Costs
https://www.bloomberg.com/news/articles/2019-08-09/uber-freezes-hiring-of-u-s-tech-staff-as-it-seeks-to-cut-costs
100 comments
Huh. I had a phone screen scheduled for next week. The recruiter emailed me to say they had some updates to share. I guess this is it...
Just the beginning of the ending of the round of tech boom we have seen. Overhiring might be a cause of it, but big companies overhiring isn't particular unique to Uber, and when they start to curb hiring, some fundamental correction of perception is probably under way.
So almost $4B of their losses were were from stock costs to employees. All hell might break loose if the drivers ever found out how much Uber employees made/make!
I don't think so. Drivers are looking for short-term opportunities that are mildly rewarding. I think they already faced the reality that making $25,000 a year to drive around and get to meet and network with people is a better fit for them than a factory job or fast food work. I don't think this fits the profile for all of them, but I also don't think they compare their jobs to IT employees and would only be bothered by it if there was an opportunity to unionize behind it to see some benefit.
Seems at their scale, they could operate their app/infrastructure by charing drivers 10% per ride or less and still rake in the money.
tl;dr:
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.
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.
They do have to replace the churn, I haven't heard the Uber has radically different average tenure for engineering.
Recession is in the air and the tech gravy train fueled by the VC culture stops here (Hopefully!).
It turns out that selling things for less than it costs is a bad business model.
For those in charge, it probably worked great. VCs likely dumped their shares on the secondary market right before or after the IPO. (thus completing the "dump" portion of the traditional "pump and dump" scam.)
With the number of board members resigning post IPO there is a high chance that many shares will be sold once the lock up expires. They wouldn't sell before the IPO as would depress the stock price significantly.
The goal is to kill the competition through underpricing and then hike prices, right? Did the killing competition bit fail?
Lyft still exists. Also, it would be trivial for someone to just create their own taxi company if the prices get too high.
You should tell that to Jeff Bezos.
They could save a substantial amount of the salaries by offshoring their technical team.
Even to the UK, where tech salaries top out around $100k.
Even to the UK, where tech salaries top out around $100k.
> 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.
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.
Sources:
Tech recruiters in London
Contacts at a bank
Twitter exchanges with other developers in the capital (including ex-AWS staff)
GDS ex-staff
Sounds like they are getting low-balled. I'd shop around as $100k total comp seems fairly low (although it buys more at the moment considering the GBP is so low right now) for anyone with more than 5-8 years experience.
Total comp for a middle engineer at Uber is $450k.
Does this include stock-based compensation? If so, roughly how much is cash and how much is stock (vesting within the first year)?
$230k can including bonus and $225k in RSU with can guarantee
Interesting! Is that for example:
* 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
* 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
That would be high for London for a middle-tier engineer! Although London is just as expensive as SF in terms of living expenses, we tend to be significantly underpayed by comparison IMO. "Market forces" etc.
Do you have direct experience or knowledge of this? Cause this doesn't square with my anecdotal knowledge or my sense of the bay area labor market. For instance levels.fyi quotes total comp for mid level engineers in the 250 range, which tails much closer to Google, Facebook, etc.
Yes I do. I know someone that got this offer and recently joined. I helped them negotiate and pick offers. This was a staff engineer but the person had only 6 years of experience.
Staff (l7) is no where near middle engineer. L6 is senior, l5 is engineer and l4 is entry level. L6 is also split into two bands 6a and 6b. As a 6a my total comp is around 240 and on par with my coworkers. The l5s were closer to 200. L5 is a middle engineering level.
L6 is staff at Uber. They have this weird 5a/5b thing. Meaning Amzn/goog/fb L7 = Uber L6. Msft would probably 65/66 map to Uber L6.
>They could save a substantial amount of the salaries by offshoring their technical team.
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).
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).
Definitely not true, you can get much more than that in London.
In which verticals / with which tech stacks?
No idea for tech firms..
But just as an example:
https://amp.theguardian.com/technology/2019/apr/03/google-uk...
My LinkedIn feed (full of recruiters) doesn't show me anything under £100k, so I doubt the market tops out where you say.
Plus there's a very large financial tech consulting market where you can make loads more as a contractor.
Plus there's a very large financial tech consulting market where you can make loads more as a contractor.
Pleased to hear it. My LinkedIn recruiters top out £60-£85k.
Consulting is definitely lucrative.
Consulting is definitely lucrative.
If they really wanted to offshore there are far better countries in Europe in which there are very high skilled english-speaking engineers for far lower salaries than those in London.
Do they though? I've read about senior level offers from Uber in London paying about 160k£. Might help explain their current situation.
Let’s be honest, Uber massively over hired in tech, either to create the illusion of being a tech company (to help raise VC), or because some within the company truly believed they were. They are no more a tech company than WeWork or Airbnb is. The company blog gives a clue to this, they seem to do an awful lot that is cool and fun and completely unrelated to regulatory arbitrage (or booking taxis). Uber could ditch anywhere between 50-90% of their techs tomorrow and it would not impact their operations one iota.
Anyone working in tech there needs to polish up their resume and hope that the many scandals at Uber hasn’t tainted them too.
Anyone working in tech there needs to polish up their resume and hope that the many scandals at Uber hasn’t tainted them too.
I completely share your sentiment. For that reason I have yet to wrap my head around the news of Uber's rival spending $80 million a year on AWS. What are these people doing???
https://www.cnbc.com/2019/03/01/lyft-plans-to-spend-300-mill...
https://www.cnbc.com/2019/03/01/lyft-plans-to-spend-300-mill...
> Uber could ditch anywhere between 50-90% of their techs tomorrow and it would not impact their operations one iota.
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.
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 thought the uber vc-backed business plan was to expoilt their drivers until they can be replaced by homegrown autonomous vehicles- if this is true they have a huge engineering problem to solve.
yeah but all their redis experts aren't going to make self driving cars.
I believe on the Fragmented podcast there was someone from Uber who said they had 200 Android engineers, blew my mind.
Not that I want to defend Uber. I do agree with you.
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.
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.
As someone who’s helped on both the technical and hiring side of a company that’s scaling, I agree and will add that a lot of hires are made in order to make life easier for existing hires. A team completely composed of 1:1 developer to team/role need is one vacation, child birth, or illness away from unnecessary added stress. From a purely technical side of things we crib it as “bus factor” and try to negate that with documentation and knowledge sharing.
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.
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.
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".
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".
There is a lot of "make work" kind of project at some of these companies. Lets design a whole new logging infrastructure or database instead of adopting or improving something that already exists. Or lets overanalyze the the font that we use for our webpage or design a new font because we have a lot of VC money and nothing better to do.
Google, especially, has a lot of side projects that don't contribute to search, adwords, g-suite, gcp, or youtube, and their moonshots have failed to materialize. The fact that they're the #3 player in the cloud space speaks to what they'll overlook.
> Uber could ditch anywhere between 50-90% of their techs tomorrow and it would not impact their operations one iota.
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 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.
But I am thankful for their opensource contributions: https://uber.github.io/
Uber actually has a much more difficult engineering problems than both WeWork or Airbnb in the sense that they are operating a real time service that requires near perfect uptime 24/7 and work across multiple timezones in multiple languages, payment methods, and currencies with varying connection speeds. That isn’t easy.
they are operating a real time service that requires near perfect uptime 24/7 and work across multiple timezones in multiple languages, payment methods, and currencies with varying connection speeds. That isn’t easy
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 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!
Poorly, and at great cost. They’re also not developing any new features, and if they do they have a product cycle measured in years if not decades. To say it’s easy to build consistently running real time services in a rapidly changing regulatory and business environment is a bit dismissive I’d say.
Agree. It’s easy to have 5 9s of uptime when you’re not shipping any new features. In fact that’s the response that some companies have when their uptime SLAs are in danger of being violated - fewer features are shipped.
> It’s easy to have 5 9s of uptime when you’re not shipping any new features.
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.
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.
All of those probably have huge tech. Imho engineering wise, Uber really needs tech. If you read uber tech posts, you can see the challenges they face. Even if you want to apply so called best practices you need an above average tech team at the very least. The proof is in the failure rate of our industry.
you want to apply so called best practices you need an above average tech team
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”.
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”.
Best practices are guidelines, not exact and fully-specified recipes that an ant could follow.
If only implementing complex tech solutions was so easy.
Rulebooks only work perfectly when everything is static. Even then they only work when you also know all failure cases perfectly which you almost surely don't. Uber is in a competitive market and can't freeze features for years at a time. Furthermore, it in a growing market which means scale alone will cause new failure points to come up.
> If you read uber tech posts, you can see the challenges they face. Even if you want to apply so called best practices you need an above average tech team at the very least. The proof is in the failure rate of our industry.
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.
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.
Those companies have large tech workforces to service those requirements
Do you really believe that Uber is run on a technology stack that is 40-50 years old?
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.
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.
Do you really believe that Uber is run on a technology stack that is 40-50 years old?
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.
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.
You’re correct, the transactional part is true, but MasterCard is following a relatively basic process:
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
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
The question is not whether it is, it's whether it could be.
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.
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.
x86 is 41 years old, which Uber uses for sure. Newer often doesn’t mean better or better enough. Telephone companies have been streaming voice data for millions of people with a reliability that I haven’t seen from any modern internet service.
This whole situation is really funny because it looks a little bit like VC funded companies slowly discovering why soviet planning doesn't work.
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.
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.
> they are operating a real time service that requires near perfect uptime 24/7 and work across multiple timezones in multiple languages, payment methods, and currencies
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?
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?
An Uber competitor, Hailo, did this. Rather than adapting their services to support multiple languages, time zones, etc, they instead just ran a fully separate instance of the service for each region.
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.
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.
Do you have a source for this? Not questioning the assertion - just interested in the issues and the design process for the solution.
I'm afraid I don't have a single source – this is from discussions about tech teams, culture, engineering, etc, at meet-ups in London over the past ~7 years. They had a relatively large engineering team so there are plenty of ex-Hailo devs around here.
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.
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.
Slack does (or did?) exactly this, I think. Each Slack workspace is its own deployment: its own web server, its own database, etc. This is loosely why accounts aren't shared across workspaces, you need to open a new tab per workspace, and so on.
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.
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.
>What would go wrong if Uber India only handled one timezone and didn't really support French?
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.
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.
> People travel.
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.
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.
Being able to fly into almost any major international city, and then just open the Uber app with my existing account and get a car is a massive benefit of Uber over all competitors and it's the real power of Uber for me.
(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.)
(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.)
uber pool is an interesting optimization problem. an eng there was telling me about the graph theory she used to tackle it.
I believe you have never worked for major tech company? In the company this size, they have multi product line (Uber, Uber Eats, Uber Freight, ATG etc) which are supported by their platform and infrastructure. It requires tons of eng work. Unlike smaller company seeks existing solution like open source, Uber needs to solve many of these themselves, which means build from scratch and also build tools to support it from scratch. Also, being the leader, you'll need to gain edge over competitors, e.g for Lyft or others, it’s sufficient to use Google Map or some other third party vendor as routing and ETA service, but Uber has its own Map team to improve the user experience. Hope this helps you understand
Hope this helps you understand
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.
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.
[deleted]
Good god you sound ignorant. Uber isn't a post office with multi day SLA.
It's a realtime service with second-SLAs that needs to know where you are, where the closest 20 drivers are, the map of the area, places of interest and a dozen other things - for millions of users in hundreds of cities - and that's just one part of the company.
Payments is a whole chunk of the tech industry in and off itself. Food delivery is a whole of the tech startup scene in an off itself. As is Freight.
The Uber apologists on here really boggle my mind. Other competitors seem to do it fine such as Free Now, which operates in multiple cities and I don't even know where their offices are located because they don't need these super 10x Devs people speak about. There is no special sauce in Uber. Once the VC money that uber spend on subsidising EVERY JOURNEY dies up then customers will move to another platform.
How many drivers and riders does "Free Now" have?
Free now (Formerly mytaxi/hailo) has 70 million passengers and 100k drivers: https://www.daimler.com/products/services/mobility-services/...
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.
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.
Lots. They operate all over Europe.
They were called mytaxi until a couple of months ago, and absorbed Hailo and many other ride hailing services over the past few years.
They were called mytaxi until a couple of months ago, and absorbed Hailo and many other ride hailing services over the past few years.
I haven’t used Uber enough to hit the problems that others mention (e.g. drivers playing chicken with your pickup hoping you’ll cancel). With that said, there’s nothing I’ve seen from Uber that Hailo didn’t give me when I was traveling in Dublin 5 years ago.
It's a realtime service with second-SLAs that needs to know where you are, where the closest 20 drivers are, the map of the area, places of interest and a dozen other things - for millions of users in hundreds of cities
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.
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.
> realtime service with second-SLAs that needs to know where you are, where the closest 20 drivers are, the map of the area, places of interest and a dozen other things - for millions of users in hundreds of cities
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.
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.
the start of the end? nice. what a scummy company...
It's complicated. They provide better service than incumbent taxi services, but they were only able to do that because Travis Kalanick build a culture that's not too concerned with legalities. And Lyft was only able to do it because Uber led the way.
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.
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.
One of Uber's most impressive accomplishments was that they were able to generate sympathy in many circles for the incumbent cab companies. It took real ingenuity for them to get themselves painted as the bad guys given how, in most markets, essentially no one likes cabs. OK, people are fine with private cars and cabs in a few cities like London (mostly) but they're expensive.
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.
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.
> Uber and Lyft really are better experiences than random cabs most of the time
For the passenger yes, but not for the drivers, and they are people too.
For the passenger yes, but not for the drivers, and they are people too.
I know this is anecdotal, but I often ask this to drivers who used to drive for cabs. 9/10 they say they prefer Uber/Lyft because of their ability to set hours.
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.
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.
Yes they are although I'm pretty sure cab driver wasn't a great work experience for most either.
> the start of the end?
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.
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.
You’d usually do these moves to increase employee churn a bit as well. 6 months from now it will probably pick up again
They don’t seem that bad here in Eastern Europe. Many times Uber is a bit more expensive than classic taxis. But most important they provide a very good service compared to regulated taxis. To understand what we had here before think of the normal taxi companies as the mafia. All of this while the government and the police did nothing.