It seems you already have a job at Shopify as a SWE, so that should more or less cover for a lack of a degree. Very few companies in tech actually cares about your degree since most of our learnings happens on the job. Therefore, there's no material benefit to doing a CS masters. 

But, you wrote that you have anxieties around not having a CS degree. Sometimes our fears are irrational (my personal fave is "I'm not technical enough") but we need to address them in some way to be our best selves. If doing, say, a part-time degree ameliorates your anxiety, it could be worth it! But before you commit to something as time consuming as a masters degree, at least do some self-reflection to see where your fear is really coming from and whether there are other things you can do to help ameliorate it. 

Senior SWE, Manager at Google

Kuan Peng

Congrats on getting the opportunity!

> What's your thought process when deciding when to switch teams?

1. Have I been miserable everyday for like, the past 3 months? I'm leaving, even if the work is "important" and/or there's opportunity to grow. You can be miserable for many reasons (bad manager, teammates you don't get along with, or you just hate the work), but the exact reasons aren't important. Whenever you recognize that something is truly making you miserable and you don't see it changing soon, leave.
2. Am I growing in ways I want? If not, I'm looking for a new challenge. Unless stability is what you are looking for (e.g. when you have other big changes going on in your life), having the same challenge day in day out probably isn't good.

> What's your thought process to decide which team to switch to?

I would say, there's \~ 3 type of team switches:

A. To a different team within the same org / in-org transfer

1. Pro: allows you to leverage your existing reputation in the organization to acquire a new position and continue using your skills/knowledge. The better your own reputation, the higher chance of landing a role as orgs generally tries hard to keep their best contributors. This option is surprisingly effective especially if internal headcount is hard to come by, like it sort of is now. Your old work likely transfers better as well and your onboarding is going to be minimal since there's a lot of shared context. I've done this three times in my career (including twice in G) and this option is not talked about much but is better than most people think. Do this if you like the tech/product, but don't, say, have a problem with your manager or your specific team.
2. Cons: hard to try completely new things. Hard to know whether opportunity actually exist. Needs people to sponsor you. Same pay. Maybe, same cultural problems.

B. To a different org within the same company / internal transfer

1. Pro: depends on the company, but at G, no formal interviews are needed so you don't need to grind leetcode. Most big tech teams also preferential hire from internal candidates vs external candidates. Can interview your potential new teammates to get a sense of their team culture and how much they like their manager, which is ***critical to your future success***. In G, you used to be able to ask for a manager's GoogleGeist ratings in the past to get an "objective" rating on how good they are. TLDR: you are able to pretty reliably assess how good your opportunity is if you put in effort to investigate for an internal transfer.
2. Cons: Same pay. Usually new context and technology, so you have to learn a decent amount when onboarding. Need to build new relationships. At the same time, they also know a lot about you. So if you've gotten a bad rating in the past, your new prospective manager can ask about that.

C. Switching companies

1. Pro: Allows you to negotiate comp. Maybe even a level jump. Ultimately, experience a different culture and definitely a different group of people. 
2. Cons: Actually have to interview. Getting a good team is more of crap shoot, since you don't have access to internal info that will help you make a reliable decision. External candidates also typically gets hired to the worst teams (because these teams have a hard time attracting good internal candidates). I think notably Meta's bootcamp helps avoid some of this problem but that has its own set of issues.

I'm guessing you are about to switch internally at G. I recommend you search up "Demystifying Transfers" on Moma, it's got a lot of helpful tips.

> What lessons have you learned from when you've previously switched teams?

1. In-org transfers are underrated.
2. You can never ask enough questions about your prospective team. Even when you don't have multiple options, invest time and effort figuring out where you are going. Team switches are expensive so take advantage of any intel you can find.
3. Quality of your manager is probably the most important factor for an IC. Everything else - tech stack, work load, probably makes a smaller difference than most people think.

Good luck!

I'm gathering the following from what you've wrote:

1. One of your partner teams is in a disarray, due to recent attrition of their EM. The other team seem unresponsive to your requests for reasons unknown.
2. You've attempted to put pressure on your partner teams by escalating to their management, or pushing them during syncs to stick to their agreed upon timelines. This has not been particularly effective. 

I can't read your manager's mind, but I sense you are not acting with enough empathy toward your colleagues. I worry that you risk destroying your long term relationship with these partner teams over completing this particular project. 

Escalation is an important tool, but it must be used w/ care. You should only use it when you know the people you are escalating (1) can actually help solve your case (2) is willing / incentivized to help you achieve this. I've personally found it only useful in dealing w/ short term fires. Long term commitments takes relationship building, which escalations don't help with at all. Repeated and ineffective use of escalation will result in "boy who cried wolf" situation where no one really cares about you say anymore. 

Is the skip manager actually sympathetic to your cause? Perhaps they are aware of the disarray on the team, and would rather sort out the managerial issues instead of meeting deadlines for other teams. I don't know, but that's just one reason why escalating to them might not be effective. 

Instead, I recommend you to ask your fellow engineers ***why*** they are struggling to meet the timelines they promised. Is platform team 1 struggling because they have too many priorities, and can't prioritize properly because they just lost their EM? Or maybe they've lost engineers too, so they are trying to do 5 people's work with just 3? Why is platform team 2 not showing up to your syncs? Perhaps they never agreed to support your project as part of their OKR? 

You need to understand what problems they are dealing with in order to know what solutions (including escalation) are appropriate. If the team is suddenly understaffed due to attrition... there's little escalation can do. 3 people can only do so much work. Unless you are ready to pitch in and do part of their work, no amount of escalation can do anything about that particular problem. But perhaps the reason they are behind is because they somehow don't understand how their work fits into your design or some other technical misunderstandings between your teams. E.g. perhaps some of the reasons are in your control. Perhaps there's actually something you can do to help them, rather than add oil to their fire. 

At the end of the day, many timelines slip for reasons beyond teams' control. Good teams communicate these factors to their leadership as quickly as they discover them. This let leadership to make reasonable decisions that either pushes that timeline before it "slips", or find mitigation strategy (additional people? less scope?) that enables the team to meet the required timeline. Perhaps you can surface the problems your partner teams are facing and see if your own leadership think you should adjust your timeline?

Tech Lead, Manager at Google

Pretty cool you are moving the build infra from Buck to Bazel (or Blaze, as Google calls it internally). What's the main consideration behind the change?  

If you could give one advice to yourself when you first entered Tech, what would it be?

I can empathize with your *"don't work until there's a fire/my life depends on it"*. I used to do the same - especially when I was at college, where would literally wait until the night before to finish my assignments and/or study for exams. I used to think I was cool because I could get away with it - but at some point it all caught up w/ me and I nearly failed out of college.

Your situation might be different, but one question to ask yourself is "why do I keep doing this?" For me, I realized that I had internalized this behavior when I was younger in high school, since back then getting work done last minute AND getting a good grade was considered cool. I felt I could "cheat" the system and felt smarter than all the other kids who worked so diligently just to get a B. So it really felt good doing it, and it was at least comforting when I did it even when the strategy stopped working later. 

I didn't really change until I knew deep down that I hated this version of me. That it wasn't who I wanted to be. I think my biggest "advice" for you is actually to figure out with yourself whether you actually want to change your behavior, and by extension, your identity. None of the external structures and support systems can help you until you make that decision for yourself.  

Having said that, if there's one thing I could've helped myself in my own journey as I strived to change back then, it's that I wish I had more structure and support system around me. You don't have to do all of this using sheer willpower and determination. Still, I wouldn't stress as much about what's happening around you as much as what's happening inside of you. If you are able to set your intention on changing who you are in this aspect, other things generally follow. 

I'll share some things I've heard about in manager circles recently about how to think about projects complexity/difficulty/ambiguity with regards to levels.

- **L3**: Bowling with gutters.
- **L4**: Bowling, without gutters.
- **L5**: Golfing instead of bowling.

The interesting bits to highlight for me is that L4 projects **aren't particularly more complex or difficult** than L3 projects, but the most important distinction is actually the fact that you need to do it without anyone else explicit looking over your shoulder to make sure you do all the right things. The goals and success paths for both L3 and L4 projects are likely similar - the difference is more in your own execution.

L5 projects are different from L4 projects in that it's often not clear what the right path / solution is. Likely there are varying *proposals* but no clear winner. You need to genuinely weigh different options, whether that's balancing different stakeholders and understanding where they are coming from, or different consider technical approaches, etc. I have found this this [LinkedIn](https://www.linkedin.com/posts/ryanlpeterman_handling-ambiguity-well-is-a-key-component-activity-7108464481726337025-wL0H?utm_source=share&utm_medium=member_desktop) post pretty helpful in visualizing this.

And to continue the metaphor... (maybe...)

- **L6**: What's new sports can we invent with a ball?

I've worked colleagues who seem to have done this in two different ways:

1. Like David said, via internal transfer. Join a multinational company with good internal mobility and find a job via internal transfer at some point. Internal transfers are usually preferred over external hires for the big tech teams generally, so once in, you potentially have an advantage even compared to an external hire from the US. I've known multiple engineers who've used this path to come to the US from India in both Amazon and Google.
2. Do a tech-centric degree in an American University. This takes way longer, is way costlier $$ wise, but I've also seen many folks pursue this path because this enters you into the US talent pool post graduation.

Take your vacations. Companies that offer countable PTO like most of the FAANG companies *expects* employees to take them, and HR will nudge managers to tell their reports to take days off when it starts piling up (from what I understand, it's because PTO days are sort of a liability for the company).

Your manager and your organization should be accounting for all the PTOs and leaves you end up taking in your performance evaluation. In theory, the impact/contribution etc should be prorated for the time you actually are doing the work. For example, if you were on a 3 month parental leave this year, they should be evaluating your performance given you had only 9 months to complete the work instead of the normal 12. So no, in no circumstances should your performance evaluations be impacted by PTO (except situations where you abuse the policy, e.g. taking waaaay too many sick leave even though you weren't sick).

Rahul is right though about the fact that you should try to minimize the impact of your PTO on your team and project. Your longer PTO will probably impact some project timelines, but it is really up to your manager and leads to decide whether that's actually problematic and they need cover and adjust timelines accordingly. Most good organizations do this already and adjust timelines for times of year where many people take PTO, such as Q4 in the US or the summer in parts of Europe.

A good rule of thumb is to give the equivalent times amount of notice period for your team and double for your manager for long blocks of PTO so they can plan around it if needed. E.g. taking 2 weeks off? Notify your manager 4 weeks ahead and the rest of your team about 2 weeks ahead of time.

Lastly, for longer PTO blocks more than a few weeks, employ good practices like setting auto-reply for your email/chat app ("I'm out from x to y, contact zy@ if you need help") and potentially create handoff docs for your team in case they need to take over for you.

"Autonomy" is an interesting choice of word. I wonder what you mean exactly by this? Maybe, the ability to decide how design ought to be? Or how much input you need from higher level people to approve your design? Alex already gave an excellent answer overall but I want to dive into this a bit more...

I think no matter your level, designs are collaborative experiences where your most of your engineering colleagues needs to be convinced that you are proposing a good solution. Higher levels by no means enables people to dictate unilaterally what stack or what technology to use. See "Material but not magic" section of the [Staff Engineer Book](https://staffeng.com/guides/does-the-title-even-matter/).

I think the difference in levels at FAANG for design has to do the level of ambiguity and scope of the project rather than their ability to more unilaterally decide which direction to go. For example, at Google:

- L4: Generally gets projects with known problem and relatively obvious solution, L4s mainly just need to talk to the relevant people to find a reasonable solution that everyone agrees on and document it well in a design doc. The hardest things here are usually clearly describing the solution chosen and the tradeoffs. It's rare the decision is controversial.
- L5: Generally gets projects with known problems but **unknown** solutions. So the hardest part is usually finding the right solution (which can sometimes be entirely a new thing to the organization) and also convincing everyone that this is the right path to go. Decisions on the right solution might be controversial and require lots of consensus building. 
- L6: Projects with **unknown** problems. L6s typically handle projects where finding and defining the problem is typically the critical factor in its success (e.g. the organization knows they needs to cut cost and infra cost a lot, but they don't actually know whether that's a problem or the problem is elsewhere, so they task an L6 to investigate). So sometimes L6s don't even write design docs, they simply write problem statements or vision docs or something that becomes the core motivating force behind giant projects. Once they define a problem, they may delegate the finding of exact solutions to the defined problems to L5s. I see L6s reviewing more designs docs than they write them.

Having said that, higher level ICs do tend to have more ***influence***. But this is more of a result of their continued good judgement rather than their title or level - e.g. other engineers simply agree that the solutions they propose have been good and give the benefit of doubt that their new solution is going to be good. It's entirely possible for high level ICs to continually display poor judgement and propose bad solutions, to the point where they have no influence despite being at higher levels. Any proposal, no matter who proposes it, will be scrutinized at the end of the day, but having more, shall we call it, "street cred" can definitely help.

First, take a deep breath! Once This is largely positive news, especially if you goals are to grow. But I understand that it never feels good to receive feedback, no matter how well intentioned (I myself feel the same way). Ones we don't see coming can be ***especially helpful,*** because it might help us identify our own blindspots.

My main advice to you is to dig deeper into this piece of feedback. I agree w/ you that her feedback is vague (or a least, your understanding of it is). Best pieces of feedback are specific - they sound like "In this situation, you did x and y, and that result in this suboptimal result, and if you thought about A and did B instead it would've had this positive impact", etc. I would try to figure out answers to the following questions with your manager or your peers, in no particular order:

- Is this a developmental feedback or a performance feedback? (developmental = you are doing fine but you can optionally do even better; performance feedback = you are not doing fine and continuing this trend will result you in a PIP). You said she suggested the latter, but I would make certain which one of these it is.
- What specific actions, behaviors, or context made her feel like you need to improve on problem solving and asking better questions? The more specifically you can understand this the better. What is that you didn't ask enough questions at a specific junction of the project or meeting? Or is it you asked the wrong questions?
- Is the problem a one-time thing, or is it a pattern? Perhaps, she's been thinking to tell you this for sometime, but couldn't find a good reason? This will help you understand the magnitude of problem.
- Is this feedback coming from her or is she a conduit for someone else's feedback? If this is her feedback, you could for example ask peers in similar context to see whether they share her assessment.

Ultimately, for you to take actions and actually grow, you need to understand where the problem is and it's not clear to me that your manager or you have discussed this in detail.

A couple of tangential thoughts on what you shared with us:

> ...that is on me to come up with an improvement plan. This feels wrong to me, isn't that her job as a manager?

...And it's also the employee's job to own their own career growth. Look, your manager **can help you grow and coach you up**, but this is at least a 50-50 relationship where both parties need to uphold their end of the bargain. I think if you don't do it, your manager will eventually come up with a plan; you just might not like that plan. I know I would rather follow my own plan if given the choice.

Lastly, I would ask you to be empathetic to your manager - it's very hard to give feedback well, and it doesn't sound this one went well. But it's much, much better getting a piece of feedback earlier when you still can do something about it rather than late, say after a project is completed. So maybe at least give her credit for that?

> That means that I'm putting in more hours than I should frequently, and I'm starting to feel demotivated and depressed.

What are your personal motivations for taking on this project in the first place? And maybe, just maybe, this project isn't a good fit for you, and given you've done well (?) in the team for the last two years, you just need to find a new project? Maybe a vacation would help with a reset? In any case, don't underestimate the effect of not taking care of your motivation, energy, and mental health can have on your work and personal life.

Thanks for sharing your situation with us - I think this is a common situation we will all run into at some point in our careers!

It sounds like your manager and your skip aren't aligned on the team's goals as it's rare for skip managers to assign work to their direct's directs. I wonder how your skip talked to you about it - was it more like, "Oh, this XYZ project would be good to do?" If so, I wouldn't be too worried.

It's entirely possible your manager isn't even aware of this non-KR task and haven't considered it. Depending on how urgent your current assigned work from your manager is, you could easily switch over to doing the other work (either way, it doesn't sound this is your main deliverable, so the stakes here are fairly low).

If you feel comfortable, I would take the initiative here and just start a chat group with your manager and skip about this. Say something along the line of "Oh XYZ \[skip\] mentioned that project A is can be really good and be my second project, but I'm currently working on project B. Is A more important than B for me to work on?" Feel free to turn this into a meeting as well if that works better for your managers.

Once the relative importance is agreed upon, you can work w/ your manager to adjust team OKR and your own GRAD expectations if needed.

I concur w/ Alex and Rahul in that your manager exhibits **toxic** behaviors, seemingly ignoring basic well being of people on the team. It seems that you've only been here for a month or so, so I think the easiest course of action is to leave. I would want to see whether one of the other roles you turned down might still be looking and would be interested in re-offering you.

> I genuinely want to make the best out of my current role and contribute positively to my team. Your insights and advice will be invaluable. Thank you in advance.

However, it seems you want to stay and try to make this work. I've gone down this path before and I can think of the two outcomes that can be "good": (1) your manager is removed from their position as the team's manager, (2) your manager's toxic behavior improves for whatever reason.

The "neutral" and most likely outcome is (3) nothing really changes but you put your head down to work and protect yourself from as much further damage. However, this outcome is not something you want, because it forces you to be overprotective, is still going to be extremely stressful, and could traumatize you for future roles. So in my opinion, this option is actually a "bad" outcome - if you were thinking of going for (3), you might as well leave.

### First - take care of yourself.

No matter the outcome, your immediate concern is to make sure to take care of yourself. This means physically and financially - make sure you sign up for your health insurance, get any medical treatment you need, and properly setup your 401k or whatever other financial benefits you are expected to receive. Do not worry about contributing to the team until you've taken care of yourself.

And secondly, you will need to pay extra attention to your mental health for the duration of this... struggle. No matter how much you try to put your head down and work, it's going to be emotionally draining, and it's going to take a long time to resolve. I would advise against working any more than you need to - going above and beyond in this type of situation isn't likely to get recognized.

### Coalition Building Stage: Take care of your peers

No matter which of the "good" outcome you decide to go for, you are going to need allies.

If you've only been here for several weeks and your manager's already been this toxic, I can't imagine how much toxicity your teammates and peers has already observed.

I would proactively schedule 1:1s with your immediate peers and support them in anyway you can. Reach out to your team lead and designer - if they want to vent, just listen and empathize.

Your goal during this stage is two fold - provide care and psychological safety for your team, and to gather information. Specifically, you would want to have a pretty good grasp for the following questions:

1. How long has this been going on? Has your manager always been like this, or are there specific stress factors that's forcing out their worst behavior (it doesn't excuse it, but it could point to the fact that it may be addressable)?
2. Has anyone on the team had **positive** experience with your manager and would vouch for them?
3. Has anyone reported this up to the skip manager or HR? If so, how was this received? Are there company surveys that points the issues?

Even if you are planning to directly give your manager feedback, it's important you build allies on the team first, will at least have someone on the team looking out for you if your manager decides to retaliate.

### Giving Feedback to Your Manager

I think you only want to attempt this if and only if...

1. Your manager's toxic behavior are irregular - people say they are not like this normally.
2. You have somehow earned your manager's trust.

If either is untrue, it's extremely unlikely your direct feedback will have its intended effect. If your manager has always been toxic, it's unlikely that you are able to change something that's very fundamental to the way they manage - and you should be able to figure this out with Question #1 from above. If you manager is only occasionally toxic but usually very understanding and has expressed desires to improve (but just don't know how), there's hope.

If you don't have your manager's trust, they are likely to see your feedback as an attack and retaliate in some way shape or form. To know whether it's possible to earn your manager's trust, Question #2 is very important. If someone else on the team has managed to establish good working relationship with your manager, that means it's possible for you to do the same using similar methods. If not... you are going to be treading in unknown waters. Ultimately, people who display toxic behavior are usually scared, isolated, and distrustful - you are going to somehow win them over and have them believe that you are one of their allies in order for you to be able to help them improve.

### Getting Your Manager Removed

Assuming you can't safely give your manager feedback, the other possible solution you can attempt involves some aggressive action: find a way to remove your manager, or at least apply pressure to your manager from the top. Question #3 should inform you whether pursuing this path is worthwhile at all.

If someone has already brought this issue up to your skip manager / org leadership, and they haven't done much about it, then this path is unlikely to succeed.

If no one have, then there may exist an opportunity to bring direct feedback up the chain to compel a change. Personally I would prefer to raise those issues with your skip instead of HR.

To do this effectively, you are going to need a lot of evidence. A lot more than what you've presented to us so far. Further, what you want need to be able to do to describe the pattern of toxic behavior, and what the effect of that is on the individuals on the team. **This is also a lot more effective if as many individuals as possible speaks out at the same time.**

Note - after doing this, you may be asked to bring this feedback directly to your manager. At this point, you can do this, assuming that you trust your skip to support you. Even if your manager attempts to retaliate then, you presumably will have higher powers protecting you from harm. However, I think it's quite unlikely at this stage that your manager will change their behavior, and in fact quite likely to double down and try to defend themselves. Still, the same thing applies - you need to find a way to earn their trust that you are trying to help them, not to attack them.

### These "good" outcomes aren't very good.

I have personally contributed to an outcome where my toxic manager was removed. Was it worth it? No:

1. The whole thing took 6+ months.
2. The team was dissolved/absorbed as soon as the leadership found an excuse to do so; most of my peers left soon after.
3. The manager attempted to damage my performance rating and bitterly left the company.
   1. No one on the team gained anything from this career wise. It's almost impossible to earn good ratings during this type of chaos.
4. I still had to find a new team within the company to join for my own wellbeing and growth.

This is why **leaving a toxic situation is usually the best thing to do.**

If it helps, manager performance depends a lot on **retention**. So by leaving, you are signaling that this manager has a problem, and you are likely to have contributed to the final resolution without inviting open confrontation.

Tech Lead, Senior Software Engineer [L5] at Google

Melissa and Jonathan already did a great job (I’m especially a fan of small, atomic cl/pr/diff!) 

I would add that if your team has an agreed upon style guide or something similar, attempt to apply that onto your cls.
If you don’t really know how to do this or your team doesn’t have a style guide, try the following instead:


Look through your past changes and the comments your reviewers left. Do you observe a pattern of similar comments? (Is it… lots of naming adjustments, unit test structure, or something else?) Focus on getting better at a specific set of feedback and ask yourself if your new cl has similar problems to prior ones. In general, try not to have your reviewer point out the same problem 3 times in a row, and past comments are a great source of learning about what kind of mistakes you tend to make.

This really depends on the person... but in my opinion AMAs are places where you could ask some questions that are a bit of curveball and not really a tactical thing related to the current set of priorities. I feel like these questions give valuable insights into how the person thinks. 

1. Career questions. "How did you arrive at your position?" "What were the crucial moments in your career?" etc.
2. Why questions. "Why are we doing X project?" "Why do we have this particular team structure"?
3. Team/Org/Company questions. History of the team/company, if they are a long time member. Where they see the team and/or company in the next 2-5 years?

First, let me acknowledge how maddening this situation can feel.

> The biggest problem is that the reviews happen in person and the reviewer gets nasty and yells at times. He is extremely rude and after a few minutes he tries to explain that all the feedback is for my own good like am a kid. I expect some amount of professionalism but I feel disrespected because of the attitude.

An engineering lead shouldn't make anyone they are responsible for feel this way, even if reviewing their code can be frustrating. **You don't deserve to be yelled at, no matter what your code looks like.** Many people struggle at having efficient code review processes because code reviews are ultimate tests of communication and trust between people, and we generally suck at it.

It's quite possible your lead has a behavior problem, or there's generally a lack of commonly agreed upon standards like Casey said. 2-3 days is a long time, the general SLA for a healthy software team is 24 hours / 1 business day, and preferably much faster than that.

But who's at fault here isn't ultimately that important, because usually all parties contribute to the problem. As you can't count on others to change, it's important you to ask yourself this question: **How am I contributing to this?** Why might a code reviewer take a really long time to review my code?

A couple of reasons I can think of:

1. The reviewer is extremely busy and preoccupied with other work.
2. The reviewer isn't familiar with the particular code base.
3. The reviewer doesn't like to review the code for specific engineers, because historically these engineers' cls have required many iterations and many comments, which were (1) energy consuming for the reviewer (2) produced unpleasant human interactions.

If #1 or #2 is true, escalate to your manager and maybe get more help for your leads to distribute review responsibilities.

But it's also possible #3 is in play here. **As a code reviewer, I am partial to, and am more responsive to, certain code authors.** It's not that I want to be and I personally strive to do better, but I just know from experience that certain people produce code reviews that align better with the principles and styles of our code base compared to others. It's just human nature to delay activities that produce stress - and **both code authors and the code reviewers find lengthy code reviews to be stressful and frustrating**.

If your lead is otherwise pretty fast on reviews with other folks in your team, I would definitely try to understand if I have done everything I can to produce clean, easy-to-approve code reviews. I would recommend watching this [Taro Video](https://www.jointaro.com/lesson/fTnWHqkYCPuaGa9FqaDf/noob-software-engineer-vs-pro-software-engineer/) for some guidance, but one of the key there is that "getting the code to work" / "not have bugs" is merely the first and easiest step. There's usually equivalent amount work to get the code, PR/CL description, test plan, etc, to be sufficiently up to standard BEFORE sending it out for review. I wrote a quick [this](https://www.linkedin.com/posts/kuanp_softwareengineering-codereview-codequality-activity-7038275986999697408-EjB3?utm_source=share&utm_medium=member_desktop) to describe what code reviewers generally look in a code review and it might be helpful to you as well.

It's also not impossible that your lead feels guilty about being an a\*\* and would appreciate the opportunity to help you understand how to prepare such clean, easy-to-approve code reviews in your code base. Either way, a conversation would likely help, especially after reading this you would like to change how to approach code reviews in the future.

First of all, congrats! I remember when I got promoted to L5 at Amazon, it was extremely meaningful. So by all means please enjoy this time and make sure to thank the people that helped you along the way. And like Vaibhav said, please pass whatever wisdom you've learned to others, whether by finding a mentee or commenting here on Taro!

I will offer you one interesting question that people often think about when they get promoted.

**Is my work, my team, my org, and/or my company** **aligned with my goals and interests?**

I've often found that the same environment that promotes one type of growth isn't always good for another. While you don't necessarily want to jump ship right away after a promotion, I think you at least could to do some due diligence to ensure that it's still right the place for you. There also tends to be less self-imposed and external pressure to meet deadlines and such in the immediate term, so in my opinion it's a good time to explore!

Promo "resetting" is probably not the right way to think about it, but it's a common thing managers use to tell reports to be patient / that they are not yet ready for promotion.

Having said that, I do think it's true that moving teams, especially when those teams have very little in common with one another, will soft-reset your promotion progress. I think this is true across Big Tech, not just at Google - it definitely happened to me during my L4-&gt;L5 promo at Amazon where all of the promo artifacts came from the team I was on then and nothing from my prior teams.

But I think the main reason team transfers resets progress, especially for L5+ promotions, is that those promotions depends a lot on two things that definitely reset when you move: your reputation amongst your peers, and your relationship with key stakeholders. Ultimately, for you to get promoted, people other than your manager needs to vouch for you and put their own reputation on the line to advocate for you.

Okay, that's the "bad" news. Here's the "good" news.

Reputation and relationship can be built outside of project delivery timelines. It means you don't have to finish shipping a massive project to get promoted. These things are primarily built with the right set of behaviors. Basically, if you think and behave in a way that L5 would consistently, then people will take notice, and they will start giving you opportunities that together will help you get promoted. If you are unclear what this set of behavior means, then figuring it out with your manager is probably the first step, but there also exists plenty of resources here on Taro that should be able to help you.

If you are already behaving in a L5 manner, e.g. being a thought leader in your team both technically and interpersonally, then promo in 1 year isn't out of reach. But often it takes longer, because to behave at L5 level requires to change your mindset and how you approach your work more generally (maybe especially so at Google). The truth is, your own internal growth doesn't reset when you move teams (it probably encourages more growth instead!). When you've internally grown to an L5... often the external indicators such as promotion will follow.

==

A quick note about GRAD and Promo! From what I understand, these are now separate processes. You could easily get a S rating in March and get promoted in August, because the S band is incredibly wide (\~70% of people gets this, including some people that got SEE in previous perf system). It is useful however to discuss where in the S band your rating falls with your manager - for example, if you are getting near bottom of S, your promotion likelihood isn't high. 

Rahul and Michael have nailed it in terms of how to "succeed" as an intern.

The only thing to add from me is this - **use your internship and Taro to figure out if you actually want to pursue this career.**

The best way to do this is talk to a lot people, both here on Taro and at your work. Ask people about their journey and figure out whether you would like to spend a significant amount of your life tackling similar challenges.

As an intern you can still easily change course and do something else either adjacent to software engineering (PM, UX, Sales, Marketing, HR, etc) or pivot to entirely different industries. Doing due diligence now on how you feel about the industry will go a long way to keep you motivated, especially through the bad times!

Good luck!

This is actually a super interesting scenario, that tech leads run into all the time. I will offer you some potentially controversial food for thought.

As the tech lead, you have responsibility to 3 parties here:

1. Your engineering colleagues, for upholding the standard.
2. Your juniors, for teaching them the standard (and helping them deliver that standard).
3. Your superiors, for delivering the project on time.

The **bravest** thing to do here, in my opinion, is to uphold the standard, delay the project, and take the blame for the delay yourself on behalf of your junior, and promise to do better next time. 

Doing this isn't part of any job description nor is it part of expectation for a tech "lead", but it is a part of what a leader of people would do, if that is something you aspire to. Leaders take responsibility for the mistakes of those in their care.

To me, this code review issue is simply a symptom of how you may have run the project as a whole. I suspect you haven't really fulfilled responsibility #2 throughout the project, and this isn't likely the first code review this junior has submitted that's subpar in quality. Could you have helped the junior earlier in the project, and mentored them to the point where at least their code was not visibly below standard? Could you have sat down earlier in the project, and pair programmed with this junior engineer to help them understand what the coding standard was?

Again, I think what you did was fine and no one is expecting you to do the "bravest" thing here and most of us will probably choose the "easier" paths instead. But from what you've described, you essentially chose to fail responsibility #1 to fulfill #3. You can make that choice, but in my experience, your reputation with your engineering colleagues and how you treat your juniors is the thing goes a long way to help you have a successful career, as they are the ones who will voluntarily vouch for you come during performance / promotion / job switching times.

Hope this was helpful, and if not, at least thought provoking! I'm happy to chat further here or over slack if you want to continue this conversation :)

These sounds like great first steps. Please update us on how you feel in 3-6 months!

I totally get what you mean when it comes to wanting to reduce exposure to social media and content services more generally to facilitate deep work, and my own relationship with this has shifted over the years.

In 2017 I discovered and read Deep Work; and then I decided to go on a social media ban, in part to help me with deep focus, in part to help me feel more secure. I deleted all social media apps from my phone, installed newsfeed blocker on all my devices, with only Facebook Messenger available to talk to friends. I basically stopped consuming content entirely from social media during this time. The only form of career content I consumed during these times were... books.

I am now reconnecting with some of the platforms, like LinkedIn and Taro, and have a different appreciation of them than I had before. Here's my takeaways from this personal journey, but YMMV.

### Social media is a powerful tool for connection, not consumption

The 5 year social media hiatus I took taught me that the best part about social media isn't the **media** you get fed by the algorithm. Instead, it's the possibility you can form genuine connections w/ strangers - the **social** aspect - that makes social media platforms so special.

In my experience, social media is most useful for broadcasting the message of who you are and/or what you are all about to a huge amount of people, in the hope you find a fellow like-minded individuals with whom you can help each other achieve your goals. Those relationships are going to be meaningful to you even when you leave the platform.

So in my opinion, unless you are **actively** building relationships and are **actively** signaling your unique brand by producing content on these platforms, it's usually not worth using them **passively** just to consume content.

A cynical way of looking at this is that you are just consuming content, you and your attention span just being captured and sold to advertisers for $$ and you are likely not benefiting a lot from that exchange. Creators intentionally say things like "Join the XXX engineers getting exponential better than everyone else, subscribe to this newsletter!" to stroke your insecurities and make you think you need their content to succeed. It's part of the marketing. We obviously aim to create useful content, but content is really only useful to you if it leads to actual improvement.

The positive spin on this is that clearly other people think your attention is valuable! So, you can treat it like it is, and control what you spend it on.

### When you are working on self-improvement, taking action is more important than having more knowledge

Presumably, you are consuming content (especially on platforms like LinkedIn, Newsletters, Taro) to improve yourself. But too often, I have found myself and others are overwhelmed by the multitude of wisdoms that dot the internet. But there's no way I have the time to consume all of the good stuff and apply it too.

Ultimately, self-improvement happens via actions and consistency. Just reading and watching stuff is just the start of it. When we are taking action, more content telling us what to do is going to simply distract us from implementing change and reaching our goals. In fact... reading content is probably one of the best way to procrastinate on actually taking actions for self-improvement because it feels "productive".

You are probably going to learn a lot more applying every lesson from just one source (say, Deep Work) over the course of a year, than reading 100 books and thousands of newsletters. There's many ways to curate your sources, but **focus** is key in helping you translate what you consume into what you live and breath everyday.

> And can we switch and up-level internally?

At Amazon and Google, this wasn't possible. It wasn't even possible to try to negotiate compensation even if the levels stayed the same (I attempted it when leaving Amazon).

Having said that, you can switch into a role with more responsibilities internally, even if your levels stay the same. If you perform well in these cases, you may be able to get promoted soon after switching teams.

I have heard of one other example where the destination manager promised to promote the person switching team within the next promo cycle. I'm hopeful for this person but IMO this feels very risky.

Yes, I think it's possible, but likely harder; it will be especially hard if the internal tool you support doesn't already have a huge number of users or it's not very critical to the running of the company.

I worked on Google's Engineering Productivity (EngProd) org for a bit, whose mission is to improve the productivity of product engineers via better tooling and test infrastructure support.

EngProd definitely had room for L6+ engineers (most were managers), but they were rare, and were really only needed when the product engineering org they supported grew beyond a certain size.

Fundamentally, SWEs at big tech are usually evaluated similarly across the company. That means especially at L6+ levels, engineers need to find big areas of responsibility and do work that result in large impact. Doing this for an externally facing product (hopefully a "core" product of the company), compared to internal tools, is vastly easier, because you can usually find some correlation between the work you are doing and the bottom line of the company. For example, for a product engineer to justify their impact, they can say did project X that resulting in improvement Y for Z amount of users, which resulted in XYZ amount of additional revenue for the company; in contrast, an internal tool engineers would certainly have a smaller set of users and murky revenue impact numbers to go off of at best. As such, career growth on these external product tend to be smoother, though YMMV.

So, if you only look at career advancement perspective, externally facing product teams are better. But on the flip side, work life balance on internal teams are often really good and tend to be more stable.

This sound like a situation where the fit is poor from both sides. Unless your manager is able to provide a dramatically different environment (unlikely) when you discuss potential PIP recovery path w/ him, I think there's little chance you will clear the PIP. 

If you don't have immigration or other dependencies requiring you to hold a job, cutting your losses here would be the way I would go. Depending on where you work, HR likely will offer you a severance package if you choose mutual termination (and I would ask for a package if they don't offer it initially). 

You might not need this, but maybe Alex and Rahul's tips on [finding teams that fit you](https://www.jointaro.com/lesson/UGIUC9zaGccK0tOarBri/how-to-find-a-good-team-with-career-growth-opportunities/) could help you as well!

Great question! Rahul and Alex already shared some of their thoughts on location [here](https://www.jointaro.com/question/K35C2YRAXVZvj7t85ClU/how-important-is-location-for-software-engineers/) and [here](https://www.jointaro.com/question/ltyKjUmX0aWrJZjnEByD/does-not-being-in-the-bay-area-hurt-your-career-as-a-swe/), and I mostly concur with them holistically that Bay Area in a vaccum is better.

However, I feel that you've provided some good context on what you are considering, and since I lived in Bay Area for about 2 years after graduation and moved up to Seattle (mainly because of my partner started her job there), I'll try to weigh in on this with a bit of my own personal perspective.

### To learn the most, you need a good team.

From a professionally learning perspective, the most important thing is finding a good team for you to learn from and build your skillsets and perspectives.

With this in mind, the location doesn't matter as much as the composition of the team that's offering you a job. For example, in a situation where a team with most of its members in Bay Area and a minor hub in Denver, I would choose to be with the majority of the teammates in Bay Area, because **learning in person is way more effective in person,** early on in your carer.

Colorado is sufficiently big enough of a tech hub to have major companies like Google having dedicated engineering offices there. I think if you found a good team situation where most of the team is located there, you'll have a great opportunity to grow.

That being said, if you aren't yet at the stage where you are comparing offers, I would look at jobs at both location, if only to have potential offers from Bay Area as leverage.

### Support systems are tremendously important.

Your career will have a lot of ups and downs. It's inevitable. I remember being part of the best team and under the best manager of my life for about a year; and one day, that was over thanks to an reorg. If you and your partner are serious, I would discuss whether Colorado is where you guys want to be long term, and make a decision together.

That being said, Taro isn't a ... life or relationship forum, so I'm not going recommend you to do it one way or the other. So I would say that if you do decide to go to Bay Area, make sure to build up your support network there (friends, etc) and keep the connection to your partner strong.

### This decision is a 2-way door professionally

One more piece of perspective on this. Going to work at a particular location as a software engineer is a non-binding decision. In Amazon they call these "2-way doors". It means you can reverse the decision if you don't like the results, at least when it comes to your professional career. Going to bay area after 2-3 years in Colorado (or vice versa) isn't going to be very hard, and your software experience will translate no matter what location.

But some decisions are not. This includes decisions relating to your partner.

Personally, when I had to make the decision, I asked myself - if my partner and I were to break up because we didn't try to make it work being together in the same city, would I regret it? For me it was a resounding yes and that's why I moved.

First, I'm sorry you are going through this. It can't possibly be easy to motivate yourself to go to work every morning.

My initial gut reaction is that you should just leave. You are 8 months into this role, so it's past time I would shrug off the bad behavior you described as "miscommunication" or "unintentional". Removing people in power is quite hard for leadership to do, and requires a lot of explicitly terrible behavior for it actually happen - and it doesn't sound like that's a bridge any of the managers wants to cross.

I am a bit confused by the presence of two staff engineers on the same team - staff engineers generally oversee the work of 10+ people, so I presume there's at least 20+ people in the team. That's a LOT of people on a single team / feature. If not, it seems their titles are inflated - their behavior certainly doesn't indicate they know how to be an effective staff engineer. It simply seem like these two are monopolizing power and not actively sharing it w/ people on the team. In any case, you can elaborate more on the team structure and the operational problems you see, we may be able to help more.

Still, it may still be some time before you can leave. So I would still try to at least find one thing that you can do on your own (that doesn't need anyone's permission) to improve the lives of people around you in the meantime. Maybe you can start documenting all the learnings from your oncalls, eventually making an oncall handbook. What you despite unfavorable situatio will go a long way to boost your own confidence, (doing so did for me).

Maybe one additional thought:

Would your old company consider giving you a significant pay raise? They are reaching out to you, presumably, b/c they weren't able to retain some of the employees they didn't lay off or they messed up their $$ calculations. You have some leverage here that I would use to see if you can extract a better deal from your old company. I would entertain the idea if only for the fact that it would be an offer I can use to negotiate with all the companies you are already interviewing with.

Let us know how it goes!

Senior Software Engineer [L5] at Google

Hey there!

Rahul is spot on. Even if your specialize in a front end, the core software engineering competency is the same across most software specializations. 

I'm a web engineer without a ton of backend experience, but I've never thought of myself as exclusively web or front end. Being a generic SDE is much more liberating, both from a job search perspective and a compensation perspective. You can still do primarily front end work even if you transition to SDE.

Great question! I love how you've thought about this, and I agree, this seem counter-intuitive.

I have a few reasons I believe why this making themselves "replaceable" is good for the senior engineer / tech lead. I'll refer to this from a tech lead perspective as not every senior engineer is a lead and has to deal with this problem. 

In short, in making themselves replaceable, senior engineers / tech leads are able to lead less stressful lives, get rewarded in performance reviews for building great teams, and lastly helps them find more impactful problems to work on for staff promotion.

### Redundancy

The most practical and immediate reason is what you've mentioned - create redundancy within the team. Having other subject matter experts in the team means the lead isn't always being called into every important issue that occur. This is obviously good for the team, as single of point of failure is a big operational risk.

But for the lead, not being that single point of failure significantly reduces stress. This is especially true when the team has oncall - you don't want to be woken up at 3am or having to bring your work laptop on your vacation because you are the only person who's able to address urgent issues. In other words, building redundancy in the team helps leads to actually take their mind off work to recharge and avoid burning out.

### Scale yourself = Leveling up the team

Inserting oneself into every decision for the team (e.g. micromanaging) is exhausting and ineffective.

This is because when you are the only one making decisions, the team doesn't get better, as your teammates don't learn how to make the decision on their own.

It may even initially feel really good, as you feel huge sense of power and responsibility. But it gets really annoying really quick when you have to babysit everyone. And there's no one to blame as you didn't spend the effort to teach everyone how to make their own decisions.

Ultimately, **a gate keeper who doesn't share their secrets slows down their team.**

I experienced this when I first became a lead. I was quite nit-picky during code reviews and thought "upholding the standard" was what I should be doing. This turned out to be quite wrong, as this slowed down my team's delivery, and because I wasn't teaching them how to think about code quality effectively. When I decided to instead help everyone understand how how to think about code quality and start thinking as code owners together, it massively boosted the team's productivity as we simply spent less cycles on the code review process. It not only did not decrease our code quality but instead helped our code base become better as people proactively sought ways to improve the code!

[Part of the responsibility of a lead](https://www.jointaro.com/lesson/uHqZZ15SK19MatEvLSO6/what-makes-a-truly-great-tech-lead-a-vp-of-engineerings-perspective/) is to level up the team, especially empowering them with the knowledge and giving them agency to make their own decisions. A team that's full of independent folks who can make decisions on their own are extremely "agile" and effective. Building this type of team reflects very positively on the performance ratings of a senior engineer / tech lead, not mention how personally satisfying it is to work with independent people with whom you can bounce ideas off of each other.

### Free-ing yourself to do greater things

One of the biggest reasons, IMO, to make oneself replaceable, is so we can tackle bigger and more important problems. One of the hardest part of becoming a staff engineer from senior senior is to figure out what are the biggest strategic issues that your business faces, and then to work on these problems. You won't have the bandwidth to find problems, much less solve them, if you are constantly having to make tactical decisions every day. You need to be able trust that your team is able to run without your oversight while you dig into more important, long term issues.

You asked whether it's a good idea to make yourself replaceable is only good when the company is in a "hyper-growth phase". While I have not been part of a declining or static organization, I would argue that it's even more important to ask in these situation whether there are problems that aren't being solved today that, if solved, would dramatically positively impact the organization.

So, don't make yourself replaceable just so you can relax and chill; make yourself replaceable, so you can do even greater things!

If there are other folks with thoughts on this topic, I would love to hear others' perspectives too! 

Jordan and Jonathan's answers are both great.

I do want to put "strong opinions" in context. Strong opinions are vital in helping organizations make decisions. Correct ones steer the organization toward success, and well, incorrect strong opinions are often disastrous. So being cautious about having strong opinions isn't bad thing.

In a way, opinions are generally **predictions about what would happen if a particular action was taken/decision was made.** That's why, like Jonathan said, it's important to:

1. Logically think through why you arrived at that opinion/prediction
2. Be open to alternative predictions that could also be correct

To develop stronger opinions and make more powerful predictions, I would start with having opinions about your own work and your own ownership area first, before attempting to vocalize opinions about other people's work. This is especially true if you are afraid to be wrong.

So maybe right now you are taking a lot of opinions from others about what you should be doing in your space - but maybe you don't need to. Try planning for your own work. By doing so, you'll inevitably have to know what your opinion about what the biggest problems are, what you should be doing about it. You will even have to explain this to others, like your manager, and your act of presenting your thought process will demonstrate that you have at least some opinions.

Further, this will allow you to figure out whether your opinions are correct and gain the needed confidence. Repeat this and eventually you will have opinions about myriads of things, and you would also have done the work to back those opinions up.

Ultimately, if you find that your own opinions about your own work isn't correct, it won't be a big deal (the impact should be limited), and you can always strengthen your own understanding to make better predictions later.

Hope this helps!

Short answer, (1) is the way to go.

I know your projects are complex, because complexity is everywhere, no matter the stack and no matter the technology.

"Tell me about the most difficult / complex project you've done" is probably one of the most common non-technical questions we are asked about in interviews.

These questions are asked to college sophomores, some of whom have only taken intro CS classes. Do you think the college students' projects are technically complex, at least from an experienced interviewer's perspective? Likely not, but it doesn't matter - and it won't matter for your case either.

The reason the actual complexity doesn't matter is because the main point of these questions aren't to examine whether you had project with sufficient technical complexity, but **to figure out how good you are at explaining complex things.**

I think the reason this question is so popular, is because the ability to explain complex topics simply is indicative of how well a person understands a complex topic. And the ability to understand complex topics (and explain them) to paramount to collaborating in big tech. Ultimately, **they are looking to hear a story that demonstrate (1) your depth of understanding of a specific topic (2) how you overcome challenges.**

So, having said, that, here's what I recommend you prepare.

First, search through your past projects to find a project you really, really enjoyed, and one you enjoyed especially because it was complex and it took you a while to figure out what you needed to do.

Note down what was so challenging about it. Was it the multiple layers of abstraction? Or the fact the the dependent data arrived at different times?

Then try to remember the things you did to actually overcome this complexity, or if you didn't overcome it, how did you work around it? Maybe all you did was to actually fully understand the complexity and what it required of you. Whatever it is, note it down.

Finally, try to "explain to a 5-year old". Or your sibling/cousin/a friend who doesn't know a thing about your field. Can you explain them and help them understand that what the project was all about, and why it was so hard / complex, and how you came up with the ways to overcome that challenge?

If you can do that, you will do just fine when you explain that same project to an interviewer at Big Tech :)

Best of luck!

===

P.S. If you are applying to entry-level roles, you will be compared to recent college graduates, whose technical scope is very unlikely to be complex. Heck, it might not even matter which professional project you decide to explain, as long as you explain it well and crush your technical interviews (since that's where almost all of the weight is).

P.S.S. I would be a bit more careful about "coasting" at my current company, especially since you are going to need references to back you up. You don't need to acquire bigger scope projects for interviews, but your reputation, where you work at, matters. Tech is a small world and you don't know who will be running into down the road.

I love books. They can be transformative in helping you to see yourself differently and help you approach situations in our careers differently.

Though, like Alex mentioned, books aren't as useful as real practice for learning hard technical skills. Additionally, to really appreciate a book, you need to have had the experiences to relate to its message.

I shared about some of the books that spoke to me at different engineering ladder for me on LinkedIn - see the [post](https://www.linkedin.com/posts/kuanp_softwareengineering-careergrowth-leadership-activity-7063274576385888257-JdPu?utm_source=share&utm_medium=member_desktop) here if you want the full list. Not all books here will be useful since you are just getting started, but I hope everyone can find the right book for them!

A bit late to this topic, but I had a thought to add on top of Rahul's great recommendation, especially if you are not just trying to find a decent manager, but a great one.

To find a great manager, **interview their reports**.

You want to ask them how they feel about their manager and the culture. Go straight in with something like "How do you like X as your manager?" and you can dive into specific questions later.

You want to do this because engineers will typically give much more honest perspective and will try less hard to sell you on the team/company, and can potentially address your concerns about the PIP culture. But more importantly, you want do this because engineers generally can't wait to tell how much they love their manager if they've got a great one. 

All managers have flaws, but great managers are leaders who inspire loyalty in ways you will only know once you've reported to one. I've had about... 8 managers in my 8 years of being in the industry (wow I've gone through one a year 🤣), and two of them were phenomenal people I would work for again if given the chance, and I know almost everyone on the team felt the same way.

If the response you get is a neutral "meh" or a mildly positive "oh yeah, they are good, I guess", then it means the manager is not that good. Great manager will get you responses like "they are the best manager I've ever worked for", "they are soooo gooood!!", and the people will be able to tell you multiple instances the manager helped them when they needed the most.

Best of luck to you - and to anyone else in the search!

What a thought provoking question!

This questions gets into the psychology of self-improvement and I'm not sure any of us are really experts or have degrees there. What I can share is what I've learned through my years of being w/ a coach, reading various books, and applying the advice/lessons I've been given. So do take all of these w/ a massive block of salt.

And before I get started, Jordan and Casey has a list of amazing questions and resources. I would think hard about them.

Specifically, "does this habit make me feel worse?" is an important question. If reading those email headings makes you feel like a failure or somehow inadequate, then I do believe this isn't healthy.

Now, the second question is whether this behavior has actually achieve your goals. Have you taken more proactive behavior in social settings when you've seen those messages? If not, the habit is at best ineffective.

If a habit makes you feel worse AND doesn't help you achieve your goals and/or become the person you wish to be, then it's likely self-destructive.

From what I can tell, most of us have some level of self-destructive tendencies - for me, it's binge watching shows and binge gaming, and for some it's comparing themselves to others, etc.

However, from my personal experience and reading other psychology books, there almost always is a good emotional reason we are engage in self-destructive behaviors, despite the fact we know it doesn't help us achieve our goals.

A large part of that for a lot of us is the **feeling of comfort.** Loneliness, self-loathe, and other painful feelings are sometimes ingrained in us from our past experiences, and reminding us of these painful feelings can sometimes in turn help feel us feel more comfortable because they are familiar.

So maybe the question to ask is **what are you personally or emotionally gaining from this activity?** We humans are very bad at doing things that give us no incentives. There must be something you are gaining from doing this that you need. Know this will help in the case you wish to replace this behavior - you would probably have satisfy the underlying emotional urge some other way.

Lastly, resources!

If this piqued your interest in psychology of our behaviors, I've found "Maybe you should talk to someone" very informative and great read.

If you are looking for more proactive ways to become more proactive socially, there are actually social coaches for engineers out there. I've chatted with [Myke](https://www.linkedin.com/in/mykemacapinlac/) but never taken any courses with him, but this might be something you want to look more into.

I wrote about this somewhat recently: <https://www.linkedin.com/feed/update/urn:li:activity:7044932251666567168/>.

In short, I think code velocity statistics are valuable and worth working on, but **make sure you understand it's an imperfect metric and don't over-optimize for it.** Ultimately, your goal with code is to do something useful ("impact").  

Quality commits can be a few lines long, so I wouldn't index too highly selecting exclusively for those you mentioned that are between 100-200 lines in delta. It's best to just count the number of cls generally.

In terms figuring out what's "normal", the best way is to look around. Some code bases are much slower than others to develop in, often due to years of tech debt. If you can, pull up code velocity statistics from folks who code in your code base, who are probably going to be mostly folks on your direct team and adjacent teams.

Hope this helps!

Lastly, I have a theory about maybe one gap in your behavior. It's just a guess, so feel free to ignore this if it doesn't apply to you.

### Own the project plan

From what you said, like

> For now, I will just go through the notes over and over again and hopefully come up with something.

and

> in which I have to say there are many frustrating moments after my manager explained his plan and I still want him to clarify more.

It seems like you are relying on your manager to tell you their plan, and you believe you primary role is following the plan given to you by your manager properly.

And that your biggest problem is not understanding your manager's plan properly.

I would think about this a bit differently. Maybe, just maybe, you need to actually do more of the planning and less religiously follow your manager's plan.

If you were an SDE II at a big tech company, this would be the case.

SDE 2s are expected to independent come up with their own plan to make progress on projects and get **only assistance** on designs. That means you may have an advisor, like your manager in this case, but you would be expected to own the creation and the execution of the project. Issues come up all the time during execution of projects, and it's your responsibility to react to these changes and adjust the plan accordingly.

So what is your plan? Why should it be done that way?

Write it down in a doc, and use that document to discover parts that you don't understand. If you are too intimidated to share it directly w/ your manager, ask a teammate to take a look first and ask for honest feedback. Again, prioritize asking your peers to figure out the things you don't understand. 

It's entirely possible that your manager is wrong on some level about the plan - after all, they have to keep track of everything else that's going on in the team. It's your job to be the subject matter expert of the plan and know it better than anyone else on team.

### Figure out how well you are actually doing

One of the things I've noticed from your question (and this was also true of my own situation) was that your manager seem to be the primary stakeholder who is both responsible for guiding your work, and assessing your performance.

This can work, if your manager was previously a SWE in your team/org, is also the subject matter expert, and most importantly, is a good coach.

It seems your manager has technical knowledge but is not a good coach. A manager who's able to coach will recognize what you need and teach you to help yourself. Saying *"I can't show you everything."* isn't a sign of good coaching - in fact, good coaches don't typically give you the answer, but helps you to find the way. Your manager needs to help you by either (1) asking the questions to help you understand how to think about the project and how to execute it (2) find someone who's able to help guide you through the process.

Unfortunately, managers who are able to coach well is rare. In these situation, it's dangerous to rely on your manager for everything. I would try to find other sources of guidance.

Specifically, I would look for a tech lead or some senior engineer in the same technical area, and talk to them to figure out two things:

1. Am I really underperforming? What is the expectations for people at my level taking on similar projects? Did I learn all the things I should during my onboarding?
2. How am I supposed to execute this project? What question should I be asking but I am not? Who I should be talking to but I'm not? How would they think about the project?

Other experienced engineers are much more able to give you an objective perspective on what the expectations are, because sometimes they are closer to actual work than the manager is. The goal is to **identify the gap** between what you are doing and what other folks would do in a similar situation.

In short, I hope your manager is able to help you identify the gap and help you improve, but don't count on them to do so; proactively seek additional data to formulate your own hypothesis.

### Setting expectations w/ your manager

First, you do need to take actions on the relationship w/ your manager. I think it's important that you acknowledge that something is amiss and that you would like to figure out how to address this together with them. The best way to do this is directly talking to them about it.

Use something along the lines of this during your next 1:1 to start a conversation about it would be good:

> I noticed in our last discussions that you seem disappointed about the pace of my execution on the project. I am doing everything I can but I realize I may not focusing on the right behaviors. I would like to work on this. Would you mind helping me understand what I should be doing instead?

This shows to them that you have the desire succeed, you don't mind receiving feedback, and you want to be coached. It should set up your manager with a coaching mindset. 

Ask them to paint a picture for you of what they imagine your role in the project would be like, and how they would execute this project (after all, they did say "You know I can do this very quick" - okay, how would they go about doing this?)

The goal is for you two to agree on a subset of behaviors that you should exhibit, because behaviors leads to outcomes. If the behavior isn't something you know how to do, agree on that you would work toward it but that you would like guidance from someone on acquiring that set of behavior. 

This [taro question](https://www.jointaro.com/question/t8NzbavMpB1a8EC5Zt2B/how-to-define-a-yearly-performance-plan-with-manager/) might not align completely with what you are asking, but it contains multiple resources to expectations setting w/ your manager that you might find helpful.

Hmm, this is a tricky situation. I would agree with your assessment that the "trust" between you and your manager is "in danger". You offer some really good details here, and this feels like a combination of two separate issues:

1. I've joined a team recently and I seem to be struggling to match the expectations for my level.
2. Manager seem to be disappointed in my pace of execution and I'm worried about our relationship.

Please leave comments for additional details if this isn't the correct assessment.

First, if this is the case, know that this isn't saying a ton about your ability, but rather about the lack of infrastructure in your team around properly bringing people up to speed. But this likely will still require a lot of effort on your part to figure out what the gap is between what you are currently doing and what is expected, and how to bridge that gap.

I myself experienced this when I first came into Google and I had to switch teams to find greener pastures. It's unfortunately common, and this may end up being a route you take as well.

Having said that, there are a few things I would like to offer to you to think about. I'll split them into separate train of thoughts since there's a lot going on here. I hope these help you - best of luck!

> Software engineering is a team sport and I have never experienced such apathy towards the people I work with.

I love your self-awareness with this one - it's hard to admit that you feel this way! Awareness if the first step toward addressing this - and we all need to feel like we are part of a great team to excel :)

> Is this the default in remote work?

I don't know if it's the default; I do know that, even prior to remote work becoming more accepted during covid, remote work always had **extra communication challenges**.

For example, one of the core aspect of showing up in a team is **presence**, and while we have tools that allow remote folks to simulate in-person presence to a degree, nothing we have comes close to speaking to a person face to face yet. (Or even just watching a teammate physically come into the office, working hard on their own.)

You might want to check out this [question on remote communication](https://www.jointaro.com/question/Uh8AcxVnZkosgQBkTuSH/how-to-build-connections-and-improve-productivity-as-a-remote-engineer/) for suggestions on what you can do.

Lastly, if you are genuinely looking to build genuine relationships, the most important thing to focus on is getting to know the people on an individual basis. For example, do you know who on the teams shares similar hobbies as you? Or who has the most interesting side-gigs? Do you know what are the career goals of your fellow teammates? And what motivates them to work for the seed stage startup you all work at? You'll likely have to take the initiative to get to know them and ask them questions first before they reciprocate for you.

I think you are asking about the [pallet x taro](https://taro.pallet.com/talent/welcome?step=welcome&pallet) collaboration.

Brad did a great job already, but here's some more specific answers to your awesome questions.

> Let's suppose that I have submitted PR1 for review and that PR2 is now to be worked on. If I wish to start on PR2, do I need to wait for PR1 to be reviewed? If yes, then will I remain idle until PR1 is reviewed? If not, then do I not risk that I need to revise PR2 if the reviewer has blocking review comments on PR1?

No, don't wait.

Yes, you do risk having to rebase + revise your dependent PRs when you practice this method. This is typically a small amount of work, **assuming you have already vetted your approach with your reviewers.** Generally, blocking design changes during code reviews are extremely painful, since your subsequent PRs depend on the first parts of your chain. Watch [this video](https://www.jointaro.com/lesson/fTnWHqkYCPuaGa9FqaDf/noob-software-engineer-vs-pro-software-engineer/) (and the rest of the code review series) if you are not sure what this means.

> Should I in general, complete all PRs before asking for their review? Or should I ask for a review as soon as I complete a PR? What if I realize that PR1 has something missing once I start on PR2 and start using PR1 as a dependency? Do I then revise PR1 and ask the reviewer to review PR1 again?

In general, send PRs as soon as they are ready (and ready is not the same as the code being "functional" - [this same video](https://www.jointaro.com/lesson/fTnWHqkYCPuaGa9FqaDf/noob-software-engineer-vs-pro-software-engineer/) covers this). If you have modifications to PR1 that is needed later, can you make this modification a PR on its own? That way, PR1 can be submitted without blocking for additional review.

I find myself doing this all the time. I would plan a feature to be split into 3-4 PRs, but I end up with around 6-7, because there's sometimes suggestion of followups that I haven't considered that I work on and send for review later.

> Are [**stacked pull requests**](https://www.michaelagreiler.com/stacked-pull-requests/) a well-accepted way of handling such dependencies? Is it prevalent and accepted as a standard in the software industry?

Yes, I would say this is the prevalent best practice. Small CLs are not a panacea, but it's one of the most proven best practices in the industry. From what I can tell, almost all of the teams in big tech attempt to encourage this.

One thing I'll add is that you do want to keep the amount of PRs you have to in concurrent reviews small, likely to a maximum of 3. **Reviewers do have trouble keeping track of longer chains.**

So even developing a single feature, find a way to divide it such that not all changes needs to be in a single chain - as if you are dividing a single project for multiple developers to work on simultaneously. This will not only help you keep the number of concurrent reviews in a single chain small, it will also pave the way for you to handle bigger, more impactful projects with multiple developers.

If there's one thing I've learned over the years, it's that there's no one "best" schedule or one "best way to work", but there are "best practices" that help you achieve more. 

I think the key is at least trying out some of these best practices in productivity and see what you like the best and which ones you can stick with long term!

For example, I know some folks really like the pomodoro method and take breaks every 25 minutes. I've tried it, and it doesn't work for me - I just want to keep working and I hate context switching.

Some folks love early morning productive hours but your personal life may not be able to accommodate that, on a daily basis. I've tried it, and while it does work for me, I can't do it consistently. 

I've also had several days recently where I worked semi-continuously late into the night for 5+ hours, and it felt really good! 

There are no expectations at most workplaces on how you ought work, as long as you are upfront about how you plan to get your work done. If one day you just can't seem to focus and want to go for a walk, then by all means, do it!

So having all that, here's some of resources I can find on Taro about personal productivity:

- [Day in the life of a FAANG Engineer?](https://www.jointaro.com/question/sOoGZwl8fsQ3hq8yv10v/typical-day-of-average-faang-software-engineer/)
- [Notifications and focus blocks?](https://www.jointaro.com/question/wavBNFOwhWDRAssDmwcc/turn-off-teamsslack-at-work-to-improve-focus/)
- [SWE Burnout](https://www.jointaro.com/lesson/xsbM1ctL9HYa6d7E9ejh/the-silent-killer-of-too-many-software-engineer-careers-burnout/)
- [Uncle Steve's tips on productivity](https://www.jointaro.com/lesson/s9VPqSHk2EuK2xOaBqYq/getting-to-the-top-1percent-of-amazon-engineers-productivity-tips-from-a-life-engineered/) (YMMV)

Re: certifications, see this taro [discussion](https://www.jointaro.com/question/RtBvd9fF8MGUqct7eVOH/are-google-certificates-worth-it/). In short, they aren't worth very much if you already have a lot of experience with the technology, which you seem to have already. 

I also don't think coding for the sake of interviews is important. LeetCoding is NOT real coding, though real coding skills do translate somewhat to it. If you needed to look for a new job, you can probably get good at leet code fairly quickly that it's a non-issue for interviewing.

Instead, I would look at this question as what you imagine a day in your future dream job will be like. Will you be spending most of your time creating and managing cloud services, or will be it creating new constructs and models out of code? 

For me, I enjoy writing code and I am not a fan of managing and configuring cloud services, so the choice is clear for me :) If you want to code more, checkout the [side project discussion](https://www.jointaro.com/question/KORArGLRW6mNn47ddC1S/how-will-side-projects-enhance-my-skills-as-a-software-engineer-on-the-job/)!

<https://www.aboutamazon.eu/news/working-at-amazon/what-is-a-bar-raiser-at-amazon> aligns with what I know from my time there, but there actually maybe some folks in Taro who are / were bar raisers at some point in their career who can talk about it some more.

Interview bar raisers are basically experienced interviewers from outside the hiring manager's organization that help calibrate interview standards across the company. It's a high-demand, voluntary role on top of one's day job with a lot of potential impact.

Are you asking this question because you would like to be a bar raiser?

Burn out is very common in our industry, so you are not alone!

Like Casey said, we won't be able to offer specific advice without understanding your problem in detail, but there is a general tip I can offer as food-for-thought for you.

Fundamentally, burn out at work happens when your time working frequently leads to your mental, physical, and/or emotional energy being completed depleted.

There are many tactics to (1) reduce energy leakage (2) increase energy generation.

For (1), the fundamental rule is **establish your boundaries**. Finding your manager pinging you off hours? Finding yourself getting distracted with Youtube or other social media that's not helping to make you feel better? Establish firm rules around what or what you will not do. There's quite a few books on this topic, but I've [this one](https://www.amazon.com/Book-Boundaries-Limits-That-Will/dp/0593448707/ref=asc_df_0593448707/?tag=hyprod-20&linkCode=df0&hvadid=598354936952&hvpos=&hvnetw=g&hvrand=8190971527141964482&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9033257&hvtargid=pla-1655045528820&psc=1) to be quite insightful.

For (2), I would say there are two approaches to this. One way is to **establish habits that give you more energy** - for example, taking care of your physical energy will set an increased baseline for your other pursuits. The other is to **find your intrinsic drive** - do you know what you find meaningful to do, and are you doing those things? If not - do you know how you might figure it out or find a way to do those things in your life? Doing what you find most meaningful will give you a lot of energy and keep you going even when the work is hard.

This [Taro question](https://www.jointaro.com/question/iJpayIUPb3vo71fUFEAI/how-will-advances-in-ai-affect-software-engineering-careers-in-the-near-or-forseeable-future/) on the effect the recent breakthroughs in AI on Software Engineering, this [other question](https://www.jointaro.com/question/n2qq0tGjSTDu982KL3nL/what-are-product-skills-and-how-to-develop-them-in-the-age-of-chatgpt-and-copilotx/) on what skills to acquire are equally worthwhile to read, and [this question](https://www.jointaro.com/question/3xg5SvXnyTQ0mhNLfbK1/how-to-ai-proof-your-career/) addresses how to think about integrating AI into our workflows..

In short, I wouldn't be worried about it in the near future, from a job opportunity perspective. If you are good at your job, you are always going to have role somewhere. (Nevertheless AI and AI-based applications are an interesting field!)

Another question you might want to ask your leadership: why do you need to do this project, now? If multiple teams failed at in the past and the probability of success is low, why does your leadership want the team to do it? How long do you really have to do it? They may have very good reasons and it could help you evaluate your strategies.

I love that you are trying help address major issues for your team and are being ambitious about your own growth. 

If you are most junior member of your team, the priority in my opinion isn't so much to chart your own path, but to learn from the other folks on your team. 

One thing to note is that while there are many engineering practices that are helpful, few are universally helpful. Even "code quality" can have varying amount of importance depending on the stage of the product / team. So it's important to understand the situation well before proposing changes to the current way things are done. 

As such, I would try to really understand the perspectives of more senior folks on your team and ask them what they find really annoying, and start addressing some of these issues. 

Having said, if there's one area you might be able to help with is onboarding, since you probably onboarded the most recently. Maybe you can improve documentation or start a mentorship program?

I recently (starting this year) took @Rahul's advice to put myself out there and started writing content on LinkedIn, and here's what I'm finding out...

1. Your immediate network will only take notice once you've done it consistently.
   1. When I first started writing, there actually weren't many people I knew intimately that interested or comment. For better or worse, many of my friends and coworkers just don't care about of what I'm doing - everyone just got their own stuff going on.
   2. The goal of your content is likely going to be adding value to people at scale - and that means strangers outside of your immediate work/personal circles. Since they aren't your primary audience, don't worry too much about their opinions!
   3. Having said that, recently, I did receive a few in-person, positive comments about the content I've been putting out from my friends, and that did mean a lot of me. This felt even better because I wasn't expecting it.
2. You'll soon quickly bump into other creators with similar aspirations as you, and their presence will help support your journey.
   1. The platform does matter, but people in the content creation world are generally very uplifting and wants to boost each other's influence. No matter your niche, there's going to be fellow creators. Don't see them as competitors, but as collaborators!

Looking forward to that office hour Rahul!

> I want to network with more senior engineers, especially those in the Taro community and within the companies I intern at, but I am scared to approach them.

Don't be! We don't bite 😬

In terms of what I find interesting in mentees, in no particular order:

- Share your goals / dreams and what you are doing about it - I want to know that my help is going to legitimately help you, so knowing what you want to do is very helpful!
- Sharing your struggles and insecurities and being open to overcoming them - I want to help where you are feeling the worst about!
- Ask good questions about the careers/life of others and being a good listener!

Put it this way, one of the best way for mentees to provide value to mentors is give them the feeling that they were useful. So actually being able to use the advice and turning into something useful in your life will incentivize people to help you. 

Another way to inject yourself into a community like Taro is by helping organize things. Maybe you want to participate in "water cooler topics"? Go to #random in Taro slack and start a thread, every Friday! Maybe you live in an area with lots of other Taro people. Organize an in-person meet up! Maybe there's a cool hackathon going on at your college. See if folks are interested in coming and organize the logistics of it. 

First, to answer your question around whether there are negative impacts of taking a career break - I believe yes, there is to some extend. It will at minimum raise a question during interviews that you would have to address. 

However, 3-6 months career breaks are very common, especially in the current economy (people getting laid off takes about that long to find new jobs), and so it will not be a red flag. The amount of companies that reject you purely based on you having a career gap will be very small. Long term, assuming you find renewed energy and commitment to toward whatever career/interest you decide to pursue, no employer would really care for the simple reason that how you look on paper / resume is much, much less important than your ability to perform on your job. 

If you are mentally and emotionally burnt out, you won't be able to perform properly - so I would consider taking a break as a personal investment into yourself. Being able to take a step back and taking care of yourself shows a lot self-awareness, and when you manage to emerge out of it renewed and passionate about what you want to do, you will be much more prepared to tell prospective employers why you did what you did. 

> Are there any specific steps or strategies I can follow during my career break to make it a more positive experience, both personally and professionally?

Since everyone's needs are different, evaluate these tips for yourself:

1. Go into with the goal of increasing your level of self-awareness - it would be good to come up with your own answers to these questions: 
   1. Why did I feel so burnt out? 
   2. What behaviors/habits/self-narration can I change to prevent similar situations in the future?
   3. What things help me feel energized and committed? How do I invite more of these things into my own life? 
2. Seek out help proactively. There's plenty of professional out there - coaches, therapists, or mentors who are able to help you on your journey. You are still going to have find the answers yourself, but you don't have to do it alone. 

Best of luck! Feel free to PM me on slack if you need anything else. 

I can totally understand how frustrating this can be for you. I had this happen to a really good friend of mine who joined a startup early on (taking a paycut to do so), and then eventually finding out that later hires were getting paid way more. Unfortunately, this is quite common.

But I strongly advise taking a step back and looking at this situation in a different light, and examine the facts and your assumptions.

**Fact:**

Your company pays a new hire, who is at lower level, with higher salary (or TC).

**Assumptions:**

Your company/HR disrespects you or thinks you are not good or thinks you deserve to be paid less for some reason. E.g. they are trying to offend you personally by paying you less ("Play you" in your own words).

This assumption likely doesn't reflect the reality.

The fact of the matter is that each salary contract is an independent negotiation. And negotiation is all about leverage, and how you use that leverage. It's likely somewhere along the process negotiation, you handled it sub-optimally, resulting in a lower pay. No company will ever pay you more than what you bargain for.

**Now, this isn't all bad news.** Here's a couple good news:

1. Your company was willing to pay a lower level person higher salary. This means they are in fact very capable of paying even higher salary for you. (You likely need to force them to do this with leverage, which we'll get to in a second.)
2. You might not very good at (1) getting leverage in negotiation (2) using that leverage. This is a thing you can improve on! Getting good at this skill will boost your future earnings manyfolds.

At this point, I would ask yourself a few question:

1. Do you like your job and your responsibilities?
2. Do you like the people you work with?
3. Are you learning?

Based of these questions, search deep down to see whether you still would like to stay here.

If yes, your goal is to renegotiate your pay. This can be hard, because right now, you don't have very much leverage. The only leverage you have is that you are going to quit without an alternative. Unless you have a tremendous relationship and/or the company will go down the drain the moment you, I don't think asking directly will do anything. It doesn't hurt to ask though, just keep your expectations in check.

To increase your leverage, you need to a find another company that is willing to pay you at a level you believe you deserve to get paid. Then you need to bring that offer back and ask for a raise. In the process of finding a team that's willing to pay you what you want be paid, you might decide that a new opportunity is better anyway.

Lastly, if there is anything you can do that will decrease your leverage in these negotiations, it's this thing you said you are doing:

> Knowing this information, I avoid putting extra effort into the team.

Here's 2 reasons why:

1. You are taking out your own personal frustration on your teammates who depend on you and your effort, and who had nothing to do with your salary negotiation. When you need to find new offers for your leverage, someone will have be your references, some of whom might be on this team. Do you want references who loves working with you or those who don't?
2. You are senior engineer, and you probably know how important these people are to the organization. The more important you are to the company, the more leverage you have in forcing the company to do something you want, because it hurts more for the company to lose such important people. What you are doing is making yourself less important - how will that help you make a case that you deserve to be paid more?

Even if you are feeling vindictive, the best way to take revenge, is to become really really important and quitting at the top. I hope you don't go down the path of revenge though - it doesn't serve you. You can get easily get paid more by leaving and not hurt other people in the process.

> How can I best work effectively with someone like this?

Lee and Jordan's answers are both great, if you wish to work this out. But honestly, do you need to? Can you leave this situation? Can you find a way to not have to work with this person?

> Is it worth escalating to my skip's manager?

It doesn't sound like that this E6 is willing to change their ways (this isn't the first time I've heard about this E6, it seems.). The relevant people to this person's performance review already know about this person's behavior. I have doubts your skip's boss would appreciate hearing about a squabble happening 3 levels below. The ball is now in your EM and your skip's court to decide what to do about it.

For you, ask yourself, **what is your goal in all of this**? What can you accomplish that is within your control?

Getting this E6 fired isn't within your control. Changing the E6's behavior isn't, either.

But how you respond to all of this is. Will you try to ameliorate the situation, knowing what you do may not have an impact? (It's true that if you did manage to build a solid relationship with this E6, it would be tremendously helpful to both you and them). Is there something technical you can learn or an interpersonal skill you wish to pick up amidst all of this?

\
[**"The Four Agreements: A Practical Guide to Personal Freedom"**](https://www.amazon.com/Four-Agreements-Practical-Personal-Freedom/dp/1878424319) is a great book. From what I can tell, it's all about setting personal boundaries and having integrity, and is a great read regardless.

If you want to read a book that help with this situation, read [Leadership and Self-Deception](https://www.goodreads.com/en/book/show/180463) instead. It was tremendously helpful to me in understanding my own role in sticky situations like this.

I think there might be a gap here in your understanding about **hard work**, though you are definitely not alone!

Hard work does require time and effort, especially the latter. But rarely are time and effort the differentiating factor between those who work hard and succeed, and those who work hard and don't.

The reason is that most people don't find it that hard to put in more effort and time. Especially earlier on in their careers, most of us have time and energy in droves.

Instead, the hardest work any of us gets to do get to do in our lifetime is **changing ourselves**. Changing oneself requires us to be **self-critical** (which can be painful), **self-aware** (which require restraint), and **courageous** (doing what makes us uncomfortable).

You said -

> I'm sure there are people who don't work-hard and get promoted, but these people must have something that gets them promoted such as great communication skills and the ability to sell themselves, so at least in that sense, they are unique and productive.

It sounds like to me that you believe people are uniquely born with communications skills and ability to sell. No, not usually, anyway. Good communicator build trust, and building trust requires one to be truthful. And being truthful is [harder than you think (at least it was for me)](https://www.linkedin.com/posts/kuanp_lessonsandgratitude-softwarengineer-careergrowth-activity-7027901502123872256-tVMJ?utm_source=share&utm_medium=member_desktop).

Even being productive is hard. It requires learning about ways to structure your day and improving your energy levels.

Acquiring these skills takes hard work, and knowing that you need these skills AND taking actions to actually acquire them is even harder.

Spending more of your time, instead, is easy. It's mentally easier to stay put and put in a lot of hours, than spending effort thinking and working on getting more efficient. Maybe your project isn't going well, but talking to your manager about it is scary and hard. So you just take the easy path and work more hours, when instead you could've escalated it and gotten the help you needed in much shorter time.

Simply putting in more time is ***lazy***. It's almost as lazy as thinking one could "chill" and grow in one's career (though definitely better...).

If you truly want to work **hard**, put your effort into things that makes you **uncomfortable** and forces you to **grow**.

(Check out Phillip's similar but more [eloquent answer here](https://www.jointaro.com/question/nJ762p255cGyuth36H6w/whats-the-core-insight-behind-quick-growth/))

Building off what Steve wrote (drive long term fixes), perhaps you don't have to solve this problem entirely on your own either, but take a directive role instead.

You can work with your manager with come up a list of consistently recurring issues. You manager should really want to solve this issue as well, because they can't afford to have single-point-of-failure in the team. You may ask questions to yourself and your manager to figure out what is the main contributor and address it systematically.

For example:

1. Deployments of new code frequently cause outages =&gt; Are they catchable by tests? if so, maybe help focus the team on adding tests to their code changes. Is it more that the systems underneath are not decomposed well enough and thus are dependent on internal workings of each other?
2. Lots of false alarms =&gt; Are you alerting on the correct metrics? How can you tune your monitoring solution
3. Oncall engineers don't know how triage issues =&gt; have everyone been sufficiently trained? Is there an oncall playbook? Can you have someone shadow you every time?

Once you have a list of potential deeper issues and possible solutions, prioritize them. You can then either work on the priority solutions yourself, or delegate to a fellow engineer (maybe one of the recently promoted folks?) and you can guide their work.

Great question!

I want to note though that most of what you've mentioned don't ***directly*** help you be a better engineer. These simply lay foundation for you to have a healthy life, with which you can pursue whatever you want. ***Don't do these things to be a better engineer; do them because they make you feel better.*** As every person's body and mind is going to be different, you should try things out see what sticks.

For me, these activities help me feel better:

1. I exercise 4x weekly (HIIT/Crossfit). This is by far the most foundational piece of my routine. I couldn't do this without investing some $$ into PT in the beginning, however.
2. Having a coach and/or a therapist. Emotional health is severely underrated, and we all have some level of trauma from our childhoods.
3. Eating well - I tended to eat more when I am stressed, so being mindful while eating have been a welcoming challenge.
4. Journal frequently - self-reflection and the resulting self-awareness is key to growth, and you need to grow to be a better person if you want to be a better engineer. See Philipp Su's [incredible answer for this](https://www.jointaro.com/question/nJ762p255cGyuth36H6w/whats-the-core-insight-behind-quick-growth/).

For me, I've tried these and they didn't stick, but they work for a lot of people.

1. GTD or Second Brain - unfortunately, the cost to upkeep the system(s) did not equal to what I was getting out of it.
2. Meditation - I did it for about 2 month straight, every day, but I didn't feel any more clarity or peace than when I started. It may not have been the right time and I'll try again later.

> How does the 'one diff, one thesis' workflow looks like?
>
> Should i make multiple PRs each one of around 250 lines?

Tactically, there's a lot of tools, and we had a similar post for [Github](https://www.jointaro.com/question/xiPsx4LT8aKUuG3GAbry/how-to-apply-one-diff-one-thesis-via-github/) some days back that might help you. And yes, generally each of your PR should be smaller than 250 lines (250 is considered on the large end).

Having said that, in my personal experience, **it's quite time-consuming to break apart large PR/Diff/CLs**.

The main reason most people end up in such a situation is because **they try to implement a working, end-to-end version of the feature before they send anything for review.**

While this is understandable - I remembered being scared to send in something I didn't know whether it worked, this is also is counter productive. Don't do this if you can. (If you did, treat this as "prototype code", and rewrite it in a new branch with the following approach.) Instead, it's best if you strategize your implementation such that you don't end up in this situation.

To do this, you need to break down the feature into distinct chunks, each with a "thesis", such as "implement this button". A thesis should have enough function to be verifiable via manual or automated tests. Alex has [an amazing, in-depth example on the Taro blog](https://www.jointaro.com/blog/every-junior-engineer-must-learn-this-software-project-decomposition/) on how do this, I recommend giving it a read.

Once you've properly decomposed your feature into distinct chunks, then figure out what's the one thing everything else depends on. Start with that chunk. Spend time cleaning up your code in that chunk. As soon as you think it's good, send out a PR for that chunk. These PRs should be naturally be fairly small because they aren't trying to do too much (PR for "Make an API call in Android" is probably 100-250 lines code, depending if you have test coverage). Keep working on the next chunks while this is in review. Submit and rebase. Rinse and repeat.

Having language difficulties is very tough; I've seen many people struggle with the reverse where there's a ton of English. Regarding this, I think it's important you find someone who is capable in both English and the other language(s) to help you. You needs mentors who are core to the organization especially in situations like this. See this discussion for making use of [mentorship](https://www.jointaro.com/question/hzFDQkYySUfzxeivVcHC/how-to-best-utilize-11-sessions-with-tech-lead/).

> I asked her to assign me an onboarding buddy

Well, you don't need anyone to assign you a mentor! You can just ask for people's time. If people don't want to help you, they will reject, and that's ok!

This [class](https://www.jointaro.com/lesson/n384HdJuDgulSHbHQLnf/masterclass-how-to-succeed-at-a-new-team-or-company-as-a-software-engineer/) on how to onboard basically covers all the main points of effective onboarding. It's important to note that being independent and asking questions goes [hand-in-hand.](https://www.jointaro.com/question/cLsgiARaD5kVmV1BvdUi/how-do-i-balance-being-more-independent-and-asking-questions/)

> But I feel guilty about asking people for help. I feel it doesn't do much for them. As with most, I don't have a team meeting where I could thank them & their/our manager would notice it.

While relationships you build do need to be 2-way street eventually, it might help to realize that people who help you (especially those take extensive time to mentor you) will get credit for it during performance season, especially if you make a point of [giving thanks to them via their manager](https://www.jointaro.com/lesson/noWZaoGWlrYQxX2Vhigd/effective-communication-guide-part-31-the-power-of-thanks/) (who might be the same as yours). There's really no need to worry about it - some people also intrinsically like talking to and helping people. Additionally, remember those who helped you and (1) help them back (2) pay it forward by helping others.

First, I think the steps you are already taking are great. Most collaborative individuals won't be peeved if you assign them tasks like this, since you are clearly trying to help everyone be more productive. 

That being said, one thing you could do is to make this not *your personal* initiative, but your team or your org's initiative. So if the person isn't happy with it, it's on them to bring up with the org publicly. Maybe...

"@person, **I'm helping our org identify and improve test flakiness as part of the test flakiness reduction initiative \[Link\].** I saw this one flake a few times and noticed you were the original author. Would you be able to take a look when you get a chance?"

\+1 to giving credit to others. Lifting others up is the best way to promote "credit where credit is due" culture fairly and others will eventually reciprocate for you without you even trying. 

Having said that, it sounds like you asking whether sharing your personal experiences outside of work, at work, can be perceived as "bragging". 

It depends, but IMO, I would think about

1. Is it the right time to talk about it? For example, I would generally say "official" meetings are not a good place to do so, since it distracts from the agenda of the meeting and typically don't contribute anything meaningful. It's great to do so at an off site or a team lunch or a "watercooler" conversation. 
2. Are you being able to have a conversation around these type of topics? Is other people also sharing their experiences when you are sharing yours? A good strategy is to ask and listen to other people talk about their experiences instead of talking about yourself to first, and hope they ask you about yours too. 

If you are not the type of person who's deeply passionate about making development processes faster, I don't recommend this role. However, you could interview anyway for practice, just like Michael said.

Every company is different, but I can say that software development in Engineering Productivity (EngProd) is generally very different from that of an engineer that works on part of the stack for an external facing product ("product engineer"). I was on such team for \~1 year, and it wasn't a good fit for me at the time.

For anyone else interested in knowing what it's like to be an Engprod engineer, keep reading.

EngProd's goal is to help is to improve the the development experience of product engineers and speed up the delivery of product features. As such, a big chunk of your job is to figure out what are some of the issues slowing down the teams you support. It's rare you will be handed well-defined projects, at least compared to produce engineers of similar levels, because EngProd teams don't generally have PMs.

Usually this involves digging very deep into test frameworks, release automation, etc, tools that help your fellow engineers be more productive. You then would need to dig deep and figure out whether these tools can address existing problems. And yes, you would also have to figure out what these existing problems are in the first place. You are basically the PM, the TL, and the Engineer for the project, all at once. This can be tedious (you might have to dig into the internals of build tool) but rewarding work (can save lots of engineers ton of time).

As such, I find being an EngProd engineer really hard for more junior engineers, since it takes a lot of (1) self-driven product exploration and solution specification (2) an inherent understanding of what makes a "good development" process vs not. (2) is especially tricky because unless you know how to be productive already (or at least what productive looks like), it's hard to figure out where the problem might be for your fellow engineers.

But the role could be good for more senior people who already know the productivity bottlenecks and wish to have organizational impact. This would be especially good for those who love building tools for fellow developers more than shipping their PM's next priority, for example.

First of all, congratulations on making the onsite round!!

I'm assuming you are going do your due diligence to prepare your answers. Do you best. However, know that the information battle isn't in your favor - no matter what you do, as a candidate, you aren't likely to know enough insights about the company to "impress" them.

Instead, I would take a different approach. Impress them with your curiosity. **Focus on preparing good questions, rather than good answers.**

When digging through the official/public information available, jot down anything you don't understand. Don't see how their go-to-market strategy will work? Ask the interviewer to explain the parts you don't understand. Maybe the company has "published values", but not clear information on how this manifests day-to-day. Ask specific questions about it. What do people talk about during lunch in the office?

Ask each of your interviewer why they joined the company. If their reasons resonate with yours, dig deeper and see if whether they found their initial goals fulfilled. If not, also dig a bit to see.

I feel the goal of these rounds is to show you are genuinely thinking about the future of the company as a whole, and a big part of that is asking the right question and having in-depth discussions. It's also an opportunity to figure out if it's the right fit for you.

Good luck!

While sprints and agile frameworks are commonly used in software industry, not every team needs it. Can you provide more detail on how you your team's productivity/execution/teamwork is impacted by the lack of one? What do your teammates think? If your team / company is small, full agile-based sprints might be more pain than it's worth. Knowing these details might help you convince your teammates or your manager if it's necessary.

> I want you to know that I'm concerned about communicating this request for proper planning with my manager.

Hmm, this is a bit strange. What concerns you? It seems like you are looking out for the team as a whole, and you don't come off like you are here to criticize your manager. If you mention this as a personal curiosity like "I've been wondering why we don't have sprints/agile process" or an suggestion you want input on "I have proposal that might help the team and wanted your opinion on it", any reasonable manager would be happy to talk about it.

Yeah, your TLDR is pretty spot on.

The general idea for One PR/CL/Diff, One Thesis is that it should be smallest chunk that can be understood, tested, and rolled back. IMO smaller code reviews are designed to (1) lessen the amount of things the reviewer have to think about for each review (2) allow reviewers to spend less time per review, so they can squeeze time to review more frequently, leading to faster convergence on agreed solution. It's the more "empathetic" option. 

Option 1 of having a single PR with multiple atomic commits fails both above goals (though probably better than having a giant PR with single or non-atomic commits). Rebasing can indeed be annoying, but lengthy code reviews are worse.

Touseef is spot on with his suggestions. I'll add a few I've seen work well.

**Video Conferencing**

1. Show your presence and your focus. Turn camera on as often as possible. Unmute and speak as often as possible. Send emoji reactions or participate in chat as much as possible.
2. Whenever an async discussion is getting tedious, start a video conference call with the other person if they are also available. For example, if a code review is going back and forth a lot, message the other person to talk directly if possible.

**Text Communication**

Leave paper trail whenever possible. Investigating a bug? Document steps you take and your thought process in the ticket/bug tool. Have an idea? Put it into a doc. Slack/chat messages tend to be ephemeral, so prefer putting your thoughts in more permanent forms if possible.

Keep a running documentation of your work. Once a week, collect your accomplishments and artifacts into a block in this doc. They come in handy during performance and promo, and helps assess whether you want to change how you work.

**Caveat**

If you are the only one in your team working remote, and the rest of the team (and perhaps even the rest of your company) is in-office 5 days a week, be aware this will generally work to your disadvantage. This is especially true if you don't already have strong personal connections to your coworkers and leadership. While it's possible to do this (I observed someone doing it well prior to pandemic...), it puts onus on your in-person teammates to surface as much of the off-line conversation online. In this is indeed the case, be aware you will have to put in a lot of extra effort to make the arrangement work.

There's actually one similar thing getting kicked off where I am, where it's being called "TL Cooperative." It's not so much a forum for people to talk about work issues, but rather a place for people to discuss and learn what the Tech Lead role is like, how it is different from a standard IC, and what skills are needed and so forth. This is particularly interesting since at Google you could be a IC senior engineer or a Tech Lead senior engineer (neither has management responsibilities), and they are different roles with different expectations. 

I think if the goal of your round table is for learning and helping each other get better, then it doesn't need to be heavy weight, since people only come if they want to learn. If it's more of a work/project alignment related meeting, then maybe reconsider whether it's necessary?

I concur with Rahul and with Michael in the long term.

I think in the short term (\~5 years), we will likely have more need for software engineers than today. A couple of reasons:

1. A huge amount of our economy is still very much manual and analog and would benefit from automation using software.
2. It takes software engineers to build AI systems. They can't engineer themselves. (OpenAI culture famously [value engineers and researchers equally](https://blog.gregbrockman.com/define-cto-openai)).
3. It's very costly to run LLMs, and no one's figured out how to make this profitable yet. So it's not yet scaleable be used by everyone. Specifically, pure AI-programming today is neither cheaper than nor as effective as employing human software engineers. It's much more likely that we'll use LLMs to make human engineers more 2-3 times effective, like Rahul said.

Long term is anyone's guess, but here's my "science fiction" perspective...

Engineering of all kind, including software, means designing and building complex and automated systems using the tools available. LLM technologies like ChatGpt, and Bard will become just another set of tools in the wheelhouse. Chatbots based on LLMs may be able to generate code, but they can't engineer systems. That being said, using these tools effectively will be require a different way of thinking than traditional software tools and languages, such as "prompt engineering".

In the end, we humans still have to collaboratively design systems around these tools to solve our goals, so I wouldn't too surprised if 10 years down the road, here on Taro we are talking about "prompt reviews" or "prompt quality." I also don't think this timeline is a given, since internet took 10+ years until the 2000s to really take off.

I think as software engineers, we are always looking for new tools to use (for example, very few people use C nowadays...), so adding AI-based tooling to your toolset is very, very wise, but as with all new shiny tools and frameworks, do so wisely (advice from [this video](https://www.jointaro.com/lesson/P7OwweZWcyvb3Gz3bNOE/how-to-properly-learn-to-code-as-a-software-engineer-do-the-simple-thing-first/) applies here.)

First, I can tell this is a very stressful situation! Let me try to address a few of the context you've provided to see if they help you feel better.

> My manager has promised to find me a new task, but the problem is that I don't have any experience with the tasks he has suggested"
>
> "I am afraid that if I admit to not knowing how to do these tasks, I will appear incompetent in front of the company managers we are contractors of, and risk being laid off.

In general, it sounds like there's a misalignment between (1) what the team needs (2) and what you are able to contribute to the team.

My first thought is that there's no point for you to pretend to know. If you do, you'll likely just do a poor job, and be in greater risk of being laid off anyway. Maybe you don't need to say this at your standup, but you have to let someone know, at least your manager. 

My second thought is that your manager does not know what you are able to do, and you need to let them know. It seems your manager thinks you are technical program manager instead of a data engineer.

You need to correct this sooner rather than later. Start a conversation with your manager to create an alignment between what the team needs and what you can do.

For this conversation, make sure you brainstorm all the things you know you can do, with examples from your previous jobs if possible. Since your manager doesn't seem to understand what a data engineer does, explain to them if you can.

At the same time, observe and brainstorm the list of things your team is struggling with that you might be able to help with as a data engineer. Propose things that you can do for your team that you can see.

Hopefully your manager will understand better and give you things that's actually in your wheelhouse!

I was an SDE2(L5) at Amazon, and SWE2(L4) at Google, and I know of SDE2s at MSFT.

This is an interesting question, and I get the sense that what you are looking for is what kind of effort it takes to be "meeting expectations" to "exceeds" at mid level but not try so hard to get promoted. Note most FAANG expect promotions to senior, with Google being an exception, "try to not get promoted" isn't helpful long term.

In short, I don't believe overtime is frequent and isn't expected, but can happen from time to time. I'll split my answer into "what I've seen" and "what I recommend".

Sorry about the essay in advance 😅.

### Workloads

- The majority of engineers I've known don't work overtime, at least not consistently. I didn't and most of my colleagues rarely did either.
  - When myself or people I know did put in overtime work, it was generally due to (1) oncall / off-hour outages / executive escalations (I got a [Jeff Bezos "?" Email](https://www.quora.com/Whats-it-like-to-receive-a-question-mark-e-mail-from-Jeff-Bezos-at-Amazon-Inc) once.)(2) aggressive deadlines for projects, which would happen once in a while (a weekend every couple of months or so?)
  - Aside from oncall, I've only worked overtime for projects because I wanted to get them done by the certain date. No one's ever asked me to work overtime.
- If you are not oncall, you don't need work emails, slack, or any other communication on your personal device.
- Majority, up to 75%, of your time is tasks related to coding (reading code, debugging code, writing code, reviewing code) when not oncall. This can fluctuate, depending on the stage of the your project (you'll usually get 1 project at a time)... typically around the beginning and the end a project you spend a lot of time coordinating your project and talking to people. Then you'll have some chunk of your time (5-10%) taken up by team activities.
- When oncall, it generally takes 120% of your normal time, and you need to plan your personal life around it. Pages in the middle of the night happen. There's generally no time for project work when you are oncall either, but you usually can skip team related meetings if you got urgent stuff going on.
- You can generally work whatever work hour you prefer, but you won't have much control over the timing of your team meetings, and these tend to run 10am-3pm.

### Strategies to not overwork

Fundamentally, as an mid level SWE, you need to be (1) independent, and (2) effective, to get good performance ratings. You can do this without overworking most of the time.

- Independence
  - Know your people (Who knows what and who's helpful? Who is the gate keeper?)
  - Know your processes (How do launches work? Some processes are very LONG and you need to know to start them early.)
  - Know your system (How do you debug your system? Can you explain to others how things work?)
  - Fundamentally, if you are able to unblock yourself using these above knowledge for your projects, you'll be good.
- Effectiveness
  - Good time management matters. No one cares whether you work overtime, or when you do your work, but you need to get your work done. You need to know when you are most productive and manage your focus, see [this video for more tips](https://www.jointaro.com/lesson/uGdn2AiDfn3B07FkpIVR/a-powerful-tool-for-software-engineer-productivity-focus-blocks/).
    - Are you a morning person? Come into office early before anyone is there and crank out your work before your daily standup. You can "chill" rest of the day and head home early. I did this a lot.
    - Are you a night owl? Show up to work right before your first meeting and crank out your work in late afternoon or do it in evenings instead.
    - Additionally, establish clear boundaries between work and personal life. Turn off slack/calendar/email notifications whenever you are not oncall. Even better, don't have them on your personal devices at all (I don't!).
  - Good code quality and high code velocity matters.
    - If you are able to crank out good code, quickly and efficiently, and get them through review quickly, you'll rarely ever have to work overtime. This [amazing Taro video](https://www.jointaro.com/lesson/muNsq91JownUzDm7AxLX/what-software-engineers-dont-get-about-clean-code/) goes into more detail about myths around code velocity and code quality. This is by far one of the most important skills to have as an L4.
      - Most engineers that do work overtime do so because they struggle at code velocity (and in return code quality). It's a vicious cycle. Avoid it at all cost.
  - Being good at incident management matters.
    - Knowing how to handle pages is super important. If a page goes off in the middle of the night, you need to be able to quickly determine whether it's a real issue so you can go back to sleep. This requires a pretty good understanding of your team's metrics and how to read them. This shouldn't be hard to pick up (find someone to shadow) but might require 2-3 times oncall to get used to it.
    - You also need to know when to escalate - if you don't know what to do or you can't make the decision, escalate it to your management chain. Or if you need knowledge of a peer to address the outage, pull them in as needed.
      - I once had a partner team page me to try to get me do some work off-hour to unblock their release, which wasn't part of our team's protocol, so after some back and forth I just paged my managers and let them handle the discussion

Apart from focusing on behaviors, choose your team wisely - you can generally get good answers to these questions from talking to team members (beware, managers can give rosy answers).

- How healthy is the team's oncall systems? Do you have to be oncall at all? (Some teams don't have oncall at all!)
- Does the team historically been pretty good at estimating projects? Do managers and leads in the team proactively shield the team from external pressures?

Avoid some of these following L5/senior level work.

- Mentoring your peers. Keep relationships professional and help when you can, but you don't need to actively look for mentees. Limit regular 1:1 to those with your manager and your tech lead and formally meet your other teammates on an ad-hoc basis whenever needs arise.
- Multi-person projects when possible. These require more coordination. Prefer big multi quarter projects you can do mostly on your own.
- Getting interns and being the main person onboarding new teammates. Though be generally helpful when they do have questions.
- Being the main code reviewer your team. Prefer being an occasional / backup reviewer. Or being a primary reviewer for a sub system.

Please note that **these are all fairly natural progressions and are extremely rewarding**, so I don't generally recommend avoiding all of this. You need at least one of these to reach exceeds anyway. However, this is a possible way to reduce time commitments at the cost of career progression.

First, what does your heart say? How do you feel about this?

I personally would follow a manager I trust and rely on (it seems your manager is). They are extremely hard to come by. I would say if the manager has asked you about this, then they really are thinking highly of you. You've clearly got the chops to handle the work, and feeling "bored" about your current work isn't a good sign for your growth.

I would do some research about the target team though. Can you talk to the ICs on it? It might give you some peace of mind if you are risk-averse. Ultimately, it might not matter - for me having a trusting, supportive manager with whom I already have a great relationship with will trump everything else.

I have a couple of thoughts here, though they are based on my own time in Amazon as SDE1/2.

Generally, I would NOT worry getting the chance to work on new technologies or new tools. Instead, I would index on areas/packages that **(1) critical to my team's success (2) yet to be owned by another engineer**.

In Amazon (and other big tech too), the key to be a successful SDE1 on promotion track to SDE2 is **ownership** and **independence**.

That means, being the go-to person of a **high-impact** area that no one else wants to touch (maybe due to its tooling or technology) is extremely helpful for your own performance and career growth to SDE2, as that typically gives you the room to exemplify ownership and independence.

When I was SDE1, I was tasked to onboard onto a Javascript Library as replacement for the departing SDE2 who owned it. This thing was gnarly. It was written in vanilla ES3 javascript (this was in 2017 and ES3 was released in 1999), with no concept of classes, and most frustratingly of all, it was deployed to production by... manually issuing an update request to the server hosting it.

It was a huge source of pain for myself and caused sev2s frequently, and almost nobody wanted to touch it because it was vanilla javascript.

But I took it on and became the go-to person for it. It was really painful the first few months, and then I got comfortable with its internal logic and these helped me address some of the sev2s. Then I realized a huge problem was the manual, human-driven deployment process so I managed to fit the existing process into an automated release pipeline that reduced deployment outages to nil. Eventually a colleague and I migrated the thing to ES5 and even added unit tests! It was really easy to prove my impact during performance season because I became an expert of a critical system in my team.

The point here is that it's more important for you to find important areas to own rather than looking for the newest tech or tooling. Once you've spent enough time with it, find ways to solve the painpoints you are facing - after all, you will have become an expert, and your work will go a long way to helping others in your team.

Internal transfers are great! I've explored this process at both Google and Amazon and know of people who've done it at Microsoft. 

Internal transfers are typically much better than external transfers for the following reasons:

1. You get to leverage your existing knowledge of internal technology, tooling, and culture. At places like Google where there's a ton of internal tech and tools this is especially true. 
2. You can interview your target team much more rigorously, outside just the hiring manager. This gives you valuable perspective. (People are also much more willing to talk since you are a fellow Googler/Amazonian/etc and they won't fear saying something they shouldn't). 
3. You can stalk their team's projects, cls, etc, and can request things like previous google geist results to see whether the team is healthy or not. 
4. If you like the company benefits, you get to keep them. 

Having said that, regarding your specific case, here's my thoughts and tips in no particular order:

1. To find teams hiring, go to Grow, the internal tool. With the recent layoff, headcount is likely extremely limited. Don't assume a Grow posting equates to an open headcount. Ask the hiring manager for every opportunity you are interested in. 
2. It's better to have been in your current team for at least 1 year and not on Pip to do internal transfer. Seem like you've hit that. This allows you to transfer without your manager's permission (otherwise your manager has to click a button allowing you to leave). 
3. Generally hiring manager will not reach out to your current manager. You can discuss this with your prospective hiring manager to make sure they don't. 
4. You won't have to do coding interviews for internal transfers. Yay!
5. There are Googler coaches for internal transfers. Just search on Moma. 

And this is just from what I heard personally when I was looking during the 2020 headcount crunch: 

1. During headcount crunch, often hiring managers don't have an open head count but will ask for it when they have a good candidate. The higher your level, they more likely they are to do so. 
2. Just like you can "stalk" the team you like, the reverse is true. The hiring manager will want to see your perf history, cl history, project history, etc. If you have a list of your artifacts (like ones you might have for perf), prep into a nice doc and send it along. 

Best of luck!

I sense you are feeling very frustrated about this situation, especially since it seems like it's happening again. I empathize - this isn't easy to deal with, so kudos to you for posting this question and asking for help here. Your manager certainly won't be stalking these pages :D

My initial gut feeling is that you are doing well, and that your manager is indeed off the mark. Any project spanning multiple quarters is considered a L4 level project at Google, so if your last project took that long by design or difficulty, that demonstrates "exceeds expectations". 

That being said, it's important to figure out first what is your "accurate" rating and then to align with your manager about it if possible. 

Since your manager isn't really able to explain your company's performance system to you (this happens more often than we all would like, unfortunately), you need others to do that. 

Skip managers are generally great resources for this. Just don't mention to them that your manager hasn't done a good job with yours,  tell them that you just want to understand it better for your own career growth. They should be able to help you chart what it looks like to go to L3 to L4, and maybe L4 to even L5. 

Similarly, go to your fellow peers (especially more senior people) with similar questions and figure out what being "meets expectations" at L3, "exceeds" at L3 look like, and what "meetings expectations" at L4 look like, in your company based on their experience. Asking them career-related question is very, very normal and should never be looked down upon, it's a great thing. Of course, don't tell your manager about it if you don't feel comfortable. 

Once you have a more objective evaluation of these ratings look like, take a hard look at what you are doing, pretend to be your own manager and see which criteria you think you've satisfied. If you are not sure, keep going back to those other folks for more specifics. Again, just for your own curiosity, if you wish to not share your frustration with your manager. Did you do enough for L3 Exceeds? L4 Meets?

You can then put all your findings into a doc. You goal is first to find consensus with your manager about the criteria of evaluation. If you are able to do that, you can together discuss to how evaluate your past (and future) projects along these axis. 

If your manager still refuses to have a conversation about it then... it might be time to go. Having a manager that doesn't want to teach you the system when you've done so much homework seem very problematic. But at least by now you would've gotten a much better sense of how well you've performed. 

Best of luck!

Just from what I've heard from friends and coworkers (I've only worked in the US), among what you haven't mentioned. 

Tech friendly, in no particular order

1. Singapore
2. Tel Aviv / Israel
3. London / UK
4. Zurich / Switzerland
5. Vancouver+Toronto / Canada
6. CA, PNW, Texas, NYC / USA

Immigration wise I know USA and Canada have clear paths to Permanent Residency for tech workers. This sounds like the type of question that chat gpt could answer pretty well.

Agree with Alex, if you can find someone who is able to dedicate their time to be your mentor, that's awesome. 

That being said, I wouldn't underestimate relationships with peers or leads who are not officially your mentor (see this [Taro post](https://www.jointaro.com/question/8Q6snKStnebzvJvJtAxN/how-important-is-it-for-you-to-be-connected-within-your-org-to-move-up-as-an-ic/) for more context). 

Alex actually has a great talk about finding scope with an example from his time at Instagram: <https://www.jointaro.com/lesson/WYk4J05iBqOuPtD0CYKX/session-1-solving-a-multi-million-dollardollar-instagram-bug/>

I can't tell if you are looking for promotion into senior or staff, so I'll link this very recent question about [staff level promo here](https://www.jointaro.com/question/WfwnrBnTSTuZdLI2f1XL/how-to-work-on-a-promotion-plan-in-a-mid-year-review). [Rachel's discussion](https://www.jointaro.com/lesson/FzvHLUprcYonudsxnJc2/whats-the-difference-between-a-senior-and-staff-engineer/) on staff engineers literally discusses how at Staff, you have to find your own projects.

In general though, I think this is fantastic question because figuring out what problems exists and how to solve them are inherently important to your growth as an engineer. While there are top-level directives that results in big projects with huge impacts, often projects start with smallish estimates and become bigger projects and bigger impact, because the engineers on them are looking out for the correct risks and ways to leave things better than when they started.

There's a couple ways I've personally seen people of all levels find projects, and one key insight is that often people weren't aware these projects.

1. Pain points during development: the software we work on is never perfect, so as you execute, you are bound to find specific patterns that slow you down. Are there some much needed refactor, or re-achitecturing that needs to be done? Is there some tooling or patterns that you've seen and learned elsewhere that would help with the pain points you yourself have encountered? Start there - if you are feeling the pain, you (and your peers) may be more internally motivated to solve it.
2. Pain points for users: similarly, the products our software power are far from perfect. Are there some critical user scenarios or some obvious missing pieces that doesn't take long, but everyone has been moving so fast that this has never been prioritized? Is there a pattern within user feedback that the org isn't focused on? Figure out why - and maybe some of these require small amount effort but have decent sized returns. These high-leverage items are great things to focus on.
3. Pain points for organizations. Is your organization struggling to deliver because the lack of, or sometimes too much of, process? Do people in your team or organization trust each other? See if you can do anything here - potentially these things don't even involve any coding, but are extremely rewarding projects to go after.
4. Look consistent patterns of negligence. Have there been recently outages, complaints, lost deals or revenue to the company or product, due to internal or external factors? Are there things your senior people are putting off because there's other, more important things? Take a deeper look at those issues and maybe there's something you can do to help while your senior people are (maybe correctly distracted).

Lastly, you want to prioritize these projects by leverage - the impact the project would have divided by the amount of effort it takes. Impact doesn't have be material or necessarily measurable (it could be trust earned with important members of organization, more trust in the product or people in the org, etc), but it's good for you to have an expectation for what would the impact be if you invested your time and energy.

Another idea may be to have more individual 1:1 discussions with these individual engineers. Larger meetings with lots of strong voices tend to lead to chaos, and is costly for everyone involved. 

Focus these 1:1 meetings on (1) building trust between you and the individual, and (2) figuring out what is negotiable about their position and what is not. Do this for every strong opinionated stakeholder. 

Then figure out if there's a compromise in the middle. Pitch this to each person as your idea, priming them with "It's important we find a common solution" or something of the sort to remind them that you are all here to figure out a path forward, and refine it. Then finally bring people together at a bigger meeting to have this proposal approved. 

Alex covered in plenty of detail how to ask questions and that is by far the best way to learn things quickly, because it typically leverages other people's knowledge! Do this when possible.

That being said, I'm interpreting your question and followups as you being interested in how to better understand and learn about complex technical concepts (sometimes on your own). For this, I want to share some personal tips that might be able to help you.

### What does it mean to understand something?

Before we dive into how to better understand things, let's define what it means to understand things, and what it is not.

I believe that **understanding something means being able to describe it relates to everything else**. In other words, it's about understand the **relationships** between a concept and nearby, relevant concepts. This[ question/answer on Quora](https://qr.ae/prISjH) does pretty good job giving an example of what I mean.

Understanding is NOT having the memory of a fact ("Knowledge"), especially if you can't make use this fact to make any predictions. **You should never have to memorize anything you have understood.**

Understanding is NOT blind intuition either - how you feel about something could be totally wrong, especially when you have yet to study it in depth.

### How do you then gain understanding of something?

So if you struggling to understand complex technical system(s), I suspect you might specifically be struggling with **connecting what you are learning about with what you already know.**

I see this happen all the time when folks are assigned tasks about systems they are unfamiliar with. They sometimes jump straight into the code or detailed design documents of the target systems, gets overwhelmed by the irrelevant details, and end up feeling really bad about themselves.

Instead, I recommend doing exercise by listing (1) what you already know about the target system, (2) and how it is relevant to something you already know. Maybe the target system is downstream dependency that a service your know well call can via a certain API. Maybe the target system is very similar to something you've seen before, from another job or school. Start exploring from there.

People do this all the time. Sentences like "Lacrosse is like soccer, but with sticks," or "Typescript is like Java, but with functions as first class objects" help people position a system in relation to another system they already know. So as people learn about typescript, or Lacrosse, they will keep comparing/relating it to what they know and learn by applying from concepts from one to another.

Another way to visualize the process of learning as a graph search problem.

You are at node A, and you need to find the shortest path to node C.

Jumping straight into the target system's code or docs is like sampling random nodes surrounding C, and trying to figure out if it's part of your shortest path. Bad idea - you will probably waste a ton of time computing paths that doesn't lead you anywhere. At best, you will end up with isolated islands of facts about the target system that doesn't help you predict how it will behave since you are unlikely to understand the principles with which it was built with.

Instead, start with where you are - at node A, and examine every node related to it that gets you closer to node C. You may still dig into details of the systems along the way a little bit, but only pay attention things that gets you closer to your goal. Ignore everything else. (I think this basically A\* search, which is fairly good algorithm for solving this type of problem.)

I hope this helps. Best of luck!!

Would it be accurate to say that a huge part of de-risking is building alignment between different stakeholders in a project, especially early on?

What are some common risks engineers tend to ignore but tend to blow up on our faces later?

Google

Senior Software Engineer [L5]

It's definitely not disrespectful, in fact those folks may appreciate having someone outside of the company to vent about the layoff to. It's also important for you to get a sense of what the post-layoff culture looks like. At some companies there's very little change, others an 180 flip (e.g. Twitter 🐥), so as an prospect you would want to see if the culture is still a good fit for you. 

I can imagine this is very stressful situation for you especially amid the current tech climate. First, know that your situation is not uncommon and there's no shortage of contentious work (you may empathize with the [Taro post here](https://www.jointaro.com/question/laa5DS4dlZDLDcPFjJmz/how-to-manage-politics-from-more-senior-engineering-folks/\)), so learning how to deal with them is helpful regardless of the outcome of this one. 

### Find reliable help

The first priority here is definitely figuring out a way to accomplish your work. Since this SWE 2 is clearly of no help to you personally, find other peers that can help you. You said there was tech lead. Schedule something with them, so you can more accurately assess how difficult your task is. Do you have other SWE2 or SWE1 peers that you can rubber-duck with? I've added some color on [this post](https://www.jointaro.com/question/8Q6snKStnebzvJvJtAxN/how-important-is-it-for-you-to-be-connected-within-your-org-to-move-up-as-an-ic/) as to the type of people you need to have on your side during your career - can you find these people and can they help you get these tasks over the line? Does your team really need to blocked on you? Can someone else with more context do your task instead and you can contribute in other ways?

### Triangulate the truth

It's important you understand the situation from multiple perspectives, because what you are seeing might just one side of the story. Make sure you are able to collect enough "evidence" to support a particular story that rings true to not only you but everyone else who are involved. Acting on your own version of the story may alienate your peers, especially if you are incorrectly perceiving the situation.

Is the SWE2 actually correct in their estimates? Are they planning their projects properly (why is the most "blocking" issue being addressed by you and not them?) Are you the only one who thinks they lack technical depth (what does that mean, specifically?) Do they regularly throw teammates under the bus? How are you actually performing, in the eyes of your other colleagues? 

Talk with your tech lead and the senior engieers who helped already to understand both what they think of the SWE2's behaviors, and what they think about your role in all of this. Talk to your SWE1 peers to see how they perceive what the SWE2 is saying. Tell them that you want to improve both the situation for the benefit of the team and are just confused by what's going on. 

### Address this particular contentious relationship

Lastly, it's important to address this situation, either directly with the SWE2 or with your EM. To do this properly you are going to need (1) put yourself in the shoes of both the SWE2 and others involved (2) a truthful story about what happened. Whether or not you talk to the SWE2 directly, it's important that you share your concern about SWE2 and your project with your manager. Your EM may not believe you right away, so you need to careful about presenting your story as so not appear you are distorting the truth in your own favor, but if you've already triangulated your thoughts prior and they are still accurate, you should be able to back it up and convince your manager. 

Of course, feedback is best offered directly to the person, though only if they are receptive. Ultimately, the behavior you are describing will hurt the SWE2's career trajectory in the future as throwing teammates under the bus will not help them influence anyone. If they are in fact receptive to receiving feedback from you (which might be... unlikely given what you said), it would be good to do so. 

Want to echo everyone else's point that the senior engineer is abusing their position and should be helping you instead - either directly on these problems or indirectly by pointing you to the correct resources.

From your perspective though, blaming/harboring bitterness toward your senior engineer might not be helpful. I also want to echo Michael's point -

> Trying to figure it out all on your right now is the worst thing you can do

If you are overwhelmed and don't know how to accomplish your assignment, you have to tell your team/manager/peers you need help. That you can't figure it out on your own. It ***is stressful*** to admit it, potentially in front of everyone at a standup, but you have to look at the bigger picture - both you and your team benefits by you learning how to do it properly. Sometimes, it doesn't matter what "should" be the case - it's not the case now, so you and your team have to muster the courage face reality like adults and solve the problem together.

If your seniors/managers are unable/unwilling to help you even after this, do you have any peers on your team who have written react tests before? If there's no one on your direct team, are there anyone in adjacent teams? Ask for a favor from them, "bribe" them with coffee or whatever, and have them show you how.

Later - if you wish address this relationship with your senior engineer, checkout <https://link.jointaro.com/gKieVqcwbH2SYc1t8> and other resources here on Taro about resolving conflicts between peers. 

I'm glad you found my comments valuable! I hope they are able to help you on your journey.

One thing I'll say, is that almost every engineer appreciates good code, good designs, and great unit tests. I've personally read Clean Code and had to learn a lot about how to write good code, both here at Google and elsewhere. If you are curious about Google's own decision making regarding code health, maybe checkout <https://www.goodreads.com/en/book/show/48816586>. 

That being said, you don't want to be the lone-wolf clean code preacher. That's a very common failure mode for engineers and it will only make you and your team bitter. Since software is a group effort - you'll likely have to earn their trust initially, and you'll probably need to introduce some of these concepts slowly. But please do. As a TL, I love it when people are thinking on their own about how to write cleaner code, about how to bring about better code over time. It takes time and good relationships to build this type of culture.

Best of luck!

Commenting as Google engineer here, and I just want to caution against making general statements about codebases of large companies as a whole. Google has plenty of terrible pieces of code. The product I'm currently working for has plenty of code that's not covered with unit tests, especially those written in the earlier days of the product, when it wasn't even clear the features involved would generate traction/users. 

Software isn't written a vacuum; ultimately, the goals of software is to deliver value to customers who are willing to pay for it. As such, the constraints on the software very much also depend on these business factors. Since software isn't a religion, but a tool - we can sharpen the tool as the needs change. 

As you onboard, I would advise observing both the software needs and business needs of your team. It may not be wise to give too much recommendations before you understand how exactly you can add value to your new team.  

Some questions you can ask to help you determine what kind of technical direction your new team should go towards:

1. How long is the current software expected to live? Do you expect to need to throw out or rewrite the code a few years down the line, either because the business evolves very fast or the tools are evolving very fast? 
2. How much difficulty does your team have in moving fast and implementing features that drive value for your business? How much difficulty does the business have in scaling existing features (how bad are the oncalls?) How much of that difficulty is caused by lack of tests (and thus lack of confidence in the code change), lack of proper separation of responsibilities (spaghetti code?), or something else? 
3. How many people will reading and editing the code, now, in the near future, and in the long term? If the startup is located in a slow-growing business (6 years and still series A seem slow?), then maybe there isn't a ton of engineer who's going to suffer low productivity due to tech debt. It may also be easier to navigate around tech debt with a smaller team, than with a giant engineering organization thousands of features in-flight. 

Having said all that, I would say that it's never bad, for yourself, to write high quality code - I would apply 20/80 rule here. If you can spend 20% extra time to produce 80% better code, do it. Mayb you can get 80%, or even 50% test coverage with minimal effort? It's likely worth it and leading the way yourself probably the best way to change code quality culture in your team if that's something you desire to see. 

Alex is spot on! It's super important as an IC to be well-connected, especially within your org, in order to achieve your own goals and the goals of people who depends on you.

This is the masterclass Alex was talking about: <https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/how-to-build-deep-relationships-quickly-in-tech-12172022/>. The best advice that applies at all times IMO is [give credit to / thank others meaningfully](https://www.jointaro.com/lesson/qVASSX157IA6E3hwUN8g/how-to-really-say-thank-you-to-coworkers/).

Since you mentioned "as you moved up the IC levels", I can describe the role of people I believe people should focus their energy on finding and connecting with, for each level that I've experienced thus far. After all, we all have a finite tank of emotional energy to spend - so who we spend it with does matter.

Note, direct manager is not included here because that's an important person to have a connection with no matter the level.

### Entry Level (L3): Look for great peers.

1. Look for a rubber-duck buddy, likely someone of slightly more experience than you. Early on in my career, it was super helpful to compare notes with someone whom I felt really comfortable talking to. I wouldn't understand many things, and maybe they wouldn't either, but you could discuss and figure it out together. Or maybe they've spent 2 days debugging the same type of issues you are facing now and you can save two days learning from them. Or maybe you can talk about which senior engineers in your team are actually helpful for specific types of questions. The biggest challenge of entry level engineer is onboarding properly, and having a buddy who's done it recently is a tremendous asset (plus, they can get credit too for helping you!)
2. Look for a mentor who can take you under their wings. This could your TL, your manager, or someone outside your direct team. Having a reliable mentor who's honest with you is great because they can generally give feedback to help you grow without you feeling like they are judging you (compared to say your manager giving you feedback). They can also share parts of the promo process without having to be politically correct. I personally had someone like this when I was at Amazon, who helped me put together my promo doc and ALSO held me accountable privately when they noticed that I was slacking off.

### Mid Level (L4): Look for great leads.

1. Look for technical leads, whether or not they have the "lead" title. They are often the thought leaders of the organization and those who contribute greatly to engineering decisions. As your goal as an L4 now is to independently deliver projects, on time, it means you need to be very much be in sync with your leads and support them where possible. As an L4, team leads not only look to you to not be a burden ("be independent"), but also to help them where possible. Spot a gap in your feature or risk that your lead didn't see? Volunteer yourself to address it. Your leads are often distracted by your team's many concurrent projects, but you, as an L4, have more opportunity to focus on just a few projects. This means you will have the time to discover issues that sometimes can only be uncovered during implementation, such as a needed refactor. Do these when possible. In addition to learning a lot, it will also earn you lots of trust and appreciation from your leads. Finally, spotting work for yourself like this is also a great sign you are getting ready for senior level responsibilities.
2. Connect with your project peers. Often, your main projects will span multiple teams and you'll have peers working on a different parts of stack together on the same projects. It's important you don't funnel all discussions through your leads (or processes) but talk directly to your partner engineers, understand their plans, and adjust accordingly. Own your project and make sure it ships - and that includes building alliances with people on the other side of fence.

### Senior Level (L5): Look for great partners. And build up your own team.

I'm still working on this so I'll link this talk that I found extremely helpful: [Good vs Great Tech Leads](https://www.jointaro.com/lesson/uHqZZ15SK19MatEvLSO6/what-makes-a-truly-great-tech-lead/). But in-essence:

1. Build great relationships with cross-functional partners. This can be PM, TPM, EMs, or UX. Engineers at this level will be having fundamentally different types of discussion than L4 (not just "how do we build this", but also "what should we build"). As such, it's super important to have regular discussions and have great working relationships with your cross functional partners, so that you don't discover that your team has just spent a year building something that no one in the outside world wanted.
2. Find people you can up-level and build yourself an informal team whom you can rely on. While it's important at lower levels to mentor junior peers or new members of the team, this isn't a necessity - but at senior level this becomes almost part of the expectation. As a tech lead myself, I find that I can add the most value to my team's own delivery by coaching the engineers on my team on the mindsets and skills necessary to be great contributors. They in turn do great work so that I don't have worry as much. You don't even need to know all the answers. Sometimes it's just telling them who in the organization they should talk to or how to act when an emergency occurs. Be the rising tide that lift all boats - or if you prefer a football reference - A great QB elevates everyone else around them.

I'm not qualified to speak on L6+. But I heard <https://staffeng.com/book> is a great resource for this. Hope you found this answer helpful! Good luck on your journey.

Great question! I was confused too when I first joined. 

Once the session is about to start, Alex or Rahul will post in the "general" channel of the Taro slack. It will look like this <https://snipboard.io/6ImBVA.jpg>. Then you click the link and join! 

> In that series, Alex mentioned picking a tech stack and sticking to it.

When I listened to the same talk, I got the sense that when Alex was more talking about sticking with **an area of software with similar concerns** than specific languages or frameworks, though of course there is some noticeable differences between different languages/frameworks.

For example, there are hundreds of web frameworks and each may be written in JS or TS, but they all fundamentally solve the same set of issues: how to transact data and render UI using such data effectively and efficiently on the DOM. There's likely years of practice necessary to be a good web developer, but perhaps only several months of practice necessary to get good at new UI framework. Even with Android (Alex's example), some companies use Kotlin while others (like Google) mostly still use Java.

C# and Java share many features together and if you were already an expert in building backend using C#, I don't believe it will take you a long time to transition your knowledge and experience to one using Java. As such, I wouldn't be too worried about this, as long as you don't switch too frequently (it still takes \~2 years to really leverage some of the nuanced powers of certain languages and frameworks).

> Should I look for jobs that use the tech stack that I am strong with?

I would advise sticking with the same area of software if you can and treat the specific language as a bonus, **assuming you like (or at least, don't hate) the problem space within this area of software.** Once you master one area, it's much easier to branch out to other areas of the stack since you have something to base your exploration on.

CrowdStrike Principal's answer is great. Adding links to a few other similar questions in case you want more things to chew on:

- <https://www.jointaro.com/question/FUP3gHb7rv9CXc84LaKn/how-do-you-get-more-independent/>
- <https://www.jointaro.com/question/QhqQQGrDgFjZbqohpKe0/how-can-i-become-more-independent-and-better-at-unblocking-myself-with-tricky-technical-issues/>

And regarding working with managers on promotion

- <https://www.jointaro.com/question/nbYTuVbu3dqGlPALRGbR/how-to-drive-my-promotion-discussion-with-my-new-manager/>

I'll add one more thing:

> I'm in process for L5 promotion and I feel this feedback can negatively impact my chances.

This sentence indicates to me that you think this feedback itself will hurt your promotion chances. That's incorrect. Your manager telling you this is actually a gift (and in general, feedbacks of most kinds are gifts), because whether they tell you or not, this is what they already think about you. This likely means they don't think you are ready for promotion.

One thing to keep in mind, is that independence is more than just doing certain things, but more of a mindset, that translates into a set of behaviors that people look for. If it's not clear to you what those things are yet, you might want to chat up your slightly more senior folks you are on friendlier terms with. They may be help you more candidly, since they are just trying to help. For my own L5 Amazon promotion some years ago, this is exactly what helped - my colleagues helped me understand what the gaps in my mindset and behaviors were, and I worked to improve them. My manager's opinion changed accordingly as I did better work and promotion by then was a formality. Best of luck!

I presume tomorrow's <https://www.linkedin.com/events/howtonavigatetechindustrylayoff7008960596712849408/comments/> will hopefully address a lot of your questions and concerns.

Since you didn't get laid off (yay!), you likely have some time to prepare yourself and figure out a long term plan, so there's no need for you to go into a crisis mode. Post-layoffs, people left behind often struggle with surviver's guilt and in general tend to worry about their future job security. So if you are struggling with these, know that it's very normal, and you can address it. It's also true that the work load will generally increase due to same amount of work needing to get done but less people to do it with.

It seems you are asking whether you should take some time off to examine your wellbeing and your relationship to work, given the stress you feel. I would say that if you should do this, even if there was no layoff. We as knowledge workers contribute via our intellectual output, but if you don't take care of your physical, mental, and emotional well being, your output will only diminish. In other words, since your company really needs you, they would be really dumb to not let you take the time to make sure you yourself is in a good spot. In my view, it's almost irresponsible for employees to NOT take time off to take care of themselves (it's really not that different from an ignoring a simmering production issue given how employees are arguably contribute more to a company's success than its systems)

It's a tough time, but these times come regularly in our capitalist economy today. It will no doubt happen again in 10-ish years. Learning how to manage these situations will undoubtedly help you and everyone who relies on you down the road.

Such a great question!! It's amazing that your director is trying to focus on area, because it's soft skills are often separates great engineers from the average (and you are on Taro to learn about it!!)

> Personally, at this stage of my career, I haven't thought about whether I would like to stay in IC role or get into management some years down the line.

Great! There are many resources and videos on Taro (like [this recent one](https://www.jointaro.com/lesson/E4p2ZMi8bWPuD47aVyYX/every-senior-engineer-must-decide-ic-vs-management-track/)) about this, but if there's one thing most engineers gets wrong about IC vs Management track is that they think only the management track requires you to work with people, or one requires better soft skills than the other. I believe this to be very wrong. High level IC (Senior+) and managers really both rely on influence on their jobs done, so learning soft skills is a great to level up your game no matter which path you end up taking. 

> The ones which come to my mind are -\
> \- Presentation Skills\
> \- Leadership Skills\
> \- Conducting meetings well with a large audience\
> \- Decision Making

These (though "leadership skills" and "decision making" might be a little too generic to categorize as skills) are definitely useful skills to have. That being said, I don't think these skills determine your fundamental competency as an engineer. For example, presentation skills are really useful, especially if you are demo'ing your work or need to present at conferences. Good presentation help you shine when you've already all the ground work. However, these events happen so infrequently in your job as a SWE, that the added benefit doesn't really make a difference in your day-to-day and in general during your performance. In the case of Amazon, they are infamous for ditching powerpoint presentations at all levels of company in favor of written documents - and I would recommend getting better at writing clearly and concisely if this is more along the line you would like to pursue. 

Having said that, I think there's one skill that trumps them all - and that's relationship building. Alex and Rahul did a [great talk on this](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/how-to-build-deep-relationships-quickly-in-tech-12172022/), and paying attention to do the small things to build deep, lasting working relationships will pay dividends the more how senior you go. It will help you deliver features faster. Make better decisions as a team. Have other people who wants to be lead by you and/or wants to help you succeed. 

Just one, from 2-&gt;3.

> I didn't work on it, it's not my problem.

One of the biggest difference from SDE2 and Senior is how widely you view issues as relevant. SDE2 tend to stick to their own ownership area, or their own project. Senior engineers more likely recognizes and brings attention to issues, technical or otherwise, as problems that needs to be addressed. It doesn't mean they need to personally fix it - often they are just starting a conversation about it - but they usually won't sweep things under the rug because it doesn't impact them personally. 

I also think it's totally OK to not have any "critical feedback" to give to your manager, given you are six-month into your entry level role. 

Another idea is that you could potentially use this exercise to help you increase your own understanding of what does a good manager and good team look like. Ask around - what does your teammates think of the team and their work, and what they struggling with? Is there anything here that you agree with? If so, amplify their voice instead. 

Check-in with your peers outside of your team, maybe from bootcamp, to see how their managers are and see whether your current feelings are accurate. There maybe interesting discussions to be had there that could inform your feedback to your manager.

Agree with Charlie - it all depends on the life expectancy of the UI code you are writing. If it has no users and pivots are likely, there's no real value in adding UI tests. When you serve millions of users, tens and maybe hundreds of developers are working on the same code base, and regressions are harder to detect (for the simple reason that not all developers are experts at the product behavior anymore), automation is great and enables faster development because it allows developers to be confident in their changes. 

That being said, there are actually several different types of UI automation (from simpler, unit-test-esque screenshot tests designed to test UI rendering and simple interactions to heavier end-to-end browser tests like Selenium). The heavier the tests are, the more cautious you should be about implementing them. 

> However, I'm curious on why you say that I shouldn't reveal my PIP?

I like all the answers people have said - that being PIP'ed say less about your ability but more about the fit between you and the specific team. Employers care less about your past performance but more about your current ability and motivation. It's more important to them you have had one year of software experience under your belt than the fact you got PIP'ed in this team. It's extremely unlikely that anyone with decent amount of experience will have performed well in every team they have been part of - it's been 50/50 for my own career thus far - so it's just about finding the right fit most of the time, and moving on when it's not.

At the same time, it also sounds like this weighs heavily on your mind, and as someone who's been through some rough patches in their life, I can empathize if you are having a hard time not focusing on it. If this is true, then the key here in my experience is to start learning and build goals, principles, and metrics you can use to evaluate yourself such that you can be certain that you are far better than when you were. After all - we all started somewhere - it's not that important where we were, but how we moved forward from there to go where we wanted go. If you continue to struggle with this, please don't hesitate to seek additional help via therapy or otherwise. I know it can really eat at people from their inside.

> Also, my past company was known as a high-performance company. If I'm a bad fit, does that mean that I might not be suitable in a high-performance company? I just recently realized that my past company was known for its "sink or swim" culture, which explains why there was lack of proper onboarding. Does all high-performance companies have "sink or swim culture"?

First, it's probably best not to label it by company, but rather by team. High functioning teams (including those at Google and Meta) rarely have a sink or swim culture, because they realize no one can succeed on their own and the best teams have strong performers all around. Mentorship is often a huge part of senior engineers' job in those companies (watch [Alex's talk on relationships](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/how-to-build-deep-relationships-quickly-in-tech-12172022/)), and your last team seemed clearly understaffed and over stressed. I think making "finding a supportive team" your priority during your job search is an often overlooked criteria that you might want to emphasize as you continue your search!  

I think someone from Meta can offer more precise advise, but maybe you'll find these helpful since this generally maps to other big tech companies as well:

1. At Google, The main difference between Level 3 and Level 4 is independence. Meeting expectation at L3 means you are doing everything you are told to do. At Level 4, you would be expected to figure out more of what you need to do on your own, especially from an implementation perspective. E.g. You are trying to implement logic A, get it to work but change doesn't really fit the intent of the surrounding code - L3 would probably submit it for review soon after, but a good L4 will take some time to maybe do a refactor first then send the code logic change.
2. If you manager is new and isn't able to clearly explain to you what performing at the next level would look like, it may be best to find a more senior team member who's able to show you what that would look like. What is the code velocity of the average level 4 engineer on your team look like? How about the best level 4 engineer? Coming close to their levels and learning from them how to do it would likely go a long way.
   1. Caveat here: you also don't want to focus on Code Velocity too much (it's more of trailing indicator for how effective you are at implementation) - it's more important to figure out how the top performers on your team are able to move so fast, rather than trying to brute force this.

Good luck!