I would suggest seeking a second opinion if it’s available. Maybe from your skip manager, your manager’s peer managers or someone with enough observation of how you work. 

Maybe your manager identify the correct syndrome but can’t prescribe the right treatment. They might not identify the right syndrome. It’s hard to tell on the Internet from far away. It’s better to have someone who knows you to give you another piece of feedback. That’s the gift you should look for.

Staff Engineer (former Engineering Manager)

Cat Chen

Use the most common async communication channel (be it email, Slack, Teams, or Workplace) to post the list of action items. Each item needs to include:

1. The assignee. If there are multiple assignees, you may need to assign an owner (or DRI or whatever your company calls it). You can try multiple assignees first. See if they shift blame to each other when none of them deliver the action item. If they do that you have to assign a single owner.
2. A well-defined outcome. People should be able to easily judge whether the action item reaches the desired outcome or not. Ideally, people are able to track progress toward the goal as well.
3. The deadline. If the action item can be tracked as it progresses, a timeline is better than a deadline. Anything that deviates from the timeline before the deadline should be corrected.

Now the most important part: You need to follow up by reposting this list of action items again and again in a predetermined cadence with updates. Something like this:

1. Action item one. Assigned to individual A. Finished.
2. Action item two. Assigned to individual B. Progressing slower than expected. B shared the context of why it's more time-consuming than expected. B proposed this new timeline.
3. Action item three. Assigned to individual C. C has been unresponsive when inquiring about progress.

Everybody can see the behavior difference between A, B, and C. They are held accountable in public. Of course, you need to reach out to them in private before posting an update if you are not sure about what's going on with their action item. Give them a chance to update you even if you see no activity. Give them a chance to share the context of what happened and why.

Do this in the team's public space if it's relevant to the team, even if the action items came out from a 1:1. It's not about whether it came out from a 1:1. It's about how it matters to the team and how to make sure the team gets what it needs to succeed. 

Post it as soon as the meeting finishes. If you are not sure if someone signed up for something in the meeting, ask them. If they are tagged but didn't think they sign up for it, they should speak up as soon as possible or everybody assumes they signed up for it.

Meta, Robinhood, Baidu

Mostly what Rahul said. If your level is L5 or below, it's better to avoid down-leveling. If you can negotiate up-leveling that's even better. If your level is above L5, down-level may help make your ramp-up easier.

The job responsibilities for L3 to L5 are pretty predictable. If you can do it you should be able to consistently do it forever. Down-leveling just means "we doubt you can do it consistently". It doesn't make a lot of sense. The only scenario in it that may make sense is you were promoted recently. They may doubt that you were promoted immaturely. But if you are confident you can do the job consistently you should push back.

