Lyft was paying engineers 300-450k a year, sometimes with just 2-4 years of experience. This was true even pre 2020. The interviews were just leetcode hards, with an instant reject on not getting the problem right. I feel like a parrot repeating the same thing, but none of these companies hired the talent they thought they were hiring.
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
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.
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.
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.
> 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.
>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
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?
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.
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?
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.
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.
> 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.
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.
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.
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)?
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.
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.
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?
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.
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).
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.
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.
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”.
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.
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 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."
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!
> 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)
> 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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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?
> 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.
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.
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.
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.
> 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?
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.
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.
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
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