I'm a new MLE at Meta, so I'm in bootcamp. I'm trying to go for a team that’s super in-depth with regards to ML and neural architectures vs. a team that would give me more breadth. How can I find such a team and what questions can I ask to identify it?

How to find a team with specialized technical depth?

I'm a new engineer at Meta, and my goal is to find a team with a real product future. Because of that, I'm wondering if there's ways to evaluate if a certain project is going to pick up traction. How can I figure out during the team selection process if a team is doing its due diligence on gathering context and proving out business value before building features or if its just building them for the sake of building them?

I'm new to Meta, so I'm currently in team selection. My goal is to choose a team that maintains more critical pieces and are more stable with respect to layoffs/reorganizations vs. (slightly) more moonshotty teams with higher risk/reward. An example of the latter would be a team working on maintaining an ads pipeline while one for the former would be a team experimenting with new UI features.

How can I find a team that meets that bill, and what questions can I ask to help identify this?

How can I find a team that's more on the stable side?

Entry-Level Software Engineer [E3] at Meta

I've been on my current team for around a half, working primarily on the back-end. Unfortunately, I discovered *after* I joined the team that Android work is very interesting to me, so in order to pursue this, I would need to switch teams. There is actually a team fairly close to mine in my org where there's compelling Android work.

Right now, I'm heads down on a big project, so my immediate instinct is to wait until that's done to bring up this conversation with my manager, who I have a very good relationship with. Is this the right thing to do or should I have this conversation sooner rather than later?

What's the best way to approach a team switching conversation with my manager?

I'm considering a team switch, but I'm wary of the effect that it will have on my E3 -> E4 promotion timeline, which I know we have to do within 2 years. I've been at Meta for around a half - Does the timing for a switch work out here and what other factors should I consider?

How should I factor team switching into the E3 -> E4 promotion timeline?

I've been on ~5 teams during my ~4 years at Meta, and I'm wondering if I need a mindset shift when it comes to choosing a team and staying there. Is it more on Meta that teams don't fit or should I make a bigger effort to stay on teams longer and establish myself there? I'm also looking to get to E6 someday, so the team switching makes things tricky.

I've been on a lot of teams and wondering if I'm thinking about teams correctly.

I joined Meta very recently, so I'm in bootcamp. However, the company just announced a mass hiring freeze, so teams aren't taking in bootcampers at all effectively (there are very few exceptions). It's not clear when this freeze will end. Teams are still giving bootcampers tasks as they understand that we're pretty much "free" labor.

This is such a weird situation, and I feel like I'm spinning my wheels. I like Meta as a company a lot, but I'm unsure how to make the best of this situation. Any advice?

Some additional questions:
1. What do you look for in the team?
2. Do you tell your manager?

What's the best way to think about a team switch?

[Part 1] Meta Intern Success Series - Internship Program Overview

- The Meta SWE internship program is very legit. It resembles the experience of working as a full-time Meta engineer as closely as possible, complete with calibrations and a formal manager.
- The program is also hard. The pass rates that got mentioned around the company were 50 to 75%. It's one of the harder internships to get a return offer from as the goal is to perform at E3 MA. If this is your 1st internship or you have only interned at companies weaker than Meta prior, the high bar can be overwhelming.
- However, the reward is tremendous. Meta is an incredible company to work at and amazing as a career starter. Meta is also one of the highest paying companies for the entry-level band (E3), and the signing bonus for return offer interns is sky-high (60k to 100k).
- 4 outcomes for Meta SWE interns:
  - No offer: As mentioned before, many interns will unfortunately be here. The numbers after this correspond to the percentage of the "surviving" pool.
  - MA (70%): "Meets All Expectations", which is a regular return offer. The vast majority of successful interns get this. 
  - EE (25%): "Exceeds Expectations", which is given to very strong interns.
  - Rockstar (5%): For interns that completely crush it and are very close to functioning as a mid-level engineer (E4).
- Internship schedule (assuming standard 12 week length):
  - Weeks 1-3: Onboarding
  - Weeks 5-6: Mid-cycle review
  - Weeks 10-11: Final calibrations (return offer is decided here)
  - Weeks 11-12: Relax and have fun. Only your performance from Weeks 1 - 10 is counted towards your final review
- As an intern, you formally report to an intern manager (IM), which is shown on the org chart. On top of the IM, you will have 1-3 other peers who will review your diffs and help you. During calibrations, feedback from your IM and these peers will determine your final rating.

