Lession Learned After My First Half at Meta

It’s been 8 months since I joined Meta with 7 full months in the team after bootcamp. I’ve made many notes during this time that I’d like to share with public.

General Takeaways

1. Engineers take full ownership of their projects. Because at Meta tasks rarely come from above; instead engineers find problems and decide how to solve them. This differs from traditional tech companies where engineers are often executors of tasks.
2. People proactively identify problems and propose solutions. And I believe this is a big driver of innovation at companies like Meta.
3. People actively help each other. Because we need to help our colleagues (especially less experienced ones) achieve their goals too. Being useful is not easy, but very valuable.
4. Things change fast around here. Yesterday your project was a priority, today it’s not. Sometimes it’s just not the right time for the team or org, and that’s okay. So, learn to understand what matters most, deliver those parts, and improve if needed.
5. A temporary solution often becomes permanent. Because priorities change, people leave. This doesn’t mean your code must be perfect, but it shouldn’t be hacky either.
6. No one has all the answers.

Things I could have done better

1. Reserving more time for identifying and fixing problems or making suggestions.
2. Working on a few smaller projects rather than one large, especially in the first half. Small projects are easier to complete, and even if something goes wrong, there will still be something to show at performance review.
3. Maintaining stakeholder confidence. At some point key stakeholders started to worry; I could have fixed this by proactively reporting progress and addressing their concerns.

What I Want to Focus On Next Half

1. Improving my productivity. I want to learn to consistently finish my core tasks within 80% of my time and use the rest to help others, and improve our processes.
2. Increase the quality of my code - fewer comments and revisions, standard setting code.
3. More in-depth code reviews.
4. Spotting potential roadblocks early and minimizing the risks in my projects.
5. Explaining systems I work with in detail and communicate technical information better.
6. Deeper understanding of my org’s goals and strategy and how my team fits into it.

In general, it was a good half. I met lots of interesting people, worked on scope I’ve never worked before and I definetly became a better engineer.