> If you happen to be in 2nd bucket (non-regrettable attrition), so does that mean you will never be hired back even after few years have passed ?

Careers are long, so it'd be foolish for a company to blocklist someone forever. For example, if you start/join a very hot startup that's relevant to the original company, all previous sins will be forgotten. 

Even in less extreme cases (i.e. not a startup acquisition), I'm sure things change as people move in and out of a company. I'm not sure how long the waiting period is, but you can certainly re-join after a couple years. 

Tech Lead/Manager at Meta, Pinterest, Kosei

Rahul Pandey

> All the space is on less priority projects

That's a problem. You need to identify the priority projects, either by creating them or finding them in the roadmap.

If you can't, your career will stagnate. In that case, you need to switch teams or leave the company that is growing and can offer increasing scope.

Yes, you could be eligible for re-hire after getting laid off. When someone gets let go (either voluntarily or involuntarily), their manager will usually add a note on their file: 

- **Regrettable attrition:** We are ok with having this employee rejoin us later. The company would prefer to retain the employee.
- **Non-regrettable attrition**: We don't want this employee to come back. The employee departures that are either neutral or beneficial to the company.

If you're in the first bucket, you are eligible for re-hire within a shorter time window. Not all layoffs are regrettable, so it depends on the circumstances of the layoff. If they're performance-based, they would be non-regrettable attrition. 

