I've never worked for FAANG or Tiktok but here's my thoughts on how I'd approach it.

1. If you live near the office, go in everyday for the first 90 days - minimum (even if remote option is available)
2. Setup 1:1s with everyone on the team (design, product, all engineers)
   1. Ask them questions to understand what a successful engineer at your level looks like.
   2. Identify 1-2 high performers on the team/within the eng org - understand their workflow - how they prioritize work, how they unblock themselves, any productivity tips that are specific to eng tiktok work, etc. 
3. Ask your manager to help set expectations, what do they expect you to accomplish in first 30, 60, 90 days at the job. 
4. At 90 days at the job, setup 1:1 with your manager and review with them what you accomplished in the first 90 days, ask if you are meeting expectations and ask for feedback and where you can improve. 

Engineering Manager @ Blend

Joshua Yu

- Do you ***actually*** care about people's growth? - I think a lot of people think that they care about people but their actions speak differently. Impossible to be a great manager if you don't have a genuine care for other people. 
- **Are you okay with spending 0-20% of your time in coding/development and 80-100% of your time in meetings / handling process / coordinating with folks?** - sure, for different orgs its different but its common that managers go days/weeks without writing a single line of code and spend most of their time chatting with other people and coordinating efforts to enable other people to do work. 
- Are you bored? - sometimes I'm tempted to switch things up when I'm bored where I should actually just stick to the thing I'm already doing.

hope that helps. 

For me, I setup some criteria/rules ahead of time to make decision making process easier. Obviously, there's some discernment needed for one-off situations but generally here's how I look at initial recruiter messages. 

- Glassdoor 4+ rating
- Total comp
- Remote flexibility (hard requirement)
- Fintech company
- IPO'd/10+ years company

I'm at stage of my life where I'm more concerned about stability/consistency. When I'm looking to change jobs, If a company has at least four out of the five, then I usually go forward. If less, then I generally say no.

With glassdoor, it should be noted that most people report/review on glassdoor because they've had a negative experience with the company. At my current company there was &lt; 4 glassdoor company, but I'm loving my experience so far. With bigger companies (1000+ people), I'd take the comment/review section with grain of salt. I think a more relevant feedback would be asking your potential teammates/manager what the work environment is like.  

Engineering Manager at Blend

Here's what I would do in your situation:

1. **Revisit the code owners file** – to me, doesn't make sense for backend folks to be approving frontend PRs. 
2. **Teach why 2000 LOC for PR is generally a bad idea** – things aren't usually black/white situations where it's completely good or completely bad... there's nuance and discernment needed to be practiced. Maybe the external team is pushing huge PRs because they don't fully understand pros/cons of big PRs. (this can be done via email, presentation, team meeting, or any combination of these)
3. **Teach how to have smaller PRs** – related to above, maybe the external team doesn't know good practices on how to split up a bigger feature/PR. Take some existing 2000 LOC PR, and give examples of how you would've broken it down into separate chunks.
4. **Repeat above this multiple times, have patience** – it's hard to change behavior, unlikely to change behavior after you've said something once / taught it once... lower expectations to change people's behavior... generally takes multiple reminders over long periods of time. Recognize how difficult it is for you to change quickly so that you give people the same amount of patience to change as you would yourself. 

Sucks to suck (jk). Here's some things I would tell myself if I were in your situation:

- **Put my ego aside and ask what the junior did** – it would be easy for me to feel jealous/envious of this other engineer, feel they are undeserving, even distant myself from that junior engineer out of jealousy.. but those feelings and actions do not help me in getting paid more. What would help me getting paid more is putting my ego aside and try to extract as much information from the junior engineer as possible as to what they did differently during their interview/negotiation process.
- **Avoid putting extra effort into the team reflects my character** – it's easy to 'justify' working with less effort in this kind of situation.. however, I am harming myself the most with this kind of attitude. I am reinforcing the behavior of 1) encounter stimulus, unfair situation 2) put less effort into what I'm doing due to unfairness. Continue this kind of behavior for 10-20 years... not pretty.

This is what I would do if I were in your position (a junior engineer at a cross-roads @ their career).

1. **Optimize for learning not earning** – early on in my career, I made the mistake to over-indexing on earning; these days I've changed my mindset to always optimize for learning and from my experience, the earning will naturally come. 
2. **Surround yourself with mentors/seniors** - one of the biggest catalysts of my career was being around people who 1) were more technically strong than me 2) wanting to invest in me 3) pleasant to work with. If you find this magical place, I suggest you stay there for as long as you are learning/growing.
3. **Double down on high demand skillsets** – in the frontend world, everything is react/typescript these days and now it seems the battle is between react frameworks (e.g. remix vs nextjs). Double down on existing high-demand skills (e.g. react/typescript) and keep a pulse on where the next 'high demand' trending tech is within frontend. 

Here's some off-the-cuff thoughts

