Meta’s Post

Kinda interesting that the peak of Meta engineers is an E-9, and “staff” engineer is E-6. Same with the enlisted military ranks. Once you hit E-6 (Staff Sergeant in the USMC) you are eligible for retirement. E-9 (Sergeant Major or Master Gunnery Sergeant) is the highest enlisted rank, just as it is the highest level of engineer at Meta. I wonder if that was purpose-driven or coincidental?

Many engineers struggle getting to senior because they run away from bugs. I repeatedly saw this at Meta first-hand with something I call “Bug Hot Potato”. How it starts is one engineer gets assigned a bug. They quickly make up an excuse that the bug is out of their domain and assigns it to another engineer. However, this engineer has the same selfish mentality so they counter with an excuse of their own and assign it back to the original engineer. This cycle repeats several times while the bug isn't getting fixed, end-users suffer, and both these E4 engineers (rightfully) aren't getting promoted to E5. Being a true senior engineer is all about ownership. You can't only do the glamorous feature work; you also need to get your hands dirty. Every system inevitably has bugs. If you aren't willing to play your part to squash them, you simply don't deserve to be a senior engineer. To learn more about why you must become a debugging expert to be a great engineer and how to do it, watch our video here: https://lnkd.in/g4GXfJGv #techcareergrowth #debugging #softwareengineering #seniorengineer #techlead #growthtips

The average Meta engineer pushes ~125 commits per half. Back at Meta, I had a rockstar mentee who went from junior [E3] to senior [E5] in just 2 years and pushed a whopping ~500 commits per half. This engineer was the fastest growing talent I have ever mentored, and writing 4x more code than average was a big reason why they got promoted so quickly. So how did they do it? When most people look at this insane number, they immediately assume that quality took a hit and the commits were garbage. However, this was actually the complete opposite for this engineer. This engineer arguably had the highest code quality of any engineer in our 100+ person organization. Every pull request of theirs was a delight to review. Every diff they had was atomic, focused, and reasonably sized. They were diligent about proactively discussing their strategy with senior engineers beforehand, so their code was always clean, optimal, and readable. The big thing that really made engineers feel comfortable accepting their code though was their test plans. This engineer was always so incredibly thorough, testing every possible case and attaching the proof. This is why this engineer got their pull requests approved on the very first try 95%+ of the time. When you're pulling in those numbers, you really are only limited by how fast you can type. When you write some of the best code in the world, your career growth becomes unstoppable. To learn exactly what I taught this engineer to make them so technically strong, take my new 3.5 hour code quality course here: https://lnkd.in/gzkq36Sv #techcareergrowth #seniorengineer #codequality #growthtips #promotion #meta #techlead

😍 Now that’s the Valentine’s gift I needed! 🎉 After earning the Google Advanced Data Analytics certificate, I’m happy to share that I’ve successfully obtained the Meta Backend Professional certificate! Learning top-class backend engineering practices from the Meta team has been invaluable. And diving back into hands-on development remains an absolute pleasure. 🦾 I firmly believe that frequently embracing broader challenges is key to being a strong product development partner and staying relevant in this dynamic field. 🚀 Strong, versatile problem-solving + More empathy for other teams = Better products What do you think? #SoftwareEngineering #WebDevelopment #Meta #CareerDevelopment

Blameless postmortem reviews are an underrated part of Meta engineering culture. They don't blame engineers personally for breaking things. This allows postmortem conversations to revolve around the systems in place and how to improve them, which results in: 1. Less breakages over time - Everyone focuses retrospective energy on system improvements 2. Faster resolution - People are shameless about owning and escalating breakages 3. Better team health - people don’t beat themselves up over unavoidable breakages Relying on fear to prevent breakage is much less reliable than automated system level tactics (e.g. test coverage, push blocking, static analysis tooling). I've always enjoyed this aspect of Meta's engineering culture. Does your company practice blameless postmortem reviews?

Today I had the chance to experience a day in the life of an Engineering Manager at Meta! 🚀 🚀 I would like to thank my host Greg Vannoni for this amazing experience and for guiding us through this enriching day. We went over the Software Architecture of Meta's system, met with other Software Engineers and Tech Leads, and had the opportunity to ask questions and get valuable insight from them. Here is a brief glimpse of what I learned 💡: - Tech stack of Meta and what new technologies they invest in... (PHP, Hack, Python, SQL, VR) - How new products are built at Meta - from design/strategy to execution and scaling. - Understanding of team dynamics and various career paths within the company. - Mindset/Attitude of a Tech Lead and what their typical day looks like. - An overview of the interview process at Meta and how to get well-versed in technical interviews. Lastly, I would like to credit Nimroz Ortiz, as part of the UA JSP Team for conducting and organizing this program!

What does it look like to be a senior+ / staff software engineer? Spoiler: it’s not just years of experience. 👇 Staff engineers are the engineers you hear about that are L6 level and above at Meta or Netflix that are making $400,000+. 😅🤯 Why don’t we all just become staff engineers then? Haha, well if it was just as easy as being a software engineer for 8-15 years - we’d probably all be that level - but it’s not that easy. It takes extreme focus, mentoring, training, and real drive to continue leveling up all the way to a staff level. Alright… So what does a staff engineer look like? Glad you asked. We’ll explore this together in this week’s newsletter. 🚀 https://lnkd.in/eeGPUUpv P.S. I’ve also asked 4 of my favorite staff+ engineers to weigh in with their opinions. Thanks Irina Stanescu, James Willett, Daniel Moka, and Ryan Peterman for your review and contributions on this one! You won’t want to miss this. 🙋♂️🙋♀️

One problem tho. Code explains when, what, where and how but it never explains why (yes, even with comments). Optimized code isn't readable and readable code is not optimal. I do agree with relationships because the standard senior software engineer ego says "read the documentation" which is in v0.0.1 while the product goes to v3.14.15. Over the period of time, I am seeing less of that and that's a plus. I agree with the final statement as well. I genuinely feel that documentation and proper unit tests help the code soar. It should be built into the development process. Documentation is like legislation, code is executive and unit tests are like judiciary. It should be by the people, for the people and to the people.