Lyft to Cut at Least 1,200 Jobs in New Round of Layoffs to Reduce Costs
wsj.com
wsj.com
EDIT:
For reference I work at a company that requires leetcode medium/hard perfection and am appalled at the money we pay for the engineers relative to the value they bring
One more point: Startups are confused about the role engineers play. A completely divorced product management and engineering workforce will kill new ideas. Engineers actually building the product have insights into what else can be built that product does not. By hiring engineers with zero product sense and treating them like robots, you get no innovation. This doesnt matter at a behemoth like amazon or google, but it does at a smaller company. Clean syntax != good engineer
If you think co-pilot is cool now, just wait and see what it does in 5 years. A team of 10 tomorrow can probably replace a team of 50 today.
So maybe the interview process in 10 years is more like: "build an auction site like ebay in the next hour."
This is very "Monkey's Paw" and I can absolutely see something like that taking hold, as sloppy and stupid as such a task might be.
I had an interview with a YC company who asked me how to do something, and then I did it, and then they asked "how could I make it a one-liner" - immediately thought was "I'm pretty sure I don't want to maintain a codebase full of fun little one-liners for everything" - managed to get it, but it definitely looked like crap.
If I were to get asked to build eBay in an hour, I'm sure my auction model would be 1) shit, 2) very prone to social engineering type attacks (fake bids, etc)
Shoutout to the interview I had where I was asked a tricky graph question, reasoned my way to the optimal solution, then failed because I "should have recognized" that it was a variant of Djikstra's algorithm from the beginning. As we all know, being able to regurgitate an existing algorithm shows far more promise than being able to logically create it yourself!
What will it do? It can't write exponentially better code. Maybe 50% better, so that I would need to edit it's outputs less often. The only thing I could see it doing exponentially better would be writing _less_ code. Telling me "stop! close this file. close this project. you are working on the wrong thing!"
Technology can jump sharply but then go relatively flat. We still haven't gone back to the moon, 50 years later. We still don't have at-home nuclear power plants.
At my last company, we stopped doing system design entirely because we found it was completely uncorrelated to whether or not a candidate did well on the job.
Our project-based interviews were the main hiring criteria, and we originally planned on using system design interviews for leveling. What we found is that doing well on the project-based interview was a much better signal than the system design interview. When we used the system design interview for leveling, we under leveled certain people and over leveled others. We discovered that it would have been more accurate to only use the project interview for both making a hiring decision and leveling.
Ultimately, what we had trouble with was formalizing the evaluation criteria for the system design interview. With a project interview, we formalized the requirements of the project and everyone on the loop evaluates candidates against those criteria. With the system design interview, only one person ends up evaluating each candidate and a single person's judgement is highly variable. Unless the candidate did something egregiously wrong, it was very hard to say whether or not something was strictly "bad" or "good" and it was impossible to write down the list of "bad" and "good" qualities ahead of time.
Did you have any trouble with candidates declining the project? My first instinct as a candidate is to turn down take home project based interviews. I almost always say no to them (especially if it’s for the 1st round) for a few reasons:
One: In general they seem like a poor use of my time. I would rather do 5 one hour coding or design interviews at 5 different companies than a single 5 hour project at one company.
Two: I’m skeptical that anyone is actually reviewing the submitted project. And the evaluation criteria are usually unclear. For instance is it worth it to add linters during the build process? Or to introduce caching for api responses? Will the person evaluating the project notice details like that?
Lastly: Every coding or design interview carries over to the next one. Preparing for one is preparing for all of them. In contrast I’ve seen projects (for a backend role) range from “build a simple weather api, any language” to “build a sudoku solver specifically in JavaScript”.
Our process was to have someone "setup" the interview by introducing the project and helping the candidate get set up. Then the candidate would work on their own. Periodically, someone else on the loop would stop in, see how things were going, answer questions, etc. At the end, the last person on the loop would go over their code with them. This was a very important step. Hearing someone talk about their own code is just as important as the code itself. It's also interesting to see how candidates debug things, should any bugs arise. Finally, we would debrief. We'd bring up their code in a meeting room, test their project, ensure it meets the requirements, find bugs, etc. We'd discuss the code, see how clean it was, whether or not it was nonsensical, etc.
Selecting a project for a project-interview is non-trivial. It's definitely possible to pick a bad project. For instance, sudoku solver sounds like a bad project. The evaluation criteria is too strict and it sounds like there is probably an "optimal" answer. Basically, it sounds like one long leet code question. A good project question has a number of qualities:
1. The project needs to be a language of the candidates choice. You want to see how they code, how they think about problems etc. If you give them a skeleton, you're constraining their thinking and will get a weaker signal. It's also very informative to watch a candidate setup a new project. Good engineers will easily setup a new project in the language of their choice. Weaker candidates will suffer.
2. Evaluation criteria needs to be clear. We had 5 requirements that the project needed to meet. It was objectively easy to say whether or not the requirements were met. Failure to meet any of the requirements was essentially an auto-fail. I've seen project interviews where they don't tell you exactly how your code is evaluated and then run a test suite against your code. Forgot to test a negative number? Auto fail. How is that reflective of work done on the job? Such opaque criteria are terrible.
3. The project needs to be well-defined, but still somewhat open ended. We had 5 criteria to meet, but it was amazing the variety of responses we got. New grads would struggle to get all 5 done in time. Experienced engineers would use the time to go above and beyond. Going "above and beyond" wasn't really necessary. We could still judge skill just from the basic requirements, but it was cool to see how far some people took the project in the short time given them. This is a reason something like "sudoku solver" is a bad question.
4. The problem needs to involve some sort of data model / state tracking. A lot of software engineering involves tracking state, so we found it's important to see how people actually do that.
5. The current team needs to do the interview themselves. For instance, going back to a sudoku solver, how many people could sit down and do that in a short period of time? How many people spend their time thinking about discrete math problems like that? Personally, I don't like doing that, so it seems weird that I would require that of a candidate. Everyone on the team should feel comfortable that the project is achievable and reflective of the general work done on the team.
I'm consistently shocked by coworkers I've had, who I knew had to pass challenging leetcode interviews, who seem to not only know nothing about building real world software, but don't really have a firm grasp on algorithms.
Yes they can process a leetcode question requiring dynamic programming in record time, but when mapping a real world problem to a dp (or any other similar solution) are completely at a loss.
I see diminishing returns from LC hards and greater other than as a guardrail to block management from hiring senior people who are practically no better than the junior people.
given a day or two, sure, I can go review, find that solution, and provide an implementation and explanation as to why it matters for a particular problem domain, but an hour-long phone interview isn't gonna check that effectively, unless they really want to see the initial stage of me silently reviewing maths literature to awaken knowledge in cold storage
on contrast, I _can_ explore systems design stuff fine in that space of time, because systems design _is_ what I practice regularly in industry, because that's what I'm regularly asked to do.
Somehow companies are going to have to now filter through a lot more candidates to fill positions, and for right now leetcode-like tests are the quickest way to get a gauge of an engineer’s performance (on leetcode).
Don’t get me wrong: I think leetcode hiring depending on how it is done doesn’t result in getting the best talent.
High comp did not just start with covid. This had been the case for many years before the pandemic.
I suspect that if rideshare companies ever get to being profitable, we'll see the emergence of white-label rideshare software that gets made for a tiny fraction of the cost of what Lyft and Uber spend. Because that'll be an organization with a real incentive to keep costs down.
I also suspect that with larger companies, a lot of that below-the-waterline code is not ultimately necessary, the kind of stuff that if they were running a tight ship wouldn't be there. I certainly get reports like that from friends, anyhow. But it sounds like that's ultimately not an engineering problem but a management problem.
It's kind of like the high jump. You get the same result whether you're an inch over the bar or a foot.
I'm curious, who do you think is hiring the 10th percentile engineers? What are those people doing?
Lyft screwed up by not getting into delivery and people normalized using Uber for rideshare plus delivery and stopped finding a reason to use Lyft.
Engineering can only work in the bounds of the problems set to it. If the leadership doesnt want to diversify streams , get into delivery for example there is nothing engineering can do there. In the end you need both good business acumen to succeed and engineering is just a multiplier and facilitator there.
Also, some folks may dislike Java and this example may also convey why Sun failed in their minds.
No, it's a clear way to refute the absurd argument that a company struggling or even failing automatically means all their engineers are incompetent morons.
It's pathetic how there are people in this thread throwing blanket accusations of incompetence at engineers being laid off, primarily because they were far better paid and had far better jobs than them. It reeks of envy, and complete lack of empathy.
Well to an extent it's failure of engineering.
The best engineers are not code monkeys. But people who can map the business domain to code perfectly.
Given this is HN, we've all seen engineers who make business impact. some had degrees, some didn't. And we've seen engineers - who complicate matters while not actually shipping usable features , but doing things the GRRM martin way of plucking weeds. \
maybe step away from the mega corps and notice impact engineers have on a tech company's business direction.
When a company’s engineers ship quality code fast, they end up with more bandwidth. Then the company does more shit. What new has Lyft really built? It could be a symptom of slow engineering.
Search, Android, GCP, Workspace, Ads, just to mention a few are all still available.
Your argument is “I found the interview easy, and hence it’s not that bad.” Just pointing out that perhaps OP thinks the culture you’re part of is not a good one. I’m not taking sides here but curious what this clarification means to you.
Your point about engineering not being part of the problem is another. It’s partly true - unless your technology is true main selling point (like openai or maybe google search), then sure engineering makes or breaks the future of the company. So in one way you yourself point out the commodity nature of what companies like Lyft do - given how many companies around the world do it as well now that is. Then the question becomes what exactly are you paying top dollar to these engineers for? Create 4 more unnecessary open source projects to make sure the engineers feel like they’re getting exposure?
Airbnb is the epitome of this. Like dudes, you rent out rooms, what are you trying to do creating open source ecosystems in data engineering for?
Elons original thesis of Twitters problems was absolutely correct, why you needed 8000 people to run that org (or whatever the number is for Lyft especially on the engineering side) is beyond me. Overengineered is absolutely the correct term in these cases I think.
> Then the question becomes what exactly are you paying top dollar to these engineers for?
Again Engineering is one vector in a company's success but not the only one. It might well make sense for Lyft to pay well for good engineering talent there. Maybe not paying well might have doom'd them much faster.
Your take on OSS is also a naive one . OSS helps in off boarding long term maintenance costs (if the project becomes popular enough) and staves off bit rot. It helps attract talent , creates industry standards etc. Engineering is feature multiplier and for some companies it does make sense to OSS.
I would be careful not to express luxurious views in future interviews. Saying that Lyft engineering wasn't swollen and engaged in silly side-projects flies in the face of the layoffs announced in the article we're talking about.
An interviewee expressing those views would be seen as out-of-touch, if not stupid.
Anybody who read the mythical man-months knows that adding engineers to a project gets be detremental if it leads to a point where the marginal added communication overhead gets higher without really needing more people to achieve the goal.
The usual solution in big companies for the overengineering problem is that people who don't want to fight the org self-select, drink lattes all day long, and let the few people who are needed to solve the engineering problems do the work.
Nicely put indeed
Ride share isn’t sufficient.
If ride share can’t break even very soon then the company is fucked either way. At this point the VC money trucks are long gone and public markets have little interest in unprofitable companies long term.
In finance, such situations usually imply that someone in the middle of the transaction made money while grifting others - is that all that was going on in VC?
If you really want to understand VC’s from a finance perspective it comes down to trying to value intangible assets. Having ongoing customer relationships is inherently valuable. Lyft could for example sell their customers email address to scammers, but the goal is to leverage those relationships more sustainably thus extracting vastly more money.
For a rapidly growing unprofitable company it really just becomes a question is the long term value of those intangible assets (software, customers, patents etc) worth more than the current burn rate. If it is then you have a profitable investment in a company that will eventually become profitable or get bought out by someone else.
Also, wouldn't the very high salaries paid to a lot of engineers contribute it Lyft having unsustainable economics?
I doubt the interview was literally just Leetcode. They're screening resumes and making judgment calls about who even gets to interview. They also evaluate the candidate's experience and so on.
Leetcode is a gate, but it's not the only gate.
Engineers need to stop being bitter about others making more money than them and start roasting the business people that fail to make the company profitable. Even if they make 1/3 of what engineers do, they fail at their primary job function and need to be let go.
I realised in 2016 that Uber/Lyft were never gonna print cash so I didn't work for them.
people who own the failure will have more luck developing their skills and becoming more marketable, than people who run away from failure and play the blame game. woe be to the contributor, manager or otherwise, who believes their little bubble of excellence will never pop.
Let's say each project touched about 20-40 people.
What projects were they working on that leadership deemed 1200 employees now useless? Was it... 30 growth projects they shouldn't have been working on? 50? 100? 20? 10? Was there just not enough work going around?
Imo Leetcode is fine for younger hires since at that point you are just looking for aptitude and/or someone who has the work ethic to grind.
With that being said, Lyfts hiring practices is probably NOT why they are laying people off. This is a business issue. No amount of infrastructure or hackernews-style idealistic interviews would be able to fundamentally change their position in their business segment, especially if its just for hiring ICs. The people at lyft are plenty talented, contrary to what OP is saying.
> With that being said, Lyfts hiring practices is probably NOT why they are laying people off
My comment was more a critique of the en-vogue hiring practice of basing a majority of a hiring decision on whether the engineering candidate can pass leetcode level X.
As for why Lyft is struggling is really two-fold, not diversifying themselves besides ride-hailing really pinned them into a corner unlike their competitor Uber which branched into food delivery and other gig businesses. In addition they like many other tech companies over-hired due to pandemic money and herd mentality.
Have you tried not paying that much and checking how much value you'll get in return?
Anyone who can write code can learn to leetcode (artificial time-pressuee aside). There's nothing that sets aside leetcoders from the rest of the engineering talent pool except that they put in the time (or have a competitive programming hobby). I haven't seen any evidence that leetcoders are worse in executing, compared to those that will not (or can not) put in the time.
Are companies laying off people people's they could not execute at the expected level? Or is it because of leadership strategic errors (over hiring)? Even if your assertion that engineers are overpaid is true - that is a failure of leadership. However, I don't see heads rolling in the C-suites, it's the fault of "macro-economic headwinds" they failed to see coming.
I still see the same mistakes, the same mindset, the same process and the same result with very very few exceptions.
Im sure uber drivers do similar but i have taken over 1200 and only had this happen once or twice
Could you expand on this a bit? I'm not familiar with reputational differences between the two (beyond the early days corporate culture exposès).
At least with Lyft the id of the complainer matches the registered id.
If one ever visits /r/uberdrivers its just constant discussion on what tips they got and how to extract more tips from people
Uber went public 4 years ago.
- The latest cuts could impact 30% or more of Lyft’s more than 4,000 employees
- The cuts could help Lyft slash 50% of its costs
Sometimes companies just leave thise positions open for months.
But, if one is being charitable, one problem as you say is that there probably really isn't a market for unsubsidized rideshare in a ton of places--even if they are a better service than traditional taxis. I know where I live--50 miles outside of a major city and adjacent to a couple small cities--Lyft and Uber availability is very thin as it is. I couldn't really depend on it for anything.
Recently I see the price I pay on my phone and then see the fare the driver receives on theirs and it's sometimes a good chunk less than 50% of what I pay.
They were probably assuming that by now they’d be back to a pre-COVID level of ridership by now.
The landscape has changed dramatically since they IPO’d and unlike Uber they don’t do food delivery which probably softened the blow to Uber.
In a more reasonable scheme the technology portion of a cab company is a small part of their overall expenses, commensurate with the degree of value it brings to the business.
This is true in some white-labeled cab dispatching apps (see: Curb), but not true for ones that chased sky-high valuations with assumptions of pure-software margins (see: Uber, Lyft).
You can afford to pay a huge number of top-dollar engineers and product people when your margins justify it. Being the tech layer on top of cabs turns out to not be in this category of business.
I mean just look at Netflix. They were never a tech company, they were an entertainment company with a tech advantage and thats extremely obvious now. Same thing with something like Carvana. How the hell did they ever manage to convince people they are a tech company and will have tech company margins when they are just selling cars.
Remember for the past 10 years where every bit of skepticism about these companies was vigorously attacked as either being a) grossly out of touch idiocy or worse, b) malevolent forces representing a conspiracy of anti-tech incumbents?
You had VCs that were willing to believe literally anything, and naturally an entire cohort of entrepreneurs happy to tell said VCs anything.
The fact that these same VCs haven't been run out of town on a rail suggests the bubble will regrow once things settle down some, and that's disappointing. I for one believe the efficient allocation of capital towards speculative technology is crucial to the advancement of the human race, but the people who've been doing it for the past decade have proven themselves to be credulous rubes who are utterly and congenitally incapable of it.
A: Drivers need to get paid enough to want to do it.
B: Riders need the rides to be cheap enough to choose it.
C: The quantity of drivers generally available needs to be consistently high enough that riders can find the rides they need when they want with little wait time.
D: The quantity of riders generally available needs to be consistently high enough that drivers are willing to sign on and wait to accept rides.
E: The overhead of running the business.
Profit comes from the spread between A and B minus E. But A is dependent on D: if there aren't enough riders seeking rides then drivers get fewer of them and need to make more per ride to it to be worth signing on. Likewise B is dependent on C: If they have to wait longer for rides or risk not having a driver available, they won't pay as much or choose to use the service.
The company has knobs they can turn by controlling how much they charge riders and how much they pay drivers. But because of the connections through C and D, they can't turn one without affecting the others.
And it may be that depending on their overhead and the natural density of an area, there may be no valid pricing solution that doesn't lead to the system collapsing from disuse. They have been able to avoid that up until now by infusing the system with "free" investor money, but that doesn't last forever.
Last I checked, their profits were from selling a stake in another startup, not operations.
If the new CEO took over "days" ago, to what extent was this his decision? I'd think it would take weeks for a longtime CEO to cut this many roles, and a new CEO has to get up-to-speed on all aspects of the business before being able to do anything major. Perhaps he spent 6 months vetting the company during the courtship phase, and was planning this all during that time?
But now, they all want to scale down to be profitable.
A small scale Uber or Lyft is just a cab company with an automated dispatch agent. It should be valued like a cab company, not a tech company.
Although, maybe not if all your money goes to AWS anyway...
No, to the best of my knowledge, the push towards autonomy came after they realized that they would struggle to get profitability through scale. Just look at their first pitch deck[1] from 2008, there's no mention of autonomy. They didn't really start pursuing autonomy until around 2015, when they finally started hiring researchers for that[2].
[1]https://techcrunch.com/gallery/here-is-ubers-first-pitch-dec...
IMO the lines are a little fuzzy and the definition of "tech company" seems to be shifting pretty often to fit a specific narrative.
Like why is Netflix considered a tech company instead of a media company (like Disney or whoever owns Discovery +, AMC, or similar) when all they're doing is producing video content on a streaming service but Uber has to be valued as a taxi company when they produce an app that coordinates movement of people, products, and other things?
I guess part of the problem is everything is "tech" so the term is starting to lose meaning except when we want to No True Scotsman something (not that I'm accusing you of doing that here).
It’s funny that CBS and stuff was a tech company 100 years ago.
Similar is the morph of Google into just a clear channel or other ad company. Search and adtech was hard years ago so they were a tech company. Now they sell ads and data.
My great-grandfather came over from France to work as an "engineer" in the mines of Minnesota. I suspect that for him as for me, the novel technology created an opportunity for quick-on-the-uptake people to make a decent living figuring out the new thing and making it go. But eventually the technology becomes settled and boring, so it's a different thing both in terms of skill and economically.
If you're interested, you might look at Wardley mapping, one axis of which involves technology moving along this axis: Genesis -> Custom Built -> Product -> Utility/Commodity. Also relevant is the technology adoption lifecycle: https://en.wikipedia.org/wiki/Technology_adoption_life_cycle
Before they started making their own content, Netflix was a pure tech company. They pioneered a lot of the streaming technology we now take for granted, and they were the first to solve some very difficult challenges.
Recently the market re-priced Netflix stock to be more like a media company, so reality has caught up.
They were in the business of renting DVDs by mail.
Lyft's stock is down like 70-80%.
So you could argue Uber is actually on the path to achieving that vision and Lyft failed, not that neither should be "valued like a tech company".
Anyone who dared to suggest that the new ride share companies were actually just cab companies feeding off a pump of VC funding were down voted and shouted down into oblivion. Turns out those people were exactly right though...
> But now, they all want to scale down to be profitable.
I am a bit confused by these two statements. In the first, it sounds like you are using "scale" to describe the customer reach and sales volume of the company. In the second, it sounds like you are using "scale" to describe the number of employees.
I agree that Lyft and Uber should not be valued like Google or Meta. Wall Street agrees, as you have surely noticed. But both are much more valuable than a traditional cab company. It is the "automated dispatch agent" you mention which makes them that way and which also requires innovative use of silicon and development of software.
As an aside, were there ever nationwide, publicly traded cab companies in the United States of America? I cannot think of any.
> The entire promise of Uber and Lyft was profitability through scale.
Here "scale" means scaling to the entire country/planet. Which, as far as I know, they still are.
> But now, they all want to scale down to be profitable.
Here "scale down" means trimming on employee count where there are inefficiencies.
> A small scale Uber or Lyft is just a cab company with an automated dispatch agent. It should be valued like a cab company, not a tech company.
Here somehow you went back to your first meaning of "scale", but used the layoff = "scale down" to imply they want to scale down to a local cab company. I've yet to see a local cab company has an app that's usable in an entire country instead of just one city.
By the same logic, if Airbnb has layoffs, we should suddenly compare their market valuation to a small local vacation property group that only rents beach houses in Maui or something...
You, sir, are an absolute savage...and correct.
It also doesn't help that Lyft has not been profitable since going public, so if it were valued as a taxi cab company, it would probably have negative enterprise value.
Can't expect to cut 30% of a struggling company's workforce and expect growth to keep happening.
Seems like a last ditch effort at shoring things up. Or cutting enough to look good enough to sell.
I'm starting to think that many companies seem to define "growth" in terms of headcount, rather than revenue or marketshare, and that they overhire based on a perception of needing to grow the company whether they need the people or not.
Lyft is a mature product. Heck, they felt like a mature product when I used them for the first time five years ago.
So why would they need to keep hiring engineers? What new features necessitated the hiring of additional teams?
If the cuts are done well, they'll cut the most of the future projects and focus on a few key areas. Still it is a high risk for them and they may not survive.
This is mostly recognizing that they were feature complete like 5 years ago. They're now in the "keep the lights on and rake in the money while it lasts" phase of a company.
Uber made much bigger bets than Lyft. Expanded world wide, launched stuff like eats, and burned a ton of money on self driving cars.
It's quite possible actually if those 30% were not the ones contributing anything to said growth.
I'm not saying this is or is not the case at Lyft.
The marginal cost to provide a ride is all that matters to their business in the end. Any meaningful improvements to this via software has likely already been achieved