For more expert internship advice: [Full SWE Intern Advice Playlist](https://www.jointaro.com/tagname/Software%20Engineering%20Intern/)

Hi,

With tons of layoffs already happening and rumors about impending layoffs, is there something one can do to protect themselves? Logically, performing above expectations and being a critical part of the team would make sense. However, recently looking at LinkedIn and other career news, seems like no one can be sure that they’re safe. So, do you have any tips on how to approach this? Does it make sense to stay put within a team where you have great relationship with your manager and skip etc or find a new company to get ahead of this risk? Thanks!

Are layoffs random or can I do something to prevent getting laid off?

The product I support breaks often and I've been the go to individual to resolve internal fires. Addressing them takes time away from tackling more impactful tasks, and it's beginning to affect my output. My team doesn't find such infra issues as priorities so fixing them gets little visibility and I'm concerned this will have a negative impact on my PSC. How do I balance this properly?

How do I balance addressing fires and working on p0's?

One thing I'd love to ask about is effective pressure management. Coming from small cos to a big company like Meta; despite startups having a reputation for chaos, I personally find there's  a larger number of failure modes at big companies - a review taking too long, lack of good logging, misalignment, which can lead to either a project being derailed or just flat out failing. I've personally gotten better myself at pressure management (trial by fire); but would love to have thoughts from folks on how they work on this skill!

How does one effectively handle pressure especially when the stakes are high?

I work overtime a lot, and it's pretty stressful. I'm also worried that amidst all this effort working for Meta, I'll lose track of who I am overall and what I can do for other companies. What can I do to strike a better balance here?

How can I have less burnout and better work-life balance?

I'm in bootcamp right now, and many teams are telling me that they have all 3 of these things. My bootcamp mentor says that's not really feasible - There are trade-offs. Am I gullible if I believe these teams at face value?

Is it possible for a team to have great WLB, availability of scope, and impact?

Session #5 - Mentoring Junior SWEs [E3] to Senior [E5] In Just 2.5 Years At Meta

For the key points, you can find them in the slides (linked below), so the summary will be framed more as action items.

**If You're Pushing For Senior/Are Senior+ Already**
- Mentorship is a core part of healthy senior engineer behavior, so invest in it if you aren't already.
- Now you need to find good mentees. *The main thing to look for is their coachability, which largely depends on how smoothly they process feedback*.
- How can you tell if someone is coachable?
  - They go the extra mile making sure their code is clean.
  - They respond to code review comments (particularly yours) with enthusiasm and speed. They're hungry to learn more and go deeper into feedback on their code.
  - They go out of their way to help others as opposed to many people who just help reactively (or not at all).
  - They have a good cadence with you when you spend time with them (e.g. it's easy to have a fun conversation with them over lunch).

**If You're Mentoring Other Engineers**
- *If the extent of your mentorship is that you answer a lot of your mentee's question, you're not truly a mentor.*
  - True mentorship is being proactive and having a clear vision for what your mentee will become. Create a growth plan for them to get to the next level and outline deltas to make it clear.
- If you haven't already make sure that your manager and the manager of your mentee (if they're on a separate team) are aware of your involvement. This is vital for getting proper credit and not growing them incorrectly.
- Your mentality should be that you serve your mentee, not the other way around.
- To build a ton of trust quickly, tell your mentee this: *"No matter what happens, I'll do whatever extra work is necessary to make sure that you're okay."* You are majorly responsible for your mentee's well-being.
- Always call out when your mentee does good work, even if it's something small like a well-written commit. Do it in your 1:1 where it has more gravity. Showing appreciation as a trust/morale building technique is *severely* underutilized.

**If You're A Mentee Looking For A Mentor**
- Show strong gratitude for code review comments on your commits. Don't just give them a thumbs up or worse, silently make the change. For deeper feedback (often times coming from senior engineers who you want to mentor you), go the extra mile giving thanks.
- Put yourself out there: Don't be a hermit. Go to team lunch, offsites, coworking - Become known as a friendly face within your team. Strike up conversations with engineers more senior than you just to get to know them.
- Strive to write good code. It can scary as a junior engineer in particular and default to churning out tickets as fast as possible with bare minimum quality; avoid that instinct and try to spend an extra 30 minutes to 1 hour trying to build things out properly (and then talk about your thought process on your pull requests). You want to show senior+ engineers that your hunger to be an actually good software engineer instead of a commodity coder is there.

Related Resources:
- [Presentation Slides](https://docs.google.com/presentation/d/12OelIHF08oBZwe-TzVlz8fqp4WiOTem_e9KsGe7X8XA/edit?usp=sharing)
- [Meta E4 To E5 Growth Plan (Pretty Applicable To Any Large Company)](https://firebasestorage.googleapis.com/v0/b/tech-career-growth.appspot.com/o/articles%2Fmeta_e4_to_e5_growth_plan.pdf?alt=media&token=e13d88fd-9356-4c20-a229-cf0cad78a9af)
- [How To Get The Most Out Of Mentorship](https://link.jointaro.com/sobZVTxh3nvUFTnb9)

I'm trying to get promoted to E5, and my progress so far has been decent. I'm doing well on all 4 axes, but I currently have a gap on the people axis (it's not Exceeds Expectations yet). I know that people/direction are very important for E5s, so I really want to get better here. I do things like give tech talks and mentor some rotational engineers, but it doesn't seem to be enough for an E5-level people contribution. What can I do to shore up this aspect of my performance?

How can I strengthen my people axis to push for E5?

I am a little worried about the potential of layoffs at Meta. I am not sure if I will get a needs support. I have been working on doing a design doc for the past month, and my manager has generally been very positive towards me. But I feel like I might get a NS due to my not submitting as many diffs and accepting as many diffs. I joined my team less than three months ago, and still technically ramping up. I would be sad if I got a NS or a pip, but it wouldn't destroy me.I guess my question would be how can I best buffer myself during these next few months, and how can I avoid situations like this in the future? What should I do if I do get put on PIP/NS?

Hi,

I got promoted last half to IC5 and have been leading impactful work streams within our team. I am enjoying my new role and work. In our last 1:1, my manager asked if I wanted to lead a very high priority org level initiative that has impact across multiple teams and suggested this could be a potential staff level project. While this is a great and unique opportunity for promotion, I am also nervous about taking this up because:

1. I am scared this might be more challenging than I am ready for and failing this would put our Org's key launches in risk.
2. I just got promoted and didn't want to actively pursue promotion as I wanted some time to settle in and become a solid IC5 first.

Wanted to get your thoughts on this and what you would do in my position? And if I say no, should I be worried about my manager passing me up for potential opportunities in the future? Thanks!

Is there something as growing too quickly?

Session #3 - Becoming A Tech Lead Again In Just 1 Month After Joining Robinhood From Meta

[Here's the presentation slides](https://docs.google.com/presentation/d/1j5Lj_IGrtCRUpobj0f8k9egrBAej9apzikGp_V_iTCk/edit?usp=sharing).

- The expectations for an L5+ (senior+ at a FAANG or similar company) engineer are high. You won't get 12 months or even 6 months to fully onboard: You need to start having huge impact and showing your depth within 1-2 months.
- After starting, Alex told his managers that he was happy to offload any responsibilities they had so they could focus on higher-level issues and expand their scope. As a tech lead, you need to view your manager as a partner, not just a boss. "Treat me as a resource."
- The project that Alex was first put on was to make settings more server-driven within Robinhood
- The most impactful thing to do was to add color to the project:
  - Stabilize and then drive the workstream meetings
  - Create a thorough tech spec
  - Align XFN to figure out how to treat each settings section properly, especially in places where there were inconsistencies
- How Alex added his depth:
  - Wrote a 5+ page Android spec for his portion
  - Manually audited all of settings and compiled a detailed spreadsheet of inconsistencies to fully capture impact
  - Thorough data analysis spec, doing complicated SQL queries himself
  - Mentored an L4 engineer in the process, giving them L5 scope
- Recap (how you can incorporate the learnings here into your work):
  - Earn trust quickly: Be "aggressively" nice. Find out how you can add value to others and be very sincere and upfront about it.
  - Fill in the gaps: View your projects holistically and figure out what's missing to move the project forward. This will often times be "less flashy" non-coding work.
  - Bring people together: Don't be paralyzed by your lack of knowledge. Especially if you're new to a company, you will be clueless in a lot of scenarios. If you're in a cutting edge company like Meta/Robinhood, there will be a smart person(s) somewhere out there with the answer: You just need to bring them together in a healthy way.
  - Go deep: There's far more to a senior engineer than their ability to code. If you're a new L5+ engineer, even the tenured L3/L4s at the company will code circles around you in the beginning. If you're an L5+ engineer, figure out what behaviors and fundamentals you have that more junior engineers don't and show those as much as you can. This generally involves shipping software in a much more holistic way.

Session #7 - Building XFN Alignment Across Multiple Orgs (w/ Staff Engineer Cat Chen)

[Cat Chen](https://catchen.me/) talked about his success building alignment across multiple orgs. 

Cat was working at Facebook as a Staff Engineer on the growth team. His charter to get the Android apps on app stores beyond the Play Store. (There were 10+ non-Google stores where Android apps get downloaded with some level of traffic.

Getting an app listed on a 3rd-party platform is simple – sign up as a developer on that platform; upload the Android app for review; wait for approval and launch it. Just as simple as publishing to Google Play.

**BUT it's not that simple at a company like Facebook.** Facebook lawyers wouldn’t allow Cat to accept the Terms of Service on behalf of Facebook the company. Cat didn’t have the privilege to bind Facebook into this contract and even if he did, the lawyers would certainly advise against that.

Instead of simply handing this problem to another person or org, Cat met with a director-level lawyer. Given he was on a different time zone, and in a different job function altogether, this took some legwork. The director explained the risk profile (Facebook could have unlimited downside by blindly accepting an agreement). Eventually Cat discovered a workable solution by using a contracting company to sign the legal agreement, which limits the damages that Facebook may face.

Impact of this work: 
- Successful launch of the existing Android apps
- Ability to launch other apps in the future
- Deep and positive relationship with the legal team, and Cat owned that relationship (which made him indispensable)
- **Almost zero lines of code written!**

[Connect with Cat](https://www.linkedin.com/in/catchen/)

For more resources on how to communicate, build alignment, and operate as a Staff Engineer:
- ["How do I sell the vision behind a large, org-level project?"](https://link.jointaro.com/NGCrB2ifkkpDaDe69)
- ["What's the Difference Between A Senior And Staff Engineer?"](https://link.jointaro.com/BEM2RAjPFe8Pv7826)
- [Guide to Effective Communication](https://link.jointaro.com/mP3WEd4zt5ecnupX6)

My team got split up recently, and I got put onto a sub-team I'm less familiar with (I have more context and experience with the other sub-teams formed in this re-org). Any thoughts on how I can make a case to be on one of the teams I feel like is a better fit for me, and if I'm not able to do that, how do I make the most of this new situation?

Ended up on a less preferred team after a small re-org - How to navigate this?

Like a lot of E5s, I'm working on a piece of my team's overall project roadmap, which is set by an E6 TL. The piece I own is less technically complex than other parts, but it is quite XFN heavy (great for people/direction contribution). I was wondering if this is still enough to get to E6 or do I need the higher technical complexity as well?

Is it okay to have less technical complexity when growing to staff?

I'm a product generalist at Meta and I've been offered to opportunity to ramp up to Android and possibly specialize in Android dev. What are the considerations I should be thinking about when 'switching tracks' like this. E.g. will this reset my progress towards promotion as a prodgen or will it enhance my skillset for future opportunities?

I've been working mostly as a Backend Engineer. 
I'm growing interest in ML. I have a few questions:

- Will my SWE knowledge help me, or will it complement with ML? Or being MLE is a totally different/separate field?
- Is there overlapping between ML and SW?
- Would be recommended to do a Masters or Practice/Courses?

Software Engineer interested in ML - How would a transition work?

Performance Review Ratings Example: Meta & Google

- Meta:
  - Meets Some Expectations (MS)
  - Meets Most Expectations (MM)
  - Meets All Expectations (MA): Need this or above to be doing okay.
  - Exceeds Expectations (EE)
  - Greatly Exceeds Expectations (GE)
  - Redefines Expectations (RE)
- Google:
  - Needs Improvement (NI)
  - Consistently Meets Expectations (CME): Need this or above to be doing okay.
  - Exceeds Expectations (EE)
  - Strongly Exceeds Expectations (SEE)
  - Superb
- Other companies will use a 1 to 5 system which roughly maps to the above, Google in particular

I joined my team in June this year right after bootcamp. When I joined this team, we set the goals for the half, and then got reorg-ed to a different domain (think ML for ads vs ML for recommendations).

Our models had only shown limited success in the previous domain before the reorg, we spent around 2 months (July and August) just building new versions of these models for the new domain. 

It's October already, the model hasn't shown any significant success in any of our projects with XFN. We are getting closer and closer as we understand the problems better. However with code freeze in November, December - it is unlikely it will reach production or even online experiments by then.

Does that mean I would have "no impact" at my first PSC? This would be the case for all of my teammates which seems bonkers.

I thought about writing a long note with all of the progress we've made in understanding the problem (which will result in a model that's cheaper than the current one and easier to understand), what are some results we have seen already, and hypothesis on where to go next. 

Still to be honest I'm scared the results I got won't be good enough to get to production by PSC-time, and thus I'll be marked as no impact. In retrospective I should have studied the problem more when I joined but I was so new to Meta. 

How can I mitigate this? Looking for a side-project now I can fully own (as E5, I don't think attaching myself to a teammate's project is good enough) is unlikely to get any results with the current model we have.

For example, knowing that we got EE- in people axis meaning that it's on lower end of EE.

In PSC, will we know ratings for each axis?

The setup on my team is pretty standard: There's an E6 tech lead that has broken up a big project into multiple pieces, and I own one of those pieces (and the rest of the pieces are owned by other E5s). I'm leading a couple engineers (<5), and I think they're E3/E4.

Zooming out, this seems like decent E5 scope, but I'm sure there's some gaps to turn it into E6 scope. The tricky part is that my org is pretty XFN heavy, so it's hard to get things added to the roadmap, and with the hiring freeze, it's hard to get more engineers onto my team to lead.

All that being said, what are some ways I can find staff scope in this situation?

I joined Meta as an E4. I'm coming from a company which doesn’t have as much structure around performance review. 

I feel good about my coding ability and project impact, but I’m not entirely sure what are the ways to think about the people dimension as someone relatively new.

I just joined Meta as an E4 engineer. What are the ways I can succeed in the people axis?

I joined Meta as an E5, and now I'm looking to get to E6. I want to stay on the IC track, so my goal is concretely to get to E6 and stay there, not become an M1. I know that leadership is crucial for EMs, but is it the same for staff engineers at Meta? I'm currently leading <5 engineers who are probably E3/E4, and I'm wondering if I need to expand my leadership scope there.

Is the amount of engineers you lead relevant to get to E6?

Meta is my first large tech company, so I don't know much about the other big players (Amazon, Google, etc). I was curious as to what makes Meta unique compared to other giant tech companies, so I could get a better understanding of the industry overall.

How does Meta's culture differ from that of other Big Tech companies?

As a self-taught developer, I don't have a systematic knowledge base as those who were trained by college degrees or bootcamps. How can I built up a knowledge system as a Software Engineer over work?

For example, after I get a bird-eye understand of the industry, I can fit the pieces that I'm dealing with at work into this system and build up my knowledge with a more systematical way. Can I get some suggestions/approaches for this, or get to know your experience building your own knowledge system?

For self-taught developers - How to build my own knowledge system during work?

Hey all, as you know there’s high probability of cost cutting and lay offs by increasing bar at meta.
I joined the company 2 months ago and plan to travel to another country(12 hour time difference) and work remotely for about 20 days! (Whole month of December)

In lieu of new information, should I be trying to stay in the same time zone and be seen around meetings(my team is fully remote)? It will probably also help my productivity.

I’ve already booked tickets and I’m not sure what to do.

I'm relatively new to the company, so I would love to understand more about this. Here's more specific questions I had:
1. How is the first one evaluated? Is it different because you're new?
2. Is it evaluated from the day you joined the company or the day you joined a team out of bootcamp?
3. How is delayed impact factored in? Since I'm new, I'll have some small wins by PSC time but am not likely to have big ones as they're waiting to launch/realize impact.

5 Offers w/ FAANG Companies As A New Grad: Details + Lessons

In 2014, Rahul graduated from Stanford with a BS and MS in Computer Science. He received new grad Software Engineer offers from 5 companies: 
1. Facebook
2. Twitter
3. Microsoft
4. Google
5. Square

This video outlines the exact details of the offers, and models out the increase (or decrease) in value of those offers 8 years later, in 2022. The total compensation of the offers range from $174K/year to $262K/year, and those numbers go a lot higher if you factor in stock appreciation.

If you want to better understand how compensation works in top tech companies, first watch [this video](https://link.jointaro.com/819tdsqwJj4VnaEC6).

I recently got moved to a new manager, and I've been having some trouble building back up the more fluid and quite positive relationship I had with my prior manager. In particular, I'm trying to get more signal into my feedback and how I can improve. When I go over this kind of content with my new manager, they'll say something more quick and high-level like "That makes sense", but they won't give me something more specific and concrete. How can I go deeper with these kinds of conversations while keeping our relationship healthy? I want to make sure I respect their boundaries.

How can I get my manager to dig more into the "awkward" stuff in 1 on 1s?

I'm looking to get promoted to E4 in the next cycle, but I'm worried as my impact contribution isn't very clear. I've done a lot of work, but due to churn within my org (which includes a recent re-org), a good amount of my code isn't truly in production yet. I've documented my work in Quips and tasks to show that I did it, but I'm wondering if a lack of shipped impact will hold back my PSC.

How does a lack of impact due to org churn affect impact axis in PSC?

I'm pushing for the E4 promotion in the next PSC cycle, and I've gotten some feedback that I could shore up my people axis contribution. Given that, I was wondering how important people is for this promo and how I can get points on this axis as a growing E3. People axis contribution seems harder given the hiring freezes (e.g. it's harder to be a bootcamp mentor) and the fact that the main intern season is over.

How important is people axis for E3 -> E4 promo?

As we all know, Big Tech hiring is drastically slowing down, which includes Meta. However, this means people axis sources like interviewing and being a bootcamp mentor become harder to get.

I'm also fairly new to the company, so it's harder for me to do things like mentor and onboard others for people axis credit.

All that being said, how does people axis work for me and how can I get a good rating there?

How does people axis work with a hiring freeze and being new?

I'm a new E4, so I obviously have promotion on my mind. I have a good amount of experience coming into Meta (~5 YOE), so I want to move more aggressively with this promotion. If I work 40-45 hours per work with very good work ethic, what's a reasonable target to hit for the E5 promo?

What's a good trajectory to go from E4 to E5?

I work on a pretty planning intensive team. Sometimes we'll spend several weeks planning out our next project, but since planning takes so long, not much time is left for execution after we're done planning. This leads to us having to sprint to deliver, and after we go that, we go back to planning and the cycle starts all over again. This is all pretty hectic, so I was wondering if anybody had any ideas on how to improve this process?

How to deal with weird development cycles?

When I started in bootcamp, my bootcamp mentor assigned me a couple tasks to do. How important are these tasks? Do I need to get them done with a certain speed and quality? Are you judged on them in any way?

How much do the initial tasks you get in bootcamp matter?

I'm a new E3, and I know that there's the up-or-out promotion timeline to E4. I was wondering how much of a challenge this level-up generally is and what are the main things to keep in mind with this promo?

In my effort to grow my scope as an engineer (and get promoted), I’ve constantly hit the same weak spot - not “working through others” enough.

I’m always happy to identify problems and solve them, but as a relatively inexperienced engineer compared to the rest of my team, I feel uncomfortable pushing work onto others, as I often am not sure my ideas will even be fruitful.

This issue is exacerbated by the fact that my team skews very senior and I don’t feel comfortable/qualified working through them.

How should I approach this problem?

I'm a senior engineer on a team that's mostly E5+. How can I work through others?

I just started at Meta in the business engineering org (formerly solutions eng). We have a lot of XFN work with sales and SWE teams, so lots of opportunity to coordinate projects and be customer-focused. I was a SWE at my past company but I'm hoping to eventually transition to PM as I believe it is better for upward mobility within a company?

How can an engineer transition to product manager and do you think there is higher potential to reach VP level at PM?

It seems to me that Meta has SWEs drive a lot of product decisions but I've always heard Product is better for high growth and the famous examples of Sundar and Satya

Is Meta more engineering driven or product driven and how does this affect internal mobility for EM vs PM?

I was curious if anyone had tips on writing a decent one page resume - especially in how to pick apart what's most "important" from my previous work experiences and fit it into one page.

Hi guys, I’ve recently joined a new team and learning a new coding language. The first task given to me by my team was a refactoring task to ramp up. They said to take your time as there’s no rush to finish it right now. However, it seems to be a very complicated refactor as there’s multiple lambda functions each referencing variables from all over the place. How do I communicate this with the team and not look incompetent?

Struggling with an underscoped refactoring task - What to do?

I have worked at Meta my entire career (~5 years). I know that Meta is pretty "startup-ey" among the Big Tech companies, but I imagine that it can't mimic startups entirely and there's unique learning value startups can offer. Does switching to startups give big value to career development?

What's the difference between Big Tech and startups in terms of learning and growth?

Comparing Meta to other companies, splitting between a PM and an engineer is very awkward. PMs end up doing a lot of strategy work, but when it comes to what tactics you pick, it seems like engineers have to pick there.

My PM is very senior at PM6 and their guidance is extremely high-level to the point where the concrete projects we need to work on aren't entirely clear. How do I fill in these details, so I know what to work on?

How can I fill in for concrete product strategy when the direction coming from my very senior PM is more high-level?

I'm pushing for E6, and I'm having trouble doing this in my current org. I'm considering an org switch, and I want to make sure I don't end up in a similar situation - How can I properly evaluate an org for availability of scope and mentorship?

How do I determine whether finding scope and working through others is easier on my team or on another?

At my old company, where I worked for many, many years, I wasn’t learning anything new. On my new team, I feel like a junior engineer since everything is new. Because of this, I don’t feel like I’m being taken seriously, even my engineers more junior than me.

I'm trying to stay positive throughout this learning process but would obviously like to build up respect among my team as quickly as possible to start feeling like a heavily valued voice in the room. Any advice on how to do that?

How can I quickly gain respect among my team as a senior engineer?

I'm in the initial stages of a job hunt right now and recruiters seem to have the perception that I'm more qualified than I actually am (especially at non-FAANG companies). I'm E4 at Meta (mid-level) and not performing exceptionally well at this level, but recruiters are trying to push me for 'Senior' roles. Should I just go along or push back?

I know this is a bit of an unorthodox question since most people have problems with downleveling, not the other way around. I'm somewhat confident of passing the coding/systems design rounds for Senior/E5 positions at these companies, but I really want to avoid a situation where I join and immediately start getting overwhelmed by the actual job responsibilities.

Context: ~2.5 YoE

Recruiters keep trying to up-level me. Should I push back?

I've grown to be more of a "tech lead"-style E5, which leads to a lot of time spent roadmapping and talking to people instead of actually executing on the project and being more hands-on. My team is heavier on the E3/E4 side, so I'm able to delegate a lot of the coding work away. I was wondering if this was normal for Meta and whether this is an okay way to operate as an E5?

How normal is it to be mostly hands-off as a senior engineer?

For my current project, I have 2 broad options for the infra/platform to support the feature:
1. Using a proven technology that has existing use cases within Meta but a somewhat limited API
2. Using a new technology that's not completely done yet and has uncertainty, but should have better APIs and performance

There's also the option of trying to do both, benchmarking them against one another, and then choosing the better one. However, I don't think we'll have the time to do that.

All this being said, any thoughts on which technology to go with?

How do I choose between 2 technical approaches for my project?

I'm a new staff engineer at Meta, and I know that the bar is high for E6. In particular, an E6 needs to be able to have a large influence on the roadmap and team charter, leading and creating very substantial projects.

All that being said, I want to start crafting and executing that vision as soon as I can to hit the ground running, but I'm unsure on exactly how to do that with Meta's more bottoms-up culture. At my previous job, things were more top-down (i.e. leading *with* authority, where software engineers work on things because their manager/leadership tells them to). How do I lead the team with this almost opposite engineering culture?

I've heard from my peers at Meta that you should post a lot on Workplace, otherwise it can reflect badly on your PSC. Is this true or more of a myth?

Is posting on Workplace required for good performance?

In particular, is the number of "comments" on the question correct after creating a question?

**this is cool**

## this is a header to really emphasize the point

I'd love to understand the backend of Taro

Before I was at Meta, I worked at a networking company for 10+ years. It was very different from Meta as a massive consumer web company. On top of the domain differences, the culture is also very different between these 2 companies.

I'm working on ML at Meta, which is something I'm pretty new to. As a senior engineer who wants to make an impact quickly and make a push for staff, how can I effectively make this domain switch to hit the ground running fast?

What’s the most effective way to switch domains in tech?

I had a feedback session with my manager, and they gave me feedback that I was doing well overall but they would like to see me become more familiar with Meta's experimentation tools. They mentioned that this wasn't bad feedback as this unfamiliarity is expected with relatively new Meta engineers like myself. That being said, I'm unsure how to process it: Should I process it urgently and if so, how do I become familiar with Meta's gigantic experimentation infrastructure?

I got feedback about experimenting, and I'm unsure how to process it.

I'm relatively new to Meta, so I'm having trouble processing things in meetings as they happen, making them a substantial waste of time for me overall. I don't want to seem dumb, so I would to avoid asking a bunch of questions during meetings to make people explain what they just said. What can I do to make meetings more productive for me?

It's hard processing what happens in meetings - How can I be more effective?

I'm a mid-level engineer who's struggling with some performance issues at work. A staff engineer on my team has taken notice and has been very generous with offering help and advice, to the extent of basically handholding me through my projects. While I truly appreciate the help, I'm wondering if this will be seen as a negative signal during performance evaluation since I'm supposed to be operating 'independently' at this level.

Is excessive help from senior engineers good?

I've been at Meta for a while and have thought about outside opportunities. I feel like it can be frustrating getting things done at Meta a lot of the time - Too many processes and people to align to ship projects. I want to work somewhere where I can just write code and ship cool products. Any thoughts on next steps for someone who's been at Big Tech for a while?

An XFN stakeholder came up with a last minute requirement for a big project I'm working on, which will probably slow down the launch by at least a couple days. I already made promises to other XFN about the launch date.

What's the best way to mitigate the heat on failing to launch on time and zooming out, how do I deal with last minute launch blockers in general?

Got hit with a last minute requirement on my project - How do I minimize the thrashy impact it has?

I recently joined Meta, and I'm aware of "up-or-out". However, I would like to more deeply understand how it works and have a better mental map of the entire thing in general.

How long do Meta SWEs overall take to go from E3 to E4 and then E4 to E5?

How does up-or-out work and what's the transition generally like for E3 -> E4 -> E5?

I'm debating between two teams in bootcamp. All else assuming equal, the hiring manager (HM) of team A is higher up on the org chain (Team A HM reports to X, Team B HM reports to U who reports to W who reports to X).  

Should this play a factor in deciding between teams?

How should the management chain impact my team selection in bootcamp?

There's so many teams to choose from - It can be overwhelming. However, in a company as large as Meta, I'm sure there's huge variance among teams. How can I find one that works for me, particularly when it comes to find E5 scope for promotion?

In bootcamp right now - Any thoughts on good orgs to join?

In particular, I'm having trouble figuring out really complex bugs. For example, on my current project, we're auditing a lot of the existing feature set to see what issues they have so we can fix them as we revamp them. I'm happy to find lots of issues, but I have no idea how to fix them, even after finding a code pointer.

I talked with a senior engineer on my team for help, and they were able to get more color on the situation. However, they mainly were able to do this as they have been in the org for a while and knew who to go to for what: I can't replicate that deep knowledge they have as I'm fairly new to the company. How can I create a systemic process I can follow to figure out these situations?

How can I become more independent and better at unblocking myself with tricky technical issues?

How Alex Got Into Meta With 0 Prior Leetcode Experience

I've heard that you need at least 400 diffs a half. What about code reviews? Is that 500-700?

[INTERNAL] How many diffs do you need to get promoted as an E7 code machine?

It's hard to figure out what's going on right now; there's just a lot being said like that some Meta employees "don't belong here", it's time to "turn up the heat", and "low performers" need to be weeded out (I would have thought this was already the case at Meta?).

At the end of the day, I just want to figure out what this means when it comes to employee performance and PSC in particular. I've heard from some managers and engineers that the ratings will be upshifted (e.g. you need old EE to get MA), but I've talked to my manager and they said that this won't happen. But if that's the case, how will the performance review system change?

Any tips on what concretely could be happening and what we can do here to adjust to these changes?

Related articles:
- [Zuck "turns up the heat"](https://fortune.com/2022/07/01/facebook-warns-staff-not-expect-big-budgets-new-hires-be-prepared-to-work-harder/)
- [EMs instructed to push out low performers](https://www.wsj.com/articles/meta-managers-are-urged-to-identify-push-out-low-performers-11657576630)

Zuck is "turning up the heat" for employee performance. Unsure what this means and what I should do.

I was working with a team during bootcamp, and they mentioned that they intentionally have very low test coverage (both unit and integration). This team is more on the back-end side. Is this a bad sign or is there something specific about Meta's culture that I'm missing here?

Is it a red flag if a team doesn't have tests?

I work on the privacy side, so our core projects are often held up by XFN. This leads to me having to find something to do in the meantime, which often means smaller, ad-hoc efforts. However, I've been told that working on larger projects across a lengthier time horizon is better for promotion. What can I do during these blocked times that also shows good execution signal for promotion?

What can I do if my projects are blocked?

I've shared feedback before with engineers more junior than me, and they didn't seem to take it well. They started avoiding our meetings afterwards - I feel like they thought their PSC was at risk. How can I prevent this situation from happening in the future when sharing feedback with E3s/E4s?

As an E5, I will have 1:1 meetings with E4s on the team to lead/mentor them. However, I find myself running out of time in the meetings sometimes - What can I do to make effective use of all the time?

How to make effective use of 1 on 1s with E4s?

I've had some trouble historically getting my ideas pushed through. In some cases, I'm unable to get my idea to land, and another software engineer will get something similar approved later on. What can I do so people are more likely to help me push my vision?

How can I build up more influence in an org?

I'm learning it's important not just to do good work but also to make your work visible to your team and sometimes wider circle. This is common feedback given to junior engineers at Meta. What are some ways to get more visibility on my work and what are some rules of thumb (e.g. structure of posts, cadence of posts, when to share progress in team meetings)?

Does my manager see how much time I’m actually working? I work offline sometimes and am worried if this may look like I’m coasting

Do managers know how long you use your system?

I’m currently working on a 0 to 1 project that’s outside of the team’s scope, so I have no senior engineer on the team to support me and tell me what to do. I have to spend a lot of time piecing things together and it's been rough - I've missed on the team's ship goals as it's hard to move fast enough on this project. How can I make this situation better?

I've been given crazy 0 to 1 projects - How can I scope them out and disambiguate them?

I'm primarily on the back-end, but I've been put on a lot of other stacks. I've worked with www and Bloks and now I need to pick up native Android to debug a deep link issue.

I'm having a hard time with the Android issue. I took a long time just setting up the environment, choosing between VSCode, Android Studio, and OnDemand. I'm now working with adb, which I don't really understand as it's completely new to me. There's not a lot of documentation for my problem area, and it's been rough.

More broadly speaking, how can I do better in these situations and pick up new stacks faster?

How can I pick up other tech stacks more quickly at Meta?

Meta is slowing down hiring, and they’re trying to focus on a few big bets across the company. As someone who is joining the company soon, how will this impact the bootcamp team selection process, and should this impact my team strategy?

How will the Meta hiring freeze impact bootcamp?

I'm joining Meta as a Machine Learning engineer. I've found content on Taro (and other platforms) to be helpful, but sometimes I'm not sure how applicable the advice is for my domain. For example, I won't be working with any designers, and I probably won't touch any UI components in the way a mobile developer might.

How much of the engineering advice on Taro applicable across domains?

I'm an Android engineer working on an infra team, and like every other Meta E4, I am working towards the E5 promotion. Because of this, I'm spending a good amount of time building up the non-coding skills needed for the people/direction axis, doing things like XFN alignment and project management.

My question is how "all-in" should I go developing these behaviors: How much of an engineering excellence commitment do I still need to maintain? How often should I still be landing diffs?

As I grow from E4 -> E5 and develop people/direction skills, how should I think about and maintain the eng excellence axis?

I'm trying to figure out the proper level of fidelity here: Should I have very granular estimates or something that's not super structured - Just a high-level idea of projects with some buffer built in.

I'm curious to know how to structure this plan to ensure that one doesn't take on too much and get overwhelmed, but is also full enough so that in case of blockers on core projects, there's a pipeline of projects to switch into. Would love to hear thoughts here!

Should I do a lot of upfront planning around the work I will take on across the half?

I work in a Big Blue team that needs to go through many layers of approvals to ship anything. Sometimes we'll be working on a project for 1-2 halves and then the approvals will be pulled back, torpedoing the project.

What can I do to improve the process here, so my team can ship more?

My org is really slow at building alignment - How can I improve that?

I've found other resources in Taro about [creating scope](https://link.jointaro.com/gDpKcGk8KSw79Nhb6) and [working through others](https://link.jointaro.com/SRQcR4vUAZZXQ5Ap9), but I was hoping I could get a more nuanced and clearer response for my situation.

Context:
- My team hasn’t identified a goal metric that it’s able to move or a way to get there.
- There are plenty of different projects, but only one that has a clear launch path from leadership. The rest of the projects are stuck in approval loops, in some cases for more than 1 year. I work on a Big Blue team with lots of external dependencies like legal, compliance, and many more.
- The project with the clear launch path has Android work built on top of one of the company’s top priorities. I'm trying to find an Android mentor, but it's hard to get one close to me on the org chart. I plan to discuss this with my manager to determine the path forward.
- There’s a great example of an [E6 promo through improving engineering efficiency](https://link.jointaro.com/pcezxnUxBAG3CdVw5), but my perception is that the pain points in my org would be solved by alignment with leadership, not engineering.

I've been at E5 for a while now and am having trouble finding scope and working through others to get to E6.

As an E5, I'm switching to more of a tech lead role, and one of the engineers I'm leading has had consistently poor code quality despite being at Meta for a few years now.

I've asked my manager for feedback about this, and they say that we should come up with a plan to improve the situation. I've already invested time in this, and I'm not seeing results. How can I get the code quality feedback to fully land and improve this engineer's code?

I'm having trouble getting code quality feedback to land with an engineer I'm leading - What can I do here?

Meta announced that they won’t be giving return offers to interns this summer amidst economic headwinds, which is really demoralizing. 

Other companies are also putting a hold on hiring junior engineers – what should I do?

Meta is rescinding intern offers. How can I succeed now that I can't convert to full-time?

For the core workstream I got put on, there are a lot of potential angles to really move metrics, which I'm excited about. However, they mainly seem to be non-code solutions.

I've gotten earlier feedback that I need more coding signal, which has me apprehensive about this current workstream. I know that an E4 needs a lot of coding contribution for Engineering Excellence, but I am pushing for E5 which is more people/direction driven. Is it okay for me to take on this project or should I find something with more coding work?

My main project doesn't have a ton of coding work - Is that okay for an E4?

[Part 3] Meta Intern Success Series - Onboarding Efficiently

- Onboarding is arguably the most important part of your internship as it sets the foundation and tone for your entire internship.
- Set up a 30 to 45 minute meeting with your intern manager (IM) ASAP, so they can explain the codebase to you at a high-level (i.e. a component level).
- Make sure you have a recurring 1:1 meeting with your IM, which should be a weekly 30 minutes. Your IM should set this up for you, but in case they don't, you can work with them to set it up.
- You will get 2-5 onboarding tasks to work on across the first ~2 weeks. The purpose of these is to familiarize yourself with the codebase.
- Aim to put out your 1st diff by the end of Week 1. If you're doing this around the end of Week 2, you're really behind.
- Ask a ton of questions and learn to ask high-quality questions. Don't be afraid of "over-asking" questions: If you're polite while asking questions and attaching great context to them, you will be fine no matter how many questions you ask.
- Use Work Chat DMs to ask for help aggressively during this period as it's vital for you to become productive within the codebase very quickly

Related resources:
- [Asking Effective Questions That Get Great Answers Quickly](https://link.jointaro.com/E8eaKmMpZcKWNGkbA)
- ["How can I learn a large codebase fast as an intern?"](https://link.jointaro.com/L8tXjWah6ycdNpNf7)
- [There Is No Such Thing As A Stupid Question](https://link.jointaro.com/F4p3fL4eHqp5GXti7)

[Part 4] Meta Intern Success Series - Working With Your Intern Manager

- Meet with your intern manager (IM) at least every week for 30+ minutes. Anything less is a recipe for failure as your internship is so short.
- Treat your IM as a resource, not a boss. They are there to help you. Don't be afraid to leverage them aggressively to unblock you.
- The incentives align between you and your IM. They get rewarded substantially if you get the return offer, and it's rough for them if you don't. It's in everyone's best interests for you to get more from your IM.
- **Do not hide issues**. If you have any sort of problem, whether it's a technical one or a mental/emotional one, share it with your IM. Learn to be vulnerable.
- Ask for feedback every 2-3 weeks, don't just wait for mid-cycle. You can ask how you're trending rating-wise to get a clear picture. It is hard to course correct if you come out of mid-cycle with a poor rating.
- Ask for feedback regularly and make it clear to your IM that you treat all feedback as a gift and you act on it fast (literally within a few hours/days).

Related resources:
- [You Should Be Vulnerable With Your Manager](https://link.jointaro.com/CCLPu9Pp6pmRrn427)
- [Having The Proper Mentality For Manager 1:1s](https://link.jointaro.com/wmxxUCrHKvUH1D4b8)
- [Suppress Your Instincts And Treat All Feedback As A Gift](https://link.jointaro.com/TsJKvMLrzvveMkpS9)
- [Full In-Depth 1 Hour Masterclass On Effective 1:1s](https://link.jointaro.com/67uVtoJWBYwrqgDJ7)

[Part 5] Meta Intern Success Series - Writing The Code

- Keep your diffs focused and atomic. Aim for 25-250 lines of code per diff.
- Use stacked diffs: They are core to Meta's code culture. If you're unsure how to break up your work into a diff stack, work with your intern manager to come up with how things should be broken down.
- Make sure that all your diffs have a really good context section. You can have a "Context" section at the top explaining the overall goal of the diff stack (i.e. usually what your intern project is meant to do) and then a "In This Diff" section which explains the specific problem your diff tackles.
- Attach a test plan to show that your code works and to turn the diff review into a high-value artifact. Record a video of you stepping through the flow if possible (this should be easy as many interns work on internal tools) and make sure to cover those edge cases!
- Keep a very close eye on your Phabricator notifications. Your goal is to respond to code review comments quickly (within 30 minutes) and gracefully. **Code review feedback is the main way you grow as a SWE intern** as the internship's goal is to develop your raw coding ability.
- Land diffs ASAP, so you don't need to deal with rebase hell.

Related resources:
- [One Diff, One Thesis - What Every Code Review Should Be Like](https://link.jointaro.com/Wnp45zAysqyaidSF7)
- [The Most Common Mistake Made When Authoring Code Reviews](https://link.jointaro.com/bCaB7gh2u5budm2V6)
- [What A Test Plan Is And Why Every Code Review Needs One](https://link.jointaro.com/62fq4369rxjXuDju5)
- [This Is What A Good Code Review Test Plan Looks Like](https://link.jointaro.com/ieDhChExstEpD8sw9)
- [Full In-Depth 1 Hour Masterclass On Effective Code Review](https://link.jointaro.com/Vn7YSzTL61i9shwM8)

[Part 8] Meta Intern Success Series - Rahul's Internship + Current Economy

I interned at Meta in the summer of 2013 (it was called Facebook in my day…). I barely got the return offer at the end of the summer. My reflections on what I could have done better: 
- Too much back and forth on my code. I made the same types of mistakes in the code I wrote, and I occasionally tried to pushback if a reviewer requested changes. 
- Not communicating with enough with teammates. In addition to my intern manager, I should have had a regular 1:1 with the person who was primarily reviewing all my code. 

What I did well: 
- I was responsive. I replied to messages + comments quickly, and I tried to share my insights (from my project) where possible.. 
- I was a good culture fit: I built a substantial hackathon project which garnered some attention.

Advice for the current economic condition: 
- Focus on cultivating relationships with people on your team, so they are able to refer you. 
- Leverage the work you did in Meta to more easily land interviews at competitive companies.

[Part 6] Meta Intern Success Series - How Most Interns Fail

Here are the common ways SWE interns at Meta fail:
- **Misalignment of expectations**: Make sure that you're getting feedback regularly from your intern manager (IM) and ask every 2-3 weeks for a honest, real take on how you're trending. Don't wait until mid-cycle for real feedback!
- **Doesn't take feedback well**: Remember, feedback is a gift. Respond to it gracefully and quickly; treat every piece of feedback with urgency. As an intern, you barely know anything (which is expected): If you get constructive criticism, there is a 99% chance that it is correct.
- **Writes sloppy code**: Volume is straightforward and not that special - Most interns know how to write a lot of code from school. The point of your internship is mostly to teach you how to write good, clean, production-level code. Make sure your diffs are thoughtful, focused, and atomic with thorough context sections and test plans.
- **Sphere of influence is too small**: Don't only rely on your IM; you need to have 2-3 other peers to vouch for you in final calibrations. It can be comfortable asking your IM for help on everything, but you have to diversify: Make sure that you also ask other peers for help and to review your diffs. Consider having a recurring 1:1 (once every 3-4 weeks) with your non-IM peers.

[Part 7] Meta Intern Success Series - Succeeding As A Remote Intern

- Learning speed is severely nerfed by remote work, which is awful for you as an intern since this is when learning speed is the most important. It's important to keep this mind as you navigate your internship.
- Attend all team events, even the less formal ones (i.e. non-offsite) like team lunch. It's extremely important to build relationships and social capital in this environment where everyone is more isolated.
- Have 2 to 3 1:1s with your non-intern manager peers.
- Match the working hours of your team if you're in different time zones. It's absolutely vital that you always get blocked ASAP, and this is way harder when you're operating on a different time scale. This could be painful, but it will be worth it.
- Do virtual coworking whenever you can. The idea is that everyone joins a video call and just works, no meeting agenda or anything. The idea is to mimic an in-person working environment as much as possible. This creates peer pressure for you to be productive and makes it seamless for you to ask for help (just say something on the call!).

[Part 2] Meta Intern Success Series - High-level Expectations

- As mentioned before, your goal is to be operating as an E3 MA (Meets All Expectations) by the end of your internship. Assuming the standard 12 week internship, you have 10 weeks to do this.
- You will be working on production code, dealing with Meta's gigantic codebase. The exception is FBU (FB University, a "pre-intern" program) where you build an app/website from scratch in isolation.
- **Every week is crucial**. A great/terrible week can make or break your internship.
- Raw coding ability is the main thing you're judged on as a SWE intern (literally ~90% of your packet). The 2 main components here are velocity and quality, which means that your goal as a SWE intern is effectively just to write a lot of very high-quality code fast.
- In a vacuum, target landing 3-4 diffs per week. Of course, this will vary based on org, stack, etc - Work with your intern manager (IM) to get a more accurate range. You can look at previously successful interns in the org to generate a baseline as well.
- Write 1-2 Workplace posts as technical writing is super important at Meta. The easiest thing to do is write about your intern project as you hit major milestones, especially when you launch it.
- You need a cast of people to vouch for you during calibrations. Target having 2+ peers on top of your IM (i.e. so 3+ people total).
- You will likely work on an internal tool as it's free from XFN thrash and dependencies. Meta has a lot of respect for quality internal tools as well.

- I've been reaching out to people via DMs and public workplace posts, comments on threads/tasks/diffs, sometimes email.
- Sometimes it takes 1 week to get a response or I just never get one, despite multiple follow-ups.

Unfortunately at a big company like Meta a lot of the stack is proprietary and are essentially black boxes, so I can't just search public documentation or use StackOverflow. Sometimes the documentation/wikis are outdated, so when the team maintaining it is unresponsive I have a hard time gaining traction with my projects. Ideally I'd try to go into the codebase to figure it out myself but it's hard to familiarize myself with another repo quickly especially if it requires special setup to get things running.

I also have a sample Workplace post that shows how I'm asking questions and looking for help: [REDACTED TO PRESERVE COMPANY CONFIDENTIALITY]

How can I get faster responses to my questions and unblock myself?

I came in as an E4, but I feel like I'm over-leveled. I only had ~1.5 YOE before Meta, and I was doing relatively straightforward coding work at startups. However, when I joined my team, my manager's goal was to get me at E5 ASAP.

This has led to them giving me a lot of very complex scope. Here are some of the things I've gotten/am expected to do:
- Got a hard 0 to 1 project with no senior engineer to assist me
- Lead 2 E3s
- Work across multiple, completely separate stacks

I haven't been able to handle all of this - I'm falling behind and feeling pretty stressed out. I would much rather just take the time to build up the E4 fundamentals and stabilize at an MA initially vs. chasing E5 promo right out the gate.

My manager has higher expectations for me than I do, and it's sort of overwhelming.

I came into Meta with ~1.5 years of startup experience. I'm very good at Leetcode-type problems, so I was able to land an E4 offer. However, my prior experience mainly consisted of raw coding (E3-scope), meaning that I didn't have much experience developing E4 behaviors coming into Meta. This has led to me struggling on my current team where my manager let me know that I'm currently trending around MM. My team and manager have compounded this by being quite ambitious - I've gotten a lot of E4 EE+ scope with things like complex 0 to 1 projects (my manager is trying to get me to E5 ASAP). This is all hard to handle and has been a huge source of stress for me, so I'm currently considering other options.

Here's what's on the table:
- Stay on my current team and stick it out, trying to recover to MA by the next PSC.
- Switch to another team within Meta that's slower-paced.
- Job hop to Google as an L3. I was able to land an offer with them during my job search, and I kept that line open. I'm exploring team matching with them now.
- Go through some additional interview rounds with Google to get in as an L4.

Which of these is best for my career?

Came in over-leveled and now treading water (trending MM). Where do I go from here?

Here's a recent example: I took 2 months to finish bootcamp, and I was very indecisive throughout that time, talking with various managers and tech leads. I initially talked to real time ads infra, then streaming areas, and many others. Even after picking a team I feel FOMO that there’s a better team I could have joined instead. How can I feel better about my decisions?

How can I be more decisive about my career decisions?

Meta Platforms, Inc. is an American multinational technology conglomerate based in Menlo Park, California. The company owns Facebook, Instagram, and WhatsApp, among other products and services.

Senior Software Engineer [E5]

- For learning that's more unique and unable to attain at Meta and other Big Tech companies, you want to go smaller as there's a bigger delta between the 2.
- Smaller companies often times let you wear many hats. For example, back when I was at Course Hero, I got to manage the Google Play store listing, design the entire Android interview process, and reply to customer reviews. There's no way they would let me do that at Meta as a rank-and-file Android engineer. Startups can let you own the product a lot more holistically.
- However, the downside with very small startups is that you can be pigeonholed into just writing a lot of code. For startups, the highest leverage thing they can do is often churning out code and features.
- I've seen crazy growth trajectories of people who join startups early (including those at early Robinhood), growing from L3 to L7+ in ~5 years. However, I think this is more the exception rather than the rule as most startups will not be nearly as successful as Robinhood.
- Growth infrastructure is very hard to build and fine-tune. Meta has done an excellent job with its career matrix and relatively clear PSC guidelines. Most startups won't have this and will struggle to define it. This can lead to people in startups being stranded in growth deserts where they actually level up slower than they would at a Big Tech company.

Related resources:
- ["How do I know when it's time to leave a team/company?"](https://link.jointaro.com/7EqTrhgW9c8bwFc98)
- [Taro Premium Session on ownership and specialization at startups](https://link.jointaro.com/2ZevbN54MPZPTocH8)
- [1.5 hour masterclass on choosing the best team/company for you](https://link.jointaro.com/F4DDyKfuo3hMhj868)

Robinhood, Meta, Course Hero, PayPal

Alex Chiou

In a startup, your learning and growth will depend a lot more on **the people you work with**. 

In a larger company, the people are still important, but you can also supplement your learning with things like architecture meetings, planning meetings, and better documentation.

Meta, Pinterest, Kosei

Rahul Pandey

Specifically for career growth, I usually use this metaphor:

Think about learning to swim. Big tech companies hire the best swimming coach to teach you. The coach has successfully trained Olympiad medalists in the past. The swimming technique they teach is the best of the best. There's just one tiny problem: There are so many people learning to swim the swimming pool is full and has a long line.

You've been learning about swimming with this coach for years. You learn everything possible from the books. You practice every movement on the land. You are just waiting for your chance to get into the water. You are frustrated that you haven't received the credit for swimming because you haven't demonstrated swimming in water. You believe you can totally swim. 

This is big tech. You believe you have the skills and deserve that promotion. You just need an opportunity but that opportunity never comes. It's so political and unfair!

On the contrary, nobody knows swimming better than you in a startup. There's no peaceful and safe water like in a swimming pool. There's a ravine. Water is rushing through. Swim or sink. Jump in and see if you can get out alive on the other end. If you can you are way ahead of the other person waiting for their swimming pool access. If you die, nobody remembers the dead bodies at the bottom of the water.

***

Meta's culture is already leaning towards swim or sink. However, it's too big and the bottleneck for supporting employee growth becomes opportunities. Meta is (or at least used to be) very generous at spending money on enabling employee growth. You can learn from the best. You just need to have access to opportunities to practice your skills. 

Startups don't guarantee better outcomes. There's a chance but you have to accept the risk of getting a worse outcome.

Meta, Robinhood, Baidu

Cat Chen

Often refers to the "Big 5": Google, Meta, Amazon, Apple, and Microsoft. They have all broken the 1 trillion dollar mark at some point and are premier career destinations for software engineers.

Senior engineers have proven themselves to be extremely capable at shipping high-quality, complex software efficiently. This collection breaks down how they operate and how you can get to this level too.

A startup or start-up is a company or project undertaken by an entrepreneur to seek, develop, and validate a scalable business model.

What's the difference between Big Tech and startups in terms of learning and growth?

Meta

Discussion

Meta