This makes me realize it must suck to be a mediocre blind developer.
The average person is just average. Unless there is something about visual impairment that makes them better at development, then I would expect them to be on average, just average developers.
Yet I would guess that visually impaired developers get more scrutiny. If nothing else, just because they are a novelty.
Anyhow, I guess I am just reminding myself to treat each person as an individual.
I feel I'm a mediocre blind developer and it does suck, mostly just the blind part though.
I do my best not to let my coworkers know I'm blind (I work remotely.) Mostly to avoid either 'cripple porn' or being disregarded. Either way, it's easier.
I'm "on the spectrum" as they say, and I don't talk about it much; I'm quite concerned with what's called "passing". I want people around me to focus on the things I can do, rather than the things I can't do. Can totally empathize with that someone with a more acute disability than mine, such as blindness, would want to do the same.
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.
Apple | Cupertino, CA | Data Engineer |Full time | Onsite
Apple is a technology company headquartered in Cupertino, California, that designs, develops, and sells consumer electronics, computer software, and online services.
Apple's is looking for both junior and experienced engineers to work on big data, machine learning and high-scale, low-latency distributed systems. As a part of this team you will use machine learning at very large scale to build intelligent systems that operate at scale.
Requirements: - Ability to code in any statically typed language, excellent understanding of Data Structures and Algorithms - Experience and interest in Distributed Computing.
Nice to have: - Hand on experience with Spark/Spark streaming/Kafka - Hands on experience with Hadoop or large scale distributed processing.
- Functional programming experience in Scala (using monoids/semigroups etc in large distributed systems)
If interested send your resume to appleMLjobApps@group.apple.com
NOTE : As of this moment we are not looking for new college grads and applicants should ideally have more than 2 years experience.
Apple | Cupertino, CA | Data Engineer |Full time | Onsite
Apple is a technology company headquartered in Cupertino, California, that designs, develops, and sells consumer electronics, computer software, and online services.
Apple's ■■■■■■ team is looking for both junior and experienced engineers to work on big data, machine learning and high-scale, low-latency distributed systems. As a part of this team you will use machine learning at very large scale to build ■■■■■■■■ systems.
Requirements: - Ability to code in any statically typed language, excellent understanding of Data Structures and Algorithms - Experience and interest in Distributed Computing.
Nice to have: - Hand on experience with Spark/Spark streaming/Kafka - Hands on experience with Hadoop or large scale distributed processing.
- Functional programming experience in Scala (using monoids/semigroups etc in large distributed systems)
If interested send your resume to appleMLjobApps@group.apple.com
NOTE : As of this moment we are not looking for new college grads and applicants should ideally have more than 2 years experience.
Apple | Cupertino, CA | Data Engineer |Full time | Onsite
Apple is a technology company headquartered in Cupertino, California, that designs, develops, and sells consumer electronics, computer software, and online services.
Apple's ■■■■■■ team is looking for both junior and experienced engineers to work on big data, machine learning and high-scale, low-latency distributed systems. As a part of this team you will use machine learning at very large scale to build ■■■■■■■■ systems.
Requirements: - Ability to code in any statically typed language, excellent understanding of Data Structures and Algorithms - Experience and interest in Distributed Computing.
Nice to have: - Hand on experience with Spark/Spark streaming/Kafka - Hands on experience with Hadoop or large scale distributed processing.
- Functional programming experience in Scala (using monoids/semigroups etc in large distributed systems)
If interested send your resume to appleMLjobApps@group.apple.com
NOTE : As of this moment we are not looking for new college grads and applicants should ideally have more than 2 years experience.
