This is a great question and what Taro helps with! (If you don't feel more confident after reading through Taro discussions, attending the live events, and chatting with us directly, ping me for a refund!)

- **Study the code review process at your company**. Learn from high quality PRs, and incorporate feedback from poor PRs into your own code. 
- **Build real programs**. That means you should actually run the app or service, and print statements, and understand the code flow. This will feel different from solving programming puzzles, and that's ok. 
- **Talk to people on your team and adjacent teams**. Take advantage of being the new person and schedule 1:1s with everyone on the team and learn what they work on (and what challenges they face).
- **Figure out what your team and company care about**. You could spend the next 6 months increasing test coverage from 60% to 90%, but does anyone actually care? This is not strictly about software engineering fundamentals, but if you work on things that people care about, you'll get more feedback which will help you get fundamentally better.

Tech Lead/Manager at Meta, Pinterest, Kosei

Rahul Pandey

Some good resources on making connections with others on the team: 

- [1 on 1 Meetings Are An Exercise In Proactivity](https://www.jointaro.com/lesson/ZPnCvmwqV0hqxJEr0kqh/1-on-1-meetings-are-an-exercise-in-proactivity/)
- Get a higher level perspective on what's important with a [skip level 1:1](https://www.jointaro.com/lesson/TToehFEc738PBhJcALwL/how-to-effectively-leverage-skip-level-11s/)
- [Saying thank you to coworkers is a superpower to finding peers](https://www.jointaro.com/lesson/qVASSX157IA6E3hwUN8g/how-to-really-say-thank-you-to-coworkers/)

There are 2 approaches here: 

1. Can you get more people in the team (or others in the company) to care about your work? 
2. Can you get involved in other projects. 

More thoughts below to figure out which path is more viable. 

### Option 1: get more people to care

What is the impact of the work you're doing? **Who would get upset if your project never finished, either internal customers or external?** 

If the answer is "*no one cares*", that's a sign you probably shouldn't be working on this 😅

Part of this is a marketing challenge: how do you describe your work to other developers or PMs to show the positive impact? Does your work speed up developer velocity or reduce friction for a group of customers? Find the people who care and start meeting with them and adding them on your code reviews. 

### Option 2: get involved in other projects

Think about your work in terms of a portfolio. **You wouldn't put all your money in one stock, so you shouldn't pin your career hopes on a single project either.** Some companies even formalize this like what Google did in the old days with 20% time.

In addition to your main project, can you allocate regular time to contribute to other work? By "get involved" in other projects, I actually mean "***add value***". So just stamping PRs with LGTM is probably not enough. 

It's important that you feel like an integrated part of the team if you do this, e.g. attend weekly meetings and have regular check-ins with the people involved.

If you can't find an easy project to get involved in, could you invent your own? This typically works better when you're more senior and have been at the company for a long enough time, but could you find something relatively straightforward and implement it? Before you do too much, make sure you talk to others to ensure they'd actually get value.

I like your approach to deliver valuable updates in standup, by asking the question "*what does my team actually care about?*"

The way I'd do this is to look at the top 2-3 priorities for your team (I guess, in your case, the whole company), and figure out how your work ties to that. Then in your standup update, make the connection clear. At the CXO level, they probably care about things like timeline, and anything you're doing that could speed up or slow down the shipping date. 

Related content about standups in Taro: 

- [**How to update in standup if we are spending time coding but are not blocked?**](https://www.jointaro.com/question/vFJsfI2ByVws6jbgXbnD/how-to-update-in-standup-if-we-are-spending-time-coding-but-are-not-blocked/)
- [**How do I give a good standup update on a fragmented team?**](https://www.jointaro.com/question/yN8OBFtUjVm5qYdGYGCb/how-do-i-give-a-good-standup-update-on-a-fragmented-team/)

For a startup, the core question is "**Have we achieved product market fit?**"

The definition of product market fit (PMF) is frustratingly ambiguous, but fundamentally, it means that the market (*customers*) are demanding your product faster than you can keep up. So if your startup is losing money, that's ok, as long as there's clear demand that people want the product, and there's a path to profitability in the future.

However, two things give me concern here:

1. To get to series C, there should be solid evidence of PMF. There's actually an expectation of this at series B, so it's worrisome if you feel there's no PMF yet. 
2. If the company does indeed have PMF, why would they build multiple products? That doesn't make much sense unless there's a clear narrative connecting the multiple products. 

Unfortunately, in the bull market of 2020/2021, lots of companies got too much funding when they didn't actually have a good business, which means that they're desperate now. I'd try to evaluate this in your startup by asking questions to leadership and also observing the behavior of smart people in the team. 

Related: 

- [\[Case Study\] Maximizing SWE Growth: Ownership and Specialization At Startups](https://www.jointaro.com/lesson/8hT0g5peO8fwDZmvvIFZ/case-study-maximizing-swe-growth-ownership-and-specialization-at-startups/)
- [\[Case Study\] Hypercharging Your Growth At Early Startups (w/ Staff Engineer Seed Zeng)](https://www.jointaro.com/lesson/yu7Y0b4gD7AiTiCJ5tVi/case-study-hypercharging-your-growth-at-early-startups-w-staff-engineer-seed-zeng/)

Similar to the advice we shared in the masterclass about [**joining a new team or company**](https://www.jointaro.com/lesson/n384HdJuDgulSHbHQLnf/masterclass-how-to-succeed-at-a-new-team-or-company-as-a-software-engineer/), I believe one criteria (perhaps the most important criteria) should be: the people you'll work with on the project.

I know you mention technical skills as the priority, but the people you work with will dictate how much you learn the skills.

The people will also be the best predictor of how much technical depth the project has. I recommend you look at the work of the potential people on the project and evaluate if you have something to learn. Look at:

- Their code commits
- What docs they've authored
- What meetings they take part in

I think it's a reasonable time to leave a job. Since the market is so contracted, you can effectively get a discount in equity if you are able to land a big tech job.

In your case, I'd carefully evaluate the startup. If they raised money in 2021 or early 2022, they likely got a bunch of money and a valuation that they're not actually worth. Double check what valuation your equity is granted at. In a startup, the people become much more important. 

The other consideration is job stability. You can't expect more stability in a startup in general, and this is especially true in this environment. So if you have special needs around immigration, for example, the large enterprise will certainly be safer. 

For your question about getting alignment asynchronously, the answer is **absolutely yes**. This will depend on the size and scope of the meeting, but I'd argue that almost all decisions can and should be made async. 

There should be a written record of the thought process, and I'd also recommend broadcasting out the decision with the explanation that "here's the tentative decision we made, which will be made final by Monday if I don't hear any feedback or concerns".

You should give people ample time to respond, but this is a nice forcing function to make progress: the default is to keep moving forward, and only have a meeting if someone shouts.

Two ways to evaluate (among others): 

- **How organized and efficient is the person who runs the meeting?** Once you've been on the team long enough, you can start to predict who you trust to run tight meetings, and who is scheduling meetings due to a laziness of not writing things down. 
- **For recurring meetings, what % of the past meetings did you actually contribute something important**? If you don't speak in the meeting for several weeks, you should start to question if the meeting is actually worthwhile. 

The other thing I'd focus on is taking detailed notes about what happened (doesn't have to be you, but someone in the meeting should be). Once you have the notes (both the meeting agenda and past meeting summaries), you can make an evaluation on whether it's worth going. <https://www.jointaro.com/lesson/vbRxLekspVWvgP1clpFw/taking-amazing-meeting-notes/>

Steve Huynh talks about his approach to meetings in this video about productivity: <https://youtu.be/Mj75QsirVHE>

@Michael, the video with Steve is coming out on YouTube in \~6 hours!! (This is the highly edited / polished version.) And I'll also be adding that in Taro for an ad-free viewing experience. 

The ones you see on Taro with the [Steve Huynh](https://www.jointaro.com/topic/steve-huynh/) tag are minimally edited, and I'll add more here in the coming days.

I love Lee's answer. Focus on the skills that will never go out of style (that's what we built Taro for!). I promise that the next ML technique, JavaScript framework, and even mobile development space has a pretty short half-life. 

Instead of thinking about your career 10 years from now, I'd work forward from what you enjoy doing and where you have a unique insight for the next 6 months or year. The world will be very different in 10 years. 

See also this very relevant video about [Why It Doesn’t Make Sense To Have a 5 Year Career Plan.](https://www.jointaro.com/lesson/g0IQZNUqI2oAkyGmF9oq/why-it-doesnt-make-sense-to-have-a-5-year-career-plan/)

Steve Huynh had some great advice about managing your career: <https://www.jointaro.com/topic/steve-huynh/>

I don't reply to recruiters **unless it's clear that they actually looked at my profile**. If they spent the time to comment on a side project I worked on, a position I have on LinkedIn, or my YouTube channel, they have effectively "earned" my trust that it's a connection I want to make. Perhaps this is a low bar, but connections are free!

My philosophy with LinkedIn is to blindly accept everyone who sends me a connection request. This will work until I hit 30K connections, which I'll hit in the next month or two. 

When it comes to replying to messages, though, I use the above criteria to see if I should bother replying.

I made a video about exactly this! <https://youtu.be/7jKkLv4oGs4>

The tl;dr (or, I suppose *too long; didn't watch*) is that **company tiers are a very rough approximation of the "best" companies to work at**. Generally, these companies will: 

- Pay near the top of market
- Have upward mobility for employees
- Be growing rapidly / is well-regarded for having talented people

Obviously, each person's priorities when looking for a job will be different, but people (hiring managers, recruiters, coworkers) disproportionately look at the above factors when coming up with "tiers". 

I'm very glad the US Government stepped in to restore faith in the banking system! There's probably some additional de-risking we could all do (e.g. spread money out across various banks), but honestly I don't think we'll change our behavior by much. 

As a startup (speaking from the Taro perspective), there is so much that we don't control, and frankly most of the macro conditions don't really impact us. For example, our revenues are small enough that a broader recession won't really hurt us. If there is a macro condition that leads to our downfall, there's probably a systemic issue and there will be a lot more concern than just Taro :P 

Could you share an example where something you said came across as bragging? I think of this in 2 ways: 

- **Work experiences**: you should absolutely talk about your achievements, but also lift up people around you and give them credit.
- **Non-work experiences**: if you think this could be perceived as bragging, I just wouldn't share it. 

Yes, you can (and should!) get away with doing this. **In fact, I'd encourage turning off notifications** from Teams/Slack/any other messaging service every day for at least a bit. 

The way I've seen some engineers do this to make it a bit easier on the team is to have some regularity around it. e.g. no notifications every morning, or that you're not active on these apps on Wednesdays. 

That way, if you are a single point of failure for the team, at least your teammates can expect or plan around you being slower to respond during those periods. 

**In general, it’s very hard to negotiate with your current employer, and even harder in this market**. To explore that route, I’d start chatting informally with coworkers, and potentially even your manager if you have a good relationship with them. Check if any of them had any luck negotiating their compensation with the company.

*Where this could work*: if the company is doing their annual salary adjustment. In these cases, you can suggest to your manager what you’re expecting, and justify that with some combination of (1) you’re doing more work due to the layoffs and (2) you have numbers from a competitor paying you more.

2 weeks feels reasonable to me. You can tell the recruiter that you'd like more time to prep for the final round and check their level of flexibility. At bigger companies, they won't mind at all, as long as you give them enough notice. 

The thing worth optimizing for is to get the final feedback around the same time. That means you probably want the ***final round*** interviews to happen within a week of each other. 

Relevant videos about negotiation: 

- <https://www.jointaro.com/lesson/YliP9kVbd1zym9kmv9Gg/the-key-insight-behind-negotiation/>
- <https://www.jointaro.com/lesson/8VeEnbxdbPKsZbTcCFm5/3-quick-powerful-negotiation-tips/>

It's good you've done some reflection on what has historically been the issue when applying for these roles ("*half is due to anxiety/freezing up and the other half is inexperience with DSA*"). If you know you can get interviews and your reflections are indeed the primary issue, I think having some accountability would help. But because these programs require a big commitment, it's good to validate that through some failed interviews first.

By the way, in the Taro Premium Slack, we have a few people who have done Formation.dev who may be worth talking to about their experience. 

In the short-term (next few years), **there will still be ample job opportunities for general software engineers**. I talk a bit about this in the video about [ChatGPT vs Bard](https://youtu.be/qShBoH_rbs4). The impact of AI is that it'll make a good software engineer even more productive. An engineer from the future can get as much done as a team of 2-3 engineers today.

However, the demand for novel software in the world is very, very large. This appetite means that software engineers will remain gainfully employed (assuming you can use AI tools effectively).

In the long-term, *I'm not sure* :P But I'd also argue that it doesn't matter. So much about the world and your experience/skillset will change in the next 5 years. I don't really believe in planning out your career more than 5 years. 

Can you easily check with your teammates how they feel about the manager's behavior? Ideally, have this conversation in person with people you trust (in a walking 1:1, for example). Just knowing that others empathize with your feelings can help, and it can also help in terms of next steps.

In general, as Alex mentioned, **Human Resources is designed to protect the company, not you**. So I'd recommend not going to HR unless you have evidence of others experiencing similar issues.

If you want to express your thanks, then do it through the recruiter. (At a large enough company, I honestly don't think it'll matter much since there's a well-defined process to prevent bias.)

I remember at Meta, there was actually an incident where interviewers found it annoying to be contacted after the interview ended. I'm sure your thank you is innocuous, but looking people up on LinkedIn could send a negative signal unless they've explicitly indicated that they'd like to do that. 

If you want to stand out here, I'd thank the recruiter and ask them to pass along the feedback. In your thank you note, **mention specific details of the conversation** that you thought were very interesting and insightful. This will increase the chance that your interviewer forwards your email or mentions it to the relevant people.

Most of the time, passive income is not actually that passive 😅 you have to put tons of effort (often for years) before you start to see any real benefit. 

The way I'd think about this is to choose a path where you can't lose: you gain valuable skills by producing the thing (blog, video, podcast), and if you actually succeed, the money is a nice bonus. 

For context, my YouTube channel made $9K in 2022, after I spent 2 years working on it, around 10 hours/week: <https://youtu.be/KY-L6CoMDEw>

Well, it's not a good sign... :P 

But my assessment would depend on details around ***how*** and ***why*** this change was made:

- What was the reason they cited about why quality assurance was disproportionately impacted by the layoffs? 
- How much automated tooling exists? (all levels of the testing pyramid: unit tests, e2e tests, etc)
- How has the quality of the company's software been historically? What have been the main problem areas?

The strategy of "*hope that engineers push great code*" feels foolish, since this is almost impossible to do 😅 So you better have a very mature infra around linters, issue detection, and alerting. 

I love Touseef's answer.

One of the challenges in your case is the sheer amount of stuff you could learn. There are 9 services and the surface area is huge. That can be overwhelming.

Here's the life hack I wish I knew earlier: spend 10 minutes upfront (each day or each week) to decide *what* to dive into.

Look at where the code is actively being modified, where the discussion is happening, and work backwards from alerts.

When you parse out what is actually important for the team, you create direction (and motivation) for deeper learning. 

I like Michael's answer a lot -- it's fine to reschedule a 1:1 meeting in good faith and not feel guilty about it (especially if you've only done it once).

However, the fact of the matter is that there likely is a power dynamic here. The director is likely busier than you (as an E5), and perhaps they perceive the "opportunity cost" of a no-show on a meeting to be a higher.

In general, I really dislike when people cancel meetings a few minutes before they're about to happen. A few tactics to prevent this from happening: 

- Send an agenda ahead of time. Doing this legwork shows that you're serious about the meeting and it's not just a general catch up that someone can dismiss. Put the agenda of the meeting in the calendar invite or in a running 1:1 doc.
- If someone does this, send them a message saying "I understand you're busy. When is a good time to reschedule?" So they don't just cancel the whole thing. 

A go-to question for me: 

> What is your least favorite part of this job? What have you tried doing about it?

You can compare the answers with Glassdoor, and the attempts to fix it will also be telling. 

The answer depends on your goals. An MA objectively means you're doing fine (no risk of getting PIP'ed). However, if your expectation was to get the E5 promotion, there is likely a gap.

It's possible to get promoted with an MA rating, but it's rare. Statistically, an MA rating puts you in the bottom 60% of people for E4. That's perfectly fine, and in some ways, that's expected since you joined the company recently. But the data does matter!

I'd chat with your manager in a bit more detail about the 4 engineering axes at Meta (**project impact**, **engineering excellence**, **direction**, and **people**) and check if that confirms your internal sense of how you were doing.

BTW, we're planning to capture this data with [promotions.fyi](http://promotions.fyi) :)

Short answer, *not really*.

As a developer who works in the terminal (not all devs use CLI tools), you should know your way around at least one command line editor: emacs, vim, nano, etc. You don't need to be a wizard, just know the 5-10 commands to do basic navigation/editing.

I am partial to emacs :)

However, at this point, almost all engineers realize the magnificent power of IDEs and the joys of things like visual debugging and completions. **If you had to invest in learning vim/emacs deeply vs learning your IDE deeply, you should definitely pick the IDE**. Since you spend more time there, it'll have way more impact.

(shameless plug: I did a conference talk about improved efficiency within Android Studio: [Android Studio Shortcuts](https://www.youtube.com/watch?v=HLQUtLbjW98&list=PL7NYbSE8uaBBUYfGl1GaKY8GCp5E1Ypkg&index=2)

Another perspective: sync with your team about what kind of interview each person wants to conduct. It’s fine to do code debugging vs live coding vs DSA, but what you want to avoid is randomness -- **the interview experience should not be completely different based on the interviewer.**

IMO the test of a good interview (for both the company and the candidate) is “*if this person came in and interviewed on different days with different people in the office, how much would the various assessments agree?*”

I agree with Alex that you should simply not tell the recruiter. In general, I see a tendency for engineers to **over-share** when they talk to companies: 

- Performance at previous jobs (e.g. whether you were [PIP'ed](https://www.jointaro.com/lesson/7SsdpweHE4sbyTtz2kxQ/the-key-to-avoiding-the-performance-improvement-plan-how-to-figure-out-where-youre-trending/) or not)
- What level you were/are
- What compensation you're expecting

There's an information asymmetry between you and the recruiter. They look at hundreds of applicants per day, so **you should not share too many details unless there's a benefit for you**.

---

Tactically, here are some phrases you can use to gracefully talk about why you left: 

> I learned a lot in my previous role and I know a lot more about the ideal environment for my impact and success

You're hinting here about potential issues you faced, but it's a much more positive spin in terms of your learnings

> I'm really excited for this new opportunity for X reason

Focus more on the job you're applying for rather than the job you left. X could be the company, tech domain, the people, etc. 

First, I want to acknowledge that this is actually very common! I personally faced this when I was transitioning into a TLM (tech lead manager) role at Meta. The classic story arc is: 

- You are a good engineer and develop lots of context after several months or years on the team.
- As older people leave the team and newer ones come in, you find more of your time going into mentorship, helping others, and on-call support.
- You find it increasingly harder to do your own job given the additional demands on your time.

There is actually a healthy tension where you feel like you're doing multiple jobs -- that's the point where it's valuable to re-assess your job and ask for help. I have a few thoughts:

- Document where your time is going in a given 1 or 2 week period. Then categorize it in 2 ways and have a discussion with your manager.
  - Time you enjoyed vs didn't enjoy
  - Time you thought was well-spent (e.g. 1:1 time) vs wasted (e.g. asking the same question over chat)
- Try to move a lot of your knowledge sharing in more public forums, and encourage others to jump in as well. 
  - For example, if you find yourself saying the same thing 3 or more times, ensure that it lives in a wiki somewhere, and be diligent about sending the wiki link to people instead of repeating yourself again. 
  - Create a forum/chat for questions so they don't all go through you. Provide an opportunity to the others on your team to answer questions before you jump in.
- Write down what work you'd do if you didn't have the tax of all the glue work that you're doing today, and how much impact that would drive. Doing this should make it clear that it would be the highest leverage thing. 

Once you have this buy-in from your manager, you hopefully have a strong ally in empowering the others on the team. Also, keep in mind that the benefit is not simply your ability to do higher-leverage work, but also that it creates a more resilient team. 

Here's some related content:

- [Giving feedback (part of the Effective Communication series)](https://www.jointaro.com/lesson/2AMacpeOvubb33Nm4exk/effective-communication-guide-part-5-giving-feedback/)
- [Improving on-call systems](https://www.jointaro.com/question/ScxFpybXXC90qmnLEU7A/how-can-i-improve-the-unstructured-chaotic-oncall-rotation-im-on/)

**A good manager is rare**, so my first instinct is to figure out if there's a way to make this situation work. A couple considerations on whether to switch projects or not: 

- As a senior engineer on the team, are you able to craft a new project or initiative that you would actually enjoy working on? 
- Is there something you can "take with you", e.g. a promotion or milestone that can help you get to E6? Switching teams means you'll have to rebuild context and relationships, so make sure you're aware of the time cost of that. 

Given that you don't like the people on the project, that feels like a good reason to switch teams. Keep in mind that if you switch projects (and not teams), there's a decent chance you may still get stuck working with the same people. Staffing on projects is prone to change among team members.

In terms of bringing it up with your manager, 

- You typically want to frame your request in terms of "I'm going toward something" rather than "I'm running away from something'. That means you should do some research before talking to your manager about an idea or pre-existing project that you're excited about.
- Timing should be when you've made the commitment to switch projects/teams. If you waffle on the decision, you'll cause confusion for yourself and the team, and you will likely lose trust with your manager. I wouldn't be too concerned about whether this is 9 months vs 11 months vs 1 year. 

Here's another great discussion about changing teams within Meta: <https://www.jointaro.com/question/dMNWpXZPWuqm4mPvkJl6/when-is-a-good-time-to-change-teams/>

Are you exploring both internal and external opportunities in parallel? 

How do internal transfers work at your company? If your manager has a lot of power in choosing/blocking your next team, then I'd honestly prefer an external job change. Given your troubled relationship with the manager, it'll be hard to have a clean break from them (also depends on the size of the company). 

If you do want to do an internal transfer, I'd definitely give your manager a heads up and frame the conversation with a few of these points: 

- **You're grateful for the time you spent on the team**: the experience you had and the learnings you had.
- **Talk about the team/project you may join, and why it's exciting** (you should do this thinking before meeting your manager). You don't want to make it seem as though you're primarily leaving the current team. Instead, you want to make it seem as though you're excited about where you're headed.
- **Talk about the benefit to the company**. You can bring up the issues you've had with the Principal Engineer since that's no secret. Talk about how this will allow everyone to move faster and get more done. 

Some other great discussion about team switches: 

- <https://www.jointaro.com/question/gNdtZf6N2SxohS3YBS0u/how-to-talk-to-manager-about-switching-to-another-team/>
- <https://www.jointaro.com/question/sSgN28DhieydqHg0Zwxa/switch-companies-or-team/>

Another thing to consider is for what task you want increased productivity? For example, with the [Taro blog](https://www.jointaro.com/blog/), we've talked about the idea of using generative AI tools (either ChatGPT or tools like Jasper) to help write blog posts for us. High quality blog content will improve our SEO rankings, which can help improve the Taro business. But I imagine that won't be as useful for software engineers.

I'll share one that feels most obvious to me. *Obvious* in the sense that, in a few years, people will wonder how we ever wrote code without it: **Github Copilot**.

[Github Copilot](https://github.com/features/copilot) "is a cloud-based AI tool developed by GitHub and OpenAI to assist users with autocompleting code" I've been using Copilot for a few months and it has easily increased my productivity by at least 30%. Installation took &lt; 5 minutes since I already use VS Code anyway. 

The website shares some compelling stats on the use of Copilot: 

- 88% of developers feel more productive
- 96% are faster with repetitive tasks

In my experience, Copilot won't get the code exactly correct (we use Typescript but it still can't get the property names). But in some situations it can effectively write 80% of the code for you, which is a huge time savings. 

For a company to get 30% more efficiency from their developers is incredibly valuable. I'd recommend you checking it out and seeing how you can customize it / improve it for your workflow, since this will become more and more ubiquitous in coming years. 

It seems there's a pattern of disagreement and dysfunction between you and this E6. Zooming out, can you **reset** the relationship with the E6? 

Don't worry about a specific project, issue, or deadline. Can you just have a "get to know you 1:1" and figure out how they work and what their motivations are? 

Sorry to hear that you were laid off, but seems like you were able to get some good offers shortly after.

> How should I notify the manager at company B and explain them the situation?

I'd just explain that you really love the new project/team/scope available at company C. Employment in the US is at-will so you don't need to worry too much about how to justify this. It's pretty common for employees to hop around. Just leave respectfully in such a way that you don't burn bridges.

> How and when do I notify company C that I had to join company B to maintain my visa status?

Why does company C need to know this? No need to reveal anything that isn't necessary for your employment with company C.

> I’m afraid that company C would think bad as I’m leaving a recently joined company B (what if the company C’s recruiter think if I will do same with them in future)

Are you getting any signal from the recruiter that they think this? Have you done this in the past? I wouldn't assume this to be an issue. If it comes up that you're leaving company B relatively quickly, spin it as a positive: "I'm really excited about the work at company C, and I felt like this was an opportunity worth jumping in right now for."

> What if the company C does layoffs after joining them?

This is something you probably don't have control over, but you should evaluate the safety of company B vs company C. Take a look at this related question: <https://www.jointaro.com/question/UCG4XxyEOTjjyg4pEuwY/how-to-evaluate-a-startup/>

> Is there a possibility to make sure anything(s) with company B to burn as less bridges as possible?

When talking about your decision to leave, **focus on where you're headed (company C)** instead of **what you're leaving behind (company B)**. This way, you avoid saying anything negative about your previous employer, and it leaves the possibility open that you can come back.

David had a good perspective about utilizing [skip level 1:1s here](https://www.jointaro.com/lesson/TToehFEc738PBhJcALwL/how-to-effectively-leverage-skip-level-11s/) -- many of those ideas wqill apply to this question.

The unique perspective that the VP has is a broad view of your organization and how it fits in with other parts of the company. This VP probably hears about (and has to deal with) the most urgent fires across the whole company. So just asking about their concerns and priorities is very instructive.

Another think to ask about is open-ended questions on an interest you have. For example, "I really care about privacy work but I don't feel like we ever properly allocate time for it. This is leading to X and Y issue -- I'm wondering how you think about that?" This is effectively a soft challenge on the org priorities, but, if done respectfully, you can gain credibility and trust which will be valuable for your future career.

Some things to consider for any role:

- How many people do you know at the company?
- When was the last funding round of the company? 
- What are your career prospects? Especially if there are differences in pay/promotion as a software engineer vs SRE.

There is no separate test database for Facebook. There is a notion of a test users, but AFAIK, the test users are actually just interacting with prod data. There is a pretty robust internal tool to manage test users, have them be friends with each other, and configure them appropriately (e.g. have them be located in a certain country, have a specific gender, etc). 

At least for mobile, I'm pretty sure that for the vast majority of the life of the mobile apps, there were very few mobile apps. Testing has become much more important recently, and I believe there are some internal frameworks to allow e2e testing as part of the CI system, but these things are in constant evolution. 

If you're trying to learn, I'd look at engineering blogs that talk about testing. If a company writes a blog post about it, they have a well-defined (and stable) enough system that it's worth learning from.

Stripe has a very robust test framework (as you'd expect for a company where the core value proposition is billing + checkout!). I'd highly recommend looking at their system of [fixtures](https://stripe.com/docs/cli/fixtures) to mock a series of API requests and force the mocked API to return the same data each time.

There are generally 2 ways to do A/B testing at Facebook (note: Meta is so large now that I'm sure various orgs may have built specialized tools at this point): 

- **Gatekeeper (GK) framework**: If you have a simple binary experiment ("check the impact of this button being red or blue") then you can use a gatekeeper. You set the condition of which user gets which treatment, and then the framework will compute various stat sig metric differences
- **Quick Experiment (QE) framework**: This is for more complicated, multi-bucket experiments. You still use GKs to decide who gets into the experiment, but this system lets you compare an arbitrary number of test cases and a control.

There's a bit more nuance around things like experiment setup, universe setup, and how long your experiment needs to run. 

What do you mean by "trunk-based'? Almost everything at Meta is going to be based off mainline. There are very few long-lasting feature branches. 

One way to evaluate this is to look at where company alum go -- do they start companies, join startups, go to Big Tech, or are there lots of lifers?

You know the quote "you're the average of the 5 people you spend the most time":

You'll likely be the average of the 5 engineers on your team, so where they end up is very important for your future career.

Another dimension is longevity at the company. My sense from some of the companies in bucket 1 (many finance cos) is that they are much more performance driven -- some people have an actual PnL attached to their head. So if you're looking for more exploration and learning, I'd lean toward a more supportive environment (typically a well-funded company, and many other "tier 2" companies).

> I got a \~33% from the current compensation & SDE - II role offer

What does this mean? Generally you have a few components to your offer: 

- Base salary
- Sign on bonus
- Equity
- Bonus

One tactic is to ask for more of one component and less of another, e.g. more equity while taking less salary. When you're ready to commit, you can say something like "I'm ready to sign the offer if you can provide X amount in signing bonus".

Don't commit to anything on the call tomorrow. Just say "interesting" to whatever they say, and ask how they arrived at those numbers. 

What I've heard as a reasonable onboarding timeline for very senior folks \[Staff+\]: 

- Your first half, you should operate as a senior engineer \[E5\]
- Your 2nd half, you should operate as a staff engineer \[E6\]
- Your 3rd half, you should operate as a senior staff engineer \[E7\]
- and so on...

For the very senior levels, it takes months to ramp up on the context / relationships to be effective.

> What would I discuss in the regular weekly 1:1s, in case I run into this problem in the future?

I'd treat these as somewhat similar to your manager 1:1s. You're not looking for approval on your work, or for what to do next. Instead:

- Discuss your interpretation on the project, and what concerns you might have. Invite feedback.
- Ask for guidance / mentorship where appropriate.
- Discuss higher-level things beyond the project, things like how the team is operating, or what other priorities each of you have.

I'd keep a running 1:1 doc for each of these -- your purpose is to build a longer-term relationship that is bigger than the project.

I have a story to share on top of the great answers from Kuan and Alex. I also don't think there's a single tech/framework you need to focus on. In fact, being really deep in one technology can be a huge asset when you do switch teams. 

At Meta, there was a very senior (E7) engineer who worked on the continuous integration system, then transitioned to working on Android app development. Pretty different area, but he was still amazingly productive since they **knew what questions to ask** and they came in with **deep first-principles thinking**. (There was certainly some overlap with the CI system and mobile builds, which helped.)

Here's a great response from Rachel Zhao: <https://www.jointaro.com/lesson/FzvHLUprcYonudsxnJc2/whats-the-difference-between-a-senior-and-staff-engineer/>

She mentions that Staff Engineers should have enough influence and context that they're able to describe *what* to work on in addition to *how*.

To add to Alex's great answer, I'd say that you should also feel free to communicate with the recruiter: 

> I'm interviewing at a few other companies and would like to align the interviews so I can make the best decision for me and the companies I'm considering. Can you tell me how long your process will take and how much flexibility you have in scheduling?

You don't have to reveal the names of the other companies. Most recruiters are willing to work with you on timeline. Your next job is a big career decision -- you deserve to have sufficient data to feel good about your move.

In the last example, it's clearly documented that the E8 engineer was just flat-out wrong, right? They simply weren't careful enough in the earlier sign-offs. 

It's unfortunate that all 3 of the EMs you escalated to ended up resigning, that's just bad luck. But you still have a *paper trail* of what happened here for whoever does end up advocating for you in calibration. 

I have two meta-points:

- **Position yourself to work on projects that don't have as much ambiguity**. You probably have a sense now of which projects are prone to having changes (or, perhaps more accurately, **which people are prone to causing changes**). When you do your half/quarterly planning, orient yourself toward projects where you have a pretty good idea of what's required / don't need approvals from mercurial people.
- It sounds like you don't have great relationships with these senior folks, which is not good. You don't want to deliver a completed project *despite* the others -- you need to do it with their blessing if you want to get promoted. Can you schedule regular weekly 1:1s with the people who have given you headaches in the past to avoid miscommunications? 

Yep, I think being candid about your mental health struggle and figuring out a transition plan makes sense. I'd come into the conversation with your manager with the answer already decided (*you're not asking for permission*), but you're trying to be a good teammate in terms of timing and transitioning your work while you're out. 

- In big companies, you'd be surprised how often this happens (it's just not talked about that often), and there's a pretty well-documented path to proceed.
- At a small company (not sure how large your series B company is), the process might be more ad-hoc. 

There may be some way to figure out the optimal timing to maximize pay / ability to switch teams in a series B company. If it's easy for you to casually talk to others on the team, you could consider that. But given the paramount importance of your health, I wouldn't worry about this. 

If you're using a side project in order to land a job, the lens through which to evaluate a side project is "**how easy is it for people to judge your work?**"

Here's the reality: **99% of recruiters and hiring managers won't bother to clone your Github repo, download your app, or checkout your interactive website**. So my bias is to spend time on things where it's clear what you've done.

That's one of the reasons I mobile apps: 

- The fact that you published the app is already impressive
- The Play Store / App Store show your avg rating and number of downloads, so it's clear if you actually have users
- Looking at the (structured) app store listing for 10 seconds provides lots of data about your attention to detail, grammar, and basic design sense. 

But in your field of Data Engineering, you could find a project which has similar properties around being easy to show-off. For example, could you do *something* with the DE buzzwords (Airflow, Spark), but apply it to book sales or movies? Then make a really dead-simple infographic that a charlatan like me could understand. Now you have my attention!

The other approach is to start with people around you. Could you grab your super-smart lawyer friend and see what interesting data questions or data banks they have access to? This will give you motivation to finish the project, along with someone who can tell you if your results are actually meaningful.

My approach here would depend on the context -- given what you said (thanks for the background!), I would just agree and then re-evaluate the situation over time.

The people at extremes have the most to lose, so they'll be the most vocal about the RTO policy. For example, they may have already moved out of state. Since the burden for you to come in is not *that* high, I'd see how things play out.

The thing with RTO policies (or any large-scale employee behavior change) is that they are **always in flux**. The company will try it out, determine that full-week is too much, then ask people to come in to the office just 2 days/week, and then eventually they may decide to make it optional.

You speaking out is not necessarily a bad thing. In fact, it could be viewed very positively if you phrase it as "I really want this RTO plan to succeed, so I want to ensure that there is a critical mass of the team here on the days that we come in. I'm wondering how you think about that, or if there are specific days we should pick to come in as we get started?"

If things are indeed fully back to in-person, and you don't like it, you can explore a different team, discuss more flexible work hours, or apply to be a full-time remote employee. Point is, there are lots of options you could explore at that point. 

Building the trust back up will take time, there's not a quick solution around around that. However, it sounds like your manager is supportive and understands the personal situation you had. 

Focus on doing on-time, high-quality work. To speed up the process, I'd also look for additional projects you could take on to improve the team.

> I wonder if I need to again prove my credentials to keep me on track for L5

Something I'd **highly recommend** is to remove some of the ambiguity you're facing and have a candid conversation with your manager. Ambiguity leads to anxiety, and that can't be good for your mental health. You're making a bunch of assumptions about your performance, but I'd be really curious to hear what your manager thinks. Some pointed questions you should ask: 

- How am I doing relative to your expectations of me? 
- What are the major areas I should work on as I work toward L5?

It sounds like you're predicting the answer to some of these, but hearing the actual words will really help you form the action plan. 

You're right that the best way to develop this skill is to actually write lots of code with talented people around you. 

If you don't have technical people to review your PRs in work or side projects, an alternative is to contribute to open source. **That's the beauty of software -- if you put in the time/effort, you can find great people to work with pretty easily**! One open source project that comes to mind (and one we use for Taro analytics) is [PostHog](https://github.com/PostHog). They have tons of repos and I'm sure you could find something to contribute to. 

I don't have any recommendations off the top of my head for books/courses. I'd probably start with looking at respected developers in the field and following their blog posts or code contributions.

Sorry for the delayed response! Yes, I definitely agree that discussion over the PR will be frustrating and take much longer. I'd start a group chat to get everyone on the same page. 

If you feel like there's enough ambiguity in the project, you may also schedule a meeting among the people involved.

If you **still** feel like there's no agreement, I'd then escalate to your manager. 

Sorry to hear that you are exhausted -- I imagine morale is quite low, and you have even more work on your plate now.

You came up with great ideas! One question to ask is what type of work you genuinely would enjoy. You mention "I currently don't have significant project assigned to me because I have been the person who owns the backend system." I know many engineers would not be happy with just on-call/maintenance work -- if that's you, you should say something to your manager / skip manager. 

- You can ask that the team hire someone ASAP to share the oncall burden with you. 
- You can ask to allocate time to project exploration for something that you're interested in, and gives you promotion-ability (if you care about that).

The silver lining of the layoff is that you do have some additional leverage with the company, since they are clearly relying on you. You should absolutely take vacation when it's mutually convenient for you and your team.

Finally, I like your idea of forecasting busy periods. Sometimes it's ok for us to be exhausted if we know that there's a lighter period coming, e.g. things will be busy until Valentine's day, but then become much lighter. Identifying the lighter periods with your manager will probably help a lot. 

The codebase for most high-growth tech companies is very, very far from perfect. On my teams at Meta and Pinterest, there were often **entire modules that had no tests**. This is especially true for the mobile (Android) teams I was on, where tests were often considered a nice-to-have.

I don't have much opinions about SOLID or other principles. Honestly, it's never really come up unless you're doing a completely blue-sky project (which is rare). 

What kind of startup will you join? The answer obviously depends on how long it's been around, how many engineers it has, etc, but my initial reaction to 100% test coverage is that it's too extreme. 

As a new engineer, I'd spend the first few months simply following the existing patterns. Don't try to introduce new patterns. There's probably a reason why the company's codebase looks the way it is (the answer may very well be something unsatisfying like, "we've had higher impact work that needed to land"), so make sure you understand that before proposing any changes. 

My initial reaction is that this is a premature concern. The scope of work for each of the people on your team is important, and you're a very thoughtful TL for thinking about this. 

**However**, the TL should focus on decomposing the project into phases where, with each passing week, it is progressively de-risked. As TL, you can/should also break down the work into high-level workstreams. Then I'd focus on getting buy-in for your plan, and most likely you'll adjust the plan based on feedback from other leads/managers.

After this is done, **then** I'd focus on figuring out the assignment of people to parts of the project. Present this as more of a conversation rather than an assignment. The lens through which you delegate (or not) should be based on what's best for landing the project, not based on the people.

In a healthy (high-growth) organization, there's more work to be done than there are people to do the work. So your team will naturally orient themselves based on the criteria of what maximizes the combination of their skill level and project impact. 

Whether to try or not depends on the **cost of trying**. If it's a couple of hours of time and the potential outcome is a life-changing job, then it's for sure worth it. Especially if you think there's overlap in the work to get into Big Tech vs other jobs you're pursuing.

RE: the process through which you apply, IMO there are more effective ways than just going through open positions on company websites. In fact, since the barrier to applying in a company jobs portal is so low, you're likely competing against thousands of candidates if you do this.

I'd instead push you to figure out ways where the candidate pool is smaller. For example, a career fair at UCSC, or tapping into the alumni network, or networking at a meetup for some app/tool you've built. Relevant video: <https://www.jointaro.com/lesson/pIMdopWoJFfbANnzo7U5/how-to-get-faang-interviews/>

- The Taro network can help :) <https://www.jointaro.com/lesson/mrltjyQmSRqHf82WULku/how-can-taro-help-me-find-a-job-9272022/>
- Finally, you'd be interested in the pros/cons of working in Big Tech: <https://www.jointaro.com/lesson/CRKwIs5EqsWanWXDkqP1/the-pros-and-cons-of-working-at-faang-and-big-tech/>

Trying to obfuscate the complexity of the project is a losing strategy. Even if you are able to successfully do this, "*confusing*" is not the word you want people to describe you / your work as. The best engineers make things as simple as possible, and they get credit for helping others (especially from more busy executives) understand the core complexity/challenge of their work.

I think a better strategy is to **extend** the scope of your work so it has more impact. I wouldn't seek out complexity, just focus on getting more users, more impact, etc. 

The company would ***like*** to keep the severance packages the same, but, unfortunately, it frequently goes down.

A very common failure mode for startups (and larger companies to a lesser extent) is that they don't cut deep enough when making layoffs. What typically happens: 

- The company lays of 10% of the staff, optimistically hoping that the economy/company growth will turn around soon.
- A few months later, it becomes clear that more cuts need to be done. The company decides to let go of another 10% of the staff. 

Since multiple layoffs within a company is **horrible** for morale, the subsequent round of layoffs indicates that the company is in a dire economic condition. With few options remaining, these companies will cutback on severance as an additional cost-saving measure.

However, larger companies like the ones you mentioned will generally be more employee-friendly here. All these companies have very healthy balance sheets, so 10s of millions of dollars here or there don't matter all that much :P 

Your ability to have impact in these meetings comes from providing concrete data points and anecdotes from being "on the ground" as a senior IC. Unlike the Directors, your head is not in the clouds. A few ways to contribute:

- Present data and insights from your area
- Draw connections between various projects, e.g. shared infra
- Bring up potential problems and delays that are relevant for planning

See also some of the great resources here: <https://www.jointaro.com/question/Ivo1RsizAMGoGKXmqg6N/how-to-develop-soft-skills-like-leadership-stakeholder-management-etc/>

<https://www.jointaro.com/question/aLIUO4g83nVuZ4Q9eh7R/e5-how-do-you-show-technical-leadership/>

Do you **need** permission to get started with your ideas? e.g. could you run the integration tests as non-blocking on every build? So it doesn't slow anyone down.

- Then show how X number of bugs would have been caught earlier with the integration tests.
- Once you show the impact, it'll be much easier to get people onboard.

Here's a good Q&A from a while ago about this: <https://www.jointaro.com/question/wWlLItsSq4zSb6Trztv6/how-to-build-culture-of-owning-technical-debt/>

First question, how much do you care? How much ***should*** you care? If there are other ways to resolve the issue (e.g. talk to another manager, talk to the team, etc), those will likely be faster and easier.

In terms of talking to the director, my advice is to focus on "***dynamic over substance***". The way you present your concern makes a big difference in how it is perceived. 

- Write down the issue (with examples) in a one page doc instead of just sharing feedback verbally. 
- Talk about the negative outcome for the team if the problem continues.
- Propose solutions and just ask for feedback ("yes, that plan sounds great") 

I strongly believe you **should not** pursue ask for a voluntary layoff, unless you have an example of someone doing this successfully at Google.

More likely than not, your manager won't be able to offer you a voluntary layoff, and the cost of getting this wrong is that you are "tainted" -- as a manager, I wouldn't want to give you a high impact/high visibility project since you'd be a flight risk.

In addition, since the Google layoffs just happened, I don't have faith that Google would have the infrastructure in place to do this kind of thing. Remember that Netflix is a very unique culture where they explicitly say "***adequate performance gets a generous severance package***".

Thank you for sharing the context. 

I first want to question the assumption around what is needed for E4 promotion. You may be totally right that you need wider scope, and you have to become a mini-TL for one of the domains you point out, but that's worth clarifying. Have you already had the discussion with your manager about how you're trending relative to E4 expectations, and whether the work across 4 projects might suffice? 

At E3 --&gt; E4, I feel like the need to have one major launch is **not essential**. Especially in your case, if your team is strapped for senior engineers, I'd expect that the "let's get the job done" mentality is sufficient for a promotion to mid-level engineer. And sounds like you have good code output, which IMO is most important.

However, I can still understand your frustration since it's probably less fun to work in this scattered approach. And having depth in one area is generally better for long term career growth, where people think "*I can definitely come to you with any questions about this system*". 

I wonder if you could do that on the side, e.g. you pick an area where you dive deeper into, and spend your extra cycles in improving documentation, adding tests, and going above the call of duty. So you become the de facto lead of that area anyway.

Finally, I agree with Alex that I don't think your skip-level manager has much value to offer here, unless you can connect this issue with a broader team dynamic that is worth their attention. The failure mode of going to your skip is perceived as complaining about the situation you're in.

Use a conversation with the skip level as a way to understand the broader strategies of the org. Ask questions about their priorities, and try to provide some value by sharing your perspective "on the ground" as an IC engineer. 

David Pan talks about this here: "[How To Effectively Leverage Skip Level 1:1s](https://www.jointaro.com/lesson/TToehFEc738PBhJcALwL/how-to-effectively-leverage-skip-level-11s/)". 

Elon is good for creating shareholder value, but my impression is that he's not a fun person to work for :)

Because of the poor work/life balance, I think some engineers wouldn't want to work there (so perhaps a bit less prestige). But then you are working on a product which is universally regarded as amazing...

I'd talk to people during the interview process and figure out their background and why they chose Tesla.

This is an example where having informal, low-stakes conversations (e.g. over a coffee/lunch) is really valuable. I'm almost positive there would be other intern --&gt; full-time conversions in your org, or perhaps other interns. 

From talking to them, try to understand things like: 

- When does the conversion conversation take place?
- What % of interns get a return offer? 
- If you can, take a look at their code output / impact and compare it with yours so you can better calibrate. 

Once you have sufficient information, I'd bring it up with your manager like Alex suggested. Another possibility is to bring it up with the HR/recruiting team, depending on how well-defined the internship program is.

By **employment status**, are you referring to whether you got laid off, or to your legal ability to work in the country? 

My answer is the same as Alex's in either case: you probably should reveal this. 

- If you were part of a mass layoff, there's less stigma around a layoff. 
- If you have are an H1-B or other position which requires you to quickly find a new job, your employer would find out anyway, right? Since they'd have to transfer over your visa? If that's true, you may as well reveal it earlier. If not, I could see the argument for keeping it private in order to gain more leverage. 

One thing to ask: what valuation you’re getting these shares? Ideally, you don’t want to come in at the 2021 valuation, when in reality the stock is marked down 30-50% now.

A negotiation tactic: when you're ready to sign, just say "I will sign if you can provide a $20K sign-on bonus". Most companies are able to throw some signing bonus if they know you'll commit.

One way to think about it is, how many people are you influencing? An entry-level engineer might influence 1 or 2 people, but the CTO should influence the whole company.

Now, based on that, the people you talk to and the context you try to gather in onboarding should match that.

Mo talks about the expectations at each level in his talk: <https://www.jointaro.com/lesson/Tr3bHl6mIVsmZZ6BAQLc/session-9-how-to-become-a-data-guru-as-an-engineer-w-senior-director-of-ds-mo-shahangian/>

In addition to the resources on Taro, I'd also recommend you figure out a low-stakes way to have these conversations with a co-worker. Ideally someone not in your reporting chain, someone who won't judge you.

You can even use Taro for this if you have specific questions! We have a bunch of DoorDash engineers here. 

One thing to understand is the process through which they get things done. 50 people is large enough where not everyone knows all the projects going on, but it's likely too small/new to have a bunch of mature processes.

Also, get a sense of the financials. Understand how they actually make money. 

I touch on this in a YT video: "[Inside The New Layoff Era of Big Tech](https://www.youtube.com/watch?v=VEMhb6GiKxs)"

I have different take from Lee or Alex: unless there's a benefit to you, you should **not include graduation year**. For example: 

- If you've been promoted quickly, hiring managers may hold your recent graduation date against you and not offer your desired level. (e.g. I applied to Senior SWE roles with 3 YoE)
- If you are breaking into the tech industry after a career switch, hiring managers may think you're too old for a junior role. (FWIW, I certainly don't think graduation in 2018 makes you old!)

I kind of view this as getting a PIP, or being an expectant parent. Unless there's a benefit to volunteering that information, you should not. 

There are times when displaying your grad year could help you, for example, if you're applying for new grad roles, or you're part of some cohort-based program.

Update: the full session about "How To Survive Tech Industry Layoffs" is now live. <https://link.jointaro.com/vW7adT5fKM4eKLsm9>.

Meta, Pinterest, Kosei

Evaluate where you have an unfair advantage: 

- You have a deep working relationship with someone at the company. 
- You have expertise/side projects/passion for what they're working on
- You have a shared background (alumni, geography, gender) with someone who can refer you

Use these to decide if it's worth cultivating the relationship. 

Do you have reason to believe that the roles would fill up? Or do you feel like you're applying for specialized, very senior roles? 

- **If so**, you may want to at least hop on the call with the recruiter to keep the lead warm, and then stretch out when you start the formal interview process.
- **If not**, you should not feel pressured to talk to recruiters. The same role will exist in 3 months or 6 months as well, and you saying "not now" may actually improve your desirability as a candidate.

In general, recruiters will try to sell you on how magical and rare an opportunity is, but it's almost always BS. You should make your own judgement. If the company reaching out is a small startup (&lt; 10 engineers), there may truly be some urgency. But for most other roles, especially those at companies like Meta, Google, Microsoft, etc, they will continue hiring for software engineers year round. 

Instead of framing it as, "what negative feedback do I have about my manager?", think about it as, "what could my manager continue doing to have (even more) impact?"

Beyond a minimum threshold (which you already hit), typing speed is *not* important to be an impactful engineer.

Instead, the way to think about efficiency is to ask the question, **how can I best maintain a flow state**? I find that knowing various shortcuts for my IDE (especially things like jumping to definition, opening various classes, or using auto-complete) helps me to stay in a flow state for longer.

There was a principal engineer I worked with at Meta who literally used just his laptop for coding (no external monitor) and mostly typed with 2 fingers on each hand. And yet, he was amazingly effective. 

I would not spend any time optimizing typing speed.

@Senior SWE at Google is spot on. 

One tactic to get more concrete feedback from your manager is to **make an attempt at what an EE rating would look like**. 

So in your next 1:1 (or perhaps you have a separate dedicated 1:1 to add more weight to the discussion), you can bring some ideas.

> Based on what we talked about, here's how I'm thinking about what it would mean to hit MA, EE, and GE for each project. I'd love your feedback if I'm thinking about this in the right way.

Make each rating bucket very clear and, ideally, quantifiable (something like "Finish project X 3 weeks ahead of schedule and 4 other developers using the tool by end of half"). Be open to feedback, suggesting this as a starting point rather than a contract you want your manager to agree to.

This is the principle of "people like correcting things more than they like helping" :) I'm not saying your manager is bad, but this is a way to lower the activation energy to get feedback.

I think this is very company-specific. I know Meta is pretty strict about adjusting salary for location. Some companies (I believe Shopify) is leaning into remote work and doesn't do as much.

Here's one consideration for you: can you stay in a high CoL area for a year when you get the initial offer, and then move somewhere cheaper after that?

Most people get equity grants over 4 years. So you get the large equity grant from a company like Airbnb or Google, then move to Iowa (or even international). 

They may change your salary, but they can't change your initial 4 year equity grant!

Ask for this legwork to be done by that team, and I'd also involve various managers as appropriate (depends on how contentious the relationship is). 

Certainly you should keep your manager in the loop, and broadcast any decisions made to everyone who attended the retro.

There's another question (perhaps you discussed in the retro): why was this feature shipped before the New Year holiday? Given that many people are out of office, it seems like poor timing for the team to plan it that way. Or perhaps it wasn't planned. 

To your question: I think you should push hard for that team to be more self-sufficient. If they truly can't test until something goes into production (that seems kinda lame though...), I'd ask for the following from them: 

- what steps have they taken that other teams are not negatively impacted by their releases? what monitoring do they have, and how quickly can they turn off features?
- do they have a thorough runbook to diagnose issues if they come up?

There should also be a discussion about the cost (either revenue or user experience) for this -- if it's an internal tool, for example, maybe you can be more lenient.

How much conviction do you have that you will enjoy being a SWE more than SRE? Since you don't have the option to try it internally at your company, in a hybrid role, the cost of switching and getting it wrong is high. 

Given that you enjoy writing code and designing/building systems, though, it sounds like you would enjoy in the SWE role. If you feel good about it, I would encourage you to **make the switch ASAP**.

Your career is long and you want to work on something that you're excited about. Your career is decades long, you still have many years to go!

There might be a temporary career growth plateau, but I actually don't think it'll be that bad, given how related the SRE &lt;&gt; SWE roles are. 

The other benefit you have is leverage -- you're not in desperate need to leave the company. What I'd advise you to do is apply for 10-15 SWE roles and do the interviews. Hopefully you'll get a few offers, and that will allow you to calibrate what level you're offered. 

You only need one company to not offer you entry-level in order to make that your "target level" -- I'm confident you can pull it off. 

Your list sounds good. The complication that I often run into, though, is that there are **still significant unknowns** at the point that I know the project will be delayed. So my strategy is to: 

- Notify them of the delay and **explain why**.
- Then explain the various paths and unknowns, and for each path explain the tradeoffs and time/resources it will take. 

The hard part about this is to make the options understandable to your team (including non-technical folks), given that they will not have all the same context. 

The way you build trust in this exercise is by "meeting people where they are" and explaining the situation so that a reasonable smart person can say, "*That makes sense why it got delayed, and here's my opinion on the options you presented*".

There are 2 ways to contribute in these meetings:

- offer new features/projects to work on during the month
- offer helpful context/details about the projects being discussed

As you work, keep a doc of potential improvements/ideas that you wish you could work on, given more time.

Before the roadmapping meeting, meet with your eng manager, senior engineers, and product managers to better understand their priorities. Ideally it should not be a surprise to you (or anyone) what the priorities are in the monthly plan.

Since you have a rough idea of what will be discussed, spend some time going deep in one area. Become the most knowledgeable person about the risks, how long it'll take, and which teams need to get involved. At a company like Meta, there will almost certainly be other teams involved -- perhaps you could talk to them.

See this video for building relationships:

- <https://www.jointaro.com/lesson/GWW7hvRcgGhbXimw5b3J/how-to-build-work-relationships-faster-giving-deeper-thanks/>
- <https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/how-to-build-deep-relationships-quickly-in-tech-12172022/>

A few ways to evaluate whether to stay or leave at your company: 

- Do you feel like you're still learning? 
- Do the people around you invest in you? Do you have enough people to learn from? 
- Do you already have a name brand company on your resume? How much would your profile improve if you spent a year at a high profile company? 
- Are there any big payouts (equity, bonus, etc) that you want to wait for?

Unless you enjoy Leetcode (*I assume you don't.. :P*), I would stop. 

If you want to switch jobs, keep applying for various roles, but try different avenues like networking, Taro Premium, or shared interests in tech/open source.

When you start getting interviews, then you should grind Leetcode hard. 

Lee offered some great questions to get to the bottom of the gap in **how important you think the project** **is** vs **how important the company thinks it is**. 

A few other practice considerations based on your personal situation: 

- How close are you to a promotion? 
- How many existing relationships can you leverage in this product?
- Even if this project fails, is there enough opportunity to ship stuff/build credibility that you could still advance your career? This is common at junior/mid-level, but harder as you get more senior. As a 5A at Uber, I think it's still possible if you ship something large enough. 
- What are the likely next steps if you decide to leave the product after 6 months, or if the product gets canned?

The above questions are the more "selfish" perspective -- important to consider these along with impact to the company.

The important part of what you said is this: 

> This puts additional pressure on other teammates to perform as we set team sprint goals considering availability of all engineers and we find the team always lag behind the deadlines.

So there's a real cost to the team because of the underperformance of your colleagues. This could lead to lower quality software being shipped, and in the long-term, issues around burnout and the best people on the team leaving. 

Frame the concern in this way to your manager. **Don't make it sound like you're complaining about a specific person just for the sake of complaining**. 

The way I'd phrase it is, here are my observations about the workload on the team based on looking at jira tickets, and here are my concerns on what may happen. What do you think? 

Ooh, I'll share 3 that I've seen repeatedly in my career:

> It'll take me X weeks to ramp up into a new codebase/technology.

Generally, people overestimate the amount of time it takes to know enough to be "dangerous" with a new technology. Be ok with being uncomfortable and then get stuff done. At most companies, this is very valuable, and you'll learn a lot more. 

> My manager won't like that I'm working on this project

Stop viewing your manager as an authority, and view them as a partner. You're responsible for your career growth, don't delegate that to your manager. 

> That person probably doesn't have time for me

If there's someone who can help you gain context, debug something, or provide valuable perspective, ask them for help. Of course, there's a proper way of asking for help, but don't assume that people are too senior/busy/important for you.

You don't put these on your resume.

If you did have a sentence around how you're "a high motivated self-starter with excellent communication", you fall into the **classic trap of telling and not showing**. Instead, these traits are assessed during interviews through storytelling.

Resume masterclass: <https://www.jointaro.com/lesson/OnQV2V3J8DYVBBuGbZx6/how-to-write-a-stellar-tech-resume-that-gets-you-more-job-opportunities-8282021/>

Agreed with Mistplay. For your work experience (and projects as well, although it's a bit harder), I'd like to see more numbers showing the impact of what you did. 

How well-regarded is Amity University? If it's well known, I'd put that at the top since you're a recent graduate. 

A masters degree is **not necessary** for an amazing career in tech. It is increasingly less important the longer you've been working. IMO here are some good reasons to do a masters:

1. **Brand value** -- this becomes less important since you have 5 YoE.
2. **Immigration** -- not sure where you're located, but sounds like this isn't a problem
3. **Career pivot** -- if you want to make a hard pivot into something relatively distinct (e.g. web dev to distributed systems), a masters might be a nice clean break

The cost (and opportunity cost) of a masters degree is large. You mentioned you've only worked at startups till now. Unless you feel like there's no way you can break into other company types (e.g. FAANG or hot growth-stage companies), a masters is usually not worth it.

There's another element as well, which is to **be ok with not knowing**. Very senior engineers make a judgment call on whether it's worth going down a rabbit hole to understand exactly the format and types of data being passed into and out.

Imagine the depth of understanding for a module being from 1 - 10, with 1 meaning you have no idea what's happening, and 10 meaning that you are intimately familiar with every line of code. You don't need to get to 10 (in fact, if you get to 10 before getting started, you probably wasted a bunch of time). Be ok with getting to a level 6 or 7, and then you can make educated guesses to fill in the details. 

Some level of hand-waving is fine here, because you'll find that Staff+ engineers can usually predict what's behind the hand-waving, based on their past experience and judgment.

How senior are you? If you're entry or mid-level, your best bet is simply to switch teams. Given that (1) you're an IC, and (2) the slacking teammates are actually more senior than you, your ability to influence the situation is quite limited. 

Even if you were able to improve the performance of your team, you likely wouldn't get credit for it, since the idea of "making the whole team better" is only starts to be an expectation at the senior or staff level. Obviously it's good to help others for altruism's sake, but you have to weigh the (sometimes conflicting) needs of your career interests, the company's interests, and your coworker's interests. 

> The company size is roughly 20 engineers

This does make things trickier since at a company of this size, you probably need to work with these engineers in some capacity even if you could switch teams :P

Assuming you want to stay on the team, I'd lean heavily on your manager. Let them know this topic is something you want to discuss in the next 1:1, and perhaps share some of your concerns in writing ahead of time to underscore the gravity of the situation. In the conversation, I'd offer several potential solutions to show that you want to be part of the solution, but make clear that you do want to see a change. Some ideas 

- Get another (competent) senior engineer on loan for a month to show the team what better productivity looks like. 
- Fold this work-stream into another so you're not unfairly punished by the 2 people you're working most closely with.
- Figure out a communication structure/cadence which makes it more clear who is responsible for what, and what each person worked on. 

In my humble opinion, these are the top 10 resources I have on Taro.

Top 10 - Rahul

The best advice in Taro related to getting more done in less time 🕜

Productivity

The best advice for anyone trying to get to Staff Engineer or higher

Staff Engineer Growth

20 year tech veteran Daniel Tomko (11 years at Microsoft and 8 years at Meta) shares what most engineers get wrong when joining a new team, and what to do instead. 

This is a 4 part series filled with practical insight!