The job responsibilities for L6 and beyond can be pretty different across companies. What you succeeded in doing in a previous company might not translate well in a new company. (From a hiring manager's perspective: It's always a high risk to hire an L6+ into the team.) Resetting back to a more predictable L5 (or a lower level that's above L5) makes sense. It gives you time to figure out whether the responsibilities are the ones you expected or had experienced. If not, it gives you time to learn the new responsibilities.

You want a new job but you have no experience doing this job. If the job is vacant and they are desperate enough they will be open to letting someone without much experience do it. That's one way to go. If your team doesn't have any E5 or PM, or maybe for some reason nobody takes care of the road mapping, nobody will question you if you step up and do the job. At least in Meta. Nobody will challenge your qualification if they don't take that job themselves. It's not uncommon to see an E5 to E6 promotion happen in this way (when the team has an E6 job without an E6).

This is no longer commonly available for E4 to E5 nowadays. Sometimes a team has so many capable E5s that they are competing to do road mapping among themselves. You won't be able to take their job out of their hands. What you can do is add value to what they are already doing. You take a small piece of the job you want but you don't claim you are taking it. You are just "helping out" by sharing some ideas and giving some suggestions. If they are not good enough, it's not a big deal. Nobody thinks you are stealing their jobs.

Take your time practicing the job without officially taking the job. It's like shadowing someone else doing that job -- asking questions and sharing your thoughts. When you are experienced with the job it's easier to convince others to let you take the job. If you can do it better than the existing owner people will notice. They will ask you to do it instead of the existing owner.

Common misunderstandings from aspiring big tech engineers wanting to start their own companies:

1. Great technologies lead to great startups. I need to focus on sharpening my skills in building great technologies. 
2. Great products lead to great startups. I need to focus on honing the right sense in building great products.

You may attract investments with those. You may have great appearances in interviews with journalists. Eventually, you need a great business to sustain a startup.

If it's an Internet service with a monotonic version number, just use trunk-based. Everything needs to be rebased onto the main/master branch (aka trunk).

The reason is your version number never goes backward. You won't upgrade v2.1.1 to v2.1.2 but also need to apply the same patch to v1.9.0 and v2.0.9. Client-side software is different. If you have older versions out there you'd better take care of the security patches. Then you will have to apply the same security patch to v1.9.0, v2.0.9, and v2.1.1. That's where multiple live branches become valuable. Otherwise, keeping multiple long-live branches is a cost without much return.

If your version number never goes backward, you can keep rebasing all new commits to the trunk. You can tag new versions on the trunk and release them. A well set up CI/CD pipeline will make things automatic most of the time.

Quantify the impact of the tech debt. If you find it hard to measure or predict the impact, at least measure the effort needed. It's a typical case for "If You Can't Measure It, You Can't Improve It."

When you run into conflict with product decisions, quantifying the impact is the only right way to go. Talk about the benefit and costs of different options. "If we ship the product quickly, we are going to acquire this much of the market ahead of time and make this much of a profit." "However, if we leave the tech debt behind, we have this percent chance of having an incident every quarter, which will lead to losing this much money and the reputation loss will cause us this many customers down the line."

In theory, if you can translate everything in every option into $$$ (or other metric your team cares about), you can make an apple-to-apple comparison easily. That's a way to easily win (or lose) an argument, but at least the alignment is very clear afterward. 

What Rahul said, plus trial and error on your email timing within the day.

Review all the meetings you have in the morning. After subtracting the meeting time, consider what are the reasonable goals to achieve within the day. Know what you want to achieve by yourself, e.g. coding, writing documents, etc. Know what you want to achieve when interacting with others, e.g. getting alignment in this meeting, delivering some touch feedback in that 1:1, etc.

Keep information consumption in polling mode instead of pushing mode if you have the power to do that. (It really depends on the company's culture and your positional power.) There's no one-size-fits-all solution. Trial and error to see how far you can push the envelope -- how unresponsive other people can tolerate you. Of course, you need to set expectations with the people you work with, again and again. I used to tell people "don't expect me to attend a same-day meeting if you send the calendar invite late". (I was a manager at the time. I needed tight control over who I had to meet ASAP and whose meeting I could postpone.)

Gradually you will figure it out. You will see a pattern of when the people in your company usually make communication with what you care about each day.

Meta nowadays? Pretty risky. It's risky even back in 2017. All engineers up to E6 were forced into a rigid mold back then and only E7 may achieve "escape velocity" -- not being evaluated as a list of checkboxes against a peer. (One director predicted that E7 would soon be the same at the time.)

I can share what I saw. There was one cycle I was a TLM. I wrote like 20 diffs. My manager and their peer managers were aligned on giving me an MA. There was a director outside of our report chain acting as the org-level representative. That director's job was to sit through all calibrations in the org and make sure they are holding up the bar in the same way. They had no knowledge of my work and probably little context of our team's work (because they were not in our report chain at all and our team reported directly to our VP). They made one quick comment after seeing the metrics on screen: "20 diffs? It has to be a MM or lower for a TLM." That's it. (Our VP wasn't in the room to counter that.)

---

How managers usually deal with this:

1. Talk to peer managers. Explain why this direct report will be making a huge impact but has to sacrifice coding quantity. Get peer managers on board. If any peer manager disagrees it fails.
2. Talk to the director and/or VP to get them on board. They know the context and the necessity of sacrificing this engineer's coding quantity for something more valuable, but they need to be ready to put their reputation out there to defend this engineer. If they don't have the willingness it fails.
3. Double-check with HRBP to make sure they don't have a strong opinion on this matter.

If any step fails, the manager goes back to tap the shoulder of this engineer and reminds them to deal with the coding quantity. Sometimes the manager would even suggest a high-coding-quantity-low-time-cost project. The project is probably not very impactful, but everybody is just trying to play along with the game at this point.

---

There was a time I reported to one director. They were very straightforward about me having to deal with my diff count. I was like "I'm working on the most critical work the team needs to succeed. Am I right?" and he was like "Yes. You are doing the right thing. But still... Just deal with your diff count."

Typing speed is not your bottleneck. If you are a computer, typing is a slow IO task but the CPU task (thinking) is even slower. There's no point in optimizing IO while it waits for the CPU anyway. 

As you grow, there will be a stronger need for your CPU to better balance between computation speed and quality. Higher quality usually leads to a more clean and concise IO (both writing code and communicating with other human beings), but not every task deserves your greatest attention.

Do good work, add value to other people's work and make a great impression. They will remember you. They will refer you because they genuinely want to have you on their team, not because of the referral bonus. 

When I joined Facebook back in 2012 (the IPO year), one director said this in private: You already missed the opportunity to make a huge amount of money here (because IPO already happened). There are a lot of amazing people here at Facebook. You want them to remember you when they think of starting their own companies and ask you to be their cofounder. You goal in the next few years should be putting out good work and making a great impression with your colleagues.

I didn't become a cofounder but this turned out to be mostly true. When one of my skip manager at Facebook joined Robinhood as a VP he remembered me and invited me to interview. We met and he was like "since you have offers from other companies already it doesn't hurt to interview with us and have another option if you get the offer, right" He let me skip the phone screen and go straight to onsite to expedite the process. I negotiated hard with the recruiter (also from Facebook) after getting the offer and he was like "I would have stopped talking to you if not for our VP wanting to have you". I negotiated a top of the band (in the level I got) offer in the end.

---

Think of how many people from your current company will make it to the top companies you want to join. Think of who they are. (They are probably the best people in your current company.) Find ways to work with them and build something great together.

In a sense, you can't, at least not anywhere close to a reliable prediction.

Think about this: If you have the ability to reliably predict a large company's financial direction, wouldn't it be more efficient financially to just invest in the right companies? Why would you pick a single company and work for it?

Also think about this: If you are trying to do what all those "Wall St analysts" are doing as a full-time job, what gives you the confidence to do this occasionally and still do it better than them? If you believe they can do a better job, would it be straightforward to just purchase the analysis from the one you trust?

I would suggest using analysis from a source you trust as the base of your decision. Your advantage comes from on-the-ground knowledge that specialized financial analysts don't have. I would look at these things from my unique angle in the industry and inside the company:

1. Are the founders and other executives growing with the company? Do they learn from their mistakes and get better next time? Do they make the same mistakes again and again without learning?
2. Are the employees executing the founder's vision efficiently when compared to companies of similar size? Do they have an advantage over companies of similar size because they have some secret sauce in their way of work? Are they trapped in high internal friction like politics (aka misaligned interests) already?

It's okay to join a company, learn these things internally and fold your hand quickly because you are seeing red flags everywhere. Managing your downside is as important as seeking the upside.

By **creating value**. It doesn't have to be technical strength. 

Meta emphasizes concepts like "influence without authority" and "judging the idea by its merit instead of the level of the person behind it". What's less likely to happen in Meta:

- 🚫 I respect you for your level is higher than mine (because I don't even see your level).
- 🚫 I respect you for having more technical knowledge than me (unless I need help from that knowledge.
- 🚫 I respect you for being smarter than me (unless that helps me in a direct way).

What's more likely to be useful for you:

- ✅ I respect you because you help me make a bigger impact than I could have done by myself.

How you help someone else make a bigger impact can come in many different ways. You can apply your technical strength to solve problems that block others. You can use your business sense or product sense to identify better opportunities for others to work on. You can build tooling to enable others to work more efficiently. You can build alignment with XFN to unblock the launch that is currently blocking others.

In my last team at Facebook, I think it was two things. I was good at identifying opportunities and creating scopes for others. When people in my team worried about not having enough scope to deliver impact I helped them with ideas. I was a good listener to provide emotional support. When they felt bad and needed someone to whine and rant they came to me.

It really depends on your org and how it handles calibration, if we are just talking about Meta. Some org expects E6 writing more code while also owning larger scope with more non-coding complexity. Talk to your manager about your goal and tell them you have concern about whether not writing enough code will hold you back. Be straightforward about that. Don’t soften it. 

I’ve seen manages and directors giving hints to their E6 for “not writing enough code”, even though they are already working on what’s most critical to the team’s success. Your manager might be okay with you writing less code. Your manager have to know the probability of someone far from your team casually starts a conversation in calibration like “but hey, this person’s diff count is so low”. 

Beyond Meta, my expectation of an E6 is to identify what’s most critical to the team’s success and focus on that, especially on reducing ambiguity and uncertainty. Writing more code or less code is not the point.

This is the first time Meta experiences this. Nobody prepared for an answer before all these happened. Ask your mentor. Ask them to escalate if they don't have a clear answer. Mentors meet with coaches weekly. Coaches meet with a few managers that run the whole Bootcamp program weekly. That's the escalation path. 

Tackling Bootcamp tasks might look like free labor but it doesn't mean you are not making any impact. Bootcampers usually start with less urgent tasks but as you learn more and more in Bootcamp you can start tackling more impactful tasks. Ask your mentor to help you find those tasks. Ask people on the team you want to join. 

In the end, it's not about whether you graduate from Bootcamp. It's about whether you are making an indisputable impact. As long as you are making a lot of impacts, regardless of how the company plans for the Bootcamp people will fight for you to have you stay.

One perspective to look at this is to think about what drives you.

First of all, what drives you to stay in your current job? Is it a negative emotion like "if I lost my job I can't pay the mortgage" or "if I quit in this situation people around me would think of me as a quitter for the rest of my life"? If this is true, you should always keep your eyes open and look for opportunities that can drive you with positive emotions.

Opportunities that reduce the negativity may look attractive -- isn't great that the new job pays more when I worry about money in case of losing a job? However, that's not going to drive you better in a healthier way. You can pick up this new job and get paid more but you also get a bigger negative drive -- "if I lose this job I'm leaving even more money on the table!" Be diligent in the trade-off you make in this case.

A better opportunity is one that attracts you with positive emotion. "I grew up poor and I believe I can help people in a similar situation by working on this financial product". "More and more friends in the tech industry are suffering from mental health issues and that makes me want to work in a company that addresses the mental health market". Just to give you some examples.

If you find something that positively pulls you towards working on it, take that opportunity. Leaving because worrying about career growth is better than other materialistic reasons but it's still a negative drive. You change jobs and you will still think about "am I not growing fast enough" or "am I not promoted as quickly as my peers". That's not great.

Most of the time scope means scale and complexity.

Scale has multiple aspects that are not software scale: time (Can you keep a 6-month goal on track?), team size (Can you distribute the work among 3 engineers and keep everybody on impactful work). If you can ship 1-month to 2-month projects without problem but find it hard to predict what's achievable in 6 months and then deliver that? (It has to be more impactful than repeating 1-month projects 6 times.) Can you lead a few junior engineers and create enough impactful work for them instead of just enough for yourself?

Similar for complexity. Once you involve more people and more moving parts the complexity may go up exponentially instead of linearly.

***

There's another way to look at it from the impact's perspective: **Can you bend the curve of linear impact?** If you can deliver the impact of `n` in a 1-month impact, can you deliver a lot more than `6n` in 6 months? If a junior engineer can deliver the impact of `m` in a given time, can you lead 2 junior engineers and enable them to deliver a lot more than `2m` in the same time?

***

There's a small chance that it's management bullshit (but I don't see the likelihood if you are in a Series C startup). In some of those big techs, when a manager fails to help you promote due the things out of your control (e.g. promotion quota due to budget limit), they have to tell you what to work on and improve next. However, you are supposed to be promoted already. What can they ask from you? That's when they need to bullshit you with vague concepts.

Are you up for some challenges and willing to take some risk? If yes, go for it and take an up-leveled offer (if everything else about this offer looks good).

It’s more often to see people stuck at E4 and don’t have enough opportunities to demonstrate that they can perform as an E5 at Meta nowadays. That’s why taking a senior offer has more upside and limited downside.

Refer to my post [Job Promotion: Scaling-bound or Opportunity-bound?](https://english.catchen.me/2020/06/scaling-bound-and-opportunity-bound-promotion.html) for why E5 promotion is harder than E4 promotion. They are not the same thing. You need opportunities to practice and demonstrate E5 skills while you are E4, which is hard because those opportunities don’t always come naturally. If someone is handing you those opportunities you should take it (after considering the downside and how it’s going to impact you).

The exception I can think of is when the downside impacts you more. For example, if you are on visa and you can’t risk being let go in case you really couldn’t ramp up to a senior role fast enough.

Don’t let the levels get into your head. It doesn’t really matter what level you have and what levels they have. 

Imagine you are organizing an offsite for your team: deciding where to fly your team, which hotel to stay, how many rental cars are needed for the whole team, where to eat and accommodate everybody’s dietary preference… A lot of things. You are the owner and you are doing well staying on top of everything. 

You ask an E7 in your team for some help. They ask you what needs to be done. You ask them to help identify drivers for each rental car and match each car with passengers. They go ahead and ask everybody if they have a driver license and if they are willing to drive… In the end they come back with a list of cars with assigned drivers and passengers. 

Is this E7 performing as an E7 in your team offsite project? No. They are performing more like an E3. They don’t have much context of your project. They have the willingness to help out. You assign a well defined task to them and they fulfill the task. They don’t necessarily seek out more work, more scope or more ownership.

That’s my observation of human behavior. People don’t have the technical depth, scope or ownership needed for their level in everything they involve. In fact, everybody starts with E3 or E4 behavior when getting involved in something new. They don’t know much about this new thing and they don’t feel committed to this new thing. They are just willing to try it out and give it some effort.

So don’t pay attention to your level and their levels. Focus on going through this list:

1. Creating work that is worthy and potentially interested.
2. Getting people excited about the work.
3. Providing opportunities for people to get involved, ideally starting with some well defined tasks and making sure they are successful in those tasks.
4. Gradually ramping them up to larger scope or more ambiguity in your work.

They may have more depth and insight in the work they’ve been doing. Believe that you can bring your unique perspective and value to the team. That’s how you create worthy work that other more senior team members didn’t think too much previously.

A trick I learned from another manager: Always frame it in a way that you two are on the same side of the table.

Do you believe in the following statements?

1. You two are aligned. You want the other engineer to improve and make more impact. They want to improve and make more impact as well.
2. You are here to help the other engineer improve. You have their best interest in your mind. You are not doing this for your own interest.

If these statements are not true for you, e.g. you are just annoyed by the other engineer's certain behavior and you just want to change them for your own benefit, this is not going to work well for you.

Even in the extreme case when dealing with underperformance and potentially letting go of a person, we have to think in this way: You and I are aligned. You want to perform better and I want to help you perform better. We have a common problem in front of us, which is your underperformance. We work as one team to tackle this problem together. 

Never put the other person on the other side of the table. This thinking is guaranteed to backfire: I have a problem, which is your underperformance. You as a person are part of this problem that I have to deal with. That's very confrontational. 

Find the alignment between you two. Maybe he wants good PSC and you want them to have good PSC. Communicate that -- you are genuinely interested in helping them improve and get a better outcome in PSC. If he's open to this then you can move forward with your feedback.

You can not plan for everything, but you need to have enough clarity. Imagine a road trip over many days. You don't print out turn-by-turn navigation for the whole trip on day one. You don't know if there's traffic or detour. However, you have rough ideas of which cities you visit and which route you travel along in your mind. When your gas is low you look up the next gas station along the route but you don't plan them ahead of time. That's what it's like.

Learn through trial and error. Practice more and you'll gradually learn what you need to plan ahead and what you can improvise.

It really depends on how much you are into the Meta culture and mindset. You have to make E5 impact and demonstrate E5 behavior before you can get that promotion.

Meta is not the place where you can count on your YOE and assume you can get a promotion by accumulating experience year over year. Meta doesn't recognize experiences and only recognizes impact. As the level number increases linearly impact is expected to scale exponentially. That means behavior changes and new skill adoption are needed for E5. The most important one is shifting from owning execution to owning result.

Great E4: I wrote perfect code and shipped perfect projects that are pixel-perfect, performant, bug-free, scalable, extensible, etc. Unfortunately, our PM pointed us in the wrong direction. All the experimentations are neutral or negative. My work didn't move the needle.

Bare minimum E5: I promised I could move this metric up by 5% in 3 months. By the end of the 3rd month, I delivered that 5%. (So many things went wrong in the process but I brought them back on track. PM picked the wrong idea and I pushed back to do the right thing. Another team promised to build the dependency we needed but failed to deliver so I hacked a temporary solution. Some experiments didn't deliver the expected outcome but I planned more experiments than merely 5% so the redundancy saved me.)

As you can see, E5 requires a lot of soft skills while you scale your hard skills. The problem is you won't have the opportunities to practice those skills all lined up in front of you. Sometimes there's just no such opportunity near you. Without trial and error, you won't be learning that skill. This unpredictability is actually the most difficult (and sometimes most frustrating) part. But that's life, full of random events.

The Meta way is to get your hands dirty without fully understanding everything. They don't expect you to read all the documents and understand all of them before making a diff. Figure out the minimum set of documents you need to read and send your first diff as early as possible. Keep making mistakes and learning from them.

> I want to work somewhere where I can just write code and ship cool products. Stability and WLB are also on my mind to an extent as I do have a family to take care of.

Given the constraints you listed here, I think pre-IPO unicorns are your best bet. 

As a company grows bigger and bigger the need for internal communication and alignment becomes stronger. The value of being a so-called "Coding Machine" diminishes. The collective mindset shifts from "let's build something and it's likely to create value" to "let's talk first and make sure we are not damaging value for anyone internally". If you want to focus on writing code and shipping cool products you have to move to an earlier stage company.

If you also want stability and WLB you probably shouldn't join a company at a very early stage. That's why a pre-IPO unicorn is a sweet spot. There should be a lot of opportunities to create value by coding and building as the company grows.

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.

Keep asking yourself this question after you delivered something with your engineering excellence: **"How can I deliver the same impact with half of the time/effort?"** You might not reach double productivity any time soon but it's good to always aim high.

Never feel satisfied with "I've done this beautifully". Always seek new approaches to something you already knew very well and prove to yourself that "what an idiot I was for being so inefficient in the past". This may sound unreal to you but it's the path forward.

I've read an engineering blog post talking about having kids. You struggled when you have your first kid. After a while, you get the hang of it and realize how inefficient you were before having any kid. Then the same thing happens again after having a second kid. "Necessity is the mother of invention."

Very often people don't proactively find ways to improve their productivity when it's not necessary, because life is good. Only when they struggle do they have to invent new ways to improve productivity. This E5 promotion looks scary from where you are right now -- holding on to the same level of engineering excellence output and adding extra direction/people output. How is that even possible without burnout? You will have to struggle for a while and then you will get the hang of it.

Feel extremely comfortable failing and losing face. That's a key trait to learn quickly in a domain you don't know much about. Do that as early as possible. 

If there's a question you are too afraid to ask in your first 90 days because "would that make me sound stupid", think about what happens after 12 months. It's likely that you still don't know much about that subject and now you feel horrified about someone figuring that out. That will negatively impact your capability to make an impact. Looking back from that future the only rationale choice is to ask that stupid question and make sure you learn well from the answer even if it's very uncomfortable.

This is based on the observation I had from Meta Bootcampers I mentored. I've seen a staff engineer who was a deep expert in one subject but wasn't comfortable and proactive enough when ramping up to random subjects in the Bootcamp, and almost got fired from the lack of progress in Bootcamp. I've seen a manager (with no prior iOS experience) picked a simple Apple Watch bug, followed the wiki to set up XCode (and other Meta-specific iOS development environments), and fixed the bug in a week.

The best Meta engineers I saw with this trait of fast learning usually had prior experience as early engineers (sometimes CTOs) of successful startups. In hindsight that makes sense.  In an early-stage startup environment, if you fail to learn something quickly, build a prototype tonight, and demo it to the investor tomorrow morning because the situation requires that, your company is dead in the water. Losing face is the last thing to worry about.

Lose the pride of "I'm a senior engineer". Be a noob.

1. Motivation. Given the same level of talent and assume everything else equal, the more motivated person wins over the long term against the least motivated person. The former could get more work done with the same mental strength in the same amount of time. The latter has a lower mental strength to productivity conversion rate because of the lack of motivation. So what kind of work gives you energy (e.g. you want to wake up and start working as early as you are physically capable, you keep thinking about the problem even when you take a shower)? If you can't identify what motivates you that's totally normal in your early career. This kind of self-awareness is something you should grow over time.

2. My default is no but it depends on how much trust I have in my manager. Ask yourself this question "does this person have my best interest in their mind even when it hurts their interest?".

No. Meta culture puts more emphasis on impact (especially impact on business and impact on products). Meta culture discourages meaningless engineering excellence that makes zero impact on business or products. That means you always need to ask the fundamental question "what does this mean to the business?"

Having low test coverage is a trade-off. It may be purely negative for engineering excellence but it's clearly a trade-off for business. Writing tests takes time. Is it the most impactful thing to do? Is there anything more impact than writing tests given the same allocation of time?

Ask the manager and tech lead(s) explicitly about this. I expect them to provide concise and logical answers to you, e.g. "This is the problem the company counting on our team to solve. This is the priority we set for the problem space. These are the goals we define to track our progress in solving the problem. Given all of these, it's only rational to focus on shipping instead of testing."

If they can't provide a good answer that's truly a red flag! Focus on the process of reasoning and decision-making. Use that to judge a team's quality.

> I can't replicate that deep knowledge they have as I'm fairly new to the company.

Update your mindset. Believe in "I need to replicate that deep knowledge and I could achieve it." Then the right question to ask is "how can I achieve it efficiently?"

***

You should proactively get help to unblock yourself. The most important thing is to focus on "learning how to fish" instead of "getting the fish" in the process. It's part of the journey you are expected to take during your stay at Meta.

When I was a Bootcamp mentor and then later a Bootcamp mentor coach I kept telling people that it's critical for a Bootcamper to learn how to get the information they need. It's what the Bootcamp tasks should drive the Bootcampers to learn: ask POC to provide the context; ask POC to answer questions; ask POC who else to get the information if the POC doesn't know; follow the lead and jump through multiple hops to get the information; (when you are more senior) make decisions based on incomplete information. 

Usually, it takes you one to two years to get enough institutional knowledge in a large company like Meta. The senior engineers in your team know where to find the right people and ask the right question. Ask them to show you how they do it. Ask them to walk you through each step in their process. Isolate the ones you can pick up quickly and accept the ones that take time to accumulate.

If they tell you "I just know this person on top of my head. So you should go ask them." That's something you need to accumulate over a long time. You just wouldn't know such things on top of your head. 

If they tell you "I look up the manager and the tech lead in the org chart. I reach out to and ask them whether they are the best people to talk to about this question. It turns out the manager is technically hands-off and the tech lead is new to the team. They recommend I talk to another senior engineer in the team for my question." This process is the "fishing skill" you can observe and mimic quickly. Ask them to show you "how to use the org chart in Workplace", "how do you identify the tech lead in a team", "how to write a message to reach out to strangers in another team", or even "how to not feel bad if those strangers say no to me or just ignore me". Focus on learning in this way by keep asking people to demonstrate how they would do stuff that you can't do independently, yet.