Would it be accurate to say that a huge part of de-risking 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. 

Senior Software Engineer [L5] at Google

Kuan Peng

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!