Hacker News Reader

Comment by alfalfasprout | Hacker News Reader

I'm at Airbnb (opinions strictly are my own). The number of engineers working on tooling for us is actually not that large. The vast, vast majority are product engineers and with our most recent layoffs the majority of the cuts were for those types of engineers. My own opinion is that we simply had way too many product engineers for the amount of actual output we got from them.

Uber is on another different plane altogether... they have more than double the number of engineers and from talking w/ colleagues that worked for years at Uber it's my impression that even on infra there's a lot of bloat. Plenty of high level ICs that couldn't produce quality IC work to save their lives and plenty of pet projects.

View on HN

> Uber is on another different plane altogether

These are complete guesses for the pre-covid era, but it gives an idea of scale difference. The average Airbnb user probably books 2-3 times per year. The average Uber user probably books 2-3 rides per week. At 50x the volume, the infrastructure is different, and probably more complicated to handle the volume.

Eh, they're solving different problems. I don't think you can necessarily call Uber's problem more complicated just because it's an order of magnitude more volume. I worked at a small ad tech start-up with a team of 5 engineers on a real-time bidding platform that was serving 1k requests/second and moved to a travel company that's now 100+ engineers that serves maybe ~250 requests/second at peak traffic, but the travel company's infrastructure is a lot more complicated even though the volume is smaller.

right. this recession is actually giving cover to let go of a lot of bloat that has built up over the years.

Well, freeing it up to compete. I expect some of the bloat is just so that someone can't work for a competitor.

You'd think so but that's at least not the impression I've gotten. At Google that's certainly going to be the case but at a company like Uber/Lyft/Airbnb the bloat ends up largely arising due to managerial bloat (managers want to grow their org to make themselves seem more important) and low technical standards for higher level ICs (which results in far more resources used to accomplish each project).

Are you saying that technical standards are lowered as one moves up the IC ladder? If so, how and why?

Where does IC stands for? Probably not intensive care :D

Individual Contributor. Basically means no direct reports.

Thank you! That makes sense, I will try to remember it :)

The fact that this term exists implies bloat and a focus on process not productivity. You may as well call them "leaf nodes".

There are programmers and senior programmers, data designers and senior etc. There are also team leads and program managers. There's basically two tracks, you either create stuff or you manage the creation of it.

They have different titles now, and there's a lot of Agile fluff (how is a scrum master not just a secretarial service and the function of a team leader not to keep their meetings focused?)

Individual contributor (technical path as opposed to a managerial path)

Technical competence isn't as well evaluated at companies like Uber/Lyft/Airbnb at L6+ especially for external hires. So it's not so much that the technical bar is dropped but that it just is less enforced at higher levels. As a result you end up with a lot of ICs that are all talk but little else. This is, of course, a gross generalization. I've worked with and know great engineers of all levels at these companies. But Uber in particular had plenty of really bad apples that got hired into other companies across the bay at L6/L7/L8.

This is just a myth.

Software has way gone out of the stage where one person keep the recipe for the secret sauce, and could change the game.

No one is irreplacable.

> Plenty of high level ICs that couldn't produce quality IC work to save their lives and plenty of pet projects.

This seems so strange to me. As a lead, most of my work is management, organization, and planning. To scratch the development itch I usually have 1 pet project going on that I either use when I'm taking a break from actual work or work on in my spare time. But even that pet project has pretty clear long or short term value and the only reason why it's not being worked on by my team is because it hasn't been prioritized yet. I can't imagine working on a pet project that has no clear value to the company.

In a bloated org, they can get away with it though... we had to let one high level Uber hire go because they couldn't code to save their lives, had insufficient technical expertise to guide any kind of substantive project, and played a lot of politics to seem important. I've run into at least 4 high level hires from Uber with the same kind of profile.

At the end of the day, it's just a reminder that careful screening is important. Could be a cultural issue that impacts certain unicorns, but it's also on the hiring company to thoroughly fact-check and test a candidate (and no, leetcode and simple arch questions aren't enough).

Reply on news.ycombinator.com