This is one of the examples of classic Meta culture shock, so don't worry, many engineers have gone through this before and successfully come out the other end (I mentored many engineers through this).

Your teammate is right in that your diffs are too big. The good news is that once you start pushing more atomic diffs, you'll almost certainly find all of these code quality problems going away. Your overall strategy here should be to:

1. Decompose every task/project you get into tiny chunks where each chunk is 1-3 diffs
2. Get feedback on your decomposition before writing any code
3. Execute and push out super clean, focused, and relatively small diffs

I made an entire course about this process (and more) which you can go through here: [\[Course\] Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)

If you're crunched for time, you can start straight at the "Break It Down" section: <https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/break-it-down/>

As for specific tips on transitioning from Java to PHP, I unfortunately don't have much. I also joined Meta with a Java background, but I didn't have to write much PHP as I do Android. Java and PHP are pretty different languages, and to be 100% honest, I think PHP is sort of a janky programming language. My advice is to be a feedback sponge in code review, identify patterns from experience, and just keep on improving. More thoughts here: ["What is the effective way to understand new repository in order to make the required changes in that repo?"](https://www.jointaro.com/question/KoxB3UU2zWC9pdYU6Rx0/what-is-the-effective-way-to-understand-new-repository-in-order-to-make-the-required-changes-in-that-repo/)

Tech Lead @ Robinhood, Meta, Course Hero

Alex Chiou

Always happy to teach others how to be a good human 😁. I hope you're able to take these tactics and successfully apply them to the next 1 on 1 conversations you have!

I think radio silence &gt;3 days is worth following up on. The best thing to do though is to ask them directly what to expect with turnaround time. You can even do this live at the end of the interview round if you feel like it went well and you two were vibing: *"It was good chatting with you! Just one last thought - When can I expect to hear back about this?"*

The key to understanding what makes a conversation especially meaningful is realizing that 99% of people (even shy introverts!) *greatly enjoy talking far more than listening.* On your end, **this means that you should try to listen far more than you talk.**

But let's break down the talking part: When do people enjoy talking? *It's when they get to talk about something they're deeply passionate about.* So your operating mindset when going into the conversation should simply be this:

1. Find something the other person really cares about
2. Make them talk about it and support them with positive vibes

For #1, the easiest way to do this is to ask probing questions like *"What do you do for fun?"*. This one might not work though as it can feel a bit aggressive, especially with naturally awkward people (i.e. most engineers 🤣). What is far more powerful from my experience is *listening intently* and then "picking up" something they're interested in. This shows to the other person that you're paying attention (hence you value them as a human being) on top of the value of letting them talk about a fun thing.

As an example, let's say they mention in a broader point that they were working on a machine learning side project over the weekend. You can pick up on that and dig deeper with something like: *"That ML project sounds cool! What does it do?"*. If they're clearly enjoying themselves talking more about the project, you should foster that energy by asking more questions. On top of that, show interested body language by nodding along, smiling, and saying positive affirmations like *"That's awesome!"*.

It's true that providing concrete tactical advice to someone is incredibly valuable. However, there's also a lot of value in being a friendly, supportive face, more than many people realize. At the end of the day, a lot of us just want someone to listen. Be that someone 🙏

I cover these concepts and a bunch of others in-depth in my Effective Communication course: [\[Course\] Effective Communication For Engineers](https://www.jointaro.com/course/effective-communication-for-engineers/)

The obvious path forward here is to level up your own pull requests. Once you have become a top-notch code contributor, go further by inspiring others to level up their code (the easiest route here is to become a prolific reviewer of others' PRs leaving thorough but empathetic comments). Here's a course that dives into all that: [\[Course\] Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)

As Jonathan mentioned, don't talk the talk if you can't walk the walk. Be careful voicing a strong opinion on something if you don't have the street cred to back it up. Classic senior engineer behavior is to become a proven thought leader on an area (like code quality) and then sharing that wisdom with the team. The good news is that you have already done the first step of acknowledging your own flaws (this is something that can be surprisingly difficult). Now you just have to follow through!

Here's a senior -&gt; staff case study I gave that is a great example of everything I just talked about (i.e. cultivating a stellar reputation and then leveraging that to inspire massive change): [\[Case Study\] Revamping Oncall For 20 Instagram Engineers - Senior to Staff Project](https://www.jointaro.com/lesson/esVxIGXYC5BdgxXUkO6H/case-study-revamping-oncall-for-20-instagram-engineers-senior-to-staff-project/)

*You should definitely reach out!* Every interview loop where you're still alive is a potentially valuable resource, so you shouldn't let momentum die if you can. I understand not wanting to overload yourself with interviews, but if a company really likes you, hopefully they can be flexible letting you schedule the next round on a week where you're not overloaded.

6 days is an eternity in the current job market, so I would reach out ASAP. Digital ink is cheap, and if this company is any good, this is an opportunity worth following up on. I have seen so many engineers be surprised with how competitive a company's offer can be even if they're not a "name brand".

This other thread covers something similar: ["Final round interview IC1/IC2"](https://www.jointaro.com/question/sns4OtmSek3BpQgaMgeo/final-round-interview-ic1ic2/)

There's indeed a *very* large cost when it comes to switching jobs quickly (time/energy for interview grind, looks bad on your resume, need to go through onboarding again), but sometimes that cost simply has to be paid. Work is such a big part of our lives, so if your job is making you miserable, you should 100% quit. No job is worth your mental health - At the end of the day, I just want everybody within the Taro community to be happy ☺️

What I will say though is that you should thoroughly try to make things work if you can. In this market, staying at a job is much better than switching jobs (at least in a vacuum). Hopefully something from here can help: [\[Taro Top 10\] Growing Fast With Remote Work In Tech](https://www.jointaro.com/playlist/7BUYfX3TSWJt1xIHUfpz/)

If you still really think switching is the answer, Taro is here to support you as well and I recommend this course: [\[Course\] Ace Your Tech Interview And Get A Job As A Software Engineer](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/)

**Side note:** If you haven't been at your current job for very long (2 months or less), just leave it off your resume entirely and pretend you never did it.

Best of luck!

I think you should go for it: *It's far better than nothing.* I'm glad you're having a lot of fun with these side project and learning from them - This is why I'm such a big fan of side projects!

Unfinished side projects are one of those things where it could be tremendously valuable during an interview but it certainly won't get you get an interview as it would look pretty awful on your resume.

For more help/inspiration with side projects, check this out: [\[Taro Top 10\] Building Impressive Side Projects](https://www.jointaro.com/playlist/vKUWMgmmaEvzcYUXZs4B/)

I have actually worked alongside rotational SWEs at Meta, so I can go through how the program works. Unfortunately, I didn't know any of them too closely so I can't give any details on specifics like comp. Anyways, here's a bunch of details:

- As a rotational engineer, you *rotate* across 2 different teams across 2 halves. Given that a half is 6 months, this makes the program 1 year long. You're effectively on loan.
- The expectation is that after the 2 rotations, you are functioning at an E4 level. If you are and the team you're currently on likes you, *you will get hired as a proper full-time E4 engineer.* If these conditions aren't met, you are let go.
- *Rotational engineers are between E3 and E4 in terms of skill level.* The role is meant for engineers who have potential but don't meet Meta's very high engineering bar, usually because they have never worked at a FAANG-level company before.
  - I worked with a rotational engineer who had almost 10 years of experience! They were a senior engineer/tech lead at their prior company, but the bar there must have been really low (as it is in many non-FAANG tech companies). They were a nice person who was clearly trying but was severely lacking in fundamentals like [code quality](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/) and [communication](https://www.jointaro.com/course/effective-communication-for-engineers/). I could see why they were hired as a rotational engineer.
  - Meta has a hard cut-off for E3 hiring. I think if you have &gt;4 YOE (it might be 3), you can't be hired as E3 anymore.
- Rotational engineers are sort of like contractors in that they're not proper FTE and are frankly treated as 2nd class citizens. They don't count towards headcount allocation for teams, so engineering managers use rotational engineers to fill small gaps here and there. They are usually not given good scope.

The problem with being a rotational engineer is that you can't build up good relationships as you rotate after 6 months. Being a "Meets All Expectations" E4 isn't trivial in this economy either: Meta is cranking up stack rank and PIP percentages to fire more engineers. I have worked with a lot of senior engineers who probably couldn't survive as an E4 in this market.

What I will say though is that despite all the shortcomings, Meta is still Meta. You'll learn a lot as a rotational engineer (especially in code review), and there's a clear path towards a proper FTE offer. With Taro on your side, you would have a better chance than most. If you can't get into Meta as an E4/E5, I think it's worth giving the program a shot.

Meta E4 offers can get pretty high too - I have seen $325k TC in some cases, though I imagine a rotational engineer offer would be bottom of band, not top. Still, even something like $250k would be higher pay than most senior engineers. Meta is also *extremely* generous with high performers. A "Greatly Exceeds Expectations" rating could increase an E4's comp by $35k - $50k. So even if you get in as bottom of band, you can work your way up.

**Interesting side note:** There is a rotational PM program at Meta as well but they get 3 halves.

You can still do good work in a less cutting-edge company. A lot of engineers have the skills to hang with the best at FAANG, but they haven't been given the proper environment to fully shine yet.

I still think you should take the offer 😁. I believe in you!

Ah okay, got it! That makes a lot more sense. I just edited my original response.

**EDIT:** The question initially asked about referrals and not recommendations, so here's my new advice: I think it's totally fine to ask for LinkedIn recommendations at any time really for a coworker you got along with. If they're currently leaving for a better job, I imagine they have a lot of positive energy, so that seems like a good time to ask for a LinkedIn recommendation to me.

---

I'm confused - When you say LinkedIn referral, do you mean one of those testimonial/recommendation thingies?

At first I thought it was a referral into a new job, but then you mentioned that if you were leaving your current company (presumably for a better job), you would ask your current coworkers for a referral. But I don't get why you would need a referral if you have a new job lined up?

Maybe I can't read, haha. 🤔

Oh wow, congrats! *I'm 99% sure you should take the senior offer.* The mid-level to senior promotion at FAANG is notoriously difficult, especially at Amazon. Getting the senior title now will indeed jump start your career trajectory by several years and will save you a lot of headache in the future. As you mentioned, these top companies spend a ton of time fine-tuning their interview process to level people properly, so I'm sure they saw lots of senior engineer behavior from you during the interview. Lastly, you have Taro on your side to ensure that you're a high performer 😉

If you want more information on whether you should get a downlevel, check this out: ["When should I down level myself on purpose at a new company?"](https://www.jointaro.com/question/vck83XFTcKpuzD7qnA6T/when-should-i-down-level-myself-on-purpose-at-a-new-company/)

To set yourself up for success at Big Tech, go through the resources here: ["How to skillup to be ready for FAANG job?"](https://www.jointaro.com/question/z3Iafy18yto9egXwxs76/how-to-skillup-to-be-ready-for-faang-job/)

So here's my primer on how I write. I should probably turn this into a course later. Anyways, let's just dive in.

### Make Sure Spelling And Grammar Are On Point

It's pretty crazy to me how some engineers are making $250,000+ per year and type out some of the worst English I've ever seen. I understand that English isn't the 1st language of most engineers (including me!), but there's no excuse to have poor spelling/grammar nowadays due to awesome tools like [Grammarly](https://www.grammarly.com/).

This is a low-hanging fruit that adds so much to the resonance of your writing. I noticed that your post has very clean spelling/grammar/punctuation so you're already on the right track!

### Organize And Split Up Ideas

"Wall of text" is the next super common failure mode I see when people write. It's just a slog to read 15+ lines of text with 0 breaks, especially if spelling/grammar are poor.

This is why you'll see me constantly adding line breaks, bullet points, and headers. In fact, you can see me doing this literally right now!

This is another low-hanging fruit that takes like 1-2 minutes to implement. If it's too hard for you to do it while writing, just write out all your stuff and break it up afterwards.

### Be Positive. Inspire.

There is waaaaay too much negativity in the world. The engineering world doesn't need any more people telling you that every company is evil and every manager is the spawn of Satan so you should just leave your current job (that'll totally fix everything right?).

I've always been a *"Glass half full"* type person. However, I've also always done a good job of not mincing words and being honest with people: I don't sugarcoat. I got a ton of points for that as a mentor which is why my mentees loved me so much and [got promoted so fast](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/how-this-course-works/).

My approach is to be transparent and then share advice to improve your situation, because it's incredibly rare for a situation to literally be completely hopeless and impossible. In 99% of cases, there is *something* you can do to make things better, even if it's just incremental improvement.

I'm not that smart. But what I am good at is learning quickly from mistakes (and making lots of them 🤣) and being deeply empathetic with people, which makes them want to help me. I truly believe that anybody can do what I did. I grew up as a painfully shy introvert with near 0 friends. If I can succeed, so can you.

### Talk Normally (Like A Friendly Human Would)

You can see this with my response right now as well. Emojis are a corollary for the facial expressions I would make if I was telling this to a person IRL. Things like "waaaaay" are things I also say verbally in a regular person-to-person conversations. Having a casual vibe makes your writing a lot more exciting (and retentive) because people feel like they're listening to someone instead of slogging through a wall of text.

### Respect The Nuance

I almost never talk in absolutes, because it's incredibly rare for something to be the optimal path 100% of the time. You'll see this in how I use tentative language a lot.

Another thing I do is to proactively handle the edge cases. You'll see me write a lot of things like *"Try this, and if it doesn't work, try this"*. Thinking 1 step ahead is very important and saves everyone time. This applies to code as well, because thinking through system design and edge cases proactively is a massive productivity boost and a sign of senior+ engineer behavior.

### Conclusion

For folks reading this, you'll probably find this overwhelming and that's okay! My advice is to take all of these tips 1 at a time. If you improve just a little bit every day and have the mentality of building up muscle memory, you'll genuinely get better super fast. It's not rocket science: *If you want to get better at a thing, just do the thing a lot.*

Lastly, here's another thread that covers this all in more detail: ["How to make communication succinct and more impactful?"](https://www.jointaro.com/question/QDLV5owweJveRLlspOdc/how-to-make-communication-succinct-and-more-impactful/)

I'm flattered 😇. I have a lot to say here so I'll just go through all your questions first and then share bigger overall guidelines.

> What does Alex Chiou read?

*I actually almost never read books.* Ever since I graduated college, I average 1 book read every 2 years (a bit less than that actually).

The only reading I do is for day-to-day stuff to survive. So like the instructions on a food container or my tax return. I also read pretty much everything on the Taro forum.

> How does he think when he writes?

I take how I would talk to that person IRL in response to their question and convert that into written text. In terms of how I come up with what to say, I'll cover that later.

> Is there a certain number of drafts?

Nah, I just write. It's a big reason why I'm so efficient. I just write stuff out and make edits if I messed something up. It's the classic Meta philosophy of getting something out there quickly and iterating on it.

Overthinking before communicating is how you waste a bunch of time just to end up tripping over your own words anyways when you finally get something out there.

> Does he get someone to read it and give their thoughts etc?

For 99.9% of the writing I do, I don't. I have a lot to say (and a lot of people to help!), so I prioritize speed. I only get feedback on really big written materials like the outlines for my courses! And even then, those aren't scripts, just high-level pieces.

I forgot to mention that I have near 0 understanding of JVM and ART and I've done just fine as an Android tech lead. This is because I've always worked more on the product side and never needed to deeply understand those areas.

The only time you should feel bad about a lack of knowledge is if you have been punished for not being familiar with certain things. In that scenario, embrace the mistake and learn those things. That's life.

When it comes to the step-by-step plan to break into FAANG, this is it:

1. Get the interview
2. Pass the interview
3. Meet expectations (don't get PIP-ed!)

It looks like you're still on Step #1. The good news is that it's easy to tell where you stand with it: *Just apply!* More specifically:

1. If you have any Big Tech recruiters in your inbox, reply back to those messages
2. If you have any referral sources, leverage them to get a warm lead in. You can try reaching out to folks within Taro Networking as well: <https://www.jointaro.com/networking/?selectedServices=Referrals>
3. After you have exhausted #1 and #2, just send in applications online and hope for the best 🙏

Before you do any of this though, make sure to polish your LinkedIn and resume, particularly your resume. Follow the advice here: [\[Masterclass\] How To Write A Stellar Tech Resume That Gets You More Job Opportunities](https://www.jointaro.com/lesson/OnQV2V3J8DYVBBuGbZx6/masterclass-how-to-write-a-stellar-tech-resume-that-gets-you-more-job-opportunities/)

We also have communal resume events so keep an eye out for those. Here's an example: <https://www.jointaro.com/event/collaborative-resume-review-meetup-9/>

Lastly, my job searching course lays out the interview success process in a step-by-step way: [\[Course\] Ace Your Tech Interview And Get A Job As A Software Engineer](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/)

Easier said than done of course, but my advice is to stop constantly worrying about layoffs. Of course, if your company's share price is down 80% and your VP has hinted about job cuts several times, polish up that resume and start applying. But if you don't have concrete signals that layoffs are coming in your organizations, just focus on becoming a better engineer and building up your professional network.

At the end of the day, a tiny fraction of life is stuff we can control and the rest is stuff that's out of our hands. Just focus on hyper-optimizing that small slice you do control, because that's all people like you and I can do as regular engineers.

Here's a good video covering all this in more detail: [This Is How You Become A Layoff-Proof Software Engineer](https://www.jointaro.com/lesson/Nit24jGWG45cFdmB6sJo/this-is-how-you-become-a-layoff-proof-software-engineer/?playlistId=e2nAHFYqMZSbdopXpsII)

Since you're an Associate Software Engineer, I *highly* recommend our code quality course if you haven't finished it already: [\[Course\] Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)

You shouldn't feel bad at specializing in Android, and FAANG doesn't only hire geniuses. I know both of these for a fact as I'm an Android specialist and I'm also not a genius 😁 (at least not a "traditional" genius). In fact, I would go as far to say that I'm not that smart. I've always been pretty slow to pick up complicated concepts - "Getting" things takes me a long time.

What I will say though is that in order to get into FAANG, you need to be extraordinary in *some* way. For me, there were 2 things that helped me a lot:

- **I'm good at getting people to like me** - I've historically been effective at empathizing with people, especially when they're down and need cheering up. Because of this, I have cultivated an incredibly deep network over the years and never had trouble getting intros at top tech companies. I'm an introvert too by the way, so don't think that you need to be some "Charisma: 100" extrovert to do this, that's not the case. We share a lot of networking tactics here: [\[Masterclass\] How To Build Deep Relationships Quickly In Tech](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/masterclass-how-to-build-deep-relationships-quickly-in-tech/)
- **I'm always tinkering** - Ever since college, I've been building side projects for fun and to bolster my learning. I have published 30+ apps with around 5 million users combined, and these have been so powerful getting me interviews at Big Tech and boosting my overall coding power. I didn't built super genius or innovative apps either; I literally built some of the simplest apps you can possibly imagine. You can learn more about this here: [\[Case Study\] Building An App With 1,000,000+ Users To Get Into Facebook](https://www.jointaro.com/lesson/jly45Gx6qR1kqQwBmJEy/case-study-building-an-app-with-1000000-users-to-get-into-facebook/)

So it's kind of true that you need to be a "genius" in some way in order to get into Big Tech, but it doesn't have to be through raw natural intellect which is what people think of when they hear the word "genius".

Here's another excellent discussion I recommend checking out: ["For self-taught developers - How to build my own knowledge system during work?"](https://www.jointaro.com/question/trv7XsSTSK2WNkb7UO8a/for-self-taught-developers-how-to-build-my-own-knowledge-system-during-work/?playlistId=SzIOYQ4Ib3lj61jjhX01)

I don't think discriminating against projects based on whether they're maintenance (also referred to as "incremental") or greenfield (also referred to as "0 to 1") is the right way to go about it. At the end of the day, there are 2 types of projects:

1. Good impact projects
2. Not good impact projects

That's it. That's what truly matters. Now here's the interesting part:

1. **Maintenance projects often have incredible impact** - This is very much the case at massive companies like FAANG where most of the work is incremental. Most of the work I did at Meta was incremental. In fact, there are literally L6+ engineers making well over $500,000 per year who do nothing but fix bugs all day. This Staff+ engineer archetype is called "fixer" at Meta and "solver" across the broader industry: ["What does a path to staff look like in a coding-heavy environment?"](https://www.jointaro.com/question/lhAhs6dcftvFXkkeyLYC/what-does-a-path-to-staff-look-like-in-a-coding-heavy-environment/)
2. **Many greenfield projects have terrible impact** - Writing code from scratch often has lower technical complexity than maintaining existing code, because there are naturally less intricacies to consider. At Meta, I knew tons of engineers who were stagnant (i.e. stuck at the same level) because they worked on teams spinning up new apps and those apps never went anywhere (Meta in particular is horrible at creating new apps). Another downside of 0 to 1 work is that there's no metrics to measure your success. It is harder to make a case for why you deserve to get promoted vs. this other engineer who also wrote a bunch of code.

So when it comes to evaluating projects and choosing teams, you need to zoom out and use your personal intuition and product sense to figure out if that scope has real business impact for the company. And of course, make sure that the team surrounding that scope is very supportive. I have almost always found that the quality of people is far more important than the project itself. People learn the most from other people after all.

I talk about this way more in-depth in our new promotion course. Check it out here: [\[Course\] Nail Your Promotion As A Software Engineer](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/)

The "Project Credit And Scope" section will be the most relevant to your discussion.

Fixing bugs is tremendously underrated, especially *identifying* them. At bigger companies, there's no shortage of huge bugs hidden underneath the surface: They're effectively diamonds in the rough for your taking if you're willing to put in some extra effort.

In fact, discovering and expertly fixing a huge bug was one of my crown jewel promotion projects as I was growing from mid-level -&gt; senior at Meta. I broke it down here: [\[Case Study\] Solving A Multi-Million $$ Instagram Bug](https://www.jointaro.com/lesson/WYk4J05iBqOuPtD0CYKX/case-study-solving-a-multi-million-dollardollar-instagram-bug/)

This feels obvious (at least to me): *Go back to your prior team.*

Even though so much of Taro is about career advancement, at the end of the day, I really just want you and everyone else in the community to be **happy**:

- For many, that involves grinding interviews and promotions, working up the career ladder, and getting Exceed Expectations+ every cycle. That's the "standard" path and is obviously completely fine.
- But for others, their goal is to just do well enough at their job to get by (while still doing their highest quality work and treating teammates with respect of course) because they have much bigger fish to fry outside of work. *That's 100% okay too!*

Family comes first. If you're looking to grow yours, you should definitely prioritize work-life balance.

My recommendation is to use Taro to learn how to get more from your time. This is important for getting promoted, but it's also important in your situation where you want to comfortably meet expectations with as little time investment as possible and plug the rest into what truly matters, your personal life. Check these out: [\[Taro Top 10\] Work-Life Balance](https://www.jointaro.com/playlist/JNCZ1vbRF3NwsOQCqblt/)

If you work at FAANG, I'm sure you'll be fine longer term. Do your 30% coding on your previous team, and you even mentioned that you can dial it up as well. [Use light (and fun) side projects](https://www.jointaro.com/playlist/vKUWMgmmaEvzcYUXZs4B/) outside of work to further bolster your learning in a non-pressurized way.

Here's another great discussion to check out: ["How to achieve career longevity?"](https://www.jointaro.com/question/SyXff4kLYJr9sAYppwd5/how-to-achieve-career-longevity/)

As a nerd who knows a bunch of other nerds, I actually know the answer to this. In a nutshell, *the game dev industry is exploiting personal passion.*

Take Google for instance. We all know and use Google. We like Google. But we don't *love* Google. And when I say love, I mean *actually* love to the point where you orient most of your life around Google. There is almost nobody who has branded their entire bedroom around Google swag and attire. There is almost nobody who spends 8+ hours a day just using Google. Google, like with most tech companies, provides utilities. They're amazing utilities sure, but still utilities.

Now take Riot Games who famously makes League of Legends (LoL). I know many people (many of them software engineers) who *love* League of Legends. They'll play (on average) 8+ hours a day. Their entire bedroom is filled with LoL posters and figurines. They go to LoL conferences and cosplay. Literally most of their life revolves around LoL.

This phenomenon happens all the time with not just video games, but games in general. I'm a big Magic: The Gathering person (MtG). Wizards of the Coast, the creators of MtG, infamously pays their employees complete garbage. I'm talking TC that's 2x to 3x lower than industry average. And it's because there's no shortage of very talented, intelligent nerds who *love* MtG.

When you have this *insane* level of passion for something, you are often willing to take below-market pay and crappy working conditions to work on that thing because you truly, deeply love that thing. Gaming companies know this and take it to the bank.

So for me, I'll stick with playing games instead of working on them. Use the advice here to find a good team (that probably isn't a game dev shop haha): [\[Masterclass\] How To Choose A Good Company And Team As A Software Engineer](https://www.jointaro.com/lesson/0WEmTNZOMIh8xAdfO3JH/masterclass-how-to-choose-a-good-company-and-team-as-a-software-engineer/)

This is a classic question, and my answer is: *Focus on impact.* This is even more relevant since you're working at Microsoft, one of the best tech companies in the world, which is much more likely to have the correct view of productivity.

At the end of the day, a good manager/organization doesn't care if you get the work done and the impact landed in 2 hours or 200 hours. What matters is that you get it done. This was very much the case at Meta:

- If you could get everything done (and extra) working just 5 hour days, all the more power to you.
- In fact, if you don't get your work done but you're able to come up with a different project instead that is higher impact, *even more* power to you!

*This is why I don't think bringing up your extra hours to your manager will make you look better.* If you need the extra time just to finish your assigned tasks properly, your manager might get worried and wonder why you're inefficient. Regardless, if you are facing burnout, you should 100% bring this up with your manager. Maybe they can give you tips on how to work better, like with prioritization.

When you run into the classic dilemma of "Too much work, not enough time", you have 2 big options:

1. **Become more efficient** - Learn to get more out of your day. Start off with this: [\[Masterclass\] How To Write Better Code Faster As A Software Engineer](https://www.jointaro.com/lesson/iYpRj8XfyzCSaTYnce3y/masterclass-how-to-write-better-code-faster-as-a-software-engineer/)
2. **Cut scope** - This one is much harder, but it simply has to be done a lot of the time. At a top tech company like Microsoft, there's no shortage of overly ambitious people underestimating projects. Here's a good thread about how to push back: ["What are good strategies to push back when the deadline is not realistic?"](https://www.jointaro.com/question/mV565SdXh7QhpagyVasf/what-are-good-strategies-to-push-back-when-the-deadline-is-not-realistic/)

Lastly, most tech companies are required to have an overtime policy by law, but 99.99% of the time, you don't get paid for overtime. Most engineers are salaried, and the overtime effectively happens under the table.

This sounds oversimplified, but it's 100% true: *Just write a bunch of Java.*

Java is one of the most storied programming languages ever created. It has infinite depth and so many versions (and different companies will use different versions). You don't want to fall into the trap of learning optimistically and picking up a bunch of Java knowledge you don't actually need. Always anchor learning against action as I talk about here: ["How to avoid going down the rabbit holes when learning new things?"](https://www.jointaro.com/question/4XLModnvZVwgQYbZEbDD/how-to-avoid-going-down-the-rabbit-holes-when-learning-new-things/)

If you can't get Java learning at work, then build side projects. That is how I learned Java when I was working on weaker engineering teams (i.e. before I went to Meta). As long as you're acutely aware of problems and actively working to tackle them, you will get better. With Java for example, something I learned to really understand is the NPE or NullPointerException. Since I don't want my Android app users to run into crashes, I was forced to learn how to minimize NPEs properly (i.e. not just suppressing them and kicking the root problem down the road).

> What are other good job listing services?

LinkedIn and Otta are great, but there's many other good ones. Check this out: ["What are the best websites for applying for tech jobs?"](https://www.jointaro.com/question/VkuG4W88SZ83Ek7AfLP6/what-are-the-best-websites-for-applying-for-tech-jobs/)

> Is my approach sound or should I change my strategy?

*I think you have Steps 2 and 3 inverted*, which is a classic interviewing mistakes I've seen countless engineers make. You will never be "ready" for interviews. Just apply a bunch first and adapt your studying accordingly. In this market, DSA is less relevant than ever before as FAANG is largely not hiring so don't gatekeep the majority of your applications on completing most of the LeetCode 75. You already have the strategy of applying to less prestigious companies first, so you can use those as training effectively.

To go super deep, I *highly* recommend going through my entire job searching course: [\[Course\] Ace Your Tech Interview And Get A Job As A Software Engineer](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/)

Take the initiative! If you are lacking certain skills to get put on new projects, build up those skills. This can be done with [side projects](https://www.jointaro.com/playlist/vKUWMgmmaEvzcYUXZs4B/), and Taro has a lot of onramps for the specifics you mentioned as well:

- **Data engineering** - We have a [Book Club going over The Fundamentals Of Data Engineering](https://www.jointaro.com/event/taro-book-club-the-fundamentals-of-data-engineering-chapter-3-designing-good-data-architecture/). Attend future sessions (join #taro-bookclub in the Taro Premium Slack if you haven't already), watch recordings of past sessions (they're linked on the Taro event pages), and connect with people who attend the meetings.
- **Machine learning** - We have a *ton* of paper reading groups held by MLEs. Follow the advice I gave about the Book Club above. Here's a great sessions going through arguably the most famous paper about machine learning today (it's by Google): <https://www.jointaro.com/event/paper-reading-attention-is-all-you-need/>

Since you're unassigned, I imagine you have a lot of free time to do this "extracurricular" learning.

On top of that, I recommend just building up the relationship with your bosses so they'll believe you when you say that you can learn quickly: [\[Masterclass\] How To Build Deep Relationships Quickly In Tech](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/masterclass-how-to-build-deep-relationships-quickly-in-tech/)

I talk about this more in my code quality course here: <https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/how-to-handle-migrations/>

There are 2 big components to a successful migration:

1. **It's not half-baked:** If you're going to migrate code, migrate all the code. Don't just migrate half of it as it will just make the codebase more confusing.
2. **Nothing breaks:** This one is obvious, but it's easier said than done and people don't realize how many sub-components go into achieving this. Incremental integration is a big one as Lalit mentioned. Having good A/B test + general killswitch infrastructure is also incredibly important (be ready to turn off the new code if it's breaking).

Here's some other great resources that dive really deep into this:

- ["How to convince my engineering org to participate in large-scale migration?"](https://www.jointaro.com/question/S0q8h0Kt2gwIx0KtT9Wd/how-to-convince-my-engineering-org-to-participate-in-large-scale-migration/)
- ["Advice on AWS Migration?"](https://www.jointaro.com/question/iRuh4taVhw5uAlClMB0f/advice-on-aws-migration/)

I actually talk about this in the course here: <https://www.jointaro.com/course/nail-your-return-offer-as-a-meta-software-engineer-intern/part-6-meta-intern-success-series-how-most-interns-fail/>

Your intern manager should give you 2-3 names of teammates who are also open to reviewing your diffs. If they don't, you can just go around the team, meet people, and ask the friendliest ones if they would be open to reviewing your diffs.

A tactical angle is to go through the blame of the codebase you're extending and assigning the people you find there as reviewers. This doesn't just apply to interns either - Any engineer should do this if they're lacking reviewers.

Best of luck to your brother! The course should be really helpful to him. You can refer him to Taro Premium using your referral code: <https://www.jointaro.com/rewards/>

A manga a day keeps your motivation in play! 💪

Rahul here showing how little of a weeb/otaku he is 🤣. You **read** *manga*. You **watch** *anime*. Most anime is based off of a manga. I both read manga and watch anime.

While manga/anime haven't really contributed to my writing ability (at least not consciously), I find them really helpful for maintaining inspiration and viewing the world in a healthy way. The classic anime is about overcoming adversity, even if you come from a humble background, and that's more or less how I've lived my career.

I have had hundreds of people reach out to me fishing for referrals into Meta/Robinhood. *I just ignore them* as the people who are desperately reaching out for cold referrals are not very good engineers 99% of the time.

The thing for you to consider is the referral bonus. If your company gives a generous referral bonus, it could be worth it to spend 30-60 seconds parsing each person's profile and referring the good ones. But chances are that cold LinkedIn messages aren't coming from high-quality people.

Up to you on whether you want to take the risky time investment. It's like panning for gold.

Mihir, in your case, I think you need to switch to a more product-oriented team. Even outside of domains like electronics/networks, there are infra teams that work on software and don't really have a PM. In that case, there is no need for product vision as the product is more technical, so you'll need to go find it if you want to transition to PM someday.

It's important to remember that *perception* and *reality* are 2 very different things with the following characteristics:

1. It is easy for them to drift apart
2. Perception is (painfully) more important that reality

For #1, it is extremely common at a fast-paced company like Meta. It looks like the reality is that you are creating enough proper project artifacts, but the perception is that you're lacking. This means that you need to put in the work to align the 2 again, especially if both your manager and your skip think you aren't doing enough documentation.

Ask them specifically which projects seemed lacking in documentation to them and what documents in particular they would have liked to see. If they respond and it turns out they were incorrect that X was missing, show them X. However, this is a band-aid fix that doesn't solve the root cause: *Why was their perception of you lower than your reality in the first place?*

The answer is almost always that you can communicate *even more*. Many engineers don't realize how big the communication tax is at Meta, myself included when I first started there. For Meta in particular, try writing more and better Workplace posts. cc people more aggressively and always link relevant docs (don't be afraid to do this again and again as people might miss them the first times). Here's a great resource about writing stellar Workplace posts: ["How to get more visibility on work?"](https://www.jointaro.com/question/XA0X51AypDLCeVeleJv4/how-to-get-more-visibility-on-work/)

Check out our senior to staff playlist as well: [\[Taro Top 10\] Senior Engineer To Staff Engineer (L5 To L6)](https://www.jointaro.com/playlist/YD8LMCSlE71VUGUbNAWM/)

What tasks do you even have if you aren't getting coding tasks? Regardless, I would indeed bring this up with your manager. If they want you to focus on your current tasks (I assume they're busy work that don't actually add value), then you should politely push back and mention that writing code will have more impact and there's some important projects sister teams are working on where they need help (assuming this is the case). Expanding a team's impact to uplift sister teams is generally a good thing that makes your manager look good as well.

Given your situation, there's 2 approaches I would try:

1. Literally just ask for backlogged tasks
2. Look for straightforward code cleanup opportunities like adding test coverage

In general, just look for problems and work backwards from them: ["How do I find projects for myself at work?"](https://www.jointaro.com/question/KitOGyYkpbsXFGoHPJUj/how-do-i-find-projects-for-myself-at-work/)

We actually have a communication course on Taro! Check it out: [\[Course\] Effective Communication For Engineers](https://www.jointaro.com/course/effective-communication-for-engineers/)

It's on my backlog to completely redo this course, but the core concepts should definitely hold up in the meantime.

Here's another great resource: ["How to improve my English communication?"](https://www.jointaro.com/question/omak9oOT4NJE9dhKeMZi/how-to-improve-my-english-communication/)

My main advice with communication, like with anything, is to:

1. Have a fearless mentality (don't be afraid of looking dumb)
2. Do it a lot
3. Invite feedback (this is especially easy with written communication)

If you can truly champion all these ideas, you'll get better at it lightning fast. Tentative language and self-deprecation are particularly effective at greasing the wheels.

Lalit's answer is great, but I feel like explicitly documenting all of those in a test plan is overkill, at least for relatively small and simple pull requests.

The main thing (at least for me and engineers at Meta/Robinhood) is *artifacts*. In particular, try attaching a video if you can.

Here's my overall process for making a killer test plan:

1. Figure out all the cases your code should account for
2. Go through all those cases in your test plan artifacts

If the artifacts are good (again, video is amazing for test plans), it will be clear what the steps are and you don't need to write it all out.

If you find the video to be too long (&gt;1 minute), you can split it up into separate videos with a small description on each one. A classic example for front-end engineers is going through the flow once in dark mode and once in light mode as separate videos.

Here's another great discussion to check out: ["What can I do to quickly build my reputation as a junior engineer?"](https://www.jointaro.com/question/T6qrX3eApRMhTfLWrC9W/what-can-i-do-to-quickly-build-my-reputation-as-a-junior-engineer/)

Does this mean that you're interviewing with the recruiter on a phone screen and after that call, you don't get scheduled for another round? If this is the case, I recommend you check out this part of our master job searching course: <https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/recruiter-screen/>

The fail rate for recruiter screens is surprisingly high. As mentioned in the above course lesson, I have talked with several recruiters with screen pass rates of only 50-60%, which means that nearly half of engineers aren't making past this round. This makes sense to me as most engineers I've talked to are incredibly bad with behavioral rounds.

If you're making it past the recruiter screen but failing at the hiring manager round, it's possible that you don't have strong enough technical stories to tell in that interview.

No matter what, the probable root cause is that you need to amp up your behavioral interview skills. I'll make a course about this later, but in the meantime, check this out: [\[Taro Top 10\] Behavioral Interviews](https://www.jointaro.com/playlist/IPFmEPUhAmizNe9ZUWV5/)

*"Too many cooks in the kitchen"* is a very real phenomenon, so I get it. Even though 10 people is small for a company, it can easily be a crowd for a project. I have been on projects with just 5 core stakeholders that have turned out to be a giant mess.

Even at Taro where we currently only have 3 engineers (Rahul, Charlie, and myself), we have realized that we should be giving more solo-ownership to decisions in order to move faster.

All that being said, I have many suggestions there:

1. **Do an async in-between approach** - Just because you aren't invited to the meeting doesn't mean you can't influence the project's direction. If there's some sort of product spec document with each proposed project, ask leads to open it up to feedback before decisions are solidified and you can type in comments during a certain window.
2. **Show evidence for improvement** - Do you have clear examples of prior projects that would have gone better had leadership invited feedback more proactively? If so, compile that information together and make a case. Everything should be done for a reason.
3. **Deepen relevant relationships** - This one is more generic but still true. Nobody gets a seat at the table for free. Make your leads and manager like you so much and respect your opinion so much that they're forced to invite you.

Something to keep in mind is that you don't want any jaded-ness or cynicism to come through while proposing these options. Make sure to follow the advice from the Effective Communication course: [\[Course\] Effective Communication For Engineers](https://www.jointaro.com/course/effective-communication-for-engineers/)

I don't think OP is active on Taro anymore, but IIRC, they got laid off from that ads org 😢

I agree that a lot of ads context and skills are transferrable. For me, the huge emphasis on data analysis and logging was huge. Instagram Ads was the first engineering org that pushed me to get really good at SQL (I've written 100+ line queries parsing through trillions of rows), and now I'm always thinking about how I can *actually* tell if the end-product is delivering user-value.

"Sabotage" is a strong word, but as I talk about in my job searching course, a lot of candidates fail [not because they don't have the skills or knowledge, but because they completely fall apart during the interview for whatever reason](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/having-the-right-mentality/) and aren't able to recall their mastery.

This happens all the time with FAANG interviews as the stakes are so high, especially with candidates who are trying to break into FAANG. It's hard to truly tell if a candidate had what it takes if they failed, but if I had to put a number on it, I would say \~20% of failing candidates could have passed had they not melted down into a pile of spaghetti when things got real.

When it comes to interviews, it's best to not let the failures get to you and keep on improving: ["How to figure out why I'm not passing onsite interviews?"](https://www.jointaro.com/question/CdmrIsMFPFbsRqRUvueu/how-to-figure-out-why-im-not-passing-onsite-interviews/)

Stuff like this is why I'm very wary when it comes to contractor positions, even at top tier companies like FAANG. At the end of the day, contractors are 2nd class citizens at their company, and you are living that reality now as you don't get good projects and there's nobody truly invested in your career development.

I still think you should try conversion (I do know several success stories there, though they are rare percentage-wise), but explore other avenues as well. Since you're not getting great work, I hope you have a lot of spare time to go on the interview grind again. While you are a contractor, the FAANG name is very impressive on your resume and will count. I know engineers who were contracting at 1 FAANG company and used that to springboard to another FAANG as an FTE.

To help with finding a champion for you in your current company: [\[Masterclass\] How To Build Deep Relationships Quickly In Tech](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/masterclass-how-to-build-deep-relationships-quickly-in-tech/)

To help with the job search: [\[Course\] Ace Your Tech Interview And Get A Job As A Software Engineer](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/)

Best of luck!

The problem here is that it seems like you're trying to run away from the issue instead of tackling it head on - This is why your team is unhappy. Flip the mindset:

- **Bad:** *"I'm stuck on this task due to a lack of knowledge, and I will publicly raise it as a blocker. I hope to get reassigned off of it or the team lead assigns someone to hand-hold me through it."*
- **Good:** *"I'm stuck on this task due to a lack of knowledge, and I will use my deduction skills and communication ability to find the right people in my org on my own and get them to explain what I need."*

The former is reactive and helpless while the latter is proactive and taking control. As a senior engineer, you are going to get plunged into crazy situations all the time. If you have been on your team for a while as a mid-level, I imagine your teammates (and especially your manager) are expecting you to take on these ambiguous, unknown problems with more confidence to make progress towards senior.

This is a very common behavior evolution I have taught to countless mid-level engineers as I mentored them to senior. While junior -&gt; mid-level is mostly sharpening what you know, mid-level -&gt; senior requires a more fundamental behavioral shift where you are developing the "meta" ability of learning how to learn so you can quickly adapt to any crazy situation. So I just wanted to let you know that you're not alone in this journey - Most mid-level engineers have been where you are and have come out the other side as much better engineers! 😊

I understand that charging into the unknown can be scary, but if you have a supportive team, they will welcome you taking the initiative with open arms. The first step is championing that healthy go-getter mentality and taking that leap of faith. I believe in you!

Here's a bunch more resources that cover this topic:

- ["How do you get more independent?"](https://www.jointaro.com/question/FUP3gHb7rv9CXc84LaKn/how-do-you-get-more-independent/)
- ["What does it mean to not require handholding anymore?"](https://www.jointaro.com/question/5vEWajcZlSi7nlohTGtJ/what-does-it-mean-to-not-require-handholding-anymore/)
- [\[Taro Top 10\] Mid-Level Engineer To Senior Engineer (L4 To L5)](https://www.jointaro.com/playlist/AUMiBTvYUv0gcOzuu26V/)

There's only so much you can do to align offers, especially in this brutal market. I have seen exploding offers left and right, and team match is a nightmare because there's simply too many talented engineers and not enough headcount. My little brother got stuck in Google team match for literally an entire year and just gave up.

Overall, just try to stack your onsites concurrently, ask for wiggle room to extend exploding offers, and hope for the best 🙏

> Also, if one accepts an offer at company A, and there is a team match with company B, at what time is it okay to let go of company A (accepted offer, joined the company but less than a month, joined a company less than a year).

When it comes to instantly bailing out of a job, I think 1 month or less of tenure there is okay, max 1.5 months. Your tolerance will go up depending on the delta between company B and company A. If company B offers you double for example, then it's probably worth jumping ship no matter.

Here are some other things to keep in mind there there:

- If your stint at company A was very short (&lt;1.5 months), just leave it off your resume/LinkedIn and pretend you never did it. It will look really bad if you keep it on.
- *You will almost certainly be blacklisted from company A forever.* So keep that in mind, especially if it's a top company.

Anyways, once you figure out whatever your next role is on a more permanent basis, check out our onboarding course: [\[Course\] The Complete Onboarding Guide For Software Engineers: Succeeding When You're New](https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/)

> I find some big opportunities that bring huge revenue to the organization

I mean, you have to do this to get to senior at any top tech company like Amazon, especially if you work closely with revenue. On my journey from E4 -&gt; E5, I identified and fixed [a very tricky bug that saved Instagram over $1 million per year](https://www.jointaro.com/lesson/WYk4J05iBqOuPtD0CYKX/case-study-solving-a-multi-million-dollardollar-instagram-bug/), and that was just *one* of the major projects on my senior promo packet.

If you feel like you are learning on your team, I think you should stay, especially if you have a good manager and strong SDE 3 teammates who push you to be better. My overall career advice which I've given to countless engineers is to prioritize growth and treat level as a lagging indicator. If you are truly functioning as a high-performing senior engineer, you will eventually land a highly-paid role as a senior engineer. Conversely, if the growth has dried up, you should try to switch teams or companies.

Lastly, people understand that the SDE 2/L5 band at Amazon is crazy wide. A lot of ultra-tenured Amazon SDE 2s end up at Meta as E5 (senior). During the crazy ZIRP days of 2021, an Amazon SDE 2 within the Taro community got into Meta as an E6 (Staff)!

**tldr;** *If you're genuinely becoming a much better engineer, I wouldn't worry too much about staying at SDE 2. You can almost certainly job hop to a senior title when the market improves.*

Amazon also just hit ATH with $185/share, so that's another reason you should stay haha. You gotta vest out those backloaded grants!

Congrats on getting into Meta! Given your level and 10+ YOE, I'm going to assume that you are an E5.

I knew several E5s that transitioned to MLE internally at Meta. The process is quite simple:

1. Be a high-performer in your current role and make your manager like you (these 2 almost always go hand-in-hand)
2. Ask for an internal transfer to MLE

To help with Step 1, I recommend these:

- [\[Course\] The Complete Onboarding Guide For Software Engineers: Succeeding When You're New](https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/)
- [\[Masterclass\] How To Navigate Your Performance Review In Tech](https://www.jointaro.com/lesson/b0B8uqIAUnBLE10jJHJG/masterclass-how-to-navigate-your-performance-review-in-tech/)
- [\[Masterclass\] How To Work Better With Your Engineering Manager](https://www.jointaro.com/lesson/2PbJb2fuqF3iMHy57eEg/masterclass-how-to-work-better-with-your-engineering-manager/)

In terms of what skills you need, you probably don't need to worry about it as an E5. At E5 and above, most engineers are working with fundamental skills like leadership, communication, project management, mentorship/delegation, and communication. The technical portion usually isn't a huge part of the job, and if you master the fundamentals, you'll be able to pick up the technical ML stuff very quickly.

Something else you can tactically do is to network with the ML folks in your organization. I worked all the way on the mobile front-end at Instagram, but I got to know several E5/E6 engineers on the ML ranking side since I worked in ads. It was very cool learning what their day-to-day was like and how we could add value to each other.

Here's an excellent thread from another Meta engineer about this very topic (check out the linked resources there too, lots of great ones): ["Is it worth transitioning to become a Machine Learning Engineer?"](https://www.jointaro.com/question/Axo0nQTxkiEBDEx3rp6B/is-it-worth-transitioning-to-become-a-machine-learning-engineer/?playlistId=qeFEXCDpfUiogN6iJI4f)

I'm assuming distance education = "Online", and that's tricky. An MBA in particular should cover leadership as you're looking for, but that's something much better taught in-person than online. Anyways, I found this list of top online MBA programs in the US: <https://www.usnews.com/education/online-education/mba/rankings>

At a higher-level, I recommend against an MBA. It's generally not very helpful getting you into product management or engineering management positions and many FAANG/FAANG-adjacent companies actively look down on them. Check out this other thread: [Exploring MBA-driven career shifts from software engineering to product management or management consulting for higher earnings, particularly in Europe.](https://www.jointaro.com/question/iEbG7c5bIQ69UDCyUpaU/exploring-mba-driven-career-shifts-from-software-engineering-to-product-management-or-management-consulting-for-higher-earnings-particularly-in-europe/)

If you want to expand your network and build up leadership skills, I recommend doing that at your current company:

- [\[Taro Top 10\] Tech Leadership](https://www.jointaro.com/playlist/LoPKDstyl9aHceV8xF9C/)
- [\[Masterclass\] How To Build Deep Relationships Quickly In Tech](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/masterclass-how-to-build-deep-relationships-quickly-in-tech/)

I recommend signing up for Taro Networking too: <https://www.jointaro.com/networking/>

Based on the context you gave, this meeting seems largely useless, but I do think it has value for 1 particular thing: *Acting as a natural touch point to follow up on your promotion discussion*

Promotion is the core way you increase your compensation, so this seems like a reasonable meeting to bring it up with your manager and have some amount of a serious conversation about the gaps you have to get to the next level. Here's a good video covering how to approach that conversation: [Asking For A Promotion: The Wrong Way vs. The Right Way](https://www.jointaro.com/lesson/GvT4NBqaBULFlizarSCf/asking-for-a-promotion-the-wrong-way-vs-the-right-way/?playlistId=d2OjzsYrc0VpRisnzdh2)

What pair programming entails is covered in the name: *It's when a pair of engineers sit down together to code through something together.* If you're in-person, you should literally sit side-by-side at the same desk. If you're remote, you need to join a video call together and someone has to screen share.

In pair programming, there is usually a **driver** and **follower**. The **driver** is the more senior/knowledgeable person about the codebase and the **follower** is doing their best to learn from the driver while following their instructions.

The biggest downside of pair programming is cost. Taking up 2 engineers' time is way worse than taking up 1 engineer's time as software engineers are paid a lot. This is generally why pair programming shouldn't be used that frequently, and most companies live by that mentality. If you constantly need to pair program as the follower in order to get anything done, this is a likely sign that you aren't independent and you are at huge risk of a PIP.

That being said, pair programming is great when you're new to a codebase for whatever reason (just joined the company, switched teams internally, decided to pivot stacks). In this case, you should pursue it aggressively with the goal of weaning yourself off of it quickly.

Here's another great thread about pair programming: ["How often do you pair program and what do you make of them?"](https://www.jointaro.com/question/VbOZ4io4ShqDF0gYzEjS/how-often-do-you-pair-program-and-what-do-you-make-of-them/)

Oh no, this is bad 😟. Not having any coding tasks for 5-6 months would greatly damage your career (and be extremely boring). I've helped a lot of engineers in similar situations (and have been in that situation myself), so I have a lot of advice here. Your 3 questions are actually a great place to start!

> Should I take the initiative to review and study different parts of the codebase independently?

No, "studying" a codebase is a huge waste of time, especially at a Big Tech like Microsoft where a ton of the code will be legacy spaghetti. You won't truly learn a codebase unless you engage with it (i.e. write code into it).

> Could I propose small, self-initiated coding projects to demonstrate my understanding and initiative?

Yes, yes, yes! This is the best cure when you're stuck in a situation without work. **Create scope!** At a Big Tech company, the obvious culprit is refactoring, adding automated tests, and other sorts of cleanup work. For me at Meta, there was no shortage of non-controversial refactors that didn't need any buy-in. For example, after Instagram's codebase supported Java 8, a lot of code needed to be migrated to lambdas. I submitted a ton of commits doing that (the IDE did most of the work haha).

> How can I use this time effectively to ensure that when coding tasks are assigned, I’m fully up to speed and ready to contribute meaningfully?

Easy: By writing code. Find opportunities to write code. On top of code cleanup work, internal tools are another easy target. At Meta, a lot of internal tools were thatched together by interns and after they left, their tools fell into disarray. So that was another good source of coding with some decent impact when you were bored.

I also recommend talking to managers of sister teams (i.e. teams that have the same skip as you) and seeing if they have anything on their backlog you can help with. Again, Big Tech engineering teams often have tons of random cleanup work in the backlog from small bugs, internal tool patchups, and refactoring.

Here's another similar question I highly recommend: ["Help needed: New grad job going at a slow pace with nothing to do - Next steps?"](https://www.jointaro.com/question/MldWyFYyJUTxRGjId2f5/help-needed-new-grad-job-going-at-a-slow-pace-with-nothing-to-do-next-steps/)

If you work at a YC-backed company, you already have a huge head start! Ask the founders if you can tag along whenever they go to a YC networking event. If you're in a major tech hub, that's a great way to meet lots of talented engineers. Once you go to these events, your goal is to find people you resonate with and try to connect with them later on in a 1 on 1 setting. More tips here: ["How to Approach Taro Networking Event"](https://www.jointaro.com/question/eA6l27HoRiIDuquh3Ngi/how-to-approach-taro-networking-event/)

On top of that, I recommend signing up for Taro Networking and reaching out to people: <https://www.jointaro.com/networking/>

Communal Taro events like [Book Club](https://www.jointaro.com/event/taro-book-club-designing-data-intensive-applications-chapter-6-partitioning-db501/) is another great place to meet talented engineers. I remember there was a Taro event a while back where 2 of the engineers were having a great chat in Zoom, and they decided to continue the conversation offline after the call to dig deeper. Lots of cool stuff can happen when you just show up and participate!

I personally don't think it's necessary to go full-blown design learning mode and learn the intricacies of Figma, Photoshop, and other UI/UX tools. However, if you have the time (and especially if your team is lacking design resources), then it certainly won't hurt.

For myself, I struck a sort of middle ground by just building a lot of a side project apps on my own. When you're doing a solo side project, you are the the product manager, designer, and software engineer, so I naturally got better and better at building smooth user interfaces over time. It's not as stunning as say Airbnb, but my top apps are overwhelmingly rated 5 stars with tons of glowing feedback about the simplicity and smoothness of my UI/UX.

When it comes to design, I have 3 core pieces of advice to get better on top of doing side projects:

1. **Dogfood** - Use your own product. Feel the pain of the crappy parts of your interface.
2. **Minimize clicks** - Make it so that all your major features are less than 5 clicks away from the home screen, ideally &lt;=3.
3. **Creatively "borrow" from top apps** - Most front-end apps are CRUD products with some custom flair: There really aren't that many unique UI components going on. The first thing I do when I take on a new app is to try out a bunch of famous apps that have similar user flows and mostly copy those. There is no need to reinvent the wheel, especially if you aren't a proper designer.

I dive into all of this more here: [\[Masterclass\] How To Build And Grow Tech Products To 500k+ Users For Free](https://www.jointaro.com/lesson/OEuX0KMhcnNSTJ50Voee/masterclass-how-to-build-and-grow-tech-products-to-500k-users-for-free/)

Oh yeah, I've been there, *especially* after the pandemic happened.

So my immediate advice is to *take a break, at least 1 week off if you have the PTO saved up*. If your company and manager are generous, maybe you can even take it as an ad-hoc wellness leave that doesn't extract from your PTO balance. After covid hit, I got badly burnt out at Meta because the world was so terrible and it was hard not to worry all the time about everything. I had an honest conversation with my manager, and she immediately said to take a week off for free and she would cover for me in the meantime (she was the best manager I ever had).

If the time-off doesn't work, you might need a heavier-handed solution like therapy. I don't know any therapists off the top of my head, but one of the perks of being a Taro community member is a discount off Shimmer, an ADHD coaching service (I haven't used it personally, so I recommend going through it thoroughly while considering): <https://www.jointaro.com/perks/>

On top of that, something I recommend to everyone is to introspect on what actually makes you happy at your job and double down on it. Even for people who mostly dislike their job, there is often a tiny glimmer of joy buried within their workload, *some* specific work interaction that makes them happy. It could be:

- Working on a certain type of product
- Working on a particular task type (0 to 1, data analysis, debugging)
- Collaborating with a specific person
- Doing a certain type of behavior (mentorship, heads-down coding, presenting, brainstorming)

At Meta, mentorship was the thing that brought me the most joy. I could do 10 mentorship 1 on 1s in a day and not feel tired. So to help with my covid-induced burnout, my manager fast-tracked me on the transition from tech lead -&gt; engineering manager by loading me up with a bunch more mentees.

Here's a bunch more resources digging into this:

- ["How do I know what I'm great at?"](https://www.jointaro.com/question/hksE5OSxktWdbnQQFdaT/how-do-i-know-what-im-great-at/)
- [How To Discover Your Work Passions And Hatreds](https://www.jointaro.com/lesson/EkgSr4XwcTIerKN4Ed9d/how-to-discover-your-work-passions-and-hatreds/)
- ["How do you avoid mental burnout and passion loss across a long career?"](https://www.jointaro.com/question/lU3C1XUKQA3XiMBQaAYJ/how-do-you-avoid-mental-burnout-and-passion-loss-across-a-long-career/)

I'm mostly leaning against it. The pay is lower in Europe, so I imagine $2000 escaping your bank account will hurt quite a lot (and even in the US, this is a large amount for most engineers).

As I talk about in my [job searching course](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/), it's best to be fluidly reactive and dynamic when it comes to interviews. My advice is to put out some feelers and apply to those higher-paying MLE/DE jobs. You're bound to run into many rejections, including at the application layer. Figure out what's causing those rejections to identify skill gaps the market is demanding of you. If 50% of rejections are because you don't know Hadoop, then by all means, start a learning journey for Hadoop!

Another angle is to expand your role at your current job, *which is by far the best option if it exists*. So let's say you have identified that you need Hadoop:

- Is there a way to expand the scope of one of your work projects to use Hadoop?
- Maybe you can build a proof-of-concept that uses Hadoop as a separate project and demo it to your team?
- Does your team have interns that you can leverage to hack around with Hadoop? (Back at PayPal, my interns were working on proof-of-concept stuff and were allowed to use whatever shiny tech framework they wanted)
- The nuclear options is to change teams internally to one that uses Hadoop.

Be creative and explore all possible options!

Also, you can find a community of Data Engineers here in Taro! I recommend attending the [Fundamentals of Data Engineering Book Club sessions](https://www.jointaro.com/event/taro-book-club-the-fundamentals-of-data-engineering-chapter-3-designing-good-data-architecture/) if possible and networking with folks there. You can reach out to the leader of those sessions [Gideon Blinick](https://www.linkedin.com/in/gideonblinick/) in the Taro Premium Slack as well - I've talked to him many times and he's very nice and talented.

This feels unnecessary to me. I would only do this as a friendly ploy for re-engagement if the recruiter is ghosting you after the screen.

It's not exactly the same, but the spirit of this interaction feels similar to what I cover here: <https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/dont-be-weird/>

I think the main thing you need to figure out here is *why* you're missing the deadline. Given that tactical solutions like decomposition and timeboxing aren't working (they often don't), is it one of these 2 more fundamental problems?

1. **You don't like the tasks** - The work you get is simply not fun as it's not a good fit for your strengths and interests. Maybe your entire team/company isn't fun for whatever reason (in this case, [you might want to switch](https://www.jointaro.com/lesson/0WEmTNZOMIh8xAdfO3JH/masterclass-how-to-choose-a-good-company-and-team-as-a-software-engineer/)). This is a very common culprit for lack of productivity.
2. **You're in a funk** - In other words, [your mental is just not in a good state](https://www.jointaro.com/question/c4jq87aJ9KxbHuQz83Su/channels-to-deal-with-mental-health/). You *know* you can accomplish things on time, but your mind and body just won't go through the motions. Everything just feels sad and kind of pointless. This is a much deeper issue that's harder to correct.

If you provide more signal on which one of these is the root cause (or maybe it's something else entirely), I'm happy to share more targeted advice on what helped me.

If the project isn't in an optimal place, why not bring it to that place? It doesn't seem like you're forbidden from making progress on it - I think your mentor is just trying to be nice and push you to enjoy the last couple weeks of your internship (back at Meta, we were told to do this with our interns as well in the final \~2 weeks). This feels like one of those situations where it's better to bias towards action and ask for forgiveness instead of permission if things go wrong.

Regardless, you should still have those ☕ chats if you have spare cycles. Networking is super important! Check these out if you haven't already:

- [\[Course\] Effective Communication For Engineers](https://www.jointaro.com/course/effective-communication-for-engineers/)
- [\[Masterclass\] How To Build Deep Relationships Quickly In Tech](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/masterclass-how-to-build-deep-relationships-quickly-in-tech/)

> How can I navigate the current scenario where international relocations are paused, yet hiring is ongoing in the US? What can I do to strengthen my case for when policies might allow for such moves again?

I think the advice more or less remains the same: Do your best to become a high-performer by adding tremendous value to others, particularly those in power (i.e. people on the management track).

You can also try poking around Microsoft for folks in India who have successfully moved to the US (or gotten their transfer approved and are now in the process) to see if they're open for a ☕ chat.

> While I’m dedicated to excelling in my role in India, I worry that even with a strong performance, the potential gap I might leave behind could be cited as a reason to prevent my relocation. How can I address this possibility proactively with management?

This is actually just a great question in general! The best engineers are always striving to make themselves replaceable by mentoring others and sharing knowledge. This is a bit early for you given that you're still onboarding but it doesn't hurt to put yourself in the proper mindset with these:

- ["How to remove yourself from being a bottleneck?"](https://www.jointaro.com/question/h3lCZa6g7skJP1POWcUd/how-to-remove-yourself-from-being-a-bottleneck/)
- [\[Taro Top 10\] Effective Mentorship And Growing Others](https://www.jointaro.com/playlist/oLssVMdTJ9NtX5SX1fek/)

In general, you don't want to set a ceiling on yourself. That's the core premise behind negotiating pay and it applies for level as well.

> I might be able to get an L5 role and operate at that level, even if I don't feel that way

This is correct.

> If they think I'm going for L5, they might give me L4 as consolation, whereas if they think I'm going for L4, I might end up with nothing.

Assuming their interview process works properly, this is less correct. There are 2 ways to "fail" an interview:

1. Entirely fail (don't meet overall company bar)
2. Pass the interview, just not at your target level

If you give a performance that meets the company's overall bar and shows L4 skill/behavior, then you should get an L4 offer whether you interview for L5/L4. Offers aren't given as "consolation prizes" - The interviewers should always be checking if you meet the overall bar.

A lot of engineers undersell themselves as most companies don't have good promotion culture and are underleveling their engineers. So you should always try to shoot for the stars, especially if they give you an option to do so. 😄

Here's a good thread about this: ["How can I deal with my imposter syndrome after getting up-leveled?"](https://www.jointaro.com/question/dfs38FNIrxJUVpuBnlQz/how-can-i-deal-with-my-imposter-syndrome-after-getting-up-leveled/)

The billing alerts help for sure, but the fear is that you're attacked in the dead of night and a lot of hackers operate in non-Western time zones.

I have never directly used AWS or Azure, but is it really impossible to create this logic flow?

1. In your server logic, check to see how much spend you've generated for this day/week/month
2. If the number is insane, shut everything down

That's pretty much what we did for Firebase, haha.

If that's not possible, then these options indeed seem terrible for a casual side project unless you want to set spending alerts and effectively be on 24/7 oncall.

Firebase is unfortunately **very** crappy with this, and I remember reading a similar horror story for Firebase/GCP on Reddit a couple years ago about a massive bill resultant of an attack. For Firebase in particular, *you need to write code to set a hard spending limit*. You can't simply set a spending limit from the UI. You can find the documentation here: <https://cloud.google.com/billing/docs/how-to/notify#cap_disable_billing_to_stop_usage>

In general, never publish software that's billed in a pay-for-play way *without setting a spending limit to protect yourself*. You'll be surprised at the number of hackers who are just looking for an opportunity to ruin some indie dev's day.

Another option is to use a tiered service like Heroku where you just get billed a certain amount each month for a certain amount of compute, database rows, etc. If you don't use it all, you are indeed overpaying, but if you go over, your app will simply be spotty while you don't go bankrupt. Good tradeoff IMHO.

I'm not a fan of doing interviews purely for practice, especially not in this market. Unless your current job is trending downwards and a job search is imminent, I recommend focusing on actually growing your skills and trying to get promoted at your current role. It's true that promo budgets have been slashed too, but they're still possible. In our [Asking 7 Levels Of Engineers The Most Important Skill](https://www.jointaro.com/playlist/TnJFvWcvpUvFWLFjpY7X/) series, 2 of the engineers in it got promoted this year:

- Sammy went from Staff to Senior Staff at Gusto
- Kaushik went from Senior Staff to Principal at Instacart

Even in this terrible market, engineers are getting promoted and grinding for promotion is generally far more conducive towards organic skill-building compared to interviewing.

To start off: You are in a **great** position. Most engineers at Amazon would *love* to be in your shoes!

Going from SDE 1 -&gt; SDE 2 in 1 year is already quite impressive, so congrats! Even at Meta, that's a good pace and Meta is known for way faster promotion speeds than Amazon.

On top of that, it seems like you have more scope than you know how to handle. This is way, way better than the opposite problem of not having enough scope ([this is the case for most FAANG engineers](https://www.jointaro.com/lesson/PVLItDlHn0Cwmx0VyYTr/faang-great-for-compensation-less-so-for-promotion/?playlistId=McrmnuLDPbbj65oZ3JoH)).

Anyways, my main advice here is to *scale yourself*. There was actually another Amazon SDE 2 that was in a very similar position to you, and I gave them the same advice to great success. I recommend going through this thread they started: ["How can I teach and onboard other engineers faster?"](https://www.jointaro.com/question/tNvKJAgJanv6wdTBlIui/how-can-i-teach-and-onboard-other-engineers-faster/)

Drinking from a firehose is scary, but it's the fastest way to grow. Embrace it, take things in 1 gulp at a time, and you'll do just fine 😊

Being a true generalist is a privilege that is earned with time and accomplishment. The "algorithm" I give earlier-in-career engineers like yourself is:

1. Find something in tech you like
2. Become **extremely** good at it

This algorithm generally takes the first 3-5 years of someone's career. What you'll find is that you can actually have your cake and eat it too! By going super deep in 1 tech stack, that foundational knowledge will transfer fluidly to other tech stacks if you choose to branch out. However, you have to do that initial step first of becoming a respected specialist in 1 tech stack.

I talk about this in-depth in my code quality course here: <https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/focus-focus-focus/>

I like this question: It's important to be forward-thinking! It is much, much harder to survive at FAANG now than ever before (stack rank percentages and PIPs are being cranked all the way up), and the people coming from non-FAANG type companies are the most at risk to fall behind and into the grinder.

Contrary to popular belief, you don't need to work at a top tier company to develop the skills necessary to do well at a top tier company. A lot of it really is mentality. There are 2 core angles I've seen non-FAANG engineers struggle with after breaking into FAANG:

- **Technical quality** - 99% of companies don't have the same technical rigor that Big Tech does due to a mixture of apathy and not needing to. While a 1% edge case usually isn't a big deal for a product with 100k or even 1 million users, it's a massive deal when you have 3 billion users like Facebook does (1% = 30 million people!). To dive into this topic, I recommend these courses:
  - [\[Course\] Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/) - The tactics around crisp PRs are immediately applicable.
  - [\[Course\] Frontend System Design Masterclass - Building Playlists](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/) - It's frontend focused, but the overall ideas can be applied anywhere.
- **Communication** - From my own personal experience (I worked at 2 companies that are lower than Meta on the totem pole IMHO before going to Meta) and observing countless others, engineers at less cutting-edge companies tend to be more silo-ed (product is very separate, design is very separate, QA is very separate, etc). However, FAANG generally gives a lot more ownership to engineers and hence a higher communication burden. I recommend this classic course to help here: [\[Course\] Effective Communication For Engineers](https://www.jointaro.com/course/effective-communication-for-engineers/)

Evaluating startup offers against other offers from the same startup is tricky as the data set is small and the receiving engineers need to report them. So unless you can hack into a data source used by the company, that seems rough.

When it comes to comparing against the broader market, I just compare the offer against FAANG bands:

- **Base salary** - This one's easy, tit-for-tat.
- **Equity** - This one is much harder. You need to get the strike price + FMV and then do math to figure out the value of the options on paper. You also have to consider factors like vesting schedule and how quickly the options expire if you were to leave the company.

When it comes to evaluating the overall strength of a startup, I recommend this: ["How to evaluate a startup?"](https://www.jointaro.com/question/UCG4XxyEOTjjyg4pEuwY/how-to-evaluate-a-startup/)

We gave a big talk on understanding comp overall as well: [\[Masterclass\] Understanding And Optimizing Your Pay In Tech](https://www.jointaro.com/lesson/gk408yBIV2fa5RjVR213/masterclass-understanding-and-optimizing-your-pay-in-tech/)

The overall principles of a behavioral interview don't change with these interviews. Your goal is still to show that you would be a valuable member of the team as you are passionate about software engineering, working with others, and the company/space. Since you are Staff, you need to show signal that you're capable of leading large teams and solving incredibly difficult technical problems. Here's some good resources:

- ["What questions to ask a CTO of a startup?"](https://www.jointaro.com/question/R4FGhmGlZOQK7Lb1YAlt/what-questions-to-ask-a-cto-of-a-startup/)
- [\[Taro Top 10\] Behavioral Interviews](https://www.jointaro.com/playlist/IPFmEPUhAmizNe9ZUWV5/)

Given the team name, you should have enough to determine the overall domain. From that, there will be 1 of 2 possible outcomes.

1. **You have prior experience in the domain** - In this case, bring it up. Easy.
2. **You don't have prior experience in the domain** - This one is harder. To make up for the lack of domain knowledge, you should look for opportunities to showcase your adaptability. Talk about times where you had to switch teams/companies/product spaces and were able to ramp up successfully very quickly.

**Yes.** It is quite rare to see an external M2 hire at Meta and at FAANG/FAANG-adjacent companies in general. There are no shortage of talented M1s gunning for those spots, and an external hire is even riskier as M2s have even more responsibility (managing top M1s is really hard). There is a huge difference between managing at less cutting-edge company vs. a top tier company like Meta. If you want to dive more into what that difference is, check out this video (I recommend going through the masterclass it comes from as well): [The Rare Insight Top Tech Companies Have About Engineering Managers](https://www.jointaro.com/lesson/9EfsZpKgKWGOL877qRGo/the-rare-insight-top-tech-companies-have-about-engineering-managers/?playlistId=nbrlPXodHrOIBccAmzr8)

Given the market, I'm leaning towards Option #3 of *"Refine your scoping strategy within your own team"*:

1. Interviewing sucks right now and you're at Google, one of the greatest companies on Earth. As I'm writing this, Google is at ATH with $155/share. You're already in an incredible situation relative to almost everyone else.
2. Google is infamous for hard L4 -&gt; L5 promotions so switching to SWE doesn't seem like a great solution, at least in the short and even medium-term. However, if you're really passionate about SWE and have fallen out of love with DE, you should 100% switch.

In terms of refining scoping strategy, I believe your manager is telling the truth when they mention that there's a lot of problems. However, there are 2 reasons why they aren't being more specific with you about these problems:

1. **Not enough time** - Distilling all the noise, chaos, and complaints you get as a manager into something actionable takes a lot of effort and managers are extremely busy people.
2. **They are forcing you to grow** - If an L5 project is handed to you, it ceases to be an L5 project. Being able to identify problems and create scope on your own is crucial for L5 and even more important at L6.

If you can't find a meaty problem to take on, I recommend going full on user researcher mode (UXR). Schedule 45 minute to 1 hour 1 on 1s with anyone on your team and across sister teams who is willing to talk to you and is connected to the data layer in some way. Tell them that you are here to help and want to hear all the complaints they have. Compile the notes into a master doc and see what patterns you can extract. There was a very high-performing L5 infra engineer I worked with at Instagram who did just that to great success as I describe in-depth here: ["How can I come up with big initiatives, especially those at a Staff level?"](https://www.jointaro.com/question/c3LcBDXEcxA85y9jlFjz/how-can-i-come-up-with-big-initiatives-especially-those-at-a-staff-level/?playlistId=EWIo3USNcsgXbCs5PS0h)

Here's a potential freebie on my end too: Are there any logging events you can *delete*? At a giant FAANG company like Meta or Google, I'm sure there's a lot of deprecated logs that aren't being used by anyone. By killing them, you will save the company tons of money. One of the big workstreams I created in partnership with an L5 Data Engineer at Instagram was identifying all the deprecated logs related to Instagram Stories. The savings from killing all those events was $25 million+ per year.

I'll be releasing my promotion course in the next week as well which will talk about these concepts in far more detail.

Great question! The answer is *"Whatever is necessary to write great, smoothly functioning code"*. Software is incredibly dangerous as it's easy to rabbit-hole and learn a bunch of stuff you don't need. Whatever your tech stack is, there are an infinite amount of abstractions to unravel. If you unravel them optimistically, you will be stuck doing that forever. Here's an excellent thread about this: ["How to avoid going down the rabbit holes when learning new things?"](https://www.jointaro.com/question/4XLModnvZVwgQYbZEbDD/how-to-avoid-going-down-the-rabbit-holes-when-learning-new-things/)

When it comes to building depth and being a good coder, my broader advice is to learn how to nimble and improve quickly as opposed to trying to hyper-prepare and "study" your way to mastery preemptively. Pay close attention to user complaints, treat code review feedback as a gift, and try to gracefully cover as many edge cases as you can. If you do that, you will become a rockstar coder in no time. I dive incredibly deep into that in our code quality course: [\[Course\] Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)

I have seen managers hired externally into FAANG and FAANG-adjacent companies, but it's pretty rare as it's very risky (and a lot of those EMs struggle immensely during the interview). At Meta, most engineering managers were raised up internally (i.e. they grew to E6 and then switched over) and the externally hired engineering managers came from other top-tier companies like Uber, Square, Airbnb, etc.

This is also one of the worst markets to interview in as an engineering manager (EM). A lot of companies are slashing EM headcount - Meta in particular forced a bunch of M1s to switch to E6. If you are trying to jump from lower-tier companies to higher-tier ones, it will only be harder.

Anyways, you never know until you try so I recommend applying and seeing what happens. If nobody will even give you an interview, maybe you can try getting in as a Staff Engineer/Tech Lead.

The majority of the EM interview is behavioral and fairly similar to what a behavioral round for a Staff+ engineer would look like. Check these out: [\[Taro Top 10\] Behavioral Interviews](https://www.jointaro.com/playlist/IPFmEPUhAmizNe9ZUWV5/)

I don't know about other companies, but I'm fairly sure Meta gives M1 candidates a DSA interview as well. Check this out to help there: [\[Masterclass\] How To Ace Your Big Tech Interview - Data Structures And Algorithms](https://www.jointaro.com/lesson/V4sTACzfOh22nMVcUV3w/masterclass-how-to-ace-your-big-tech-interview-data-structures-and-algorithms/)

Best of luck!

M1 is the standard level for engineering managers at Big Tech. It is equivalent to Staff (L6). M1s should have between 8 and 15 engineers reporting to them.

Across my career, I have realized [how truly difficult it is to write good code](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/what-actually-makes-code-good/), especially when I was working at the scale of Instagram. It's already hard enough [preventing all possible product errors from users who are just trying to use your app/website/API](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/case-study-signup-form-edge-cases/), so dealing with security errors where the actors are actually malicious is even harder. So my overall response is, *"Eh, not surprised"*.

Code vulnerabilities is just one of those things where it's best not to worry about it as they're everywhere and you don't have much control over it. Most people in the world eat meat, but they probably don't want to learn exactly where that meat comes from and how it all works. It's sort of similar with software - There's way more insane jank underneath the surface than you realize 🤣

Code review is definitely a big one when onboarding. For most new Meta engineers who weren't able to survive, I could see the problems in code review. In particular, they weren't good about dealing with feedback, both in terms of velocity and how they ingested the feedback.

Dealing with code review feedback should be one of your top priorities when joining Meta, especially as there's such an emphasis on moving fast. If you have a diff out, I recommend literally checking your Phabricator notifications every 1-2 hours so you can respond to feedback ASAP if need be.

I cover this in-depth in my code quality course here: <https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/code-review-feedback/>

I recommend going through the entire code quality course as it largely stems from my time at Meta, and that course tactically covers the most important signal you need to show as a fresh E6 (i.e. *"I'm **really** good at coding"*).

For relationship building, I recommend this: [\[Masterclass\] How To Build Deep Relationships Quickly In Tech](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/masterclass-how-to-build-deep-relationships-quickly-in-tech/)

For design review and the business side, don't worry about it too much. That is putting the cart before the horse. Focus on making people like you first and writing stellar code. That will take 1-2 months at least. After you have solidified yourself, you can think more seriously about those other levers. A failure mode is jumping straight to the most advanced stuff before mastering the basics.

Being a mobile engineer is great for demos as it's very concrete. For the most part, you are simply taking [what you are already doing when recording a test plan](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/have-a-test-plan/) and polishing it up. If you want to play it safe, you can use a pre-recorded video, and if you want to make things more impressive, you can try it live (make sure to go through the flow many times though before presenting to make sure things don't break during your demo).

Here's another great resource to dig into about this topic: ["How to improve public speaking & your presentations?"](https://www.jointaro.com/question/u6sVWDU7kK3ZSmosCRK2/how-to-improve-public-speaking-and-your-presentations/?revalidate=true)

Recording yourself is a great solo-player tactic as Charlie mentioned, but as with many things in tech, you will get the greatest returns when you just try stuff. Present in low-stakes environments where it's impossible to fail (e.g. showing a small demo during daily standup) and move up to larger audiences as you become more confident.

On top of that, it really is just mentality. Public speaking is one of those things where you simply have to embrace your fear of failure and truly realize that even if you fail, you'll be okay. When you care less about something and put less pressure on yourself because of it, you will ironically do better at that thing. [It's very similar to what I talk about with interviews](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/having-the-right-mentality/).

For concrete tactics around preparation, check this out too: ["How can I get more comfortable giving presentations in front of large groups?"](https://www.jointaro.com/question/95By2irC9K5VeowfTo4q/how-can-i-get-more-comfortable-giving-presentations-in-front-of-large-groups/)

> What if manager is asking more things that you could accomplish?

My advice here is to push back. Here's a good resource about that: ["What are good strategies to push back when the deadline is not realistic?"](https://www.jointaro.com/question/mV565SdXh7QhpagyVasf/what-are-good-strategies-to-push-back-when-the-deadline-is-not-realistic/)

As an E6, it's expected of you to protect the team and prevent it from getting burnt out. You should get really good at building relationships and project planning so you can accurately estimate how long things should take. If the estimate is way past the deadline, you need to find creative ways to fix that. Here's a good video [from Airbnb Engineering Director Rachel Zhao](https://www.linkedin.com/in/rachelzhao) sharing some ideas to help there: [How Do Effective Engineering Leaders Help Their Teams Achieve More?](https://www.jointaro.com/lesson/xGJDCG7VL4hcZaq5XL92/how-do-effective-engineering-leaders-help-their-teams-achieve-more/)

> ...how to set strict boundaries and if you are not caring as much about level and total compensation?

Your main avenue to put up boundaries is your calendar. You can put a meeting block over lunch and for later in the night. Have a healthy social life so you have hard commitments to hit (*"Sorry, I can't review your diff at 8PM, I have dinner with a friend"*). More great advice here: [\[Taro Top 10\] Work-Life Balance](https://www.jointaro.com/playlist/JNCZ1vbRF3NwsOQCqblt/)

I think the new onboarding course should cover most of these topics: [\[Course\] The Complete Onboarding Guide For Software Engineers: Succeeding When You're New](https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/)

I totally get wanting to hit the ground running, but there's only so much you can prepare upfront. My advice is to go with the flow and ask individual questions as they come up. For things like project ideas and people to meet, it's hard to give concrete advice on this until you join a team and share more context about it.

The Taro Community will always be here for you! No rush 😊

From my experience, AI is the most useful *when you use it as a macro*. In other words, you should use it to do things that you already understand and know how to do. In the past when I had to write a block of Android code that I've thematically written 10+ times before, I would copy paste it from another project or file and make the corresponding tweaks. Now I just get ChatGPT to do it if possible.

If you're using AI in territory that's even just slightly unfamiliar, you should treat it as a mentor. If you're a good mentee, you wouldn't just get an answer you don't understand and run with it. You would ask follow-up questions until you fully understood the answer your mentor gave you, why they chose that approach, and how they came up with it.

Here's some other good resources covering this:

- ["ChatGPT plugins to your IDE - How to prepare?"](https://www.jointaro.com/question/ZqQiiaPjpzYQ8XKPOQZK/chatgpt-plugins-to-your-ide-how-to-prepare/)
- [\[Case Study\] How Engineers Unlock Huge Impact With Artificial Intelligence (AI)](https://www.jointaro.com/lesson/gTQZbv0lmmypLPytqw5g/case-study-how-engineers-unlock-huge-impact-with-artificial-intelligence-ai/)
- [A Framework For Integrating AI Into Your Workflow](https://www.jointaro.com/lesson/I3CvgoyGGJdZpDSDLc69/a-framework-for-integrating-ai-into-your-workflow/)

Sorry to hear about the rejection. Since you got good feedback, I'm sure you did well but keep in mind that if interviewers are good, they'll make you feel like you're doing better than you actually are as I talk about here: <https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/temper-your-expectations/>

If they did reject you due to this question (it's feasible), that's an overreaction IMHO. However, that question is definitely one of the worst you can possibly ask in a hiring manager round:

1. Layoffs are painful. By asking that question, you are dredging up awful memories. Good managers hate losing their people, so it will hurt in particular for them.
2. It doesn't show any positive signal on your behalf. In an interview, your goal is to show that you have a growth mentality and are excited to add value to their company. You want to add energy to the room, not suck it out, which is what this question will do.
3. The information isn't useful to you. Just because a company has done recent layoffs doesn't mean they can't do another one. Even if a company has never done layoffs before, it's possible there's a wave coming. Layoffs are always carefully coordinated to be a surprise.

For the future, you can use Glassdoor/Reddit/Blind to find out this information on your own, so you don't need to ask anyone at the company. If you're interviewing with a company in the US, you can look at WARN act records: <https://www.warntracker.com/>

For better questions to ask in an interview, check this out: ["What questions to ask a CTO of a startup?"](https://www.jointaro.com/question/R4FGhmGlZOQK7Lb1YAlt/what-questions-to-ask-a-cto-of-a-startup/)

Rejection hurts, but it's all a part of the process to improve yourself as a candidate. Learn what you can from this experience and come back stronger than ever before. I believe in you, and best of luck with your future interviews!

Stuff like this is why I tell everyone to [prioritize the quality of the team above all else](https://www.jointaro.com/question/PgdRncGB1RVxr79sYMf1/choosing-between-a-team-with-interesting-work-vs-team-with-more-potential/):

- If your team is toxic, working 30 hour weeks or even 20 hour weeks feels like too much as work sucks.
- If you find a team you genuinely love, the natural 40 hour boundary will go away and you can work 50 or 60 hour weeks without feeling tired (I did this at Course Hero + Instagram and I occasionally do this working on Taro too).

WLB threshold is never a static number, so my strategy is just to not think about it and optimize for having incredible teammates. When you find an awesome group of people who fight for you and make you want to fight for them, everything falls into place.

4\.5 years is the time range where engineers can start calling themselves senior, so I think you could do it. My recommendation is to make your LinkedIn match as well, because if it doesn't, you might get some weird reactions and suspicion.

While I think adding senior will probably help, I don't think including that progression of junior -&gt; mid -&gt; senior on your resume will. This is largely because recruiters rarely read past the first blurb, so they literally won't even see it. I talk about this more in my job searching course here: <https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/polish-your-resume/>

When it comes to resumes, my general strategy is to keep things simple:

- I don't like having "Junior X", preferring to just put "X" instead
- I don't segment my work experience at companies based on what level I was at each time. I just have my most recent level reflect the entire blurb

Another problem with doing the segmenting is that you are giving more information to the recruiter/hiring manager, which can only hurt you. For example, if you have this progression and it shows you were only "promoted" to senior 3 months ago, they can take this to mean that you're not a stable senior yet and try down-leveling you back to mid-level. But if you just have senior, then they don't know and might just assume you've been senior for a while.

At the end of the day, you should do what it takes to move your team and its product forward. This is especially true in a startup environment where you have to put on many hats. For example, when I was at Course Hero, I spent a lot of time on non-technical things like responding to Google Play reviews for the Course Hero Android app (when I joined the company we didn't have a formal customer support team doing this). This is because in a startup, [your sense of ownership has to be far deeper than at a colossal company like FAANG](https://www.jointaro.com/question/KWXIrFIR1EIJsvdOdo7u/whats-the-difference-between-big-tech-and-startups-in-terms-of-learning-and-growth/).

Switching technology/frameworks isn't the best for earlier-in-career folks, but sometimes it's unavoidable. But if you're truly always doing the best thing for what you work on, the impact of that (both in the product success and the feedback you get from superiors) will probably outweigh the downsides of switching around.

That being said, I don't do a good job of defining exactly what a tech stack is, especially versus a tech domain. This is because I honestly don't know what the exact definition should be 🤣. There's 4 levels from my perspective, ordered from biggest to smallest:

1. Domain
2. Stack
3. Language
4. Framework/library

When it comes to machine learning, I see the entire thing as a domain/stack. I think as long as you're doing ML stuff, you'll be fine.

*This seems like an easy **"Leave"** to me.* Manager and tech lead have been unhelpful, teammates are probably mediocre, you're in later stages with several companies already, and leaving would net you a lot more money.

The new manager and senior engineer make it so that if you fail all your interviews, you still have a (potentially) good option by staying, but it feels like a case of *"Too little, too late"*. Regardless, you shouldn't count your chickens before they hatch, so I still recommend doing your best to get along with them: [\[Masterclass\] How To Build Deep Relationships Quickly In Tech](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/masterclass-how-to-build-deep-relationships-quickly-in-tech/)

All that being said, something I tell everyone is that there is *rarely* a situation where it is 100% the other party's fault and there is literally nothing you could have done better. If the team culture starts degrading sooner after you switch to a more individualistic working style, that's generally a sign that you can do a better job teaching them how to fish (i.e. giving them tools to be a better engineer and do the right thing) instead of giving them fish (i.e. *"Do this so your pull request isn't garbage"*). I recommend going through this thread here and the connected resources: ["How can I help juniors?"](https://www.jointaro.com/question/OzbQJCzLPbOKTEqpeSxF/how-can-i-help-juniors/)

When you're interviewing for a new company, it is very difficult to get signal on this as you have limited visibility. You can use online resources like Glassdoor, Reddit, and Blind, but the veracity of those is quite dubious. You can try asking them directly, but the better option is often times to ask a more roundabout question (like about deadline culture). You can see the exact question I personally use here: ["How possible is it to spot red flags about toxic culture during the interview?"](https://www.jointaro.com/question/1JwmhC3Nh9Ku0fkDL1bq/how-possible-is-it-to-spot-red-flags-about-toxic-culture-during-the-interview/?playlistId=FWqTGeZYrXFohCOU38sR)

I am also not a fan of trying to pin an entire company to a certain level of WLB, because as you mentioned, different teams/orgs have different cultures. This is especially true at massive company like FAANG which have thousands of teams. A ton of engineers at Amazon have horrible WLB, but I know many who have very solid WLB there. Most engineers at Meta are stretched too thin, but [I was personally able to be a high-performing tech lead there working 35-40 hour weeks](https://www.jointaro.com/question/ByoW3HzfvqFrZjNadzZx/is-it-possible-to-do-well-at-a-swe-job-working-less-than-40-hours-a-week/).

When you're switching teams internally though, it is incredibly easy to figure this out. Look at the team members' pull requests and see when people are submitting them and leaving comments. If they happen late at night or over the weekend (make sure to factor the timezone they're in), the team obviously has poor WLB.

That being said, WLB is also largely determined by your own ability to maintain rapport with your manager, prioritize aggressively, set boundaries, be productive in general, and of course, have a healthy mentality around all of this (and more). More advice on how to do all that here: [\[Taro Top 10\] Work-Life Balance](https://www.jointaro.com/playlist/JNCZ1vbRF3NwsOQCqblt/)

That's awesome - Congrats on the progress! Hope the L5 promotion isn't too far away 😁

You legitimately have one of the best post-layoff job search strategies I've ever seen - Bravo! My main advice is to go through our comprehensive job searching course: [\[Course\] Ace Your Tech Interview And Get A Job As A Software Engineer](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/)

After the course, I recommend sprinting into action ASAP (so for you, this would be polishing your resume/LinkedIn and applying to jobs). From there the process is effectively:

1. Based on your application/interview results, you'll discover weaknesses in your job search
2. Get the support you need to patch up that weakness by starting another discussion here in the Taro Forum or coming to Group Office Hours
3. Repeat and go back to Step 1 until you have no more weaknesses, which will let you land an offer

On the immediate tactical side, there are some logistical things to understand fresh after a layoff, so I highly recommend this too: [How To Recover After You've Been Laid Off In The Tech Industry](https://www.jointaro.com/lesson/HsjXHysPlzS9yg0Q5A4w/how-to-recover-after-youve-been-laid-off-in-the-tech-industry/?playlistId=pE7pP0nXDx4X7mOChzHS)

There are many organic hops you can make to an open-source repo:

1. **You simply use the product as a consumer** - This is what Jaswir did. A lot of products are just entirely open-source instead of isolating a specific component and exposing that. Telegram is another great example: <https://github.com/telegramdesktop/tdesktop>
2. **You use the repo for side projects** - Every side project is guaranteed to use an open-source library at some point as it's not worth it building complex infra from scratch on your own.
3. **You use the repo for work** - This one is trickier, especially if you work at a big company where they prefer to do everything in-house. But it's possible, and I actually think this is the best case due to the double-dip I talked about in another comment.

If you're a senior engineer, you have certainly come across tons of open-source repos organically across your career. You just need to spend some time back-tracking to figure them out.

Given that the round is just 30 minutes, that's probably not enough time to give system design and I doubt the CTO would give a LeetCode problem. So assuming the round will be behavioral is probably safe. However, I think it's more likely that the round will mostly be the CTO asking you questions instead of the other way around - 30 minutes isn't a ton of time.

When it comes to asking the interviewer questions, here's my 2 go-to's:

1. **"What is the biggest challenge facing the company?"** - This is an inversion of the lazy *"What's your favorite thing about working here?"*. By asking about the tricky stuff, it shows that you care about the company and its future as you want to help it conquer its toughest problems.
2. **"What's the best thing that you have learned at this company?"** - Again, this is a twist on the "favorite thing" question. This shows a growth mentality on your end: You want to keep getting better as an engineer, and you want to understand how the company can facilitate that.

On top of these, Ryan is spot-on in that *you want to show that you've done your homework*. When you can reference specific XYZ feature of the company in your question, you are showing the interviewer that you care enough about the company to use its product, read through the recent launch announcements, etc.

Here's more resources on behavioral interviews: [\[Taro Top 10\] Behavioral Interviews](https://www.jointaro.com/playlist/IPFmEPUhAmizNe9ZUWV5/)

I'll be wrapping the above playlist into a course soon-ish as well.

My advice here is to ask high quality questions. We talk about this in [our new onboarding course](https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/): <https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/ask-questions-well/>

It's true that if you ask low quality questions, it's worse than not asking any questions at all. As you mentioned, it implies a lack of independence (and this is really important for your level).

Thanking people is another important lever: <https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/thank-people-a-lot/>

Just to clarify for others reading the thread: *There's no magic number when it comes to # of PRs and whether you get an interview.* I just imagine the minimum where it may happen is 5, but you probably need a lot more like 25+.

As the stories have mentioned, work on an open-source repo you're passionate about and go from there ☺️. Don't think about the potential job opportunity.

I especially *love* the first piece of advice of "Find a Feature You Need 🎯". You will write the best code when you have a genuine, organic need for it. If I had the time for open-source, I would definitely start with repos I use myself in my own side projects and look for features/APIs that would level up my side project apps.

This philosophy is similar to what I recommend for side projects where you should just build stuff that you yourself would use: [\[Masterclass\] How To Come Up With 100k+ Users App Ideas You Can Build For Free](https://www.jointaro.com/lesson/AI4zi759PSGn6RwIFT6f/masterclass-how-to-come-up-with-100k-users-app-ideas-you-can-build-for-free/)

If you use open-source libraries at your job and notice a gap, that's another opportunity to submit an open-source PR and it has double impact as it helps both your job performance and your portfolio for interviewing!

In general, I always recommend doing things for noble reasons (e.g. *"I use this library and know that this feature would add a lot of value for its developer community"*) instead of ulterior motives (*"I want to submit a PR quickly into this library to impress FAANG"*).

In terms of action items, the best route may be to start with side projects and then seeing if any open-source needs arise.

Ah, this one is an interesting - Folks usually just ask about their personal productivity. It's great to see you trying to level up your team! So aside from sharing Taro resources with your peers (talk to your SDM about expensing it), here's some ideas:

1. **Review pull requests faster** - Of course, you can control this individually: If you review your teammates' commits faster, they will land code faster. At a broader level, you can try implementing a 1-day turnaround SLA for code review feedback across your team. Maybe create a communal code review meeting at the end of every day or something so everyone can pitch in to fast code reviews together. Here's some more resources to help there: [\[Taro Top 10\] Code Review](https://www.jointaro.com/playlist/dyslMMcO32Oo6xrkvVyC/)
2. **Implement a no meeting day** - From what I've seen, this is either Wednesday or Friday. At Meta and Robinhood, it was Wednesday. No meeting days are so important for doing deep work, and I wrote 80% of my code on no meeting days. We talk in-depth about this crucial productivity lever here: [A Powerful Tool For Software Engineer Productivity - Focus Blocks](https://www.jointaro.com/lesson/uGdn2AiDfn3B07FkpIVR/a-powerful-tool-for-software-engineer-productivity-focus-blocks/)
3. **Do better system design** - At a massive FAANG company like Amazon, it's much better to be proactive instead of reactive. If you feel like some of your teammates' past launches could have gone better, this is a culture you can try championing. Follow the advice and process from my course: [\[Course\] Frontend System Design Masterclass - Building Playlists](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)

If these don't work, let me know by replying. Happy to brainstorm more. The fact that you're thinking about this is a good sign of SDE 3 mentality!

It's not unprecedented, 2000 and 2008 were *far* worse (source: My dad is also a software engineer and he went through both of those).

While the tech market sort of lies outside of the rest of the economy, it follows the general cycle of boom-bust. We had a massive boom during covid with 0% interest rates and free government money via stimulus checks, and now everything is coming back down to Earth hard.

The good news is that the tech industry innovates fast and tends to recover faster than other fields. We can already see this recovery in motion with the AI boom. While it will take a while before we go back to the pre-2022 market, I can confidently say that 2024 is already better than 2023 from my experience helping hundreds of Taro community members with their job search. In 2024, I've already mentored so many folks to new jobs but 2023 was pretty much a brutal desert, devoid of any opportunity.

To dig deeper into layoffs, check this out: [\[Taro Top 10\] Navigating Tech Industry Layoffs](https://www.jointaro.com/playlist/pE7pP0nXDx4X7mOChzHS/)

Totally get the feeling of work impact being immediate while side project learning feels more distant. Anyways, my advice here is 2-fold:

1. **Cut straight to the chase** - As a senior engineer with what seems like a solid scope of work, you won't have tons of hours after work to learn. This means that you can't be inefficient dawdling around with endless tutorials, books, and videos. *You should jump straight into the code ASAP.* As I talk about in my code quality course, [the best way to learn how to write good code is to write lots of bad code](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/embrace-the-pain/). Embrace writing that bad code and optimize for publishing whatever your side project is. When I picked up Android in 2013, the online resources were *terrible*, so I didn't have a choice! I had to jump straight into coding and getting my hands dirty, and I had so much fun, [publishing 30+ side projects with \~5 million users combined](https://www.jointaro.com/lesson/jly45Gx6qR1kqQwBmJEy/case-study-building-an-app-with-1000000-users-to-get-into-facebook/).
2. **Create tiny milestones** - This is super important for work, and it's important for side projects too. By decomposing your side project into tiny chunks, you are "hacking" your brain to feel accomplished sooner and more often whenever you complete a chunk. Follow the advice here: ["How do I make software less overwhelming?"](https://www.jointaro.com/question/YseMPDw538jhyS1MWlTs/how-do-i-make-software-less-overwhelming/)

Here's some general productivity advice as well so you can finish up your work responsibilities with less time: [\[Taro Top 10\] Time Management And Productivity](https://www.jointaro.com/playlist/5WA87nbbYJWLnQ60D826/)

Yes, yes, yes! It gives them credit and it lets your manager know that you are socializing among the team and getting to know peers.

I'm assuming you got a new job with an uplevel? Congratulations!

First, I would recommend our new onboarding course: [\[Course\] The Complete Onboarding Guide For Software Engineers: Succeeding When You're New](https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/)

There is specifically a section on onboarding for senior+ engineers here: <https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/onboarding-tips-for-senior-engineers/>

After that, I recommend this playlist to understand senior engineer expectations and behaviors at top companies: [\[Taro Top 10\] Mid-Level Engineer To Senior Engineer (L4 To L5)](https://www.jointaro.com/playlist/AUMiBTvYUv0gcOzuu26V/)

Big Tech in general is system design heavy as [thorough planning is far more important there](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/understanding-big-tech-interviews/). When it comes to system design resources for mobile, I recommend:

- ["What are some of the best ways to practice and prepare for System Design rounds for Mobile Development (iOS Interviews)?"](https://www.jointaro.com/question/o18lchhmOlZFU2SuS1rM/what-are-some-of-the-best-ways-to-practice-and-prepare-for-system-design-rounds-for-mobile-development-ios-interviews/)
- ["What are some good resources for learning Mobile System design?"](https://www.jointaro.com/question/NyLoSTCyju0rfywZUPvs/what-are-some-good-resources-for-learning-mobile-system-design/)

Big Tech's interviews are quite standardized by nature though, so you will get a lot of non-mobile questions. Google and Meta in particular are (in)famous for being DSA/LeetCode heavy no matter what kind of engineer you are. Here's a breakdown of the Meta interview process: ["How does the Meta interview work?"](https://www.jointaro.com/question/Ne8lv2jCMZGuSGkr8wp9/how-does-the-meta-interview-work/)

**IMPORTANT NOTE:** If you aren't able to get into the Zoom, we will be live streaming the talk on YouTube as well: <https://www.youtube.com/@RahulPandeyrkp>

The current software engineer job market is the toughest we've seen in over a decade. Ever since the massive layoffs starting in late 2022, we have seen laid-off talent flood the market and mostly run into hiring freezes and largely constrained headcount.

This means that in order to succeed on the interview grind, you need to stand out much more than ever before. The lazy tactics that worked in the prior ZIRP economy are pretty much useless now. In this session, we'll break down strategies you should use to become a top candidate.

After the presentation, we'll talk questions from the audience (that's you!) and give personalized career advice.

For more job searching resources:

- ["How to get referrals?"](https://www.jointaro.com/question/FQIi8us9uoTDIYdzMhvg/how-to-get-referrals/?playlistId=roKqDHgxu4C5CioEFpJY)
- ["How to get interview calls?"](https://www.jointaro.com/question/MWJfUBnnUr8CKYFCO8bp/i-want-to-land-a-job-in-a-big-tech-as-a-swe-how-to-do-it/?playlistId=roKqDHgxu4C5CioEFpJY)
- ["How to figure out why I'm not passing onsite interviews?"](https://www.jointaro.com/question/CdmrIsMFPFbsRqRUvueu/how-to-figure-out-why-im-not-passing-onsite-interviews/?playlistId=IPFmEPUhAmizNe9ZUWV5)
- ["I want to land a job in a big tech as a SWE - How to do it?"](https://www.jointaro.com/question/MWJfUBnnUr8CKYFCO8bp/i-want-to-land-a-job-in-a-big-tech-as-a-swe-how-to-do-it/?playlistId=roKqDHgxu4C5CioEFpJY)
- [\[Course\] Ace Your Tech Interview And Get A Job As A Software Engineer](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/)

Tech Lead/Manager at Meta, Pinterest, Kosei

Rahul Pandey

Acing Tech Interviews In A Bad Job Market

Interviews are hard - You need to find good people without being mean. Here's our advice on how to conduct interviews that find the best talent in a humane way.

[Masterclass] How To Be An Amazing Interviewer In Tech

Every mature business will have this, and it's absolutely vital for software engineers to understand, especially if they're working at a high-performance company. For the full session, get Taro Premium!

[Masterclass] How To Navigate Your Performance Review In Tech

Ace getting your return offer as a Meta SWE intern! Created by Alex Chiou, who spent 4 years at Meta as a TL, raised an intern to an Exceeds Expectations (EE) offer, and mentored many other interns.

Meta Intern Success Series

Communication is a skill that software engineers often underestimate in terms of importance, and being good at it is effectively a senior engineer requirement. In this series, Alex breaks down the principles and tactics he uses to communicate effectively.

Alex's Guide To Effective Communication

Learn what real system design looks like by seeing Alex use the tactics he used as a Meta/Robinhood tech lead to scope out a Taro feature. The skills here are crucial to being a senior+ engineer at FAANG and other top companies.

System Design Masterclass: Taro Playlists

There are many ways for software engineers to land impact outside of the code, but raw coding ability is every engineer's technical foundation at the end of the day.

[Masterclass] How To Write Better Code Faster As A Software Engineer

Here are the Top 10 free career resources I'm the most proud of creating for Taro.

Alex's Top 10

Here are the best resources to help you land a great job faster as a software engineer.

[Taro Top 10] Finding A Tech Job

Here are the best resources to help you land a job at Big Tech (and succeed there) as a software engineer.

[Taro Top 10] Breaking Into FAANG

Were you recently laid off or are wondering what you can do to avoid the cut at your company? Here's our best resources to help you figure all that out.

[Taro Top 10] Navigating Tech Industry Layoffs

Starting at a new team or company? Or maybe you're just picking up a new tech stack? Go through these resources to learn how to ramp up fast.

[Taro Top 10] Effective Onboarding

For almost all software engineers, they need to become a tech lead (a.k.a. TL) to get to senior levels. However, there's much more to being an effective tech lead than ordering people around.

[Taro Top 10] Tech Leadership

From the junior L3 engineer up to the principal L8 engineer, we all have the same 24 hours in a day. These resources help you get more out of your time.

[Taro Top 10] Time Management And Productivity

It's a skill that every software engineer needs to get good at, but it's taught terribly in interviews. Use these resources to help you actually improve at writing technical design documents and architecting scalable systems.

[Taro Top 10] System Design

Promotion is one of the most straightforward paths towards leveling up your career. However, it's often misunderstood by engineers, leading to disappointment. These resources will help turn your internal trajectory into a rocket ship.

[Taro Top 10] Getting Promoted Faster In Tech

What's the difference between a senior and staff engineer? What does it mean to be L3 vs. L4? This playlist, anchored against Big Tech levels, breaks it down.

[Taro Top 10] Understanding Engineering Levels

You have some interviews lined up, and now you have to study. However, you have no idea how to organize it all - This playlist helps software engineers do that.

[Taro Top 10] Effective Interview Prep

After the pandemic, more engineers are working remotely than ever before. However, it's much harder succeeding when your team isn't all together in an office. Use these resources to learn how to succeed in a WFH world.

[Taro Top 10] Growing Fast With Remote Work In Tech

If you're a software engineer, you can't progress in your career by simply doing what you're told. Over time, you need to learn how to create you own scope, especially as you reach senior and staff levels.

[Taro Top 10] How To Create Scope As An Engineer

It's not enough to simply do the work as an engineer - You need to figure out how to operate within your company's system as well to get maximum credit.

[Taro Top 10] Navigating Performance Review

Building side projects is one of the most organic and powerful ways to both get jobs by boosting your portfolio and level up your performance on the job by leveling up your coding skills and product sense.

[Taro Top 10] Building Impressive Side Projects

Software engineers can have impact in many ways outside of coding, but make no mistake: Writing tons of very high-quality code quickly will always be useful. Follow the resources here to learn how to become a "code machine".

[Taro Top 10] Becoming A Better Coder

All engineers start off their career as a junior engineer, usually being there for 2-3 years. These resources cover what it takes to grow from there to mid-level, otherwise known as the L3 -> L4 promotion with FAANG leveling.

[Taro Top 10] Junior Engineer To Mid-Level Engineer (L3 To L4)

After getting a foothold in the industry, engineers become mid-level. Most engineers stay at this level for quite a while as they navigate the senior engineer promotion (L4 -> L5 by FAANG leveling), which generally requires becoming a tech lead.

[Taro Top 10] Mid-Level Engineer To Senior Engineer (L4 To L5)

Once engineers reach senior and staff levels, they need to decide: Do they stay as an individual contributor (IC) or switch into the management (M) track? Use this playlist to make the right decision.

[Taro Top 10] Software Engineer To Engineering Manager (IC -> M Track)

Do you work in tech and want to start your own company? It's harder than you think, even if you're a software engineer. Use these resources to approach becoming a founder in the right way.

[Taro Top 10] Entrepreneurship And Tech Startups

Senior to staff (L5 -> L6 by FAANG leveling) is where 95%+ of engineers hit a growth wall. While junior to senior is fairly foundational, this all changes at staff where you need make big mindset changes to maximize impact.

[Taro Top 10] Senior Engineer To Staff Engineer (L5 To L6)

Internships are the most powerful gateway towards landing a high-quality software engineering job, especially for Big Tech. Use the resources in this playlist to become a rockstar intern and nail that return offer.

[Taro Top 10] Succeeding As A Software Engineer Intern

Software engineering work is rarely smooth and well-defined: There will always be crazy surprises. If you're in any sort of engineering leadership role (tech lead or engineering manager), you will need to become great at project management.

[Taro Top 10] Project Management

Communication is both simultaneously the most important and most underrated skill among software engineers. Understanding people (and getting them to understand you) is far more impactful towards your career growth than understanding code.

[Taro Top 10] Communicating Effectively As An Engineer

There will always be bugs, and this only becomes more and more true as your product gets bigger. In this series, we go deep into the often underrated software engineer skill of debugging.

[Masterclass] How To Become A Debugging Master And Fix Issues Faster

We're in the middle of the "Content Renaissance" when it comes to engineering content. More and more engineers are building large audiences across platforms like YouTube, LinkedIn, Substack, and more. Learn how you can build your own voice online and how it helps your career.

[Taro Top 10] Building An Engineering Brand And Content Creation

If I told you that you can make $10,000+ just sending a couple emails, would you do it? Definitely yes right? This is why you should always negotiate your offers. Use this collection to learn how you can navigate these awkward, high-intensity conversations to get the pay you deserve.

[Taro Top 10] Pay Negotiation

This is one of most important interview rounds, especially for engineers targeting more senior levels. However, so many engineers struggle in these interviews due to poor communication skills.

[Taro Top 10] Behavioral Interviews

Engineers are surprisingly terrible at taking care of themselves. Never forget: A healthy personal life is the foundation for a successful career, not the other way around.

[Taro Top 10] Work-Life Balance

No matter what, there will always be bugs. As a software engineer, it's crucial for you to master this often underrated skill.

[Taro Top 10] Debugging

As a software engineer, you are more than just your code. As the person bringing the product to life, you are uniquely positioned to have a strong influence on its direction. In fact, it's extremely important for very senior engineers to get to know their PM and develop strong product intuition.

[Taro Top 10] Product Management For Engineers

It doesn't matter how talented you are as an engineer: When a talented developer is pitted against a crappy team, the crappy team wins 99.9% of the team. In order to grow in your career, you must find a supportive team first.

[Masterclass] How To Choose A Good Company And Team As A Software Engineer

As software engineers, we all start off writing code. However, a mindset shift is needed as we become more senior: We need to review more code than we write to positively influence others' technical direction.

[Taro Top 10] Code Review

Data structures and algorithms (otherwise known as "DSA") are an infamous part of SWE interviews, especially those of Big Tech companies. They're agonizing, but they can truly be mastered by anybody.

[Masterclass] How To Ace Your Big Tech Interview - Data Structures And Algorithms

It doesn't matter how talented you are as a software engineer: If you don't have a good engineering manager supporting you, your career growth is dead in the water.

[Masterclass] What Software Engineers Should Look For In Their Engineering Manager

We all have the same 24 hours in a day, from the new grad engineer to the veteran principal engineer. 1 common theme that separates the rockstar engineers from the rest is that they're able to get far more done (up to 100x more) from those 1440 daily minutes.

[Masterclass] How To Manage Your Time Optimally In Tech And Achieve More Results

Money. It's what makes the world go round, and it's especially true for the tech industry. Software engineers are paid more than 95% of the population, but tech compensation is... complicated to say the least. There's far more to it than base salary.

[Masterclass] Understanding And Optimizing Your Pay In Tech

As a software engineer, you are going to work across many, many different teams and companies across your career. This means that it's vital for you to get good at onboarding, so you can hit the ground running at any new job.

[Masterclass] How To Succeed At A New Team Or Company As A Software Engineer

The absolute 1st step towards a successful job search is to have an effective, polished resume. Despite this, so many engineers mess this up, missing a lot of low-hanging fruit to improve their resumes.

[Masterclass] How To Write A Stellar Tech Resume That Gets You More Job Opportunities

The 1 on 1 meeting is one of the important mechanisms within the workplace, especially in the fast-moving tech industry. How you leverage this time will make or break your career, especially when it's with your engineering manager.

[Masterclass] How To Have Impactful 1 on 1 Meetings

Promotion, not job switching, is the true foundation for any software engineering career. However, you don't get promoted by just doing good work and hoping for the best - You have to be much more deliberate about it.

[Masterclass] How To Get Promoted Faster In Tech

Your career lives or dies on the quality of your professional network. Whether it's finding a job or getting promoted, you always need a large bench of people willing to go to bat for you.