See also this very new course, [\[Taro Classic\] How To Have Impactful 1 on 1 Meetings](https://www.jointaro.com/course/how-to-have-impactful-1-on-1-meetings/)

Use the LLM as a thought partner or brainstorm partner when you're prepping for a meeting or planning meeting. It can be very helpful to generate a lot more ideas, or to understand some obvious questions to consider.

This depends on your goals -- it sounds like you have a very nice gig! 

Given that you are on a visa, you want flexibility with two kids, and you have a direct line to the VP, it seems like a great place to be. Is there an expected end date for immigration processing? That seems like a big milestone after which you can take on more risk like a job change. 

I also question the premise that you must change jobs in order to keep learning. You can learn a ton in your current role if you're self-directed and willing to proactively find interesting work. 

Jordan talks about some ways to do this in the [Become The Go-To Expert As A Software Engineer](https://www.jointaro.com/course/become-the-go-to-expert-as-a-software-engineer/how-this-course-works/) course.

I use VSCode with Copilot for coding and Gemini for almost all higher-level questions (code or non-code related). 

The answer is to **leave the toxic team ASAP**. A bit more nuance: 

- If you're junior or mid-level, you don't have much ability to change the team culture so you should immediately leave.
- If you're senior (as you are), you have a bit more ability to change processes and people on the team. However, it stil is limited as an IC. There's probably an 80/20 rule here of some changes you can suggest or feedback you can deliver that address many of the problems. Once you've done that, just leave.
- If you're part of upper management, you may have inherited the problem and maybe even brough in to solve it. This is the case where you could consider the "fight" scenario if you have the power to make changes. 

The world of tech is big and constantly getting bigger. Don't waste your time on a bad team or with a bad manager. Find another team, company, or start something on your own. 

The last point I'll say is that there are likely some very smart + kind people on your team. Every team, no matter how dysfunctional, will have some people you jive with. As discussed in the networking course ([The #1 Rule Of Networking](https://www.jointaro.com/course/networking-guide-build-deep-relationships-quickly-in-tech/the-1-rule-of-networking/)), lead with kindness and build lasting relationships with these people. 

Yes, that plan sounds great! The only nuance I'd add is around *how* you do the 1:1s for "Set up 1:1s with teammates and other cross-functional partners during my first 2–3 weeks."

I talk about this in [Have The "Meta Conversation"](https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/have-the-meta-conversation/) and with the [Boz career cold-start algorithm](https://boz.com/articles/career-cold-start). 

- If the build succeeds, what will your next action be?
- If the build fails, what is the most likely reason? Where will you add a log statement to investigate?
- Can you catch up on the broader project updates? Learn about the broader context of what the engineers/PMs are working on
- Get up to get coffee while still keeping your brain in the headspace of the project.

I'd also investigate a product like Blacksmith (founded by a Taro Premium member [Aditya Jayaprakash](https://www.linkedin.com/in/adijp/)!) to improve build times.

building your own version of something can be extremely valuable for learning! but if the goal is to move your company forward as quickly as possible, then taking existing libraries or technologies is almost always preferred

Part of this just comes with seniority and more time in the organization.

But I think you can also do a bit of historical analysis to see what kind of things people have asked about to calibrate what kinds of questions get asked. This can also show you what/if has changed about tools or utilities that are blocking you. You can reference these posts in your question to demonstrate that you did the legwork.

Two more suggestions:

- can you create/cultivate an informal peer group where you can ask lightweight questions? tI can give you one more signal on “escalate if no one in that smaller group of friends knows the answer to your question".
- In general, I would bias toward escalating early, especially if you have a dedicated point of contact like a mentor or Tech Lead who has offered help. This goes back to the idea that over-communication is better than under-communication. If there is a real issue, then you and the whole organization will want to have heard about that as soon as possible.

You’ve been at the start up for three months, is that right? I imagine you have a one year cliff for investing so obviously there’s a economic incentive to stick around until that one year mark. You were also only at the Big Tech co for 7 months, so there’s added pressure for you to stick around in your current company.

Is there a way you can make the work that you’re doing more sustainable? I imagine if you’re feeling burnt out, other people are as well. I’m guessing that there’s at least a bit more stability or at least more runway with the Series A capital. 

We have a whole master class about code review! <https://www.jointaro.com/lesson/rhRFh49oouaUDhWUvkQb/masterclass-how-to-do-amazing-code-review/>

The ultimate code review is to actually patch the diff onto your local machine and test it out or think about how you might have written the code differently. Of course, this is prohibitive in terms of time for every code change, but I would recommend doing it initially to get a sense of the project or code.

There is definitely an element of code style, or idiomatic language use in code review, but I find that the best code reviews are about anticipating what might go wrong based on the future direction of the project or future.

Those are great questions to ask. As a starting point, if you're at a startup, the default choice should be to buy, not build. In some cases, it’s not even “buy” because you can use an open source solution.

The reason off-the-shelf is a good default choice is because code is a burden. More code equals more bugs — you want to reduce the surface area of bugs on a product you’re working on.

In addition, at the vast majority of startups, you are not doing anything novel technologically that would merit you needing to build something very unique. So off the shelf solutions are probably sufficient.

Throughout the half I would recommend keeping a job diary to track the main things that you’ve done or impact you’ve landed.

I also recommend having a 1:1 doc with key people who you work with on your team — that’s a good way to jog your memory of what you’ve worked on in collaboration with other people.

In addition to talking to people in the management chain, also talk to senior ICs. You’ll often get more unbiased perspectives from them, since they don’t have as much to gain in terms of growing a fiefdom.

On the topic of “Identifying ‘impactful’ work that matters at the E5 level.” I recommend you simply follow what is recommended by the manager and tech lead in the first few months. You should still ask questions if something doesn’t make sense, but your goal to start is simply to be a good foot soldier and earn trust.

Don’t be in a rush to prematurely lead your own initiatives or projects during your onboarding.

Distribution is as hard, if not harder, than product development. By consistently going viral, the Cluely guys have demonstrated that they are exceptional at distribution.

For a VC, that’s worth a bet to see if they can now quickly iterate and build the product.

I shared this in the other [question that Alex linked](https://www.jointaro.com/question/cgh8KidlZ4x7ob1DGbEj/whats-a-good-example-of-a-11-document-to-help-your-manager-keep-track-of-your-accomplishments/), but the format I used for 1:1s at Meta:

- (1) Top of mind for the report
- (2) Top of mind for the manager
- (3) Discussion topics
- (4) Action items

One practical tip: find a simple, yet non-trivial, application and build it repeatedly. I'm talking about building it 10+ times, to the point where you know which programs to toggle between in order (e.g. Cursor, website A, terminal, website B). 

For example, when I was interviewing for Android dev roles \~8 years ago, I built a simple application 'Flixster' that let users see a list of currently playing movies and then click into the detail view. It had a network call, core UI components, and certain perf optimizations. I built this same app repeatedly, to the point that I could confidently finish within 30 min. 

Not only did this give me a ton of confidence, but I was able to adapt these practical coding skills into many interviews I had.

Here's the SEV review template used at Meta, **DERP**:

- **Detection**: What notified the on-call that the incident is happening?
- **Escalation**: Was the on-call able to respond on their own, or did they need to reach out to other teams?
- **Remediation**: How was the incident specifically addressed?
- **Prevention**: What steps need to be taken to prevent recurrence?

I took this from [this blog post](https://certomodo.io/best-practices/incident-write-ups.html). I also talk about this in the debugging course in the video titled [Understand The Blast Radius](https://www.jointaro.com/course/become-a-debugging-master-and-fix-issues-faster/understand-the-blast-radius/).

If you proactively come up with comms in the DERP format and talk about the learnings, you'll be in a good position! Good luck. 

Yep I think that's totally fine. Purely from a work/productivity standpoint, there are diminishing returns to eating lunch with your team every single day. Not much will change with you or them!

In fact, one of the best engineers I worked with at Meta almost always ate at his desk to continue working. Or he may have skipped lunch since I would often not even see him in the cafeteria...

There's value in eating with them *occasionally* since you understand what they're working on and what they're thinking about, which makes you a better coworker. Especially if you're new, I'd encourage you to hang out with the team. But it's totally fine to eat on your own, esp if you simply go back to your desk.

interesting! this is a very new space so I don't think there are norms around pay yet. DM on Slack and I can share more opportunities or provide some commentary. In a vaccum, $75/hour is reasonable but I've definitely seen the hourly wage for SWE work be much higher, like $150/hour.

**Pros of AI gig work**:

- Flexible, remote-friendly
- Part-time, usually 10-20 hours/week
- Easy to stop anytime, and you won't '*let the team down*'
- Decent hourly income which can be a good supplement to your day job

**Cons of AI gig work**: 

- The work is often not that interesting, just doing some analysis/preference selection. This will change as the tasks become harder/more involved as LLMs get better. 
- Unstable work, hard to predict how long a project will last
- The pay rate is variable
- There's no concept of career progression, you likely won't get much mentorship
- There are no benefits, e.g. an office or health insurance

Is it worth your time? I would say yes if: 

- You have 10+ hours of free time/week and the extra income is interesting for you. 
- You want to understand what goes into training AI models

The main thing to remember about any departure is that you should frame it as an active decision rather than you being the victim of a bad company or manager. I talk about this here: [When To Properly Leave Jobs So Your Career Doesn't Get Punished](https://www.youtube.com/watch?v=RYY3maOhSWI)

However, if you didn't find any engagement in the job, and you even felt it hostile, I think you 100% made the right call!! Your mental health is worth a lot. 

No: employers will usually not expose employees who were laid off for performance reasons. There is no "blacklist" of performance. Not only would that be a really bad look, but **employee performance is contextual**: a strong employee at company A may struggle a lot at company B.

If a reference check happens, the old employer will confirm that you did work at the company, but not reveal that you were PIP'ed or what perf ratings you had.

Two caveats: 

- People form impressions and make assumptions quickly, even if your old employer doesn't officially say anything. e.g. they may make a judgment if you happened to leave a company at a time that perf-based layoffs were announced. So you should be prepared to talk about that: [Interviewing After A PIP](https://www.jointaro.com/course/the-ultimate-performance-improvement-plan-pip-guide/interviewing-after-a-pip/). 
- If there's something deeper to the departure, e.g. expoising trade secrets, that could be revealed. This is more rare, but companies won't be as nice to you in these cases.

I'd default to keep it: exposure to leadership is valuable. **However**, if you go into successive meetings with nothing to say, I think it doesn't add value to either person, or it could even be viewed negatively.

Since it's only 15 min, you should walk into each meeting with something insightful/meaningful to say. You want the old skip to say, "*I gain something from these meetings.*"

> I had a design review with my team, and my manager realized that his idea would not be the best longterm feasible and scalable

This is quite common. The solution that was assumed to be best ends up not being feasible for some reason (either expected or unexpected).

The challenge is that in an internship, you don't have much time to course correct. However, this should not be held against you. You should spend time working with your manager and TL to figure out a new game plan, then figure out how to decompose it to be feasible in your internship.

I believe at Meta, the pay bands for product/infra are still the same. At some companies (e.g. LinkedIn), engineers in the infra org get paid \~10% higher. The reason for this is the adage of **"smart server, dumb client"**: the more sophisticated business logic + complexity is handled on the backend, so therefore there's an assumption that engineers on the backend/infra are solving harder problems.

In terms of where to indicate your preference, choose the one where you'll be a stronger fit. Prefer the team/org that is most obvious based on your past experience.

ps. sorry for the late reply! I didn't see your question until now because we had a bug that hid certain questions from employee accounts :/

Since it's a FAANG company, I assume the 'center of gravity' for the company is in the US. i.e. all the top execs and most of the core decisions are made in the US headquarters. 

In that case, I don't think it's necessary to learn Hebrew. Of course, it's nice to be able to connect socially with them, but I don't think it'll hold you back long-term.

If you were at a Israeli company, it's different. For example, if you're working at ByteDance in the US, and you don't know Chinese, your career growth will likely stagnate beyond a certain point. Since the company is fundamentally non-English, you won't be able to gather connections or context as quickly.

Yes absolutely do it!! Making introductions where both parties can mutually benefit is an enormously powerful way to grow your network and gain huge career advantages. In some ways, this is a big part of the job of a venture capitalist 😅

If they get the job and accept the offer, you've earned two very strong allies in both the person you referred and also the hiring manager. Given that these people are smart (you know this to be true both personally and also on paper), there's very little to lose. But a lot to gain.

also, if you're looking for ways that AI can increase productivity, [here's a nice thread about that](https://www.jointaro.com/question/RCDwXz4X7NReouWFXJNu/how-ai-is-increasing-your-productivity/).

It's great that AI is making you dramatically more productive -- that's what it should do! The question is whether you can be trusted to maintain/debug the code after it's been submitted. This gets to your point about '**i feel like i learnt nothing.**' 

This is why I say [Debugging Is A Premium Skill](https://www.jointaro.com/course/become-a-debugging-master-and-fix-issues-faster/debugging-is-a-premium-skill/) in the debugging course. If I was your tech lead, I'd want to rely on you to explain the code to someone else, and quickly take ownership on the entire lifecycle of the code. 

In the real world, writing the code is step 1:

- Monitor the code as it gets released to production
- Maintain/refactor the code as new requirements come up
- Root cause and fix bugs in the code
- Explain the code to your teammates

If you can't do all of the above, slow down. It might mean your productivity goes from 5x to 2x, but that's still a massive improvement.

Potentially. The cost of interviewing is much higher though: 

- There's a lot more mental energy/stress that goes into interviewing. That time is likely better spent in your day job.
- If you fail, you cannot re-interview for 6+ months. If you do really badly, it may create a negative impression. 

In terms of brand, I actually don't think the gap between Amazon and Capital One is that large. So you're not missing too much in terms of company prestige. I agree with your concern about being stuck at SDE 2 at Amazon for a while.

Compensation is the big missing piece for me here. I assume Capital One pays as much (maybe even more?) than Amazon since it's several levels higher. If that's true, I'm leaning toward **taking the Capital One offer**.

- You'll solidify yourself as a Senior+ candidate
- You'll learn a ton at Capital One and be able to lead projects
- After a few years at Capital One, you'll certainly get another opportunity to join FAANG, and this time you'll certainly be Senior+

Make sure you [negotiate based on the course](https://www.jointaro.com/course/the-insiders-guide-to-negotiating-your-tech-salary-and-compensation/)!

That's a great reply. 

If you truly care about this company, my advice is to learn more about the role and build a relationship with the recruiter. You can still be upfront in your reply to the recruiter that you're not actively considering other roles, but you're still open to learning more.

The benefit of this is that you're more likely to land an interview later if you have a direct relationship with the recruiter.

That's a great reply. If you would seriously consider it in the future, you can consider hopping on a call with the recruiter to deepen your relationship with them. 

This will make it more likely you quickly get the interview when you are ready to revisit the company.

As they say, **misery loves company**. If you feel low, grab a friend or former colleague to work on the job plan together. Talk about what opportunities are interesting, what you're planning to do, and how you feel.

I've found that many job seekers *think* they have a plan, but when they say it out loud, it becomes obvious that they don't really have anything structured. Having a friend (or coach) to talk with will force you to verbalizing your plan, which is extremely valuable. 

Another benefit is the learning you get simply from hearing what the other person is planning. This helps with motivation and also your prioritization.

You should expect technology to change. Avoid becoming too reliant on a specific language or framework. There are nuances to this: 

- I am a gradle build engineer ❌ this is way too narrow, using just one type of build system in Android.
- I am an Android build engineer ❌ this is better since you're not tied to `gradle` but still too narrow since you're only useful to larger Android apps, where build times are painful.
- I am an Android engineer ❌ this is better, but even this is risky if Android apps get vibe coded or get automated by AI.
- I am a mobile engineer 😕 I have higher conviction that some form of mobile software dev will stick around.
- I am a product engineer ✅ Products aren't going away anytime, so if you frame your role as someone who just builds products, you have the ultimate job security.

Instead of thinking about your career 10 years from now, work forward from what you enjoy doing and where you have a unique insight for the next 6 months or year. The world will be very different in 10 years. Tactically, I have two pieces of advice: 

- Focus on the skills that will never go out of style (that's what we built Taro for!). 
- Think about the smartest people you can work with, and just copy them. Learn the tools and languages they're learning. Because they're so smart, you'll automatically work on interesting problems that are valuable to companies.

See also this very relevant video from an Amazon Principal Eng about [**Why It Doesn’t Make Sense To Have a 5 Year Career Plan.**](https://www.jointaro.com/lesson/g0IQZNUqI2oAkyGmF9oq/why-it-doesnt-make-sense-to-have-a-5-year-career-plan/)

> I know it is not great to dwell over a mistake already made, but I am feeling a bit anxious as the midpoint review will be in a few days.

Anxiety often comes from now knowing how you are perceived. Bring this up in your midpoint review.

Talk about how you care a lot about code quality, you write things down, and you felt bad that this mistake slipped through. You might find that your intern manager doesn't think it's a big deal at all, but at least you'll have discussed it!!

As always, refer back to [The Software Engineer Internship Survival Guide](https://www.jointaro.com/course/the-software-engineer-internship-survival-guide/) as you progress :) 

> Do you mean after you do the interview with manager? Or if there is only team for team match just accept that one?

The typical flow for team matching looks like this: 

1. You talk to the manager of a team that has a good match
2. If the manager likes you, the recruiter/company will inform you.
3. If you agree, the company will extend you an offer

You should absolutely do the talk/interview with the manager. There's no reason to turn that down, even if you think the team is a bad fit. 

My broader point is you should get to step 3 as quickly as possible. Worry about the team less and land the full-time employment ASAP.

> Also wanted to ask, when do you negotiate the offer here before or after the team match?

Wait until after the team match. Negotiation should happen only when you've gotten a commitment from the company they want to hire you (see the explainer in my negotiation course: [Negotiation Starts Now](https://www.jointaro.com/course/the-insiders-guide-to-negotiating-your-tech-salary-and-compensation/negotiation-starts-now/)).

If you negotiate aggressively during team match, I see very little upside, but a lot of downside in that you don't get matched. 

> If a company only has one team for team matching & you don't like it, can you just wait for more time?

This is risky and depends on how much you care about this company + what your other options are. As I mentioned in [this discussion about Meta team match](https://www.jointaro.com/question/ctIpEokLUNbLiR86I1hd/how-to-navigate-through-team-matching-with-meta/), I strongly recommend accepting the first team match if possible.

Most good companies will allow high-performing employees to switch between teams, but the hardest part is to get full-time employment in the company. The risk with waiting for other teams is that (1) they may not materialize or (2) the market conditions may change and the company may freeze hiring.

For context, the framework you're referring to is the [LNO framework](https://www.dualoop.com/blog/shreyas-doshi-the-lno-effectiveness-framework) from Shreyas Doshi (I talk about it [in a video as well here](50% Of Engineering Is Now Easy - How To Integrate AI Into Your Workflow)).

I think the problem should not (or cannot) be solved by spending more hours. As a starting point, can you discuss the most high-leverage ways to spend your time, either with a manager or other senior person?

You can share why this new company is a better fit, eg. "I realized that I thrive in larger teams more, where the product directon is more clear and there are really challenging technical problems."

With this framing, you're able to implicitly indicate that your previous company didn't have the right structure for you to succeed, but any issues there wouldn't carry over to the new company.

I started using Notion during the pandemic and it's nice. The main benefit it has over Google docs is that I create a separate page for each day, which gives me more separation rather than an unwieldy doc that eventually becomes 100s of pages.

I also have a saved template in Notion which captures my daily template: 

- Top priorities today
- Meetings today
- Reflections

> Is it true that if you refer too many "bad" candidates, you'll get a bad reputation? What would the consequence of this be and what's the blast radius?

A referral means that you think this person has a chance of being a strong employee at your company -- you are staking your reputation on it. So if you refer someone incompetent (or worse, unethical), you are hurting your reputation.

See also my comments on: [Referring People who Reach out on LinkedIn](https://www.jointaro.com/question/AMSkB3QPYj5Zg2Tw5uND/referring-people-who-reach-out-on-linkedin/)

> What would be considered a "bad" candidate?

this depends on if you missed something that was clearly documented in the job. For example, if the job requires Rust experience, but you refer a bunch of people who have never written Rust, those are bad candidates (even if you think they're smart).

A lot of this is covered in [The Software Engineer Internship Survival Guide,](https://www.jointaro.com/course/the-software-engineer-internship-survival-guide/) which I highly recommend you watch. And we have a dedicated course about the [Meta internship program here](https://www.jointaro.com/course/nail-your-return-offer-as-a-meta-software-engineer-intern/)!

You mentioned that you want to understand the “why” of the project before diving into the “how.” I would **caution against this** --  you could easily spend months just collecting all the context and history about a project and team. You should have an understanding of your team goals, but that can be developed in parallel while you begin doing real work.

In your 2nd week, you should start to be more familiar with the coding workflow. Continue to put out "easy" diffs, but also start to land changes that actually touch some logic.

> How do you balance learning with execution when the ramp-up time is short?

Bias toward execution. You'll get stuck, but the questions you ask will help you ramp up. [Ask Great Questions](https://www.jointaro.com/course/the-software-engineer-internship-survival-guide/ask-great-questions/).

> What’s your favorite way to get a mental model of a new codebase?

- Look at code changes and carefully review the description and test plan. Try to replicate their test plan. 
- Talk to engineers who know what they're talking about to explain their code.
- Pair program with fellow interns or full-time engineers on a well-scoped problem.

Introduce yourself in the #intros channel on the Taro Premium Slack!

Coaching can be really helpful if you feel ambiguity about what to do. The analogy is a professional athlete -- every single top-tier athlete has a coach who gives feedback on what they're doing well and what they should change. 

> What benefits can 1:1 mentorship bring to me vs general resources like Taro?

Sometimes, the value of a coach is simply that you have someone who is checking in on you. The resources on Taro are great, but there's no human component of someone spending an hour with you each week or month. It's easy to ignore the feedback from a video, but much harder to ignore the feedback from a real-life human who is talking directly to you 😅

> What are some points for consideration if I want to get a mentor or not?

Ask them how they typically work with clients, and what they've found effective for someone like you. Talk to others who have worked with them.

> How can I spot a good mentor vs a bad one? How can I quickly tell that they're a good fit for me?

Use a platform like Taro or LinkedIn to see what kind of content they create (e.g. [read their Taro answers](https://www.jointaro.com/p/yogi-sharma/) or LinkedIn posts). If the content resonates with you, that's a good sign. 

> Let's say I have an intro call with mentors. What are some questions I should ask to determine fit?

- What is their background? 
- What does the engagement look like? (cost, time, frequency of meeting)
- What are the common patterns they've observed preventing growth?
- What type of engineer is not a good fit for them?
- What would success look like in the coaching relationship after 3 months? 6 months? 

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. *Rahul will 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 Rahul - Get Personalized Career Advice Privately

Ilya is a Machine Learning Engineer and career coach with over 14 years of experience in tech, including Staff Engineer at Meta, Twitter, and Adobe. 

Throughout his career, he has built large-scale ML systems, led teams, conducted over 100 ML system design interviews, and trained the interviewers and designed ML System Design questions.

Ace The Machine Learning System Design Interview

Florian’s Next.js with Express and TypeScript Course: https://codinginflow.com/nextjs

Florian’s free web development playlist on YouTube: https://www.youtube.com/playlist?list=PLrnPJCHvNZuDG6BWjUFVxeWyYlve_SVJO

React Best Practices - Florian Walther (Coding In Flow)

The Magic Loop of Rapid Career Growth. Taught by Ethan Evans, a former VP at Amazon.

The Growth And Promotion Recipe - Magic Loop

James Pearce is a former Meta Engineering Director, open-source hacker, and sailor.

In his capacity as Head of the Open Source program at Facebook (Meta) from 2013 - 2017, James has deep insight on how to identify promising projects, make contributions, and build strong relationships.

James is currently sailing around the world on his boat!

Become An Open Source Master (James Pearce)

Learn the key strategies for becoming a go-to person in your team as a software engineer and how it can lead to career advancement. Unlock the secrets to getting promoted in tech.

Become A Go-To Person (Jordan Cutler)

James is the founder/CEO of PostHog, a YC-backed product analytics company. What makes a 10x engineer: https://youtu.be/9utyhOMkQGU

James Hawkins (PostHog)

You are being laid off, getting fired, or just want to move on - learn how to get the best package as a part of your transition out of your company.

In this course, Ethan covers topics including the law, termination circumstances, why you should never accept on the spot, how to prepare your case, the mind of the manager, common asks and gives, and if you can sue.

Course link: https://www.jointaro.com/course/maximizing-a-severance-package/

Ethan Evans: Maximizing a Severance Package

In this course, Louie tells you the things your manager wants to tell you, but can't. Either because it would make things awkward, or it would get them in trouble. 

These are things you'd have to learn the hard way. This is the advice Louie wishes he had years ago, that you will get now. This course condenses a year of One on Ones into 1.5 hours.

Timeless Career Advice for Software Engineers

An engineer influencer is an engineer who builds an audience on social media and uses that to kickstart their future startup or business.

The benefits of doing this are massive: meet interesting people, make some money, or start a company. All of these become much more interesting if you have an audience of people who know you and respect you. 

Taught by Michael Lin, ex-Netflix engineer turned engineering consultant and EECS alum at UC Berkeley.

Become An Engineer Influencer

This class contains a systematic, focused process for Managing Up successfully. It covers how to manage up in a variety of situations and to different people such as senior peers and skip level leaders.

Ethan Evans: Managing Up

If I told you that you can get $10,000 with a single email, would you do it? Of course right? Well, that’s what negotiation is, yet so many engineers are afraid to do it.

The Insider's Guide To Negotiating Your Tech Salary And Compensation

Onboarding is the critical period when you first join a new team or company. Use the advice here to learn the codebase and build trust within weeks, not months.

The Complete Onboarding Guide For Software Engineers

Ethan Evans is a retired Amazon Vice President (VP) who now coaches managers to grow into executive roles. 

He became a manager after only six months in an IC role, at a startup in the 90s. He ascended quickly across several startups before taking a "demotion" to be manager when joining Amazon in 2005. Across 15 years at Amazon, Ethan became a VP, a title he held across multiple orgs starting 2013. He left Amazon in 2020.

Ethan Evans: Thriving In Eng Management

I asked every step of the IC engineering ladder a simple question: "What is the most important skill for success at your level?"

The result is an engineer from each of the 7 levels sharing their candid reflections about the most important skill, along with advice. Companies represented: Meta, Slack, Qualcomm, Gusto, Instacart, Cruise, and Pinterest.

Asking 7 Levels Of Engineers The Most Important Skill

In my humble opinion, these are the top 10 resources I have on Taro.

Top 10 - Rahul

The best advice in Taro related to getting more done in less time 🕜

Productivity

The best advice for anyone trying to get to Staff Engineer or higher

Staff Engineer Growth

20 year tech veteran Daniel Tomko (11 years at Microsoft and 8 years at Meta) shares what most engineers get wrong when joining a new team, and what to do instead. 

This is a 4 part series filled with practical insight!