Disclaimer: Everything here is just my personal opinion, and this text does not reflect any opinion of my employer. Also, feel free to disagree with me on anything here; again, this is just my personal opinion and reflects my experience.
Before I talk about my first year at Meta, I think it is worth first discussing how I arrived here. I haven’t applied for any job at Meta. Since around 2019, I have received many emails from recruiters about positions there. At the beginning of 2024, I aced the interviews, but I didn’t join the company. At that moment, your interview’s results were valid for 1 year, and I took the entire year to make my decision. Then, I decided to join in January 2025 and started in May 2025.
Since then, I’ve been working as a Senior software engineer with C++ in Infra, specifically on a service that is an ad cache and serves billions of requests daily.
Scale
Even though I had prior experience working at large companies that handled millions of requests daily, I was still impressed by the big volume. Now, I’m working with billions of requests daily and billions of monthly active users. Of course, with this scale, any mistake could be catastrophic. If the cache ads do not work properly, it could cost the company millions of dollars. The reason is pretty simple. This cache is used to avoid expensive ranking algorithms. Even when the cache works well, adding just one field can significantly impact network traffic and storage. This is a game-changer for sure.
Tools
There is an internal tool for almost everything I have used throughout my career, including version control, container systems, databases, storage systems, service discovery, A/B Tests, observability, etc. Since I joined before the AI boom, I needed to learn many of these tools on my own. There is good documentation, though, and many experts are available to help if you are in trouble or in a corner case. If you are an experienced engineer, it is not difficult to learn and compare with the tools you have already used.
People
There are many intelligent people working at Meta. I know, probably you are thinking about the horrible history in Teamblind and on the internet. Here is something difficult to explain for many software engineers: In a very big organization, it is very difficult to define what it is and what it is not. So, the experience is more individual and impacted by your team and organization than the entire company. In my experience, I have optimized C++ code to reduce CPU and memory usage and received excellent reviews on my pull requests from people who have been working there for 10+ years. Of course, as a mathematician, I cannot tell you that everyone is above average. There is no place where everybody is about average; it is mathematically impossible.
The work
At least for me, the work is very interesting. On the tech side, there are many problems to be solved. Many algorithms that you can optimize. Many bits and memory management in C++ that you can work hard to improve. Since the scale is big, everything that you optimized is amplified by the volume of requests. Also, there are many opportunities to speak with internal teams that use the cache and to help them add new features or optimize parameters for their specific use cases. Here again, this is very personal. If you talk to people who work in other places within the company, I do not have a clue whether the work is interesting. Of course, I know people around and know that their work is very interesting too, but I cannot speak for the entire company.
One thing that is very interesting to me is that everything that you do is very easy to test in production. The A/B test tools allow you to redirect a small percentage of traffic to your release, so you can quickly check if the effect you expect is actually what is happening. If not, you can easily stop the traffic, iterate on your idea again, or completely abandon it. I cannot emphasize how good it is. Imagine your team is working on a new feature or refactoring at your company, and you need to test it with a small percentage of your users. A very common case that we know how to resolve with feature flags. I’m not talking just about this. It is like you can have a small part of the company, just for you: data, servers, metrics, release, traffic, etc. For instance, when I worked at Shopify, I optimized many database queries by creating or updating indexes. The problem was that there was no way to create or update an index just for my traffic. Once I create a new index, it is reflected in the database for everybody. Even though I could control the traffic using the index on the reading path, everyone was affected on the write path. This is the power I’m talking about here. This is very easy to control at Meta. Of course, with great power came great responsibility. However, you have great granular control here. If you are an experienced engineer who understands A/B tests, it is very easy to iterate on your ideas without creating any big problems.
About this topic (A/B tests), Kent Back described it in more detail in this interview. If you haven’t had the chance to hear this, it is better to stop here and enjoy these 50 minutes of pure gold. I appreciate it a lot, I hope you do too. In many ways, one interesting thing Kent Back said on this podcast was about the A/B testing culture and how easy it is, but also how, during his time at the company, there were not a lot of unit tests in the codebase. He worked there between 2011 and 2018. I asked about this in my onboard. My question was: “Kent Beck described that in his years here, there was not a lot of unit test culture here, how is it now?” Even though the culture of A/B testing is still strong in the company, the unit testing culture has changed. Now, in my experience, there are many tests. And it is hard to merge a pull request without them.
Another interesting thing for me is the freedom to choose what I work on. In 1 year there, nobody told me what to do. I haven’t received a task to work on. What I received was one input similar to this: “You worked on this C++ service in the infrastructure that provides cache for ads; go find a spot to optimize and improve it. The teams that are using it are x, y, and z. Speak with them and figure out what they need.” That is it. For me, this is great. I love to work on difficult and ambiguous problems. This freedom gives me the opportunity to identify areas for optimization, improve algorithms, architecture, adjust parameters, and add new features while working on other parts of the system. Identified and implemented new features. Also work with other teams, lead other engineers, and influence others’ work. Again, with great power came great responsibility. You can do whatever you want, but you are responsible for the outcome. So, this will come in the table during the performance review.
Furthermore, sitting on the other side of the table as an interviewer for system design, behaviour, and coding interviews at big tech is really nice. I had the opportunity to speak with many talented engineers and discuss different ideas and angles of a problem.
Advice for Early-Career Engineers: Not One Size Fits All
In my opinion, not just Meta, but big companies in general, are difficult places to start your career. My point is, everything is already there, and a non-experienced engineer does not know many external tools, how they compare to internal tools, or how to make decisions. A small company allows you to fail more frequently and with fewer consequences. In a small company, you probably learn many valuable things for your career, such as: doing a database migration by yourself, setting up servers in a local environment and in the cloud, making many choices about design, and, even more importantly, you have time to fail and to learn. In a big company, any of these is far from true, or at least just partially. You are handling a high volume of requests and big teams, so you cannot see your impact as a young engineer. Also, sometimes you do not have time to learn. I’m not saying that it is impossible to be successful, I’m describing the process of learning each piece of the entire process of software development: infra, coding, architecture, how to make decisions, trade-offs, speaking with customers, creating bugs, fixing bugs, and an infinite list here that I can stay the entire day working. But I think you got the idea.
As I wrote at the beginning of this text, feel free to disagree with me. I’m very interested to learn from you if you have a different perspective here. Please let me know.
Hands-on with GenAI at Scale
Of course, I cannot end this text without speaking about AI. I was very lucky to join when I did. Almost all the code assistants, models, and AI tools became useful at this moment. Meta provided all the models and code assistant for you to use. Internally and externally, tools were available. So, I could try every code assistant, almost every model. Write a pull request using them, write tests, compare different models and tools with the same input in the same codebase. Try them in a small C++ codebase with 100K lines of code, in a C++ codebase with 3M, and in a C++ codebase with 30M lines of code. Write agents and skills, and try them in different models and tools to compare and see which one is more effective for the task I was working on. This is a very valuable time and set of skills that help me improve my career a lot in the AI era.
Conclusion & Impact
To be honest, there is no conclusion here. This was just a reflection of my first year working at Meta. During this time, I was able to save around $ 5M in operational costs. Worked on many interesting problems, but also passed through very difficult times, losing co-workers and colleagues in small and big lay-offs.