from Guide to the Job Hunt on Feb 26, 2023
Why I miss (and don't miss) Meta
I spent just over two years at Meta — spread over two internships and a part-time position. My coworkers were phenomenal and I learned tons, and yet, come time to decide on a full-time job, I didn't return. Here are reasons why I regret declining Meta — as well as reasons why I don't regret it.
Two years was enough time for me to get a glimpse of the culture and a few overarching ramifications. In this post, I pass on what I managed to glean in those two years2.
This post is written for several possible categories of readers — effectively, anyone with an avid interest in working culture at Meta:
- You're considering a job at Meta. This is the primary audience, as I discuss not just culture but also its ramifications on your day-to-day. The post is organized around pros and cons, influenced by culture, people, and the working environment.
- You're curious what working at Meta is like. I'll provide some insight, but the focus is not a "day in the life of". Rather, the focus is on higher-order observations about your productivity and career progression.
There are two main ethical concerns with Meta. These concerns shape projects, policies, and discussions within the company:
- I don't stand by Meta's principles. Dissociating yourself from a corrupted brand, and criticizing from the outside is easy. The much harder and more influential tactic is to instead incite change from within the company. With that said, former employees have met challenges with whistleblowing; as one whistleblower says, "no one is obligated to torch their career in pursuit of justice".
- I don't want to be paid by ad revenue, exploiting user data. This is a solid reason. As of 2020, 97%+ of Meta's revenue came from ads.
However, these issues aren't the focus of this post, as for most roles within the company, these issues do not affect your day-to-day. I'll instead focus on the pros and cons that affect the majority of employees.
As I discussed in How to make big decisions., discussions for major decisions should be broken up into a) criteria and b) rankings. For each of the major points below, I'll a) lead with the criteria and b) present information that will help you rank Meta for that criteria.
The culture is the main pro.
The main pros for Meta generally fall under the culture category: work-life balance, bottom-up, and openness.
Pro #1. "Work-life balance" is highly valued. As a rule of thumb, managers don't ping you outside of work hours. In fact, if you attempt to merge down to main after 3 PM on a Friday, you'll get a popup advising you against it — to save some poor on-call from working over the weekend.
- Impact: Note this doesn't mean Meta employees don't work hard. In fact, the MobileVision team I joined at Meta worked extremely hard. It just meant that no one bothered anyone else outside of work hours — unless it was an emergency or a deadline. If you needed a break, you could take it without feeling guilty.
- Comparison: Tesla was far more intense in this regard. Colleagues would begin posting in team channels at 7a in the morning, all the way until midnight, maybe even a bit past that. They were always in full-sprint mode — constantly communicating. Deadlines were set in a few hours or even a day, and planning was only for a few days at a time.
Pro #2. A hack-focused, bottom-up culture. Hackathons are taken seriously, and this helps foster a strong bottom-up culture by providing a well-trodden, well-supported pathway from hack to success.
- There are several days each quarter dedicated to hackathons. It's socially acceptable to participate in these company-wide hackathons for a simple reason: There is executive support. Quarterly hackathon winners present to the C-suite, and as a result of the rare executive visibility, successful hackathon projects are valued highly.
- Impact: Employees are proud of hackathon projects that blossomed into products, such as Meta Portal. Hacks-turned-products are ultimately hailed as success stories, and as a result, employees have relative freedom and support to hack on random projects.
- Comparison: Apple by comparison is highly top-down. Although ideas from ICs aren't explicitly dismissed, they aren't well-supported. ICs are generally expected to stay in their lane, and produce work in that single lane only.1
Pro #3. You're empowered to move quickly. This is taken to the extreme: It's better to release a buggy feature now than a perfected feature later. The idea to iterate quickly: ideate, develop, deploy, and repeat.
- This is a bit of double-edged sword, which we'll address later. The incredibly strong pro is that there isn't much red tape to deploy to production — this means you have a fast road to production-facing impact.
- Impact: You can in turn move extremely quickly. The culture focuses on quick iteration, so you can ideate, develop, and deploy in a week's time. In fact, this was one of the selling points for the internship at Meta: You should deploy to production in your first week.
- Comparison: Apple by comparison moves much more slowly, releasing new features on a bi-annual clock, largely revolving around WWDC and its hardware announcements. Google moves quickly as well but kills products as fast as they release them. This puts Meta roughly in the middle.
Pro #4. Open, integrated, searchable culture. Meta prided itself on openness, meaning you learn anything and everything about projects throughout the company. This also meant that fellow employees from other teams were open to discussion and collaboration.
- Certain internal tools — like one called
bunnylol— made internal tools and documentation much easier to traverse and search. For Meta, the browser is the home for all tooling. In fact, as an intern, I could even look up questions for full-time interviews!
- Impact: You have the opportunity to meet anyone you want and to learn about their work. You can also read about almost anything in the company. If you want to, the internal Workplace tool allows you to discuss a wide variety of issues as well.
- Comparison: At Tesla, it was relatively more difficult to meet other employees and chat about their experiences or work. Generally, employees were working 24/7 and too busy surviving. At Apple, it's effectively impossible to learn about other teams, unless you have a work reason to.
Pro #5. Onboarding is well structured. The onboarding process is one of the best structured, with a multi-day orientation and multiple well-organized workshops to get you onboarded for your specific team.
- In general, Meta provides a lot of technical support for its engineers. There are clearly defined avenues for any sort of problem — IT, AI infrastructure, PyTorch bugs, and more. Commonly-used internal tools have an "FYI" channel for announcements and Q&A forums.
- Impact: You start off at Meta on very strong footing, with a very thorough understanding of tools, benefits, and resources available to you. This also means you can make an impact within your first few weeks, if not the first week itself.
- Comparison: At Tesla AutoPilot, onboarding was fairly ad hoc for technical setup, such as setting up a repository and getting setup with the cluster. However, logistics were a breeze to handle, as the coordinator Shelby was extremely organized.
On a separate note, diversity in my intern class was impressive; of 7 interns on my team, 4 were women. From what I could tell at intern events, diversity in the internship program in general was quite strong. This was less true in Facebook Reality Labs among the full-timers.
In general, my impression at the time was that Meta appeared to provide for its employees fairly well. This is even excluding the perks that are so infamous now — free food, swag, perks, even laundry of all things.
Among the interns, our default assumption was that Meta would put its people first. As a part-time, this evolved over time, but especially compared to other companies I've worked at, I still believe this is mostly true. Meta pampers its employees for sure.
Codebase, communications, and tooling are the cons.
The cons for Meta center around company-wide policies: redundant teams, repurposing all employees as QA, cumbersome codebase and communications.
Con #1. Teams and employees are highly redundant, meaning that multiple teams with highly-similar missions are tackling the same problem.
- As an example, one Meta team is called "On-Device AI," and another team is called "AI On-Device". Yes, these are two completely separate teams.
- Impact: Multiple teams vie to provide the same technology for a product, and product impact then becomes a competition between highly-similar teams within the company.
- Comparison: Redundancy isn't necessarily endemic to all large companies. Tesla AutoPilot is the complete opposite, with just 15 vision scientists in one team for example.
Con #2. Forced to use latest versions of all internal tools and external products. This isn't limited to your work device; even your apps on personal devices will be forced onto the main branch. Testing beta versions of tools and products is called "dogfooding".
- Unfortunately, the idea of "move fast and break things" is still very much ingrained in the culture, so this means your internal tools and even public-facing apps are constantly breaking or down. The internal cluster manager, dubbed
fblearneris constantly a victim to this — nodes will unexplicably die, the service itself may mysteriously fail to schedule your jobs, or the official API may suddenly produce irrecoverable errors.
- Rather than invest in more QA or gatekeeping, the goal is to push updates quickly and have dogfooding employees expose issues. In other words, the QA responsibility has been distributed across all employees — another distraction, on top of communication overhead. It would've been more efficient to introduce more official QA channels, to insulate the global company population from testing every new version.
- Impact: At Meta, it's better to release a buggy feature now than a perfected feature later. This means your productivity is hindered by internal tools, and using external products absolutely sucks while you're an employee. As an example, Quest would constantly stay stuck at a black screen. The solution was always to hard reset the machine off of the latest main branch.
- Comparison: Apple thank goodness does not do the same. First, Apple has a high bar for what is deployed, and second, as an employee, you're free to use internal builds at your own discretion — this means you can continue to enjoy the high bar for public Apple releases. In fact, it's the other way at Apple: You can use internal builds only if it's needed for your job.
Con #3. The monorepo is cumbersome. Every operation is slow, and as a result of rebasing on main for this massive, mega, monorepo all the time, parts of the codebase are constantly evolving and breaking your code. Worse yet, running a simple PyTorch "hello world" program takes 15 minutes, because in effect, you're rebuilding PyTorch on every run.3
- As an example of how cumbersome this monorepo is: pulling from the main branch can take 5-10 minutes, if you do this daily. Miss a few days? It could take up to 30 minutes. In fact, cloning the monorepo takes many many hours to finish. Every day, your first command should be
The monorepo inherently agrees with the open culture, as you can browse any code you want to. The idea was furthermore to allow reuse of any code snippet. However, the internal build tool
bucksimply performs duties that an internal PyPi repository should have:
buckdefers the reponsibility of building binaries to each and every developer across the company. Furthermore, this building step happens every time you run code.
- Instead, an internal PyPi repository would place the responsibility of building binaries with the original package owner. Furthermore, the building step would only occur when the owner decides to release the code — rather than every time the code is updated.
Impact: Your productivity is further hindered by the codebase itself, and working outside of the codebase is your best shot for improved productivity.
- Comparison: From what I understand, Tesla does not employ a monorepo, as the vision team at Tesla AutoPilot operated on its own codebase. This more regular-sized repository was a huge relief and significant boon for productivity.
Con #4. Company moves quickly. This means that fast progress is rewarded, and quick turnarounds are prized. To reflect this, performance reviews encourage setting and meeting bi-annual goals, rather than multi-year goals.
- This means the company is fairly short-sighted, at least on the team level. It's tougher to plan for multi-year objectives, as you need checkpoints every half to be well-defined.
- Impact: Short-sightedness on the team means some risks are inaccessible. Granted, hackathons make some risky bets possible — as long as the bet takes 2-3 days to build a demo for.
- Comparison: Apple for example places fairly long-term bets and is willing to dig into its massive war chest. Performance reviews occur once a year, and emphasis is placed on quality rather than speed.
Con #5. Communications are overwhelming. The internal Workplace application is effectively another Facebook but specifically for internal discussions. It unfortunately is too similar to Facebook, with a posts and page-centric interface making search fairly difficult. Discussions are chaotic and unorganized, and communication overhead becomes significant.
- In effect, imagine that you most important information is fed to you news feed style, or even Tik Tok style. This communication channel is simultaneously overwhelming and also uninformative.
- Impact: This means it's all too easy to miss announcements for important events at the company or livestreams for talks. You largely rely on coworkers to help sift through the noise and identify important pieces of news throughout the company. This has a side effect of giving anyone the ability to make a post that potentially reaches the entire company, via an engagement-centric news feed ranking algorithm.
- Comparison: Apple utilizes Slack, which introduces a bit more silo'ing in a good way. You don't have a highly distracting news feed that throws random tidbits of information at you. Instead, you use Slack for its intended purpose: Just communication. You can discover new channels but that's at your own discretion.
In general, there were many systems setup that hinder your productivity. Certainly, the company moves fast, but I think this comes only at the cost of long work hours. In short, the company moves quickly despite its systems, not because of them.
Join for the workplace, not the work.
In short, with 20-20 hindsight, I now would say that Meta is worth joining for the culture and the people — not necessarily the work or learning how to work. The culture is ideal for new graduates looking to learn, as perks, conventions, and internal perspectives can funnel your excitement into production-facing impact.
However, tooling and policies are not optimized for your productivity in the long-term. Short-term hackathons certainly enable you to accomplish crazy goals, but much of the infrastructure hinders more than helps you. For example, the work-focused Facebook clone "Workplace" distracts you with all sorts of random company-wide announcements, when sometimes, you really need focus on just relevant information.
In short, I absolutely loved my time at Meta, but there are certainly challenges to a long-term career at the company — among them, the Facebook 15 and tooling that slows you down like molasses. If you do join, maximize your time there by participating in hackathons, meeting all sorts of people across the company, and learn about as many projects as you can.
Why I worked at Meta
Here's a brief addendum summarizing my own experiences landing at Meta.
In 2014, Meta — then known as Facebook — had the #1 internship program according to Glassdoor. However, that wasn't really the reason I interned at Facebook in 2015: I met the Facebook recruiter at CalHacks, applied to just two companies — Google and Facebook — and was rejected by Google. I was elated that I landed the Facebook internship though:
- In just my interviews, I met some really cool people — among my interviewers was Amjad Masad, who left Facebook shortly after to start Replit, an online IDE that now has 10 million users, 8 years later.
- The concept of free food, intern events, and swag maybe swayed me much more than it should have. As an undergraduate at the time, it was music to my ears.
- Result: That summer was incredibly fun, fairly chill, but not nearly as satisfying. I met lots of friends I still keep in touch with today. I learned Android development, which I have never used again.
In 2019, I returned for a second internship at Facebook but now as a PhD candidate and research intern, working with MobileVision in what was then Facebook Reality Labs.
- I was back for the fun and hopefully some more satisfaction in my work. That to me was the last flaw to fix, at a high level.
- Result: The summer was both fun and satisfying. So much so that we extended it into a multi-year part-time contract. Being there for the release of Meta Quest, then called Oculus Quest, was also thrilling. As a part-time, I also got to witness the release of Quest 2.
I loved my time and team at Meta, but when searching for a full-time job in 2022, I decided it was time to try something new. In particular, I was looking for a company that addressed the cons above. The pros above are the parts of Meta that I miss (and there are many).
By comparison, if an executive suggests an idea, you'll find that all leadership in your chain of command will immediately support that idea. ↩
It's worth noting that my stint at Facebook was spread out over the following three roles: 3 months in Summer 2015, 4 months in Summer 2019, 1.5 years from Fall 2019 to Spring 2021. Since then, Facebook was renamed to Meta, the Oculus brand was eliminated, and many of the company's original slogans have since been replaced. From what I understand from my friends, the company hasn't changed all that drastically, but it's worth noting that Meta may have evolved in some aspects. ↩
There were ways around this, such as caching your builds, or forcing the internal build tool
buckto reuse previously-built binaries. Even then, scripts took 5-10 minutes to run. This was horrendously slow for a single line change. I would suggest working outside of official repositories on a debug machine, then integrating when you have to. ↩
Got a question? Ask me on Twitter, at @lvinwan. Want more tips? Drop your email below, and I'll keep you in the loop.