Let's avoid putting here obvious companies and companies who over-engineer, maybe?
http://quellish.tumblr.com/post/126712999812/how-on-earth-th...
https://www.reddit.com/r/programming/comments/3m5n2n/faceboo...
As for the 18k classes in their iOS app, I don't see why this is a sign of bad engineering? I'd expect that a large number of these are auto-generated, for example from Thrift API definitions, and I'd also expect that what we see as users is the tip of the iceberg in terms of the code needed. There's obviously a lot of analytics code, and also I'd expect the resiliency and reliability needed requires much more code than we'd expect.
Scale is handled at the back-end.
As a small-company person who migrated a few years ago to one of the Big Four, I can confirm that almost every time someone tells you about "scale" they are bullshitting you. Most developers on those companies either do not deal with scale at all (anyone dealing with front end stuff) or do so by using abstractions which allow them to ignore scale (99% of developers). But scale sounds sexy so everybody pretends they have something to do with it. And it sounds better than "bloat" which is what they really mean.
The other variant of "scale" is "I have this single-computer application running on X hundred thousand servers" or some ambarrasingly parallel problem of that sort. Then they will claim boldly that something that has a 0,0001% chance of happening "happens multiple times a day here" which sounds impressive until you realize that that thing has no impact on the SLA and you get saved by the load balancer so it isn't particularly important anyway.
The 1% of people who work on real problems in the area don't need to brag on the Internet about "scale" because they are too busy working.
The light FB app probably does very well by class count metrics, but it's intended for a totally different market. Stateside, much as we may bitch about it, it apparently doesn't matter for an app in FB's position.
Facebook wants the shortest possible time between product idea and real world users interacting with it, which is why they also have a solid CI/CD pipeline. You might not agree with the tradeoff, but the pragmatism is impressive
What makes you believe this is "clever" as opposed to a poor engineering decision? I strongly suspect that FB might have delivered a higher quality product through a more traditional team-ownership development model. Throwing large numbers of developers at a single app is unlikely to lead to a well-architected holistic solution.
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
* you decide on a team before you start, but after you know you passed the interview
* moving fast is not valued as much
I would also add that Facebook uses a lot of Open Source, meaning your experience will be applicable elsewhere.
Here are some potential advantages about working at Google:
* Being ethical is a core value of the company.
* Google/Alphabet is more diverse (Search, YouTube, Android, Hardware, DeepMind, Waymo ...) and has more offices worldwide.
* It has an advantage in Machine Learning and Research. Google even has an internal research conference.
* Google even has it's own incubator for entrepreneurial employees (Area 120).
* Google is trying hard to make it's hiring and promotion process objective and unbiased. That's why they happen by a commission of peers.
Most of the compliant about Google hiring practice has been along the line of, and I paraphrase "I was promised to be with a team or a position and then I got placed in a totally and differently unrelated position/team"
How on earth does this follow? I know that peer review is in fashion right now, but without some very strong context, this seems more like a recipe for a Keynesian beauty contest than a useful measure of merit.
There has been research that showed that this kind of decision process decreases bias.
How does it make them stand out? What does it translate to in practice?
Google's search rankings are unbiased. The ads team is separated from the search team. It's business model benefits from and supports an open internet, unlike other companies which lock users into their ecosystem.
Google is very transparent internally for a company it's size.
Google releases large of amounts of open source software and publishes research. For instance Google published a paper that explains in detail how it's Machine Translation system works.
In my 2 dozen or so ContentID flaggings, maybe two of them have been by parties with a legitimate claim to the material. All the rest have been fraud.
My most recent "pleasant" experience with ContentID was some scam copyright company claiming they owned the soundtrack to Elder Scrolls: Morrowind. The beauty of this system is that not only are they fraudulently claiming they own that content, but to get my video published I have to swear that I'm not stealing the content they actually stole.
How do I report this scammer to YouTube? Well you can't. There's no automated way, and there's no support whatsoever. They can just scam in peace for years and years and nobody can do anything about it because nobody at Google cares.
"Ethical". Riiight.
But there's no way to tell Google, "the guy making this claim doesn't own the content, he's a scammer". That's the feature I need.
I am 100% certain that the company claiming to have owned Morrowind's music: 1) Is not Bethesda (the developer of the game) 2) Is not affiliated with Bethesda in any way 3) Has no right to the music
But I have no way to communicate my research to Google. Because, guess what, those "ethical" Google employees make money off the scam, too! They take a percentage of all ad revenue, even if it's a ContentID scammer's ad revenue.
Google's business model is pervasive surveillance, so that's a pretty odd thing to brag about.
> Google is trying hard to make it's hiring and promotion process objective and unbiased
Google tries very hard to appear to be ethical, unbiased, responsible, and generally virtuous. Sometimes this attitude results in good work. Other times, and I think more often, it amounts to empty posturing and counterproductive gestures. In the social sphere, this "be seen as good" attitude manifests itself as annoying virtue signaling, speech policing, and other behavior that you also see on American college campuses. This behavior is annoying, but very common in tech and easy to ignore.
The "be seen as good" attitude also manifests in technical culture, however. There's this weird attitude inside Google that what is painful must therefore be right, as if difficulty were its own reward. While it's true that the right thing is often painful, the converse does not hold, so Google makes some bad decisions.
Google's attitude toward developer friction is, "This process is slowing you down? Too bad. That's how responsible engineers work." This hairshirt-loving attitude leads to large teams, moving slow, and general risk aversion, and I think it leads to bad engineering-cultural choices.
Google: "This language feature causes problems? Let's ban it. We'll add headcount to make up for the productivity drop."
Facebook: "This language feature causes problems? Let's add tooling to warn developers about the dangerous usages and make sure we can quickly find bugs."
I've worked at a lot of tech companies. I don't think the people at Google are actually any more or less ethical than the people at other top-tier tech companies.
> moving fast is not valued as much
It's important not to underestimate how much moving fast makes you happy and how unhappy you become when moving to a slow environment having worked in one that moves fast.
Facebook's elevation of moving fast to a first-class goal goes a long way to slowing the kind of decay that Google has suffered.
They must have a great culture. Look what FB did for the JS ecosystem just recently—yarn, React, React Native, Immutable. Really excellent stuff which you not only need superb people but also a good culture.
So, I'd say that excellent products, both the commercial ones but also open source, are a good indicator for 'culture'.
How is that good? You essentially don't know what you sign up for.
At one point, we had completely outgrown our space and we were constantly tripping over one another. It was miserable and everyone was constantly sick. Eventually, we got more real estate and everyone was happy, more productive, and less ill.
As long as you have the real estate, open floor plans are nice and help you feel less imprisoned than cubicles imo.
That's not help. I don't feel imprisoned in a cubicle. I like walls, the taller the better.
I'm currently in a short-wall cubicle farm where we have enough space to not to all get sick, and even there the cross-talk from multiple conversations can be completely distracting.
While management/facilities ignorance can definitely make open plan offices worse, I think they're still not for everyone. Some people seem to not mind being distracted, other people are really sensitive to it.
Sorry, this could be slightly off topic for this thread. I'm curious if this kind of access also applies to all the data that users put up on the platforms? To put it in other words, how does FB prevent or work to prevent LOVINT [1] like cases? If it's the same kind of access, wouldn't working in the company make the employee uncomfortable that there are people who can look at all information?
[1]: https://www.washingtonpost.com/news/the-switch/wp/2013/08/24...
P.S./disclaimer: I personally dislike FB as a platform and as a company for privacy and other policy reasons I don't agree with (like "authentic names", for one). So my bias may be showing in my question, although it's intended to know more and not meant as an attack.
A caveat is that I originally entered FB's pipeline through a referral from a friend who interned and works at FB right out of CMU computer engineering. Referrals are often enough at these big tech companies.
What are the exceptions?
I'd imagine the exceptions are some small black boxes that try to catch abuse/spam/etc in various ways & places, or are closed off to prevent a code leak from exploiting a loophole in said software. Defense in depth, and all...
For the most part, the exceptions are acquisitions (but those get integrated eventually, see above) or some third-party IP subject to obligations.
* With few exceptions, engineers aren't hired for a specific team; they go through bootcamp where they get exposure to all parts of the stack and tasks from different teams.
* Ideas usually come from engineers. Managers are there to be a sounding board/connect you with people resources as needed.
* Moving fast is valued (we used to be famously known for "move fast and break things" but now it's "move fast with stable infra". I.e., our dev infra is developed with a eye towards enabling rapid iteration.)
* Lots of internal knowledge sharing.
* Scale. Probably only Google, MS, Amazon come close.
* With only very few exceptions, every engineer has access to the near-entirety of source code at FB (Oculus, Whatsapp, Instagram...).
* Internal mobility is quite straightforward; after a year you can generally transfer to teams with available headcount without a formal set of interviews.
Of course, it's not everyone's cup of tea and like any big company it's not always 100% perfect and we don't always live up to this in every circumstance, but in general this is what it's like and what we're aiming for.