- **Clarify areas of ownership** – Sounds like there's poorly defined areas of ownership; it's odd to me that other managers/directors are telling other engineers from other teams what their priorities should be. Once reorg settles, there could be opportunity to clearly define areas of ownership.
- **Reorg thrash** – I would take this is as part of the reorg thrash - I think in this kind of environment, where there's confusion, new teams, new managers for teams, one of the best things to do is "nothing", just wait for things to settle down. Acknowledge their request and tell them you'll circle back with them once you get a chance to sync with mgr/team on priorities.
- **Push your manager for clear priorities** – make sure you and your manager are aligned on what you should be working on for the sprint/quarter. Write it down, date it, and check-in with them on a weekly/bi-weekly basis (whenever your 1:1 is with them); if they doesn't have time for 1:1... then find an alternative way to make sure you/your mgr/your pm are all on the same page.
- **5-15min checkins** – if your boss doesn't have time for a normal 1:1, propose a 5min-15min check-in every week or two weeks just to touch base. Tell them what you want to cover during that time (give an agenda ahead of time), and if there's nothing on the agenda for that week's check-in then just cancel. (show your manager you value their time)
- **Tag/cc your manager only when necessary** – as a senior engineer, I'd expect that you'd be able to discern what you should/shouldn't be working on based on your priorities; I'd suggest only looping and tagging your mgr when you really cannot solve the situation yourself. And then once the situation has been resolved give them a quick summary/tldr of the situation, what was asked, how it was resolved, and what are next steps. (b/c your mgr is stretched thin, they don't need to know everything, but still prob want to be looped in)

I understand what it feels like to still be at a company that's had multiple round of layoffs... 😅. Here's some things that I try to remind myself:

1. **Worrying doesn't do anything** – we're all humans and encounter stressful and anxiety filled circumstances... but we get to choose how we react to those circumstances. When I find myself in a worry cycle, I try to devote my thinking towards things I can control and not things I cannot control; while reminding myself that choosing to worry/anxious does not change the outcome of the situation, hence not a valuable use of my energy/time.
2. **Position myself to be able to walk away** – just like in negotiating job offers where I have the highest leverage when I have the ability to walk away, the same principle holds true while I'm still employed. If I'm in a financial position where I will be "okay" without a job for 12-24 months (living expenses), and I obtain high demand skillset in the job market then regardless of whether or not I have a job doesn't impact my life/lifestyle.
3. **What is the worst case scenario?** – for me, thinking about the worst case scenario(s) puts my mind at ease because there's less surprises, and I realize they aren't that bad... e.g. my pay gets cut, I get laid off in the future, workload or expectations is unreasonable, major reorg, I quit - can't find high paying job – get lower paying job – move into smaller apt/eat cheaper food.

😔 not cool... 

1. **Loop in HR sooner** – other people may disagree but I would suggest looping in HR sooner rather than later. You don't have to initially give a name, but I'd suggest to let them know of the situation and how uncomfortable it is making you.. so then if/when something does occur that "crosses the line" (if it hasn't already) it doesn't come as a surprise and HR would be better prepared to take actionable steps.
2. **Manager** – I agree with Alex, if you trust your manager then I'd suggest you let them know. One thing to consider is if your manager knows this male colleague, and how likely/unlikely would it be for the manager to tell this male colleague about what you've told them. Unfortunately, in situations like this it's important for you to control the narrative... 

I hope the best for your situation. 

I definitely echo some of the things that were already mentioned:

- [Notion app](https://www.notion.so/) ([obsidian](https://obsidian.md/) is pretty good too)
- Practice/apply what you learn

Another way that I've recently found helpful in retaining knowledge is creating content (e.g. LinkedIn posts) based on the things that I'm reading, listening, watching. The process forces you to 1) synthesize what you're consuming and 2) articulate it into your own words. 

For my team I implemented [standup 2.0](https://linearb.io/blog/daily-stand-up-2-0-its-time-to-ditch-the-stand-up-from-1993/)

- We use [geekbot](https://geekbot.com/) to cover all the standard questions (yesterday, today, blockers)
- We use standup meeting to talk about the juicy stuff (blockers, distractions, shipping on time) &lt;-- Like Rahul said, generally this is what leadership cares about. 

I think people are usually fine being asked to do something. However, people often don't like to be told what to do. So even if you ask a question but the assignee interprets it as a command/directive (and feel that they don't have a choice) then you'll increase the likelihood of people disliking you. 

With that beings said, you can preface and/or post-script your question with something like:

- "please don't feel obligated to take this task, if you don't think you're the best fit for the task then let me know..."

Here's a few thoughts:

- **Rare in the conflict it's 100% one person's fault** – in most cases that I've seen when conflict arises, rarely is it 100% one person's fault. Maybe see if, Person A + B can buy into this perspective and see if they'd be willing to admit/own how they've contributed to this conflict (even if they believe it's a minor part)
- **Promote team mindset** – something that you can encourage folks to have is a team/community mindset (e.g. seeking what is good & best for the team). If people are unwilling to work through conflict in a mature & healthy way then they're prioritizing their self over the team which most of the times is just selfishness.
- **Treat others how you'd want to be treated** – curious if "person A" would appreciate to be called out in the same manner that he called out "person B" – the same tone, style, word choice, setting etc. Could lead to an interesting conversation.

Hope that helps. Happy to clarify and/or provide more thoughts.

Tough situation.. I don't think there's a "silver bullet" here to solve the situation but here's some thoughts:

1. **Belief change** – you mentioned that the E6 treats other engineers on the team this way, which IMO means that this person has a fundamental belief that micromanaging style is better than the alternatives. In order for this person to change their style, their beliefs around this behavior must change. 
2. **Rare for people to change quickly** – I'm assuming the E6 has behaved this micromanage-y way for a while, and if so, then it's unlikely to see any permanent long-lasting changes quickly – the E6 might be momentarily deterred to behave that way temporarily due to some feedback but most likely will revert back to their default behavior. 
   1. it's rare for people to change quickly, it's rare for people to change at all (especially when their mode of behavior has served them over a long period of time)
3. **Clarify areas of ownership** – feels like there's opportunity to clarify areas of ownership – when areas of ownership are clearly defined, then it becomes clear who is the point person/decision maker within a certain domain. 
   1. If you are leading a meeting / initiative and the E6 is "overruling" you in that moment, you can suggest to take that conversation offline (separate time).

"Any concrete suggested steps will be great instead of just some general bullet points." I will try my best to give detailed and actionable bullet points 😅.

1. **Do a lot of reps** – take your assigned tickets, open PRs, get PRs reviewed, address PR feedback, and merge them. If you find yourself finishing more assigned tickets for the sprint, ask your manager/lead for more tickets. Go beyond of what is "expected".
2. **Get PR feedback from high quality PR reviewers** – Not all reviewers are the same – some people are excellent reviewers and if they see that you are open to learn and iterate quickly based on feedback, then it increases the likelihood that they would want to continue reviewing your work.
3. **Creep/study other people's PRs** – ask your manager, other members on your team, who writes high quality code and in what areas – look at their PRs, study them, ask questions, understand their decision making. 

The way that you phrased the question makes it seem like you're already working very hard (e.g. long hours) to accomplish all the tasks assigned to you. When you say, "squeeze time to help others", it's based on the assumption that you are already managing your time very well. 

Here's some thoughts:

1. What is your current time management system? (e.g. what hours of the day are you most productive, what schedule do you have for deep work, are you being prudent in choosing which meetings I attend, etc)
   1. [Here's a video on time management system](https://youtu.be/c3pzcV9yi24) from Uncle Steve
2. Once you've got your time management system established, decide/ask yourself, "how much time throughout the week do I want to dedicate to helping others?" And then schedule that into your calendar/week. 
3. Find opportunities to help at scale – oftentimes, the same type of questions get asked on a repeated basis and doing 1:1 zoom calls to answer questions can feel repetitive. If you feel that others can benefit from the help you're giving, find ways to write it / present it once and then distribute it to the rest of the team. (e.g. recording presentation, writing documentation)

A couple thoughts:

1. If the goal is to push the boundaries of your technical skills, then don't pick projects/tasks that you already know the answer to (aka know how to solve). 
2. One thought exercise that could help is rank the projects according to your best guess around "pushing your boundaries", and provide some rationale for each, then ask a coworker/teammate (preferably someone who is more senior than you) to review and provide feedback. 
3. Even "boring" projects have the opportunity to push the boundaries of your technical sills – since there is probably opportunities to revisit the "basics" and dive deeper to make sure you thoroughly understand them.

I think it's worth responding to LinkedIn recruiters even if the answer is "no". LinkedIn recruiters get their InMail credited back as long as their message is [accepted/rejected](https://www.linkedin.com/help/recruiter/answer/a413322). I like to respond to all recruiter messages so that they can get their credits back (IMO, it's the nice thing to do hehe).

I have three snippets that I use...

**Snippet #1**

Hello! Thanks for reaching out. Please let me know the following information before we go forward with discussion (if they weren't already answered in your original message):

\* Company name\
\* Total compensation range\
\* Remote Flexibility

Thanks!

**Snippet #2**\
Thanks for the info, but unfortunately I'm not interested in the opportunity! Good luck!

**Snippet #3**\
Thanks for reaching out. Do you see an opportunity for me to help as more of an advisor than a full-time role?

I’m currently not in the market for a full-time role, but I am open to other arrangements.

\--

I bind them the above snippets with [Alfred's text expansion](https://www.alfredapp.com/help/features/snippets/) so going through messages is must faster/easier. 