Lyft to Cut at Least 1,200 Jobs in New Round of Layoffs to Reduce Costs(wsj.com)
wsj.com
Lyft to Cut at Least 1,200 Jobs in New Round of Layoffs to Reduce Costs
https://www.wsj.com/articles/lyft-to-cut-at-least-1-200-jobs-in-new-round-of-layoffs-to-reduce-costs-da423e53
193 comments
This seems to be a common trope at HN where the failure of a company must be because of their hiring practice. Your comment also implies that the current failure has been engineering. This couldnt be further from the truth, Lyft had some of the best and smartest engineers. Lyft paid as well as they did because of the risk these engineers took in moving on from Google/Meta/Twitter what have you.
FWIW, I found Lyfts interviews to be the easiest of the companies I interviewed at.
The companies current downturn stems from the combined blow of COVID and focusing only on rideshare at the expense of not diversifying their revenue streams and their hiring or engineering has had very little to do with it.
OP says they don’t think the engineers hired by doing leetcode hard problems (and screening out the folks who can’t) does not engender a good future for the org.
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.
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.
My argument is not that 'I found interview easy and hence not so bad'. My argument is that in Lyfts case engineering hasnt been the problem with why its business is failing.
> 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.
> 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’m not against OSS, just frivolous ones funded by companies who should have no business doing that stuff. It’s not news that orgs like Uber were indulging the development and release of such projects so they can keep the fairly jobless highly paid engineers happy. There’s no way you can make an argument that the development and maintenance of airflow had any real bottom line effect on their ability to make a home rental market place. The true technology companies don’t and never did release oss solutions that were not fundamental things they could do well and needed to do well. I’m again happy (maybe I’m not) that airflow exists thanks to airbnbs indulgence, but as a bottom line for the company it doesn’t make sense. Especially in the current environment where you now are suddenly forced to show real value for your spend on engjneeeing.
I am sad that Lyft isn’t going to make it through, not only cause of the engineers but for their contributions for OSS and blogposts. I got some of their work as inspiration for some stuff. However, I acknowledge that some part of this can be a product of a ZIRP period.
Your views were commonplace 3 years ago. Now, the idea of paying for free OSS development with expensive engineer time, at an unprofitable company, in the middle of a tech-recession, is indefensible.
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.
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.
> 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.
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.
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.
>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
Nicely put indeed
Lyft actually did try and create many different revenue streams. Besides ridesharing, they own the bikeshares and scooters in pretty much every major city in US, got into their own car rental business and tried to become a one stop shop for transit. It's not that they didn't try, its that they didn't seem to have taken any of them to be profitable revenue streams.
Also, wouldn't the very high salaries paid to a lot of engineers contribute it Lyft having unsustainable economics?
Also, wouldn't the very high salaries paid to a lot of engineers contribute it Lyft having unsustainable economics?
I mean sure it's more complex than "hurrdurr bad engineers, not enough Rust etc etc" but to succeed a company needs products of a suitable quality level delivered in a suitable time scale to meet the needs of their customers. The failure to do that the buck stops at the engineering group.
Engineering isn’t usually the impetus of new product categories, which is what Lyft needs to survive.
Ride share isn’t sufficient.
Ride share isn’t sufficient.
The time to pivot was several years ago.
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.
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.
How is it possible that the money trucks kept coming for nearly 15 years on a business that has no path to profitability?
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?
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?
The general assumption by their investors was they had a path to profitability. Critically they don’t need to convince most investors just enough to keep going.
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.
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.
You’re probably right. Devils advocate though:
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.
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.
Counterpoint: Google. They've built a lot of shit. And they shut it all down a year or two later.
No, Google built a lot of shit and then shut some of it down later.
Search, Android, GCP, Workspace, Ads, just to mention a few are all still available.
Search, Android, GCP, Workspace, Ads, just to mention a few are all still available.
[deleted]
[deleted]
> Your comment also implies that the current failure has been engineering.
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.
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.
Stock based compensation is a huge drag on their expenses, to the degree that it has hurt their future. "Lyft had some of the best and smartest engineers", whats the bench mark for this? Good looking syntax in a clean code base isnt a top engineer. Delivering business value through technology is
Seems like that lends more credence to the idea that product strategy was the problem then no? How does a company decide to hire angineers and the products they'll be working on? It's true that engineering roles across the industry were overpaid in a way we're probably never going to see again, but isolated, that was just a symptom of the general amount of money sloshing around the tech ecosystem and doesn't really have anything to do with the reasons Lyft may or may not fail. The business model as it exists (at current pricing levels) is unsustainable. Even Uber is only achieving profitability because of its investments.
Don't think that's the main reason the stock is down. Uber is barely down this past year but Lyft's stock has tanked like 70%.
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.
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.
Its disingenuous to claim that these engineers werent delivering business value. James Gosling worked on Java at Sun and Sun failed, would you say that Gosling isnt a good engineer ?
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.
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.
Engineers can be passive recipients of assignments from business leaders. Or they can find ways to influence without authority and drive the initiatives that they know are needed. Everyone has that opportunity to some extent, but in some companies it's not worth the effort to break through all the obstacles.
Isn’t using James Gosling example as a question a fallacy in argument (i.e., loaded question)?
Also, some folks may dislike Java and this example may also convey why Sun failed in their minds.
Also, some folks may dislike Java and this example may also convey why Sun failed in their minds.
> Isn’t using James Gosling example as a question a fallacy in argument (i.e., loaded question)?
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.
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.
Every company claims they have the best and the smartest engineers. Have you seen any company claiming otherwise?
I talk about this when I do hiring. Our process isn't designed to find the best person for the job. We want to hire the first person who passes our bar for hiring. We just don't have the need or budget for the best and smartest people. But we often hire very excellent and very smart people!
It's kind of like the high jump. You get the same result whether you're an inch over the bar or a foot.
It's kind of like the high jump. You get the same result whether you're an inch over the bar or a foot.
Company?
Just due to the law of large numbers, any company at or above the size of Lyft is going to have mostly very average engineers. There just aren't many "10×" engineers out there in the market regardless of how much you pay. The key to effective management is figuring out how to obtain extraordinary value from average people: this can be done but it's largely a matter of organizational culture.
Very average? How do you figure that? If you're paying top dollar, which Lyft did for most of its existence, you're going to picking from a pool of the top few percent. Even 1% of all software developers is many times more than Lyft's headcount.
I'm curious, who do you think is hiring the 10th percentile engineers? What are those people doing?
I'm curious, who do you think is hiring the 10th percentile engineers? What are those people doing?
That's not how it works in the real world. There are a bunch of other companies also targeting the top few percent. Mathematically it isn't possible for them all to succeed in that goal regardless of their hiring process or compensation levels. If you actually talk to those engineers it's clear that beyond ability to solve "leetcode" type problems they are mostly pretty average.
Why not claim you have engineers that deliver the best value to shareholders? Employing the smartest people in the world to make an app to skim money off taxi going from point A to point B can't possibly be a judicious good value use of human resources, especially in the context of the extreme premium those at the absolute top demand.
I hope this downturn gets rid of leetcode. I really have no desire to grind leetcode whenever I need a new job. I am more than happy to do system design and practical coding questions (ex: integrate with some API like Stripe does), but the leetcode stuff is ridiculous for mid-senior+ level engineers.
If you think of Leetcode and similar filters as just veiled IQ tests it makes way more sense - of course those problems don’t have much to do with actual day to day engineering. If companies could just administer IQ tests they would happily do that. Since that’s illegal, they rely on Leetcode.
It's a modified IQ test filtered through the transfer function of having a CS degree. A big part of the shade that this practice gets is from people with backgrounds that are CS adjacent who are highly intelligent, can do math at a university level and perfectly capable of writing quality production ready code are dinged because they don't know some CS 201 puzzle that is never used in practice.
Interviewing isn't just a measure of how good you are at programming in real life. It's how good of an employee you will be. Conformity is a strong indicator of this. Comparing someone who completed a CS degree versus some guy that learned to program in a garage hacking together broken computer parts - the employer is going to choose the CS degree guy, even if the hacker is better at programming. CS degree means you follow direction, you can work within a rigid structure, you follow rules enough to make good grades and not get kicked out, and you're capable of doing monotonous work that sometimes has very little value.
eh, not really. even if you have a CS degree you forget how to do typical algo hard problems quickly after working in industry because you so rarely need to do them. the CS degree lets me _recognize_ when there's a problem with a particular complexity domain that needs a time- or space-efficient solution to scale, but I sure as hell can't recall the exact strategy on the spot like interview scenarios demand.
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.
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.
You're trying to frame this about college degree vs none. I'm sure that's a valid point and a college degree has value, but that's not relevant if we are talking about a degree in CS vs a degree in EE/Math/Physics. CS degree does not mean that you follow direction or work within a rigid structure any more than a degree in any other mathematical science. The Leet Code question biases the evaluation very strongly to tidbits of CS trivia that may or may not be relevant to the actual job. This will filter out someone with a background in say electrical engineering, even if the job is about doing linear algebra and signal processing (areas where EE is probably a better training than CS).
That's a fair point
Not all iq is created equal. Creativity matters
testing for creativity is much harder than testing for iq, and a high iq person with no creativity is a safer bet than a dumb creative person.
I detest leetcode-style questions, but system design questions are even worse. At least leetcode-style questions have some type of objective evaluation criteria. System design questions are entirely subjective and whether or not you're successful generally comes down to whether or not your first impression of a problem matches the expectations of your interviewer.
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.
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.
Did you hire people who did poorly on the system design interview and then measure their job performance? Or did you just determine that "passing with flying colors" didn't really improve job performance vs. "just scraping by"?
We moved from leetcode + system design question to project-based interview + system design question to just project based.
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.
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.
How did you structure your project based interview? Was it live pair coding, or a take home project?
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”.
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”.
The project interviews are in-person. They take between 4 and 5 hours, so the time commitment is roughly the same as any other on-site interview process. No preparation is required. In fact, I could tell you the question ahead of time and I would still get useful signal out of the interview.
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.
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.
That sounds like a pretty good process. I guess I’m more opposed to (first round) take home projects than I am to the idea of project in general.
Unfortunately it will likely get worse in the short term. With a huge pool of laid off people fighting for a small number of open positions (especially at the senior level and above) companies can be as demanding and stupid as they want with hiring. Leet code prowess is just another screening that whittles down the work they have to do to hire--only people that study and learn those interviews will pass them so the company has to worry less about actually figuring out if someone is a good fit for the position.
Leetcode is also just an awful signal. It would be fine if it was only problems with false negatives, but the false positive rate is through the roof.
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'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 don't think it will be the downturn that eliminates it, so much as it will be LLM-accelerated coding, and the normalization and incorporation of these tools into standard development workflows.
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."
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."
Who needs LLM-accelerated coding for that? Leetcode was already comically unrealistic as an evaluation of actual engineering skill. When's the last time you had to solve an algorithm puzzle without any ability to do research or check references?
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!
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!
I think that this shows how these interviews are really just a way to not get sued for discrimination when an interviewer just doesn’t like you.
> 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)
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)
> If you think co-pilot is cool now, just wait and see what it does in 5 years.
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.
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.
It’s a balance, an LC medium isn’t to hard to do offhand. If your business is hard tech, it’s a reasonable filter.
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.
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.
From reading recent interview experiences on Reddit, the thing got way worse now that you have thousands of unemployed engineers competing for scarce positions.
Now it's leetcode hards AND takeaway assignment.
How would the downturn get rid of leetcode? If anything it will dramatically increase its use as now there’s 100k more programmers on the market all applying for the same reduced pool of jobs.
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.
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.
The problem is that you and the other hundreds of senior engineers would perform the same if it were all design and the other example you gave. There's just not a good solution for companies that must evaluate the number of candidates these big companies get daily.
You can already filter out 95% of candidates with fizz buzz.
The Lyft service is rock solid, it's just not a very profitable business. That has nothing to do with engineering talent.
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.
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.
> the business people that fail to make the company profitable
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.
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.
[deleted]
Taking a high salary from a structurally unprofitable company is a massive risk. This has been hidden by the endless amounts of cheap money in the last decade but it's always worth thinking about.
I realised in 2016 that Uber/Lyft were never gonna print cash so I didn't work for them.
I realised in 2016 that Uber/Lyft were never gonna print cash so I didn't work for them.
And one of the puzzling things to me here is what all those engineers are doing. I mean, if you're making bad hiring decisions, engineers can happily create work for one another and themselves, so I get where the labor could be going. But it does not look to me like Lyft and Uber are particularly feature-filled.
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 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.
This already happened it was called Hailo and they got destroyed by Uber et al burning cash on incentives.
Thanks, I hadn't seen that. And yes, nobody should get into that game until prices stabilize such that the rideshare companies are profitable. When the game is setting money on fire in pursuit of a monopoly, you can't compete with Uber.
As always with large companies, what you see as a consumer is only the tip of the iceberg. For every user-facing line of code you have a hundred or a thousand lines of code made internal-only services, for interacting with partners, for variations due to local restrictions, etc.
[deleted]
Sure. I mean I have some questions about your proportions, but let that pass. We clearly agree that the amount of total code is proportional to the user-facing stuff. Which for Lyft seems to be quite stable. And since the main function of developers is to improve things, that makes me wonder.
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.
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.
In my experience, you usually have about 5-10 engineers on a team, reporting to a manager. Manager might report to a director who manages about 5-10 managers. Then VPs managing 5-10 directions, an SVP managing 5-10 VPs, CTO managing 5-10 SVPs, then CEO.
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?
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?
> 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
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.
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.
You just said that you see no difference between people that take leetcode and those who don't So why the hell use leetcode as a filter if it doesn't filter for anything?
Filtering for people willing (and able) to Leetcode is the point! When you have a large talent pool, you will have to come up with a filter; and there is also an element of luck involved - but I don't think interviewers or interviewees will be happy for an offer to be hang on a coin-toss.
I think theres a point of compensation that you reach where you just stop caring about the work or the company. If I was being payed that much a year, I'd be thinking about retiring early and trying to leave the working stiff life in as short of time as possible since with that compensation, its actually realistic to become a feudal lord in a few years especially buying into the market in a recession and riding the wave in the following years. 2-4 years of experience tells me they are right out of college too, so if you are fine with that standard of living you could realistically be living off 20k a year or less and the rest is just banked. Then in the back of your head you think if you ever do get laid off, you now have a title that was compensated at that much on your resume and new doors open for you, which you can take time opening with your massive nest egg.
Living off 20k a year in a Hcol, where these salaries primarily occur, is next to impossible. Rent alone anywhere in SF area, for example San Jose, is 2k at a bare minimum for a 1BR, or 3k for a 2BR split between a roommate at 1.5k each. That means rent is 18k-24k, not to mention other living expenses (car, utilities, food, travel to visit family, etc.)
If you went to school at say UCLA you are already used to living with a roommate in your bedroom (sometimes four). That's $1000 in san jose. Say you have a partner, now it doesn't even seem so desperate. Now you are at $12k rent alone. Fly spirit and buy the airfare long out to visit mom and dad when tickets are like $200 (i get emails for $49 spirit fares sometimes). call it $13000 with five visits home a year. Food wise you can easily do $50 a week groceries buying basic ingredients like fresh produce and rice or tortillas and beans. Now we are at about $16000 with all your needs met and about $4000 left over for any oddball expenses. SF area has bussing too, and bike lanes if you didn't want to bother with car expenses.
They didn't care. They needed to show investors a plausibly looking story how they "hire the best" by having a process with >90% rejection rate, and they did.
> The interviews were just leetcode hards,
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.
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.
It's the big gate though. No amount of experience, resume high points, etc. will overcome a failed tech screen or interview. It has stopped every single interview loop immediately that I've seen and been a part of the process. As soon as there's a "no hire" voice in the loop it's over, and the fastest way to get there is not figuring out an interviewer's tech screen question to their satisfaction.
Why is the "bar" for hiring designed around code puzzles(leetcode). Maybe that is not a good signal for hiring at all. You are optimizing for people who just grind away at these silly puzzles vs. having domain experts who have both depth and breadth across a technology stack. I have worked with many a engineer who aced these exercises who imho was entirely unfit for working at a large tech company, their communication was absolutely terrible, and their thinking was quite flawed from a variety of perspectives when it came to systems design and operational rigor. I think we will look back on this time and think what a mistake it was to optimize for employees who were good at solving leetcode.
I mean, the more senior you get the more focus you have on the stuff you describe - system design interviews, leadership interviews, etc. I know a few people that interviewed at Meta E6 for example, and they were explicitly told the leetcode interviews don't really matter as much and they are just there to make sure you can actually code.
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.
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.
yeah I agree with this 100%:
> 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.
> 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.
These companies are too large and have to rely on hiring managers versus people who might be domain experts for the actual project (who are probably too busy with said project themselves to take time to vet 500 candidates). It's an unsolvable problem I think for a large company. For much smaller companies, maybe you'd get a lot fewer applicants and it would actually be realistic for a team member to take a week to do some hiring for their team. Of course as small companies get successful, they tend to grow, then they lose this hiring relevancy advantage.
Wow, I would hate to work with you. Blaming the failure oof the company on engineering of all departments. And imagine being your coworker and not know the animosity you have towards them and the compensation they negotiated. Or maybe you do show it?
Do you think the lack of talent is what's preventing the company's success?
And companies won't learn! For how quickly most small companies seem to (or be forced to) learn on other facets, they've learned nothing about attracting and hiring the kind of engineers you want and how to keep them happy.
I still see the same mistakes, the same mindset, the same process and the same result with very very few exceptions.
I still see the same mistakes, the same mindset, the same process and the same result with very very few exceptions.
If you think that's bad wait till you see how much people a rung or two above that in management are getting paid without even being grilled on how to solve difficult puzzles.
The problem isn't the engineering, it's the business. Changing the interview process isn't going to make their competition disappear or make them profitable.
I'm not sure what you mean by "even pre 2020".
High comp did not just start with covid. This had been the case for many years before the pandemic.
High comp did not just start with covid. This had been the case for many years before the pandemic.
there was a crazy spike in hiring and salaries during the pandemic, with many companies hiring whoever they could find, as fast as possible (hence with higher salaries). I'm assuming that's what OP is referring to
[deleted]
[deleted]
Anecdotal and mostly useless comment warning: I took a Lyft for the first time in years in the Bay a few months ago to the airport. Unprompted, the Lyft driver did nothing but complain about Lyft’s pay. He waxed nostalgic over the golden years of Lyft and talked about how they trick drivers into loaning vehicles from them at high rates. Then on my return trip, another Lyft driver did the exact same thing. I can’t imagine having a bunch of drivers complaining about their pay and being sold a bill of goods is a win for your company.
If it was a net negative (or even significantly lower than minimum wage) they would stay home, most rent their cars weekly and not locked in for 3 years. It's a popular tactic for them to try to extract tips. This type of complaining will trigger a large tip from some types
If one ever visits /r/uberdrivers its just constant discussion on what tips they got and how to extract more tips from people
If one ever visits /r/uberdrivers its just constant discussion on what tips they got and how to extract more tips from people
Surely they're trying to squeeze customers for tips because the base pay just isn't satisfactory, right?
Lyft was trying to attract a certain type of person to work for them with their branding and marketing… looks like that is finally starting to backfire like I thought it would.
Im sure uber drivers do similar but i have taken over 1200 and only had this happen once or twice
Im sure uber drivers do similar but i have taken over 1200 and only had this happen once or twice
> Lyft was trying to attract a certain type of person to work for them with their branding and marketing…
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).
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).
Lyft continues to push that they are social conscious and cool. Even 2 years ago i had friends who wouldn’t take an uber because uber was such an evil company. Lyft spent significant marketing money on putting that in people head and it was really the only thing the company had going for them.
I started taking Uber Black or Lyft Black because of this, better have a completely silent trip than a driver that's constantly complaining and making the passenger the bad guy
Did you ever ask a ny cabbie about the pay? Unless you had an extremely rare owner operator, everyone hated it.
At least with Lyft the id of the complainer matches the registered id.
At least with Lyft the id of the complainer matches the registered id.
In either case, I didn’t ask.
On the other hand Uber is still subsidised by VCs so they can afford to blow money on the drivers
> Uber is still subsidised by VCs
Uber went public 4 years ago.
Uber went public 4 years ago.
The cuts are huge:
- 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
- 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
Lyft hasn't been profitable since it went public. There are a number of brand-name, silicon valley tech companies in this situation.
I'm looking for a job currently, and I'm surprised at the number of Series A and B companies still hiring. I wonder when the funding grim reapers will come home to roost.
A lot of these companies might have millions in funding in the bank, no need to show quarterly returns to the public, and a load of experienced tech workers have just hit the market who may be able to be snapped up for less than before. I think it makes sense.
confirm the roles are still actually open.
Sometimes companies just leave thise positions open for months.
Sometimes companies just leave thise positions open for months.
Those companies were doing layoffs a year ago. It sort of started there and has moved its way up. Many A/B companies are starting to pick it back up now and there’s actually a nice pool of talent available.
Has Uber made a profit yet?
Last I checked, their profits were from selling a stake in another startup, not operations.
Last I checked, their profits were from selling a stake in another startup, not operations.
How in the hell does one not make a profit when literally all they do is skim off the top of unlicensed taxi drivers, using an already fairly functional product?
For the system to function, you've got roughly five variables:
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.
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.
By having comically large back-of-house operations.
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.
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.
yeah its really odd how so many investors got suckered into thinking that all these "tech" companies that are firmly not tech companies and whose businesses make money in fairly mundane ways based on things happening in the real world are going to make trillions of dollars.
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.
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.
Total lack of due diligence and critical thinking, along with the very tech VC mindset where naysayers are poo-pooed for being out of touch luddites. Combined with the very weird incestuousness in tech investment circles where they all have the exact same brain worm.
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.
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.
They went public in March 2019 so they basically only had a year as a public company before COVID hit and dropped revenues off a cliff.
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.
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.
Subsidizing the rides
And often subsidizing the drivers... a marketplace like Lyft or Uber is only lucrative when there's a lot of volume. Otherwise, you're constantly trying to keep a doom loop from happening when there isn't enough supply (drivers) which makes riders upset or not enough riders, which drives drivers (sorry) off the platform.
It's tempting to ask why the subsidies continue given it's not like there are going to be widespread robotaxis anytime soon. Why not let prices settle at the appropriate market level?
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.
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.
Rides aren't subsidized. They have a gross profit of 1.5 billion against 0.5 billion of marketing expense.
That's because they haven't expanded into new markets recently. That will flip if they entered Europe or Asia
I always hear this but I'm not sure how they subsidize rides, is it just the 50% off type deals they give out?
When I was a driver nearly a decade ago I would get roughly 70% of the fare and that would be reduced if they used a coupon so it seems more like I was subsidizing the ride. I get that they'd lose a bit of their pie as well.
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.
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.
[deleted]
proxyon(1)
> The move comes days after a new chief executive officially took control...A Lyft spokeswoman said its new CEO “has made clear to the company that his focus is on creating a great and affordable experience for riders and improving drivers’ earnings....”
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?
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?
FWIW He was a Lyft board member for a long time before he was CEO.
I think Elon Musk would tell you otherwise
IIRC he had pretty fine-grained data during the months-long acquisition process, which would have enabled him to make decisions like this soon after officially taking over. I don't know how much data is shared with a potential CEO hire (versus a new owner).
Why do Lyft and Uber incur so much costs when they operate on a global scale? Forget global, let's take just the US, if Uber is the default ride app across the US, the cost to create the app, run the service should reduce drastically over time. It's been more than 10yrs and by now they should be doing really well. Same for Lyft. But from everything I hear, they are not. Am I wrong?
Because the margins suck. Yes, Uber facilitates a lot of rides. But those rides cost a lot of money. In addition to the trip itself, the driver needs to drive to you, wait for you to get in the car, and then wait after the trip for the next fare. That's a lot of time that they need to be compensated for. There is also a lot of competition. If Uber is too expensive, it's trivially easy to take a Lyft.
Wait, are you saying Uber compensates for the drive to the pick up location? Doesn’t make any sense, if there are enough drivers the algorithm should automatically pick the closest. Even then isn’t it the expectation that the driver ears that cost and the ride fee will compensate for that?
I'm saying that the compensation a driver is willing to accept is a function of all the time it takes for them to complete a trip. That doesn't mean Uber compensates them directly for that time.
My "bull" case for Lyft is being acquired by Cruise. Perhaps in an acquisition Lyft could restructure enough to survive and Cruise gets a ready-install base of millions of riders (and human drivers for all the markets/conditions they can't automate).
The entire promise of Uber and Lyft was profitability through scale.
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.
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.
> 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.
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).
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).
I think the issue is that "tech" is a shifting label that requires novelty.
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
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
Because when streaming started the tech was new. So the differentiator was the technology. Now they’ll morph into just a media company.
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.
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.
> Like why is Netflix considered a tech company instead of a media company
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.
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.
Before they started making their own content, weren't they mostly a logistics company?
They were in the business of renting DVDs by mail.
They were in the business of renting DVDs by mail.
No, the entire promise was to eventually have a fleet of autonomous vehicles doing the driving. The human driver phase was just to 1) drive adoption of the app and grow share and 2) generate training data for the self-driving AI models while waiting for the fully autonomous capability to arrive. Scale is irrelevant as long as you are paying humans to drive cars, because that's not a model that can ever scale and will always just be a cab company regardless of size.
>No, the entire promise was to eventually have a fleet of autonomous vehicles doing the driving.
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...
[2]https://archive.is/pklu6
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...
[2]https://archive.is/pklu6
I’m not sure if I ever believed that hogwash. I think it was a fantasy meant to try to justify ludicrous stock prices on unprofitable companies. After 14 years of serious investment, it’s not clear if self driving cars are ever going to become mainstream, and certainly not soon enough to keep Uber and Lyft afloat.
It's a bit odd to be skeptical that self driving cars won't ever be mainstream. Computers have only been a thing for ~78 years and yet they're already capable of doing so much.
But now instead of drivers, you need to acquire land/buildings/people to manage the fleet of self driving cars. Someone has to refuel/recharge the vehicles, clean/maintain them, etc. Sounds like a taxi company to me.
That's a fair point. Maybe self-driving cars aren't practical at scale but it seems like they'll still be a thing.
Well, that was their initial idea, but I think they figured out a few years ago that it wasn't going to happen in time, and tried to find a different way. In theory, software cost scales less than linearly with customer count, so increasing in scale would reduce it as a % of revenue.
Although, maybe not if all your money goes to AWS anyway...
Although, maybe not if all your money goes to AWS anyway...
But they don't sell software, they are a middleman selling labor (drivers). They were never going to have software product style scaling.
Is Uber genuinely gathering driver data? They're only managing a fleet, and it seems unlikely that each vehicle has cameras installed. Wouldn't the autonomous driving tech actually come from collaborating companies instead of Uber directly?
It's so funny because a decade ago on this very website the rhetoric was the exact opposite in comments. People would bloviate many paragraphs about how disruptive Uber, etc. were and how they were going to revolutionize transportation. People around the world in mass would sell their cars and move into the city and just Uber everywhere etc etc. Uber would pioneer self driving cars and then robots would drive us everywhere and deliver us to a fully automated capitalism future. There was much hype about how only a company like Uber or Lyft could do this and that the old cab companies were complete dinosaurs that would be dead in a decade.
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...
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...
Uber did revolutionize transportation in a lot of cities. Cabs in my city were unreliable, untrustworthy, and expensive. Now I can reliably get a ride within a few minutes.
Not sure why all the downvotes but your statement is accurate. Replacing drivers with mechanics doesn't sound very disruptive.
> The entire promise of Uber and Lyft was profitability through scale.
> 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.
> 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.
I meant a general trend for these companies to pull away from markets, not just scaling down employee count. Uber is only present in three markets now, and there are some credible rumors that they're considering pulling out from one of them (India) too.
Uber's stock is flat YoY
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".
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".
Funny how you use 2 definitions of "scale" to make your argument.
> 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...
> 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...
> 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.
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.
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.
In other countries there are automated dispatch agents pretty similar to Uber/Lyft. There isn't that much difference between them.
They are scaling down the workforce which is different from scaling down the operation. This might come next because as a business you obviously don't want to operate in a small market where the economies of scale don't work out.
[deleted]
Coming to a company near you.
Dead company walking.
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.
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.
Lyft seems like the kind of company that would be more successful run extremely lean than trying to focus on growth. There simply isn’t that many major metro areas after all.
"growth"
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.
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.
I think it's not so much companies as executives. If we divide people up by skill/topic and reward managers for being in charge of many people, then they've got a strong incentive to focus on the growth of things that make them look important.
I mean, if you can grow success without headcount, that's the dream, but sometimes growth means "investing in many different parallel opportunities" so you hire more people to do more in parallel.
Sometimes "success" means selling investors on a growth story. Hard to do that w/o headcount.
Bingo.
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?
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?
They never expanded globally like Uber did though so there is potential there, but with any marketplace, you need a lot of money to expand into a market initially because you need both riders and drivers and incentivizing use when you're new is expensive.
Can't run lean. Its a 40% GPM business.
> Can't expect to cut 30% of a struggling company's workforce and expect growth to keep happening.
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.
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.
They may survive, but it will be hard. A bug cut like this will destroy the morale in the company. What works in their favor is that the entire tech industry is cutting jobs right now and they don't look like an exception.
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.
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.
I'm not sure what y'all are talking about. They're half of a duopoly with 5 billion in revenue a year. They're going to be just fine.
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.
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 revenue in 2022 was 31B. Lyft revenue was 4B. This is not duopoly. Lyft is much smaller, loosing 1.5B per year and the stock price crashed.
They will have hard time to keep the employees and keep the drivers.
Uber is in a lot more lines of businesses and markets than Lyft is. The split for rideshare in the US is 70% Uber and 30% Lyft.
Where do you get that stat? It's interesting because I think I read that (uber 70, lyft 30) in 2018 when Uber was in deep trouble. After 5 years, Lyft can't do better than that?
https://secondmeasure.com/datapoints/rideshare-industry-over...
Uber made much bigger bets than Lyft. Expanded world wide, launched stuff like eats, and burned a ton of money on self driving cars.
Uber made much bigger bets than Lyft. Expanded world wide, launched stuff like eats, and burned a ton of money on self driving cars.
There is 0 need for a large development team for Lyft or Uber once the core tech is built out. In fact its a liability at that point
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
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
the redundancies are not distributed equally.
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