Yelp's engineering isn't likely much more than ~150 people (I worked there ~2 years ago, maybe has grown since then but honestly, given their revenue situation even then, likely not by much). The mix there is just like most companies; you've got dedicated teams for each of their apps (which includes Android, iOS, web, business-facing, etc), you've got API teams, back office teams working on moving data around and business analytics, a very secretive abuse management team, IT, etc. Yelp also, given their age, wasn't (at some point) running their primary workloads in the cloud; they had (have?) a colo DC in San Francisco that hosted a ton of stuff, so there were people dedicated to that hardware. There was some movement to get rid of this as I remember.
Surprisingly, or hopefully not, the vast majority of the company is more directly revenue generating; sales and customer acquisition. Its spread very globally; at least as of a few years ago, the SF HQ didn't house any sales people, though I think they had an office in Oakland which did.
Point being, I always got the impression that their engineering team was very "right sized" given their revenue and product scope.
When I left last August, we had around 600 in engineering, around 900 in product and engineering.
Engineering was mostly based in SF but with satellite offices in London and Hamburg. It looks like they were expanding in a large way into a Toronto office too.
Infrastructure was around a fifth of that total but included verticals like search and machine learning infrastructure.
Yelp turned off their last datacentre in early 2018 (IIRC) - and is entirely on AWS.
You may be right. I never counted nor directly asked, that was just the number I overheard. It felt right; afaik, all of the engineering happened in SF, except one remote office in (IIRC) Germany. I know there were a few companies they had acquired (Eat24 and SeatMe) which remained somewhat isolated from the primary Yelp engineering teams (with their own floors of the building and everything), definitely possible the numbers I heard were not counting them.
That number ~150 engineers seems way too small, at most tech companies I worked at, engineering comprises 40-50% of the staff, if it doesn't something would seem very off. Engineering in this case is product, platform, IT, hardware etc.
Abuse management is usually secretive because if you publish the "rules of non-abusive behavior", you end up with a bunch of behavior that complies with the official rules while still being abusive.
Because of the value in subverting abuse systems such as Yelp ratings or Google SEO, these teams usually are handled differently with an entirely different threat model - which is why they may be referred to as "secretive".
Even 150 blows my mind. Years ago I worked for one of the top 10 EHR software makers (at the time - maybe even now, I haven't looked) and we had 1/3 the number of engineers on that system.
It's funny, as soon as you have a system that has to take into account human behavior and variety of possible inputs/states, it gets massively complicated if your goal is to try to have people not be dissatisfied with it. (and if you're trying to do it right -- or alternatively, NOT making the right decisions about that goal). People just don't behave like you think they will/should.
As an example: a retail transaction database. Or a calendar booking system. That should be really simple, right? Just record who ordered what, when they received it, who sold it, etc. Who reserved the room, who to send invites out to, simple?
No, it turns out that you have to also take into account people whose orders got delayed by the human-based shipment system, people who got coupons and they expired/want to extend the coupon, people who returned the merchandise and never got any confirmation that it was received back. Or what if someone modifies the meeting location after people accepted -- does a minor change to the meeting description trigger a re-invite or update, or not? Can meeting rooms be held by more than one person at a time? Or what if you want to tie it to the email marketing system that wasn't properly integrated or planned to be integrated -- that's another couple of engineers who have the thankless task of maintaining ETLs that constantly break whenever a change comes along.
Or in the case of Yelp, I'm sure there's small teams who are responsible for the mundane tasks of how to keep track of when a business closes, or reopens, or temporarily shut down due to virus situation -- how are the entries for those businesses supposed to be updated? We never had a field for "closed by mandatory government order" -- that's gonna take a refactor of xyz to implement, etc. etc. We have users who review things, and then those users someday die/go idle/get banned. What happens to the ranking of their reviews? It goes on and on.
(and usually, the people who take the time to think about these things in advance set themselves up for much less pain, and far fewer people needed to fix it, later)
> As an example: a retail transaction database. Or a calendar booking system. That should be really simple, right? Just record who ordered what, when they received it, who sold it, etc. Who reserved the room, who to send invites out to, simple?
I am not sure people downvoting me understand what all goes into an EHR/practice management software. Calendar booking? Yep. Billing. Oh hell. Don't get me started on the byzantine mess that medical billing is! Then there's charts with icd-9/10 hell. And then everyone you sell it to wants their own charts a little different. Patient records, insurance, I mean, it goes on. The database had several thousand tables. It was insane.
I don't mean to be flippant or unnecessarily mean, but my anecdotal experience is that many EHR systems are pretty widely derided by healthcare providers (i.e. end-users).
Maybe it's not a good thing that only 50 engineers were working on that system.
Doesn't matter to me, I'm not in that industry any more. But yes, they're a mess. But, honestly, I don't know you would make it less of a mess. People just need to accept that some systems are complicated and the more you try and make it less complicated the further from that goal you get.
There is a whole bunch of stuff behind the scenes that you wouldn't be exposed to as a consumer, such as analytics data pipelines, ad sales interfaces, etc that in many ways are more complicated and do more than the consumer facing thing itself.
An old EHR system from years ago does none of those things, doesn't do engineering heavy things like live updates with thousands of A/B/C/D tests running simultaneously with multiple clients for multiple operating systems and so on.
Often this comes down to how much money you're making. Any product has a long, long tail of work you could be doing to improve things. When you're a scrappy startup with few engineers you wouldn't even think of spending time on that stuff. But when you have substantial revenues, why not hire more engineers to work on it?
The problem is edge cases take a shitload of work via pareto principle. And if your company is small, edge cases can be ignored because they affect 1-2 users. When you're serving millions, those are thousands of users. You might be the only entity in that industry at that scale and have to custom build everything.
Surprisingly, or hopefully not, the vast majority of the company is more directly revenue generating; sales and customer acquisition. Its spread very globally; at least as of a few years ago, the SF HQ didn't house any sales people, though I think they had an office in Oakland which did.
Point being, I always got the impression that their engineering team was very "right sized" given their revenue and product scope.