I recommend this: ["Template for 1:1 with Manager/Skip Level"](https://www.jointaro.com/question/PFxrzxTEboB5jCowwuHk/template-for-11-with-managerskip-level/)

Tech Lead @ Robinhood, Meta, Course Hero

Alex Chiou

Congrats on the good review!

For prioritization, I recommend this (and the overall productivity course): <https://www.jointaro.com/course/maximize-your-productivity-as-a-software-engineer/finding-the-best-things-to-work-on/>

For strategic direction setting, I recommend this: <https://www.jointaro.com/question/dIsyEpyAMFMBFKoEqChh/how-do-i-envision-my-team-and-plan-a-roadmap/>

I recommend these:

- [How To Effectively Leverage Skip Level 1:1s](https://www.jointaro.com/lesson/TToehFEc738PBhJcALwL/how-to-effectively-leverage-skip-level-11s/)
- ["Topics to talk in 1:1 with skip level manager?"](https://www.jointaro.com/question/yK1UiPgm1EElzHRIqlM8/topics-to-talk-in-11-with-skip-level-manager/)

Since you're a high performer within your team, you probably have a good idea of what's going well and what could be better from a culture/process perspective. That would be very valuable to share with higher-ups as they're thinking at a higher, organizational level.

The communication course is probably helpful as well: [Effective Communication For Engineers](https://www.jointaro.com/course/effective-communication-for-engineers/)

Since you're an SDE 1 at Amazon, I *highly* recommend going through this first: [Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)

At the end of the day, AI/LLMs are a tool, and tools are only as powerful as their wielder. Before you start going deep with AI tools, you should solidify your fundamentals first so you know how to both better prompt LLMs and police their output.

After that, I recommend going through these:

- ["How to optimally use GenAI to leverage my coding prowess and become a better software engineer?"](https://www.jointaro.com/question/jcN1xwNDlVuZ0yNBSsVL/how-to-optimally-use-genai-to-leverage-my-coding-prowess-and-become-a-better-software-engineer/)
- ["What's the best AI coding workflow?"](https://www.jointaro.com/question/hbu2PEeiszeufRKjzNBU/whats-the-best-ai-coding-workflow/)

> On a side note, I have also been thinking about is this time to become a ai/ml developer? Or atleast a back end engineer who can scale these technologies?

No unless you're genuinely passionate about the space. Check out this thread: ["The AI frenzy is really making me rethink my career - What direction should I take?"](https://www.jointaro.com/question/z4yxcV50SBaCLea3dBMA/the-ai-frenzy-is-really-making-me-rethink-my-career-what-direction-should-i-take/)

My main advice is to timebox it. Put your foot down and say that by X date, we will choose whatever option has the most consensus.

The tricky part is if things are completely tied. In that case, you will need to make a hard call. In that situation, I recommend sticking with your original design that has the backing of the L5s and L6 as I almost always trust veterans over newbies who don't fully understand the codebase yet. On top of that, it will minimize thrash.

Ideally, you can reach some sort of compromise where you incorporate some elements of the other design into yours. That's the best outcome so nobody feels like a loser.

Good luck!

> - Drive multiple work streams,

I recommend these courses:

- [Networking Guide: Build Deep Relationships Quickly In Tech](https://www.jointaro.com/course/networking-guide-build-deep-relationships-quickly-in-tech/) - You will need to work through others, and that's most effective if they really like you
- [Maximize Your Productivity As A Software Engineer](https://www.jointaro.com/course/maximize-your-productivity-as-a-software-engineer/) - Understand how to prioritize and get more from your time

> Create impact across multiple teams in a short period.

I think that's almost impossible as your first 1-2 months will mostly be around earning trust. I would try to find a big win localized within your team as a foundation. Here's my advice on how to do that: ["How do I come up with innovative, impactful ideas and bring them to my team?"](https://www.jointaro.com/question/3QIJhAT4loA7n1hSfCuw/how-do-i-come-up-with-innovative-impactful-ideas-and-bring-them-to-my-team/)

> And set technical direction at scale?

Make [high quality system design docs](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/) and go to a ton of system design meetings from other staff/principal/distinguished engineers to learn how they make high-quality docs.

Before you are even able to do that though, you should show a stellar level of individual code quality to earn trust: [Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)

The expectations of Atlassian Principal are around the same as Meta Staff, so I recommend this as well: [Grow From Senior To Staff Engineer: L5 To L6](https://www.jointaro.com/course/grow-from-senior-to-staff-engineer-l5-to-l6/)

I'm old-fashioned and I just use ChatGPT for stuff lol. I tried Copilot within VSCode, and it was just not good.

For designs though, I use [Readdy.ai](http://Readdy.ai), and it's one of my favorite AI tools (probably *the* favorite now that I think about it). Every new feature on Taro is now being designed with Readdy.

It's hard to assign a "proper" length to bugs as they vary a lot. It's true that bugs will get bigger and gnarlier on average as the company grows (I've seen engineers literally spend 2+ months fixing a single bug at FAANG), but it's not like there aren't bugs startups need to solve that can take several days or even a couple weeks.

My broader advice as always is to work backwards from the goal, especially for startups where you need to move fast. If some bug is putting your critical launch at risk, consider the other options besides knuckling through and fixing it:

1. Patch fix that addresses the symptoms, not the root cause
2. Ignore it (maybe log an error but that's it)
3. Drop the feature with the bug entirely

What I will say though is that if your codebase is relatively simple (less than 5 engineers working on it and less than 100,000 lines of code), and you keep running into crazy bugs that take a long time to fix, you need to step back and reconsider how you're architecting the codebase (and how your team overall is [approaching code quality](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)).

My default action is to review a pull request. I've gotten *very* fast at it (700+ reviews per half at Meta), so I can generally get in a review within 3-5 minutes.

Congrats on the offer! Atlassian is a top company, and the principal uplevel is quite impressive.

> Is the “risk” (cultural, job stability, PIP/stack ranking, etc) at Atlassian as bad as Blind makes it sound?

Literally nothing is bad as Blind makes it out to be, but the harsh truth is that Atlassian has indeed gotten very competitive and toxic over the past few years (I've talked to many Taro community members who have worked at Atlassian). From my understanding, their current CTO is from Meta, and he brought the worst parts of Meta culture with him (commit counting, aggressive stack rank, etc).

> Has anyone made a similar transition from internal tools to customer-facing product/platform roles at this level? What challenges should I expect?

I think the big thing is that you'll need to develop a much sharper product sense. I recommend this playlist: [\[Taro Top 10\] Product Management For Engineers](https://www.jointaro.com/playlist/2GNJo0RWsT4GK6VXyWIy/)

> For someone on a visa, is it worth taking the leap for career growth, impact, and compensation?

I think for anybody, it's generally good to challenge yourself and keep trying to push your skills to new heights. In a vacuum, I recommend taking the offer.

Best of luck!

Congrats on getting the E5 offer! Another resource I heavily recommend after the onboarding stuff is the L4 -&gt; L5 course, so you can really familiarize yourself with the Meta E5 bar: [Grow From Mid-Level To Senior Engineer: L4 To L5](https://www.jointaro.com/course/grow-from-mid-level-to-senior-senior-l4-to-l5/)

If Meta is the most intense company you've ever worked for (especially if it's your first FAANG), the course should be extremely helpful. The bar for Meta senior is *way* higher than senior at most companies.

*At Meta, you always work backwards from deadlines.* For each bigger deadline, you create sub-deadlines (i.e. project milestones), so you can quickly tell if you are behind and need to ramp things up. Once you fall behind, you need to sharply increase the intensity of your asks until you get the support you need.

In short, *you ask questions when your timeline is at risk*.

For E4s, the big piece here is often getting better at coming up with timelines/estimates. I recommend these:

- ["How do I build my time estimation skills for project"](https://www.jointaro.com/question/MVyu85xVBvFAZFEdSosX/how-do-i-build-my-time-estimation-skills-for-project/)
- ["What’s Your Process for Estimating Tasks Accurately?"](https://www.jointaro.com/question/D2XPKE9EQ0JjQ1g5uARx/whats-your-process-for-estimating-tasks-accurately/)

At the end of the day, every company needs some sort of website (at least a nice landing page), so there will always be a market for web development. It's not too bad if you don't get distracted by every new framework out there.

I would personally do native mobile development if it made sense (especially on Android), but a lot of Taro works better on a big screen (education in general is like that).

1. Split the code up into a small, modular, focused components
2. Go through each component and try to understand it. If you can't, just rewrite it from scratch
3. Do #2 until all the terrible code is gone

For the future, I don't recommend vibe coding (i.e. copy-pasting what the AI gives you while barely reading/understanding it). You should always understand at least 80% of what your code is doing line-by-line. If you don't, ask the AI until you do.

You should also not use AI for a high-level thinking. Have an idea of how your project is going to look overall, and the components it needs to have (+ the interfaces they use to communicate to one another). Then you use AI to fill in each individual piece, testing it thoroughly each time.

I recommend this related discussion: ["How to optimally use GenAI to leverage my coding prowess and become a better software engineer?"](https://www.jointaro.com/question/jcN1xwNDlVuZ0yNBSsVL/how-to-optimally-use-genai-to-leverage-my-coding-prowess-and-become-a-better-software-engineer/)

Dang, listening to 1 song over and over is kinda unhinged behavior ngl, but I've done it a lot too LOL

When I'm coding, I am *always* listening to something. I listen to anime music if I'm looking to get hyped (I'm a sucker for traditional Shonen animes with an underdog story) or lofi if I'm looking to be more chill.

For anime, I'm listening to a lot of Demon Slayer stuff to get inspiration: <https://www.youtube.com/watch?v=oapg2-AwZjk>

Before Demon Slayer, I would listen to a lot of My Hero Academia stuff. "You Say Run" is peak: <https://www.youtube.com/watch?v=3SDBTVcBUVs>

Frieren isn't exactly hype, but I've been listening to a lot of Frieren OST because I like the anime a lot: <https://www.youtube.com/watch?v=nOn0pDmrGco&list=PLRW80bBvVD3XSBlbe3M0dkxpD0QkCTe8a>

For lofi, I *love* Ghibli mixes: <https://www.youtube.com/watch?v=zhDwjnYZiCo>

I also recently found this cool channel that puts together inspirational mixes from movie soundtracks. Here's a very fitting one for us as engineers (The Social Network): <https://www.youtube.com/watch?v=6rvv8bU3pKA>

> Have you seen people successfully transition from problem management/incident response roles back into development later in their careers?

To be 100% honest, I feel like that former category is pretty rare. Maybe I've seen a bunch of engineers who had those roles, but it was labeled differently. But overall, I have seen successful pivots from coding-lite roles to coding-heavy ones.

> Do you think the communication and negotiation skills from Option B might actually be more resilient than coding skills?

100% yes, but the awkward part is that you sort of need both. As I talk about in my promotion courses, [especially L4 -&gt; L5](https://www.jointaro.com/course/grow-from-mid-level-to-senior-senior-l4-to-l5/), coding is the foundation of every top engineer's career. The softer skills then go on top of that.

Coding skills are your ticket to entry. The more fundamental skills are what allow you to stay and thrive. There's a nuance here.

> For someone at my career stage, would you prioritize the financial security of Option B or the skill diversification of Option A?

It's really tough. For most people with so much experience like you, I tell them to double down on what they already know and have carved out a niche in the market for. This is especially true for folks with families where they can't expend as much mental energy pivoting and learning new domains from scratch (it's a huge cognitive task).

However, I don't know what the resiliency of your current role's job market is. But to play Devil's Advocate again, AI is decreasing the value of coding skills. The present-day tech landscape is just a big ball of confusion right now.

> I've had a pretty rough career before this (worked at a few startups and odd tech jobs), so this is my first "traditional" software engineering job, and I just can't help but feel that I'm not working from the same base as everyone else, and I don't know how to close that gap.

Yeah, this is rough. There was a Taro community member who was in very similar shoes to you (hired as L4 at a top tech company but had the skills that were in between L3 and L4). The great news is that she made a stellar recovery as you can read about here: ["Feedback that I'm underperforming for my level. Is this PIP? What now?"](https://www.jointaro.com/question/g46nZJRKqL06skfLJSDD/feedback-that-im-underperforming-for-my-level-is-this-pip-what-now/)

When you're in this position, you simply have to put in the work. It's going to be rough and it's possible it won't work, but don't go down without a fight.

On the bright side, AI has advanced quite a lot over just the past 1-2 years. If you can't get readily available support, try to use AI to fill in the gaps. It often won't be able to give you the answer (especially in a context as huge and complex as Meta), but I've found that AI is often great just to bounce ideas off of. Sometimes you just need to get the brain juices flowing to solve the problem.

> It feels like E5s are like, mini startup founders of their projects.

That is an excellent way to put it! That is more or less the expectation of a Meta E5, and it's why I talk about it in my L4 -&gt; L5 course here: <https://www.jointaro.com/course/grow-from-mid-level-to-senior-senior-l4-to-l5/take-greater-ownership/>

> How do you ask for help in a way that gets you actionable guidance, not just links, tools, or vague high-level info? I keep getting resources or internal docs, but no one is helping me bridge that into concrete steps or showing me how to go from “scoping doc” to actual code.

To be 100% honest, what you're asking for is definitely bordering on [the realm of hand-holding](https://www.jointaro.com/question/5vEWajcZlSi7nlohTGtJ/what-does-it-mean-to-not-require-handholding-anymore/), and if I got this request as a tech lead at Meta from an E4, I would be *very* worried about them. I interpret "concrete steps to go to actual code" as a *very* large amount of disambiguation. This is something I would happily do for an E3 but less so for an E4 (I would do it to save them of course, but I would make it very clear that I expect them to stop needing it very soon).

Getting links is a pretty good start, and that is the level of help I would give an E4, even a new one. Of course, this is assuming the links point to good resources, and unfortunately, many resources at Meta are poorly written/outdated. The main resource you should ask for are sample diffs that you can model off of.

If you want more hands-on support, you should ask for pair programming sessions: ["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/)

However, pair programming sessions are a massive resource investment for the person helping you, so it's best you have a good relationship with them beforehand or have a supportive manager who can create that support bridge for you.

> I feel like my manager keeps asking me questions like, "what do you want to work? What do you want to for engineering excellence? What are your goals?

I assume the first question is *"What do you want to work on?"*.

Anyways, these are actually all legitimate questions, at least on the surface (how the manager processes your answers will determine if they're asking in good faith).

The first one seems like an open-ended product/technical question. You can either answer with a product/feature your team owns that you're excited about or a certain piece of infra/technology.

For engineering excellence, talk about parts of the technical realm you are most interested in. Is it debugging? Becoming a logging master? Adding automated tests? Doing quality code review?

For goals, that seems like a standard high-level career direction question. Share your long-term aspirations, whatever they may be.

Of course, I don't know the tone with which these questions were asked, but these all actually seem like great questions for a manager to ask the new engineer on a team.

There's a lot to process here, so I'll split my response into multiple parts. However, I want to start off with a personal anecdote first and a breakdown of Meta's overall culture.

I was actually in a similar situation to you. I joined Meta as an E4, and it was my first Big Tech company. My project wasn't really scoped out at all. Even my manager didn't really know what was going on as Portal leadership was extremely poor. I felt like I was drowning. The project was minimum an E5 project, probably closer to E6 if you were to deliver it with quality. I know this as the engineer who ended up taking the lead on this project from me joined Meta as an E5 and got promoted to E6 in just 2 halves.

The harsh truth is that Meta has always had more of a *"sink or swim"* culture, and it's a price you likely have to pay given how high the compensation and prestige of Meta is. Sure, some people go to teams where there's a well-defined onboarding and growth roadmap. After I moved from Portal to Instagram, I did my absolute best to be a TL who made that happen ([and got mentees promoted lightning fast for it](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/)). However, what happened to me and what's happening to you is more common than not unfortunately, especially in the current day Meta where everyone is stressed out and fighting for themselves.

After my first 2 months at Meta, I was 100% on track for a PIP. I didn't really do much, just meandering around doing non-impactful tasks. I was blaming the environment too: *Isn't a company like Meta supposed to have its shit together and provide a ton of guidance to their engineers?*

I was able to right the ship and get an "Exceeds Expectations" in my first PSC with a 2-prong approach:

1. [**Make everyone like me**](https://www.jointaro.com/course/networking-guide-build-deep-relationships-quickly-in-tech/) - I'm not that smart. I've said that many times both on Taro and on LinkedIn, and I 100% believe that. This means it's hard for me to stand out based on raw technical ability alone, which means I have to stand out another way. Most engineers have pretty poor social skills, so I decided to add value by just being nice to people, forging deep relationships that allowed me to be a "connector" later on. I enjoy making friends, so this is something I had fun doing anyways. One of those people I was extra nice to (even though it wouldn't help me at all in the short term) was Rahul as I talk about in my story here: ["How do you network effectively within a company?"](https://www.jointaro.com/question/DwT9GtdYK9nwFV3a7jrU/how-do-you-network-effectively-within-a-company/)
2. **Take the initiative** - If incompetent executives weren't going to tell me what to do (Portal's leadership team was 70% full of these people), I was going to figure it out myself and build a product I thought would be good. I went to all the people on the ground who were collaborating with me on this project. Product managers, designers, marketing people, even QA. I gathered whatever requirements I could, compiled them into a doc, and worked off of that. I still went through a lot of thrash (many execs realized that my cobbled together vision didn't match theirs only *after* I put something out there) but doing something janky is far better than doing nothing, the latter of which is an instant PIP at Meta.

A lot of this is admittedly E5 (senior) behavior as I talk about in [my mid-level to senior course](https://www.jointaro.com/course/grow-from-mid-level-to-senior-senior-l4-to-l5/), which is why I got rewarded with a good rating in my first official performance review (first PSC was TNTE luckily). It's unfair that your manager and team is demanding E5 behavior from you as a new E4, but you will have to do it to make it on your team. It sucks, but try to see it as a silver lining where if you can figure it out, you will grow faster than you ever have before.

Cluely is an extreme example where the company is almost entirely focused on marketing and hype instead of building an actual product. I read a TechCrunch article recently that explains it well: <https://techcrunch.com/2025/06/26/why-a16z-vc-believes-that-cluely-the-cheat-on-everything-startup-is-the-new-blueprint-for-ai-startups/>

> Despite having some semblance of a product, the startup has yet to unveil the solution it has been hyping.
>
> “The internet is up in storm saying, ‘Where’s the product?’” Lee said. “We’re earlier than the latest YC batch of companies. Yet, we’re generating more views than every single one of them.”

Marketing is really important (many startups go in the opposite direction where they have 0 marketing muscle and just write code that is never used by anybody), but I do think Cluely has gone off the deep end. At the end of day, you need a real product if you want your company to last.

In terms of how they're able to raise money, it's important to remember that the goal of VCs isn't solely to invest into sound businesses. VCs also want to build up their reputation + brand, and investing in startups that constantly make the news help them do that. a16z also didn't invest that much (just $15M which isn't huge by today's Silicon Valley AI landscape standards), so it's a small price to pay to get some notoriety.

Every engineer should be looking for ways to weave AI into their workflow. The main balance to navigate is having the AI do the work for you while not suffering a loss in understanding or learning. Check out this thread to learn more: ["How to optimally use GenAI to leverage my coding prowess and become a better software engineer?"](https://www.jointaro.com/question/jcN1xwNDlVuZ0yNBSsVL/how-to-optimally-use-genai-to-leverage-my-coding-prowess-and-become-a-better-software-engineer/)

I looked through Andrew Ng's "Generative AI for All" course and it looks okay. However, if your goal is to become a software engineer working in the AI space, I think it's much more fruitful [to just build side projects](https://www.jointaro.com/course/build-side-projects-with-500k-users-coming-up-with-an-idea/) that use AI.

Tactically, your goal right now should just be to get interviews. These fairly accessible online courses aren't counted at all by hiring managers as they're too commoditized, especially at top tech companies.

If your startup was acquired for a sizable exit ($50M+), that's pretty impressive. I would play that up. It's awkward though as you were only there for 6 months.

Aside from that, it will be tough to get into Meta as an MLE/Research Scientist if you didn't have that role at an adjacent company before (e.g. FAANG and Big Tech overall).

If Meta isn't responding to your applications, you will need to do something special to stand out like [major open-source contributions](https://www.jointaro.com/course/become-an-open-source-master/course-james-intro/) or [hugely successful side projects](https://www.jointaro.com/course/build-side-projects-with-500k-users-coming-up-with-an-idea/). There's so many people who want to work for Meta due to the prestige and ultra-high pay, and their swamped recruiters need something to differentiate the truly talented candidates.

Once you get the interview, I highly recommend this course: [Master The Machine Learning Interview As A Software Engineer](https://www.jointaro.com/course/master-the-machine-learning-interview-as-a-software-engineer/)

I recommend going through the [entire behavioral interview course](https://www.jointaro.com/course/master-the-behavioral-interview-as-a-software-engineer/), especially this lesson: <https://www.jointaro.com/course/master-the-behavioral-interview-as-a-software-engineer/good-vs-bad-questions-to-ask/>

There are a ton of other threads about Meta team matching as well like this one: ["Meta team match - How to optimize?"](https://www.jointaro.com/question/MrVPK10c13Rxbm1YKGIz/meta-team-match-how-to-optimize/)

> Do I need to try to build actual friendships with my teammates? Or is it enough to just be someone they can trust and work well with?

There's a middle ground in between these where you could see yourselves hanging out outside of the office (but rare, like 1-2 times a year), and I think that's the level you want to get to at Meta, especially now with the higher bar. So it's more like a strong acquaintance rather than a friend. However, this is easier said than done of course.

For me, I was the odd one out as I was one of the very few 2nd generation people on the team (most of them had recently immigrated from India or China), so I had to make an extra effort treating people with kindness and trying to find solidarity. However, I admittedly wasn't overcoming a gender barrier as well, and that makes things way harder. I empathize a lot with your situation.

Long-term, I frankly don't think your situation is tenable. Having this little solidarity with your team is going to be really rough, especially as you make progress towards E5. I would do your best to get good ratings on this team and then try to switch \~1 year in.

Meta is a very social company. It's totally fine to opt out of lunch sometimes; however, I wouldn't do it all the time as that will make it harder for you to fit into the team. Hopefully your lead/manager will take the hint when you're part of the group and encourage the conversation to be in a common language.

Hopefully the networking course is helpful here: [Networking Guide: Build Deep Relationships Quickly In Tech](https://www.jointaro.com/course/networking-guide-build-deep-relationships-quickly-in-tech/)

Can you get an example from a teammate who's gone through performance review before? If not, here's a super generic template (this is baked into most HR tools like Workday):

1. The impact you landed this cycle
2. What you did well
3. What you could have done better

For each of the 3 sections, you would split things into bullet points for organization.

At bigger companies like FAANG, you'll have performance review axes that further sub-divide sections #2 and #3 from above. At Meta for example, these axes were:

1. Impact
2. Engineering Excellence
3. People
4. Direction

You can see what those axes mean with my mid-level to senior promotion course here: [Grow From Mid-Level To Senior Engineer: L4 To L5](https://www.jointaro.com/course/grow-from-mid-level-to-senior-senior-l4-to-l5/)

First off, I wouldn't tell your intern manager that you're aiming for GE for the following reasons:

1. **It feels very "cart before the horse"** - Getting a return offer is already hard enough, especially in the current climate at Meta. It's much more organic to get a solid confirmation that you're trending towards MA (offer) and then work towards EE and then work towards GE. The problem with aiming for GE off the bat is that it makes your IM afraid to give you any feedback that isn't validating you operating at GE as they won't know how you'll take it. If an intern came in and just told me they're aiming for GE, I would take it negatively as it's just way too aggressive and to be 100% honest, I've mostly had bad experiences with engineers who thought that way (overly competitive and obsessive).
2. **GE is HARD** - Intern GE literally means that you're operating at E4 already, which is incredibly rare. I've only ever worked with 2 GE interns at Meta, and they were both insanely cracked (one of them made a [100k+ user side project](https://www.jointaro.com/course/build-side-projects-with-500k-users-coming-up-with-an-idea/) back in college). It puts a lot of pressure on the intern manager as every intern manager (ideally) wants to help their intern as much as possible, but raising an intern to GE takes an *immense* amount of effort. The FTE engineers at Meta are already stressed enough, so I imagine most won't appreciate the extra burden.

> ...tbh I don't understand why they don't just tell you your rating.

It's just safer for companies to divulge less information rather than more. It sucks for us as the employees, but it is what it is. Ratings were much more transparent back when I was at Meta (I gave my intern a midpoint rating), but the culture has definitely shifted to be more opaque over time.

Overall, I think your midpoint went well. Your intern manager is clearly supportive and said they will fight for you. You didn't get a rating, but you did get very valid feedback to improve ([communication](https://www.jointaro.com/course/effective-communication-for-engineers/), which is probably the most common barrier towards intern EE/GE ratings). At Meta, a lot of the communication axis comes down to [writing more Workplace posts](https://www.jointaro.com/question/XA0X51AypDLCeVeleJv4/how-to-get-more-visibility-on-work/).

> ...I feel like with back development there's really no way to get better at the stack on your own.

You can build back-end side projects, but it's just harder for them to feel as concrete as front-end. For the most part, a back-end exists to serve a front-end, but if you're only doing back-end, it's rough. It is tough for a back-end only project to find traction.

> Oh I had another question, you mentioned that one issue with Meta is that it’s all internal, but isn’t that kind of the case at other big tech companies too?

Yeah, this is the case for all of FAANG. But I feel like it's particularly bad at Meta. Meta literally forked Mercurial instead of using Git like everyone else. Meta really wants everything to be internal and custom.

> ...even with internal frameworks, product work still feels more “Googleable” and easier to improve at on your own.

I was a front-end engineer at Meta. I almost never Googled for anything even though Instagram was vanilla Android (despite being vanilla, the codebase was so complicated and the problems so hard that Google was useless). If you work on native Android on Facebook app and use Litho, Google is effectively 100% useless. Side projects were helpful though in that it just boosted my overall coding speed, muscle memory, and understanding of general Android concepts.

If you go to FAANG, Google will almost certainly not be that helpful, especially if you have made it past L3/E3.

> ...do you think it makes sense for me to plan to transfer a year from now?

If you still don't like the team, you should 100% switch. The earlier the better as you need to get to E5 within a certain amount of time.

Is this for work or for coding outside of work? For outside of work, you have the options of [open-source](https://www.jointaro.com/course/become-an-open-source-master/course-james-intro/) and [side projects](https://www.jointaro.com/course/build-side-projects-with-500k-users-coming-up-with-an-idea/). For open-source cryptography-adjacent projects, I imagine a lot of them are blockchain related.

Your tech lead/manager might be being nice to you as you're new and don't want to put pressure on you by assigning due dates to tasks. However, even newbies are being judged at Meta, and you can't take forever on tasks. Have that awkward conversation with your tech lead/manager and ask them for due dates, effectively giving them the permission to put that pressure on you (which also adds clarity, which is critical at Meta).

I recommend asking for P80/P50/P20 estimates as well, which is how Meta does timelines:

- P50 - Standard Meta goal. Ambitious but possible (50% chance of hitting)
- P80 - 80% chance of hitting, safe target
- P20 - Incredibly aggressive, 20% chance of hitting. If you hit it, you are a rockstar

> And how do you balance speed with learning?

I recommend 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/)

If you are doing things properly, you should have both. Striving for quality brings both speed and learning when done in the right balance.

I like this idea! I've thought about level-specific solidarity groups for a while. I recommend posting in #member-matching about it in the Taro Premium Slack. If you're not in the Slack, email us at help@jointaro.com

I'm leaning towards Option B, and I would combo that with [finding your own scope](https://www.jointaro.com/course/grow-from-mid-level-to-senior-senior-l4-to-l5/the-goggles/) to create opportunities to code for yourself. If you're productive enough to be able to finish your work every week with 5 hours to spare, I would be very surprised if leadership stopped you from writing high-impact code with it.

Option B is also nice as it forces you to develop a lot of higher-order skills like communication, retrospecting, debugging, negotiating, etc.

It's really tough as these questions are inherently non-predictable and asked by non-Big Tech companies. My main advice is simply to write code to practice (side projects, open-source) like I talk about here: <https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/practical-coding/>

Of course, you'll want to combo that with talking your recruiter to get as much clarity about the interview as possible: <https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/talk-to-your-recruiter/>

On top of building stuff from scratch, there are many other hands-on interview types like debugging, doing a code review, writing automated tests, etc. You really need to get as much information as possible from your recruiter.

This is one of the painful parts about working at Big Tech, especially Meta. Meta has a huge "build in-house" culture, so almost everything is Meta-specific. I got lucky at Instagram as their Android style is incredibly vanilla, but outside of Instagram, Meta uses their own Android frameworks that don't even feel like Android anymore, making side-projects useless.

Anyways, my biggest piece of advice is to *pattern match*. There's got to be some E3/E4 engineer on your team who is doing fine. Try to mirror their workflow as much as possible. [Try to make them like you as much as possible](https://www.jointaro.com/course/networking-guide-build-deep-relationships-quickly-in-tech/), so they're willing to explain their workflow to you. If being productive on this team was truly impossible, then it wouldn't exist. At E4, your raw learning power generally isn't very strong yet, which was the case for me. So when I started at Meta, my coding workflow was pretty much this:

1. Get a task
2. Find a part of the code that's already been written which is similar to my task
3. Blame the code and find the diff that landed the code
4. Do what that diff was doing but parameterize it to my use case

> If you’re full-stack in a backend org, is it okay to lean into frontend work for delivery — or does that limit your growth and impact?

Talk to your manager. If there's high-impact frontend work within your team's scope, it should be fine as impact is impact. If there's isn't, then you could be seen as being distracted.

> Has anyone here ever successfully switched teams before the usual 12-month requirement? Is asking for an exemption ever worth it?

I have seen it, and it is *entirely* dependent on your relationship with your manager. Having an engineer leave so soon is super thrashy, so your manager needs to like you a lot as a person in order to green light this. On the flip side, if a manager doesn't like you that much and sees you struggling to fit into the team, they will opt for the PIP/early exit route instead. [The manager relationship](https://www.jointaro.com/course/managing-up-build-effective-relationships-with-your-boss/) is so, so, so important at Meta.

I more or less ask the questions from here: <https://www.jointaro.com/course/master-the-behavioral-interview-as-a-software-engineer/good-vs-bad-questions-to-ask/>

If a question works for team matching, and it still makes sense when you swap out the team context for the overall company context, then it's probably still a good question to ask.

One tactic you can try to absolutely force the issue is to explicitly ask a question like this: *"If I don't have enough time and I absolutely have to backlog one of my projects, which one would you recommend I drop first?"*

If your manager won't tell you anything, I recommend going to your product manager and tech lead. It's not only the manager who should have a sense of prioritization.

You should also make the calculation that I talk about in this lesson of the productivity course: <https://www.jointaro.com/course/maximize-your-productivity-as-a-software-engineer/finding-the-best-things-to-work-on/>

I would be incredibly surprised if the predicted impact of every project you're working on is exactly the same.

> There’s no shuttle service at the office I go to...

Oh dang, that's rough 😔. Another option is try switching to a team in an office that does have shuttle service (in the Bay Area, MPK obviously has incredible shuttle service that spans a huge amount of the region).

I have seen this case a lot, especially at Meta as there's effectively a ban on the software architect archetype. Many senior+ engineers were forced to transition as they had this traditional architect role at their previous company. Most failed but a couple succeeded. Here's what I saw from those who succeeded:

1. *They built a lot of stuff*
2. They were extremely humble and open to feedback (no ego)

#1 is the main one. Just get your hands dirty again. Try doing some last minute coding at your current company, scoping out tasks and [writing system design docs](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/). On the side, you can try doing [side projects](https://www.jointaro.com/course/build-side-projects-with-500k-users-coming-up-with-an-idea/) and/or [open-source](https://www.jointaro.com/course/become-an-open-source-master/course-james-intro/).

#2 is also extremely important, and I recommend this other thread for that: ["What’s the most effective way to switch domains in tech?"](https://www.jointaro.com/question/eFr9vsyTSiYLCbtsj7RR/whats-the-most-effective-way-to-switch-domains-in-tech/)

For 1 on 1 template, there's some ideas here:

- ["What’s a good example of a 1:1 document to help your manager keep track of your accomplishments?"](https://www.jointaro.com/question/cgh8KidlZ4x7ob1DGbEj/whats-a-good-example-of-a-11-document-to-help-your-manager-keep-track-of-your-accomplishments/)
- ["What should be in our 1 on 1 doc (for manager 1 on 1s)?"](https://www.jointaro.com/question/w9iSDXQpTkS4dl41R3cZ/what-should-be-in-our-1-on-1-doc-for-manager-1-on-1s/)

> Is there a good template for a 1:1 with my manager without sounding like promotion/growth/TC hungry desperate person?

Promotion conversations are tricky, and it will vary based on the organizations. Some organizations are just super cheap and don't want to promote engineers ever, and in those cases, there is nothing you can do to prevent being labeled as a "promotion hungry" person.

If your manager/org are acting in good faith though, I highly recommend this lesson from the promotion course (and the course overall): <https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/talk-to-your-manager/>

Straight up mute Work Chat for 2-4 hour blocks if you're not oncall. Work Chat is insanely noisy. As for Workplace, only go through your notifications and then stop. If you just scroll through bigger groups, you can easily rabbit hole and burn a ton of time.

I also recommend doing everything in your power to set up focus blocks like I talk about here: <https://www.jointaro.com/course/maximize-your-productivity-as-a-software-engineer/focus-blocks/>

As an E4, you are held very responsible for raw contributions (i.e. writing a lot of code), so it's important for you to be very protective of your calendar and enter your flow state as often as possible.

> One of my biggest pain points with hybrid work is the commute, it’s about two hours each way. Moving isn’t really an option right now, so when I go in, that’s four hours of my day just gone.

Are you too far away to have a shuttle or work for a Meta office that doesn't have shuttles? The shuttles are amazing as they have wifi. I would get a ton of stuff done on the shuttle ride (Better Engineering diffs, code review, etc). It might be awkward getting to a shuttle as you need to park-and-ride, but if it's possible, you should definitely do it. The shuttles unlock a huge amount of productivity, and I would have gone crazy working for Meta without them.

Overall, I had to implement everything I mentioned in my productivity course in order to sustain being a high performer at Meta: [Maximize Your Productivity As A Software Engineer](https://www.jointaro.com/course/maximize-your-productivity-as-a-software-engineer/)

You should look to [have an awkward conversation](https://www.jointaro.com/lesson/xjeFRpp5YHxG9TTK8wjn/1-on-1s-are-the-time-to-be-awkward/) with your intern manager ASAP. You were supposed to finish this by Week 3 but you are now around Week 5 from my understanding. Point out that you are behind the current plan and ask if that's okay. I'm hoping that it is and you will get some leeway in performance review when you get graded. But if it's not and you need to move faster, you need to find out right now and course correct.

In terms of how to course correct, that will depend a lot on the context. Again, talk to your intern manager. Some projects will allow you to cut scope, others won't. Some projects can bring in another engineer to help you, some won't. Talk to your intern manager and get all the information and options.

1 year for your very first job isn't too bad. After that though, you should try to stay for 2 years at least at every job.

> So my real question is: Did I make the right call, or should I have toughed it out longer?

It's a tough call. If it was seriously affecting your mental health, leaving was the right call. But in terms of where and when you draw the line, it's hard to quantify. In a vacuum, I would recommend junior engineers spend at least 1.5 years at their first job to be safe, but careers often don't follow the picture-perfect path as I'm sure you know.

> Also, how should I frame it in an upcoming interview without throwing my former employer under the bus?

I would frame it as not being a good fit. This makes it seem like it was more of a mutual thing vs. you just complaining about your manager. Even if your manager was at fault 90%+ of the time, companies won't know that obviously as they weren't in the room. If your narrative [during the behavioral interview](https://www.jointaro.com/course/master-the-behavioral-interview-as-a-software-engineer/) comes across as constant complaining, most companies will refuse to hire you as they will fear that you are a drama queen/king.

I 100% believe the most important trait is communication, which I cover in-depth here: ["What's the core insight behind quick growth?"](https://www.jointaro.com/question/nJ762p255cGyuth36H6w/whats-the-core-insight-behind-quick-growth/)

> How fast could they ship code, create POCs and get signal quickly?

Very fast with the definition of "fast" depending based on company. Back at Instagram, the most talented engineer I ever worked with (E3 -&gt; E8 in \~5 years) did a great job just hacking together prototypes in iOS and then just sharing them with everybody. He didn't ask for permission to build them.

> Do they just write **a lot** of code in general?

If they're [code machine archetype](https://www.jointaro.com/course/grow-from-senior-to-staff-engineer-l5-to-l6/code-machine/), yes. Otherwise no.

> How many high-quality questions did they ask?

A ton. They're fearless in meetings and are always starving for knowledge. They [network masterfully](https://www.jointaro.com/course/networking-guide-build-deep-relationships-quickly-in-tech/) and treat people well so they're incentivized to give high-quality answers in return.

> How often did they take on work outside of their core responsibilities?

All the time. Even getting to senior at top companies usually requires this as I talk about here: <https://www.jointaro.com/course/grow-from-mid-level-to-senior-senior-l4-to-l5/the-goggles/>

I think if you want to move into the upper echelons of tech, you more or less have to move to the United States. There are meaningful London offices for FAANG, and I think that's more or less the most common peak European engineers can achieve.

Your observations about startups in Europe are spot-on. The big problem with Europe is that the VCs are way too conservative and founders don't give early employees enough equity. This makes it harder for startups to attract the best talent away from Big Tech and even harder to retain them if they do decide to take a chance on a startup. There's a nice video from PostHog's CEO about this culture here: [Why You Should Be Racist Toward European VCs (An Argument For YC)](https://www.jointaro.com/lesson/kZd2syeHBPERFwo5Of3X/why-you-should-be-racist-toward-european-vcs-an-argument-for-yc/)

Oh wow, congrats on the offer! I recommend this thread for a similar transition (but sort of in the opposite direction): ["What’s the most effective way to switch domains in tech?"](https://www.jointaro.com/question/eFr9vsyTSiYLCbtsj7RR/whats-the-most-effective-way-to-switch-domains-in-tech/)

This thread is great as well: ["Looking to transition to ML Engineer? What do you want to know?"](https://www.jointaro.com/question/YqrpDDCPbsGpg0lwrKXY/looking-to-transition-to-ml-engineer-what-do-you-want-to-know/)

My main advice is to be humble and extremely open to feedback. Aggressively meet others and [build deep relationships with them](https://www.jointaro.com/course/networking-guide-build-deep-relationships-quickly-in-tech/).

Even in the current economic climate, \~75 hour weeks are pretty crazy. Unless you have teammates you love and/or strong compensation (the top Series A startups can get competitive against FAANG with salary at least), I would consider leaving, especially if you have been there for 1.5+ years.

With early-stage startups, you need to be in it for the long haul (5+ years) if you want a big payoff. However, it's hard to do that if you are working such long hours and have meaningful doubt about the company's long-term success.

I recommend this thread as well: ["How do I know when it's time to leave a team/company?"](https://www.jointaro.com/question/2Ahiy6ZtUYWDjkSoG3Zk/how-do-i-know-when-its-time-to-leave-a-teamcompany/)

220 is on the higher end, but it's within that 250 line range I mentioned. Some diffs are indeed naturally hard to split.

As long as all your peers are okay with it, I wouldn't worry about it. The main thing to look at is the number of revisions your diffs go through alongside comment volume (more feedback comments = more problems in the code generally).

My main advice when asking for feedback in the moment is to make your ask as specific as possible. Follow the guidance here: [This Is How You Get Feedback - Making The Process Smooth](https://www.jointaro.com/lesson/aGuxjGbFjYb34ofhRxjs/this-is-how-you-get-feedback-making-the-process-smooth/)

Zooming out, the highest leverage thing you can do is build up the relationship as much beforehand so the person trusts you enough to give you real feedback to begin with. Follow the advice from my networking course to build up trust fast: [Networking Guide: Build Deep Relationships Quickly In Tech](https://www.jointaro.com/course/networking-guide-build-deep-relationships-quickly-in-tech/)

I almost forgot - Here's a great thread about documentation and building a good culture around it: ["Best Practices for Retrofitting Documentation in a Growing Codebase"](https://www.jointaro.com/question/HWU5rUxjVkOGYJS20yRQ/best-practices-for-retrofitting-documentation-in-a-growing-codebase/)

The main problem with documentation is writing and especially maintaining it, so I definitely like the idea. *My main concern is around the feasibility.* A lot of these AI tools sound great in theory but when you get into the implementation, it turns out that getting it to a sufficient degree of quality is extremely rough. [We learned that the hard way with TaroGPT](https://www.jointaro.com/lesson/9OfTtd8PnyR2KGWfkVtM/inside-tarogpt-building-a-career-coach-chatbot-for-engineers/). People 100% love chat bots, but we simply couldn't get the quality of TaroGPT to where it needed to be, and that's why the feature never got any real traction and we had to eventually kill it.

In your scenario, I'm very worried that your tool is going to end up generating a bunch of AI slop where it says a lot of stuff, but it's ultimately still hard to understand. I do have an idea to decrease the chances of that and that's to bring in data from more sources besides automated tests (which many smaller companies and codebases don't even have). This includes:

- Project management tasks (Linear, Jira, Asana)
- *The pull requests itself* (every line of code can be blamed to a PR, and [if a PR is good, it should have a wealth of data](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/one-diff-one-thesis/))
- [System design docs](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)

There's [a ton of artifacts you can collate together](https://www.jointaro.com/question/55fEwxKMxTLMyiurKdBH/tips-for-someone-with-poor-working-memory/) to piece together a doc for every part of the codebase; it'll just be hard to match them all outside of the blames in particular.

Best of luck!

Group Office Hours are a very simple event type with a very important goal in mind: *Get you the career support you need in a safe, communal setting*. This means:

- These sessions are **never** recorded
- All AI summary and note-taker bots will be kicked out
- If you want to ask your question 100% anonymously, just change your display name and ask it in the chat

So how does it work? Easy: Drop in whenever, raise your hand 🤚 to ask a question (or put it in chat), and leave at your own convenience. *For the sake of fairness, Alex will only answer 1 question at a time per person.*

Can't make the event? No worries, just ask your question in the #tech-career-discussions channel in the Taro Premium Slack and the community will chime in.

Group Office Hours With Alex - Get Personalized Career Advice Privately

This course is for engineers who want to grow. Whether that means expanding your scope, earning more responsibility, or positioning yourself for a promotion, it starts with one shift: being seen as someone who carries the work differently.

[Course] How To Create Ownership

Software engineers are paid a lot, but our sky-high compensation comes with a big drawback: Complexity. Between RSUs, ESPP, stock options, and bonuses, there's no shortage of financial components to make your head spin. Use this course to learn how to navigate money in tech.

[Course] Tech Finance Guide: Maximize Your Equity And Benefits

A lot of the time we know exactly what we need to do, but we just don't do it, being a lazy blob instead. In this course, we'll teach you how to overcome productivity obstacles like a lack of motivation, social media distractions, and smart phone addiction so you can get stuff done.

[Course] 20 Years Of Fighting Procrastination In 1 Hour

There are actually 3 things that are inevitable: Death, taxes, and software bugs. Many engineers are understandably annoyed by bugs as they distract you from your awesome feature work. This course is here to teach you not only how to fix bugs faster but also how to come to love them as well.

[Course] Become A Debugging Master And Fix Issues Faster

If you want to succeed in the hyper-competitive tech industry, you need an army of talented people who truly have your back. That begs the question: How do you find those people and make them want to help you? That's what this course is here to teach.

[Course] Networking Guide: Build Deep Relationships Quickly In Tech

In a market where there are fewer and fewer junior engineer roles, succeeding at your internship is more important than ever. Follow the advice in this course to absolutely nail your return offer.

[Course] The Software Engineer Internship Survival Guide

Congratulations on coming up with a great side project idea! Follow the advice from this course to figure out how to build the MVP (minimum viable product), improve on it, and grow its user base, all organically.

[Course] Build Side Projects With 500k+ Users: Shipping & Growing

In order for a side project to actually matter on your resume, it must have a meaningful amount of users. Follow the advice from this course to learn how Alex came up with feasible (but exciting) project ideas to build 3 apps with 500k+ users.

[Course] Build Side Projects With 500k+ Users: Coming Up With An Idea

Master the LeetCode interview with this in-depth course covering core DSA concepts in detail with animated visualizations and full code examples in Python.

[Course] Crash Course: Beginner Data Structures And Algorithms Concepts

Data structures and algorithms (DSA) are the bane of many software engineers' existence. They are a hard requirement in FAANG interviews, particularly Meta and Google. This course will teach you how to master this incredibly complex and frustrating topic.

[Course] Master The Data Structures And Algorithms Interview

Becoming a software engineer is one of the most impactful and attainable paths to boost your income. While it's definitely possible to do this career switch without a 4-year degree, doing so is incredibly difficult. Use this course to guide your journey.

[Course] Break Into Tech And Become A Software Engineer

As a manager, your impact is entirely dependent on the talent you hire. If you're looking to build an incredible engineering team, this course is for you. If you're an engineer looking to join an incredible team, you can now understand the other side of the table.

[Course] How Engineering Managers Hire Great Engineers

Congratulations on becoming a software engineer! The next step for you: Figure out how to evolve past the helpless "junior" label. This course will teach you how to do that fast.

[Course] Grow From Junior To Mid-Level Engineer: L3 To L4

System design is a critical engineering skill, which is why it's a huge part of the software engineer interview, especially at FAANG. However, the open-ended nature of system design leads to a lot of engineers struggling immensely with these rounds. Never again.

[Course] The Top Ways People Fail System Design Interviews

The most important language for software engineers isn't Python, JavaScript, C++ or any other programming language: It's English. Follow the principles in this course to ensure that you always get your point across while building up relationships.

[Course] Clear Communication For Software Engineers

What does it take to be a tech lead? Join Google Staff Engineer [L6] Lalit Kundu as he breaks down how you can grow into tech leadership.

[Course] Tech Lead Blueprint: Role, Skills, and Strategies

Staff Engineers (L6) are critical members of their teams, which is why they're paid extremely well with FAANG L6s being paid $500,000+ in the US. But how do you make the jump from Senior to Staff?

[Course] Grow From Senior To Staff Engineer: L5 To L6

In order to grow quickly as a software engineer, you need to learn a lot from others. This process will go 10x faster if you ask high-quality questions instead of low-quality ones: Go through this course to learn how to do just that.

[Course] Ask Great Questions That Get Great Answers Quickly

As a software engineer, you need to get a lot done with a relatively small amount of time, especially if you work at a high-performing tech company like FAANG. This course covers tactics you can use to move faster and prevent yourself from wasting time.

[Course] Maximize Your Productivity As A Software Engineer

There's much more to being an effective tech lead than telling people what to do. In this course, Jocelin Ho walks through what it takes, drawing on her rich experience as a Meta tech lead and as the CTO of Cooby (a Sequoia-backed startup).

[Course] How To Be An Effective Tech Lead

Having a high-quality, polished resume is the 1st step towards a successful job search. As a software engineer, you need to be incredibly precise with how you present yourself and avoid the many traps that make tech resumes suck.

[Course] Get More Interviews: Write A Stellar Resume As A Software Engineer

Every engineer wants to become senior someday, but this promotion is notoriously difficult, especially at FAANG. Learn what it takes to quickly become a high-performing senior engineer.

[Course] Grow From Mid-Level To Senior Engineer: L4 To L5

Data structures and algorithms (DSA) interviews are the most notorious in tech, leading to millions of engineers over-grinding LeetCode. In reality, behavioral interviews are the most important interview type, and most engineers unfortunately suck at them.

[Course] Master The Behavioral Interview As A Software Engineer

PIPs are a cruel mechanism that tech companies use to force out low-performing engineers. Here's how to avoid them and think about your next steps if you are put on one.

[Course] The Ultimate Performance Improvement Plan (PIP) Guide

Promotion is incredibly important and acts as the foundation for your career at top engineering levels. This course will cover how you can master the promotion process by leveraging the tactics Alex taught to grow his mentees to high-performing TLs with $500k+ TC by their mid-20s.

[Course] Nail Your Promotion As A Software Engineer

"Designing Data Intensive Applications" by Martin Kleppmann is one of the most famous system design books out there. Whether you're preparing for interviews or just want to get a better understanding of data (crucial for Big Tech), check out these recordings where we discuss the book in-depth.

Taro Book Club: Designing Data Intensive Applications

The software engineer interview grind is almost always far harder than people realize, and the existing resources to help don't do nearly enough, focusing far too much on DSA and LeetCode. This course solves that by going into the far more important "meta" parts of a job search like the overall structure and mentality.

[Course] Ace Your Tech Interview And Get A Job As A Software Engineer

With the meteoric rise of ChatGPT, ML and AI are on software engineers' minds more than even before. How can we leverage AI to boost our workflow? Is it worth it pivoting to MLE? Use the resources here to find out.

[Taro Top 10] Machine Learning And Artificial Intelligence (AI)

This is the kind of advice that should be viewed by every engineer ever but currently isn't.

Underrated Engineering Discussions

With the infinite amount of tutorials and infrastructure services out there, writing code is easier than ever before. If you want to stand out as a software engineer, you need to write much better code than almost everyone else. You need high code quality.

[Course] Level Up Your Code Quality As A Software Engineer

The absolute first step in a successful job search is to write a stellar, concise resume. Despite this, so many engineers fail to do the incredibly high-leverage act of resume optimization, making several basic mistakes.

[Taro Top 10] How To Write A Better Engineering Resume To Get More Jobs

It doesn't matter how skilled and talented you are as a software engineer if the team around you is fundamentally unsupportive. In order to have a successful career, you need to join organizations that foster your growth.

[Taro Top 10] How To Find A Good Engineering Team And Company

As a software engineer, you will quickly realize that you can't do it all alone, especially at senior/staff levels and beyond. In order to continue growing, you need to learn to mentor others and delegate.

[Taro Top 10] Effective Mentorship And Growing Others

Your engineering manager (EM) is easily the most important figure in your professional life, and how you manage your engineer <-> EM relationships will largely dictate how much career growth you have.

[Masterclass] How To Work Better With Your Engineering Manager

A lot of software engineers get obsessed with learning new technologies, constantly distracted by shiny object syndrome. What the rockstar engineers realize is that learning how to learn is much higher leverage.

[Masterclass] How To Learn Quickly In Tech

As you become more senior as a software engineer, reviewing code becomes far more important than writing it. It's crucial for you to learn how to leave salient feedback on others' code, even when they're working on a codebase you have never touched.

[Masterclass] How To Do Amazing Code Review

Here's the harsh reality: If you are a software engineer, you will almost certainly get laid off at least once in your career, no matter how brilliant you are. However, there are steps you can take to recover from them more rapidly than others.

[Masterclass] How To Survive Tech Industry Layoffs

FAANG - It's where seemingly all software engineers aspire to be. But is it actually worth it? Go through this playlist to find out both the real pros and cons of working at these prestigious behemoths.

[Masterclass] Should You Work At FAANG? - What Big Tech Is Like For Software Engineers

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.

[Masterclass] How To Build Deep Relationships Quickly In Tech

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

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

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

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

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

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

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

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

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

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 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

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

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

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

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

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

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

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

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

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

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)

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

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)

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)

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)

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

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

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

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

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

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

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.