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

Tech Lead @ Robinhood, Meta, Course Hero

Alex Chiou

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!

I personally think it's been okay. It's definitely buggy (my requests randomly fail 2-5% of the time), but I don't think perf has been a huge issue.

I wonder if it's built natively. Maybe it sucks because it's an electron app or something.

Even if it's built natively, Apple's ecosystem does not lend itself well to performance. Things are not performant by default as Apple assumes everyone has the latest and greatest of their hardware. I have learned this the hard way from being in their dev ecosystem for years.

> How should question-asking frequency evolve throughout the internship? I believe it is expected that interns ask very minimal questions during the last 3-4 weeks of the internship, but am not sure.

Question volume generally goes down over the course of the internship, but as I talk about in my question asking course, [the question quality is far more important](https://www.jointaro.com/course/ask-great-questions-that-get-great-answers-quickly/how-you-should-evolve/).

On top of that though, the last 3-4 weeks of the internship are wrap-up, so you shouldn't have too many questions by then unless your execution went poorly.

> How much weight does each performance axis contribute to the overall rating? Is a slightly weaker performance in independence axis still sufficient to justify a return offer assuming strong productivity, coding quality, and communication?

I forget - Do Meta interns have official axes just for them now? I think all 4 of the ones you mentioned are very important with communication probably being the weakest. Independence is *huge* for an intern. The main thing I want to see from a strong E3 is that they don't need to be hand-held all the time. I imagine Meta's for independence is much higher now given the economic climate there.

> Manager notes that my questions have sufficient context, but I struggle to make technical decisions. I frequently approach other peers to confirm the validity of my technical approach. I was wondering if you had any suggestions on how to improve technical decision making.

This is tricky as it's a spectrum. For really hard decisions, it's fine (expected even) for an intern to verify their approach. But for something small like how to name a variable or which class to put code in or whether to make a utility method, I wouldn't expect a Week 5+ intern to still need help on that (it would frankly be a bit annoying and it would hurt their perf packet for sure). At that point, I would expect them to just make the decision and have it get judged in code review.

It seems like you're able to come up with the approach but are being overly cautious about running it by people first. I recommend just writing the diff and seeing what happens. If you get pushback, make a mental note and see if you need to course correct back into the middle. But hopefully your diffs just land smoothly and you save the time you were using before to validate everything beforehand.

> **When** do you typically do this?

As soon as you get the task/project ideally. Of course, you always need to be ready to free-style. Requirements can change all the time, especially at the best tech companies which are fast moving. Another angle is that you realize that you scoped the task incorrectly (e.g. there's this massive edge case I missed and now I need to rearchitect), so you have to go back and rescope.

> **How** do you do it?

Here's an example from the code quality course: <https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/break-it-down/>

I highly recommend this other thread as well: ["How do I make software less overwhelming?"](https://www.jointaro.com/question/YseMPDw538jhyS1MWlTs/how-do-i-make-software-less-overwhelming/)

My general advice is try to envision the code and then break it down into sub-tasks. Each sub-task should be 1 PR ideally (but not the end of the world if it's multiple).

Here's a good related thread: ["Meta product vs Infra role for E5"](https://www.jointaro.com/question/zpFFj7HkEfkMdmmAyWVW/meta-product-vs-infra-role-for-e5/)

I just build side projects: <https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/practical-coding/>

There are other types of practical coding rounds though like debugging, reviewing a pull request, adding unit tests, etc. For these rounds you should [try to get a good read from the recruiter](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/talk-to-your-recruiter/), and tune your studying from there.

In a vacuum, I practice for companies that do these types of interviews by building pieces of their product. Stripe is very tricky, but I would practice for Reddit by trying to rebuild their home feed using their API for example (unless the recruiter told me otherwise).

At the end of the day, if you get the job done well and understand the solution you crafted, you're good to go. Your goal is ultimately to land impact. It doesn't matter if you use AI, no AI, or the wisdom of an incredibly intelligent pigeon who just happens to hang out at your desk.

> How will I show experience in this field to the manager?

You can't right? You mentioned you have never worked in this area?

> Will the behavior interview questions focus on the specific area of interest as well?

I recommend being upfront that you don't have experience in this area (but are eager to learn). Otherwise you will be wasting time fielding these questions you can't answer.

> Is just showing interest in the area enough or expertise is required? This is senior/staff role.

It depends on how picking the hiring manager is. AI ethics & fairness is a team only a big company will have, so I assume you're talking with something in the Big Tech range. At these companies they know that fundamentals are the most important and hope that you can learn on the job. You should play up any experience you have [where you had to adapt to a new domain quickly](https://www.jointaro.com/question/eFr9vsyTSiYLCbtsj7RR/whats-the-most-effective-way-to-switch-domains-in-tech/).

This is a tricky one - Growing pains are always tough in a startup. I remember when we introduced levels at Course Hero, and there was a similar reaction. The hard thing about levels in particular is that a bunch of engineers feel like they are incorrectly leveled during the transition.

The thing about levels though is you 100% need them at some point. As a company gets bigger, you need a standardized path for engineers to move up on, and it's better for the engineers as well as they can make their resumes clearer. It's especially helpful for more senior engineers as "Staff Engineer" looks way better than "Software Engineer" on a resume.

I assume your leadership gave you a long list of reasons on why this move was necessary and the benefits it'll bring. I recommend iterating through those with your teammates as much as possible, doing so in an empathetic way. My communication course has some general advice on how to have those tough conversations: [Effective Communication For Engineers](https://www.jointaro.com/course/effective-communication-for-engineers/)

This is awesome - Congrats on making it so far!

> How would you build trust and gain the respect of these individuals in this case to ultimately have their support for a promotion case?
>
> It also feels a little weird to come up with some artificial way to collaborate just to ask for their support for a promotion, as our day-to-day work rarely intersects.

This is why we have a lesson called "Create Scope" in the L5 -&gt; L6 course: <https://www.jointaro.com/course/grow-from-senior-to-staff-engineer-l5-to-l6/create-scope/>

Is there a way you can expand the scope of your projects so it brings in some of those L6 and L7 engineers?

If you can't do it with core roadmap/feature projects, you can generally do it with overall engineering infrastructure/culture improvement projects like [fine-tuning oncall](https://www.jointaro.com/lesson/esVxIGXYC5BdgxXUkO6H/case-study-revamping-oncall-for-20-instagram-engineers-senior-to-staff-project/), adding more automated tests, refactoring the codebase to use the most modern pattern, etc.

I recommend following the advice from this course as well to really win them over: [Networking Guide: Build Deep Relationships Quickly In Tech](https://www.jointaro.com/course/networking-guide-build-deep-relationships-quickly-in-tech/)

> The title says it all, I wanted to know from the community who are working at meta especially who joined recently if working at Meta is as stressful as quoted in Blind.

I don't read Blind, but they're probably not too far off. A ton of my mentees are still there, and they see new engineers get churned and burned very fast as they can't keep up with the culture. One of my mentees had their organization put a hard ban on external E6 hires as they kept getting PIPed/fired in their first year.

> Which org/team at Seattle/Bellevue have good scope for growth and learning and are relatively more manageable in terms of workload.

Like at any Big Tech company, this depends entirely on your manager/director chain, not the org itself.

> By the way I'm still in team matching phase and have heard that normally it takes 3 months to team match or out of process. Is that true?

Congrats on making it to team matching! Team matching doesn't take 3 months normally unless you are very picky. But I'm unsure what headcount looks like in Seattle/Bellevue. Here's a good thread about team matching in general: ["How to navigate team match interviews?"](https://www.jointaro.com/question/STBturr5E7d8ouq1WHjQ/how-to-navigate-team-match-interviews/)

> Is it possible to take internal transfer to a different country for e.g. to India from US within 3-4 months of joining?

Hard impossible. I think Meta only recently started hiring in India, so the engineering footprint there is very, very small.

Sorry to hear about all this - The job market is brutal right now, particularly for junior engineers. Being in rural America and self-taught means you are truly playing on hard mode.

> What recommendations do you have to speak to this in a way that shows growth?

It's quite hard to spin that PostHog experience. PostHog is a tool, and it's not an industry standard (though it is growing fast). You had a terrible boss. I honestly don't know what to say except to make sure you don't harp on the boss too much (even though they do deserve it). There's general advice on crafting an effective narrative in my behavioral interview course: [Master The Behavioral Interview As A Software Engineer](https://www.jointaro.com/course/master-the-behavioral-interview-as-a-software-engineer/)

> Would you advise to spin up the PostHog screenshots (signups, funnels, etc.) as a small scoped GitHub repo project with the circular economy startup? If so, how?

You don't really need analytics on small projects as in that phase, you're mostly going off of manually collected user feedback and vibes. You should focus as much on writing code (i.e landing pull requests) as possible.

> I am feeling a ton of burnout from job searching - any advice on how to transition from many months in an unemployed state to get positive work experience under my belt?

First, I recommend taking a break, at least 1-2 weeks. [Job searching is a marathon, not a sprint](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/the-1-trait-for-interview-success/), and having an employment gap of 1-2 more weeks on top of several months won't be a huge game changer.

After that, I recommend following the advice here to stand out: ["What can a junior engineer do to gain a competitive advantage in this market and land a better opportunity?"](https://www.jointaro.com/question/nhC9BwESDopIre7mob2l/what-can-a-junior-engineer-do-to-gain-a-competitive-advantage-in-this-market-and-land-a-better-opportunity/)

I'm going to be honest - "Uplevel your thoughts" seems like lazy feedback and isn't very useful **😕**. I'm not entirely sure what do here, so I'll just share some ideas:

1. **Improve your English overall** - I recommend this thread: ["Does anybody have recommendations for English speaking, writing course/coach?](https://www.jointaro.com/question/wHvqb5BNkB6HvhT75XhW/does-anybody-have-recommendations-for-english-speaking-writing-coursecoach/)
2. **Ask for help from other senior engineers** - If they don't have trouble understanding leadership, you should mind meld with them and try to see how their brain works. Take 3-5 communications from leadership that you didn't understand and ask one (or more) of these senior engineers how they interpreted these comms (i.e. how did they translate it into something that's more easily understood). From there, ask them to break down how they broke down the communication mentally word-for-word/sentence-by-sentence.
3. **Use AI** - ChatGPT and LLMs overall are pretty good at this corporate doublespeak-style communication. Put in the communications and ask them to translate into more layman's terms.

Understanding very senior leadership can be tough as execs need to communicate in a more flowery and politically correct way. It can take time getting used to, especially if English isn't your first language as it is for most software engineers.

Here's some other threads that are really helpful:

- ["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/)
- ["How Can Junior/Mid-level Engineers Effectively Integrate AI into Their Coding Workflow?"](https://www.jointaro.com/question/dlsuqOZpW9O2zOjdCUIl/how-can-juniormid-level-engineers-effectively-integrate-ai-into-their-coding-workflow/)

There's 3 separate questions here, *but it really all comes down to experience*.

### Pulling The Data

The first level is your personal experience. If you have worked on task A before and then you get task B which is \~75%+ similar, you know that task B will (probably) take roughly the same amount of the time.

The next level is the experience of others, which is what you'll need to rely on when you're new, either new to a team/company/domain or new to software engineering overall (i.e. you are a junior/early mid-level engineer). This is why it's so important to rope people in early and proactively when you're scoping things out. [For larger projects, this should be some sort of system design doc](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/).

So what if you're a new engineer on a team, and you're the only engineer in your space? (very common in early startups) Then you just have to do things to hard way, trying out a bunch of stuff, messing up estimates greatly, and building out your experience pool through a lot of pain 😅

### Evolving

You can get estimates wrong even with a lot of data - This is very common in Big Tech environments where the sheer scale leads to a ton of natural curveballs. If an estimate ever goes wildly wrong, you should do some reflection, [ideally with some sort of retro meeting for larger projects](https://www.jointaro.com/question/wVpFriUAA32k5hMZK915/how-can-retros-be-more-effective-and-fun/).

Even for smaller interactions like the one you had, [you should ask a ton of followup questions](https://www.jointaro.com/course/ask-great-questions-that-get-great-answers-quickly/learn-to-fish/) and deeply understand why their estimate was so much higher. After you get the reasons (as a tech lead, the most common case for overly aggressive estimates is missed edge cases), ask yourself if you would have been able to come up with those angles yourself or if they were truly something you didn't know at all. Both are common, but I have seen that for many cases, the more junior engineer could have seen what I saw if they had thought harder about all possible flows.

### Learning The Right Way

To make the construction of your "experience bank" effective, I highly recommend following the Lego Model and compartmentalizing all your experience into certain components and patterns: [How The Best Software Engineers Learn A Tech Stack - The Lego Model](https://www.jointaro.com/lesson/9cVK5zsAQstbTCc1wrWx/how-the-best-software-engineers-learn-a-tech-stack-the-lego-model/)

If you don't do this, it'll be hard for you to translate your experience into new projects unless they're exactly the same. If you see the world through distinct legos, you can mix and match pieces to come up with estimates even if a project has something wildly different. For example, if a new project has components A, B, C, D, and E where you have seen A-D but not E, you can do something like this:

1. Make estimates for A-D and sum them up
2. For E, just do a rough ballpark based on vibe and tag on that 50% I've mentioned many times

Yes, E is a wild card, but your estimate is probably \~80% accurate as you identified the 4 other components within your lego kit.

An example of a lego for me as a mobile engineer is this:

1. Have a screen that shows a list of items
2. You pull the items from an API
3. Some collection of features among CRUD are supported (pagination, edit, delete, etc)

I have built this lego 75 trillion times with all the different parameters (i.e. sub-legos), so I know exactly how long it'll take whenever I get any feature/project like this.

### Envision The Code

This is less related to experience, but you should always try to envision the code as much as you can, ideally line-by-line. I give this advice a lot (e.g. [envision how you would write the code yourself when reviewing a teammate's PR and look for the delta](https://www.jointaro.com/course/grow-from-mid-level-to-senior-senior-l4-to-l5/code-review/)), because it's really helpful. Clarity leads to action and higher quality of execution - In this case, it will help you do the estimate as your brain will start hypothetically feeling the difficulty and volume of the code. And if there's some areas where you're like *"Crap, I have 0 idea how this would look"*, then you know to add more buffer to the estimate.

If you like them as people (I would assume so as they're your friends), I think you should just refer them. They have very solid backgrounds.

You seem like a talented person. [If someone is genuinely in your network](https://www.jointaro.com/course/networking-guide-build-deep-relationships-quickly-in-tech/the-1-rule-of-networking/), they are probably also a talented person and are worth referring.

I understand wanting to be prepared, but *for the next 6 months, you should just pretend that other jobs don't exist*.

It's your first role in Big Tech, and Meta is probably the hardest FAANG to survive at. The stack rank percentages are going as high as 20% (!!!) in some orgs nowadays. The people breaking into FAANG are the most vulnerable - Among the engineers at Meta I saw get let go in their first year, 90%+ of them had Meta as their first FAANG company.

By doing incredibly well at Meta, you are going to solve a lot of these job searching and anxiety around job searching problems. If you can establish yourself as a high performer there and work there for 2+ years, you will get way more traction (i.e. inbound) on the job search.

Meta isn't a company where you can flourish using 80%, 90%, or even 95% of your brain. You need to give it 100%, especially if it's your first Big Tech.

Start off by going through the onboarding course: [The Complete Onboarding Guide For Software Engineers](https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/)

After that, I recommend going through the L3 -&gt; L4 course to get a very clear understanding of Meta E4 (Big Tech L4) expectations: [Grow From Junior To Mid-Level Engineer: L3 To L4](https://www.jointaro.com/course/grow-from-junior-to-mid-level-engineer-l3-to-l4/)

> ...how do you explain to a potential employer why you are looking to leave and find a new position?

I think you can be honest and explain that the company was in turmoil, not doing well. Companies fold all the time.

> Would it cost one if one speaks the blatant truth about uncertainty being the reason to leave?

It depends on how you frame it, [particularly in behavioral rounds](https://www.jointaro.com/course/master-the-behavioral-interview-as-a-software-engineer/). One of the biggest purposes of that round is to prevent "Negative Nancies" from getting into the company. It's no fun having a teammate who is constantly complaining about everything (soooooo many engineers are like this). When you talk about this, you don't want to dwell on it for too long, and you should have a respectful, empathetic tone (e.g. say something like *"Due to extreme market conditions, the company was constantly re-organizing itself, and that made it hard for any of the engineers to focus and deliver impact")*. You don't want to get this point across as *"The company did re-orgs, therefore they suck"*.

Zooming out, companies do re-orgs all the time, especially the bigger ones like FAANG. Every company is trying to reposition itself as an AI company, leading to further internal chaos. I would try to stay at the company longer if you can as a 6-month stint looks quite bad on your resume. Re-orgs really are just a part of life in tech.

How does it work for your teammates? When they talk about tasks where they did 95%+ of the work, do they use "We" or "I"? If they use "We", I think it's a fair piece of feedback to maintain the collaborative aura of the team. It's admittedly a bit weird, but I get it. If they use "I", then your teammate is being hypocritical and that is strange.

There might be something deeper here where you'll need to read between the lines a little bit. It's possible this teammate is insinuating that you aren't recognizing them or other teammates who helped you on certain tasks, i.e. you are forgetting the help you received from them.

I would do some introspection here and try to figure out what's going on as objectively as possible. These communication things may seem small, but they do add up over time to meaningfully affect the team's culture and vibe.

> If that is the case, why do we have individual performance reviews?

In a good team, almost everything will be a team effort as it's pretty rare for a task/project to be 100% silo-ed to just 1 person (this was the case at Meta and Robinhood for me). However, managers understand that different engineers will contribute different levels of impact to a project, particularly based on their seniority. This means that credit is usually divided and split for each project. I talk about this more here: <https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/depth-of-contribution/>

Here's some good related threads:

- ["Which AI Agent or Code Editor Best Understands Code Context? (Comparison for Small, Mid-size, and Large Codebases)"](https://www.jointaro.com/question/ePk7jBZxVVdppFiqj2t5/which-ai-agent-or-code-editor-best-understands-code-context-comparison-for-small-mid-size-and-large-codebases/)
- ["What's the best AI coding workflow?"](https://www.jointaro.com/question/hbu2PEeiszeufRKjzNBU/whats-the-best-ai-coding-workflow/)

Honestly, I think you just need to talk to people and try stuff. Different people resonate with different explanation styles, and AI quality varies wildly based on the type of project you have. For example, I know some very good engineers who like Copilot. However, I hate it. Most of its auto-suggestions are useless alongside its AI pull request comments.

For me, I'm old-school and use ChatGPT. 4o is good for most use-cases, and o3 seems to be better at debugging (but is weirdly terrible at some basic use-cases). AI is inherently non-deterministic, so I think people just need to try as many as possible and find their flow.

Cursor and Windsurf are gaining a ton of traction as well.

*Is there a big compensation difference?* "Lead Software Eng" (which I assume is Capital One's Staff level) pays less than Amazon SDE 2, at least in the US. If Amazon pays a lot more than Capital One (+25%) [and you aren't able to negotiate Capital One higher](https://www.jointaro.com/course/the-insiders-guide-to-negotiating-your-tech-salary-and-compensation/), then I'm leaning towards Amazon.

If Amazon doesn't pay a lot more, things get really, really hard. I'm a big believer in work-life balance (WLB), especially for family reasons. Amazon is notorious for stack rank/PIP culture, and [the SDE 2 -&gt; SDE 3 promotion is notoriously difficult](https://www.jointaro.com/question/Tno7LGeINpsTPrljUTTT/how-to-navigate-the-difficult-sde-2-to-sde-3-promotion/). If there isn't really a compensation difference, *I am actually leaning towards Capital One*. On top of the WLB, I think Capital One has more financial upside due to their stock greatly outperforming Amazon's over the past 5 years. As a 2 trillion dollar company that is also susceptible to tariffs, Amazon's stock outlook isn't the best.

This is a bit reductive, but my advice is just try stuff and see what resonates with you. This is pretty much what I did with Android. I had some spare time, and I've always been an Android user alongside my UCLA roommates. We wanted to build some silly apps, so I just did that over the summer and fell in love with it.

I got lucky because Android was the first thing I seriously tried outside of school work (which I really didn't like); most engineers will need to try multiple things before they discover a true passion. What I will say though is that if you truly love something, you'll immediately know. You'll feel it in your gut.

I recommend this video as well: [How To Find Your Path Among The Countless Paths In Tech](https://www.jointaro.com/lesson/9W3PxfplpfwoyXVC6jGt/how-to-find-your-path-among-the-countless-paths-in-tech/)

By US standards, I recommend putting your GPA if it's 3.5 or above.

To set expectations though, GPA is really not that meaningful on a resume. It's effectively a last resort for recruiters to sort through junior engineers who don't have internships. If a hiring manager sees a candidate with a 2.8 GPA and a Google internship vs. a candidate with a 4.0 GPA and no internships, they will hire that first candidate 110% of the time.

I understand that being a Meta is pretty stressful and the market's weird right now, but I think you're overthinking this mistake and doing this long-term will be detrimental. It's easier said than done, but I recommend chilling out, at least a little bit 🙂. All the extra anxiety will cloud your judgment.

Interns continue making mistakes all the time. Even my "Exceeds Expectations" intern at Instagram made some small mistakes here and there up until his final week (maybe 5% of diffs had some silly mistake). Your feedback overall seems to be good, so I really doubt you'll get punished for this.

In terms of addressing this, I don't think you need to bring it up in 1 on 1 as it's pretty minor. A simple reply on the code review of, *"Sorry about that, I forgot to check my pre-diff code quality checklist which covers this* 😅"* should suffice.

I recommend following the language in this course lesson: <https://www.jointaro.com/course/get-more-interviews-write-a-stellar-resume-as-a-software-engineer/resume-gaps/>

The side projects will help, [especially if you get traction on them](https://www.jointaro.com/course/build-side-projects-with-500k-users-coming-up-with-an-idea/). Make sure to highlight those in your narrative to assuage concerns that you are super rusty.

To be 100% honest, I would leave this team. This seems like too many problems to fix, especially as a senior engineer (if you were Staff or Principal, it's different as you would presumably have more power).

The tricky part is that the job market isn't the best right now. Having *any* job right now is tremendously valuable. Maybe you can start off by passively looking (just 2-3 hours per week just applying) and seeing what falls into your lap. If you can find good traction in the job market, then you can dive further in. But if getting a single phone screen is like pulling teeth, then doubling down at your current job and trying to fix things is a more lucrative option.

Here's our overall learning path on finding a new job: [Land Your Dream Job In Tech](https://www.jointaro.com/learning-paths/land-your-dream-job-in-tech/)

> How can I make sure they are implemented?

You have to be diplomatically annoying 🤣

Keep your eye on the ball by regularly checking in and seeing how the tasks are going. If they're on a multiple-week time scale, you should ideally have milestones in mind, and you can use that as a barometer to see if a task has had good progress.

When asking for status updates (especially if it turns out that people are behind), it's critical to have a warm, supportive tone. The failure mode is to come off as a micromanager who is just pushing people. Always offer support, ideally by putting yourself on the line (i.e. offer your own coding firepower if someone is genuinely trying on a task but is behind). Show that you're open to other options to get something done (reduce scope, reprioritize, find other resources).

Here's a good related thread: ["How to influence engineers to hold up their timelines?"](https://www.jointaro.com/question/5HDr6Eb1fw8NBH88yKR2/how-to-influence-engineers-to-hold-up-their-timelines/)

Go for it.

Meta has a culture where it's better to ask for forgiveness rather than permission. [As long as the quality is good](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/), I would personally be extremely happy if my intern did this.

What's done is done - All we can do is move forward. I highly recommend not using services like Formation as they are indeed very expensive, and I think you need to build up your personal foundation first.

I'm sorry that things have been so rough for you. My advice right now is to do some serious introspection and ask yourself if you actually like software engineering. Look back on your entire career so far (both your jobs and your side projects) and ask yourself if there were any moments that genuinely felt fun, where the time just melted away because you were enjoying coding too much.

If there were no such moments, I recommend leaving the industry. It's absolutely brutal for junior engineers like yourself right now, and if you don't have deep passion, you won't be able to conjure up the grit necessary to succeed. You can find happiness outside of tech, and at the end of the day, I just want everybody in the Taro community to be happy.

I just inlined it into my original comment. I assume that's what I got before haha.

> What questions would you ask your manager and team to hit a bulls eye with the information that will be useful for executing deliverables for your project?

You should have gotten some sort of project roadmap as intern managers are required to create one. Are you not able to see it?

When it comes to tactical stuff, you can only frontload so much of it with questions. If you roughly understand what files to change (ideally with a similar example diff to base off of) and how to test the code, you should just jump in and start coding. The exact questions you need to ask will come up [as you're executing and get stuck](https://www.jointaro.com/course/ask-great-questions-that-get-great-answers-quickly/figure-it-out-or-get-help/). More questions will come to mind after you get a ton of code review comments.

Preparing is certainly good, but there's a failure mode where you're stuck in inaction as you try to fully understand everything and have the perfect plan before writing any code. You need to strike a balance between having a plan/clarity going in and going in there and winging it.

Given how detailed and thoughtful you are (which are great instincts to have!), you have probably hit the upper limit on how much you can prepare/learn before jumping into the code. So now I recommend jumping into the code!

> What questions would you ask yourself for clarity of what you should do?

So your goal is just to get diffs out there fast:

1. What's the next diff I need to write?
2. Do I know how to write the diff? (files to change, technical strategy to follow, etc) You should be able to envision the code in your head.
   1. If not, what questions do I need to ask teammates to get clarity on how to write the diff?
3. How do I test this next diff I have to write? In other words, how can I [create an awesome test plan](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/have-a-test-plan/)?

> How do you build trust with your manager and teammates early on?

Have 1 on 1 meetings and put in the effort to show a lot of warmth and energy in them (seed the agenda, take meeting notes, have positive body language, etc). On top of that, follow all the advice in the course here: [Networking Guide: Build Deep Relationships Quickly In Tech](https://www.jointaro.com/course/networking-guide-build-deep-relationships-quickly-in-tech/)

It's 100% okay, but switching teams so early can be logistically difficulty, especially for a SW1. At Meta, it was almost impossible to switch until you had minimum 1 year tenure on your current team.

In terms of working with the toxic senior engineer, the first thing I recommend doing is talking to your junior peers and seeing how they feel about the TL. If they also don't like him, then he's certainly the problem and you either need to jump ship or escalate (i.e. talk to your manager). Check out a similar thread here (I recommend the linked discussions from there too): ["How to work with a non-helpful tech lead?"](https://www.jointaro.com/question/pDt2pAGF8T0SGTdzMP3R/how-to-work-with-a-non-helpful-tech-lead/)

I do recommend spending some amount of time trying to defuse the situation as it's not sustainable to run away whenever a bad teammate appears. There's tons of people like this in Big Tech in particular as it's so political. You will eventually have to learn how to deal with them, or you will be switching teams every 6 months.

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

Yes. The recruiting team will start hating you. If it gets really bad, I can see it escalating to your manager.

> How do referrals in big tech differ from mid-sized companies? I'd imagine the smaller the company, the more your individual reputation matters. Does reputation still matter in big tech?

You'll get punished more for bad referrals the smaller the company is as it's more tightly knit. At Big Tech, many people run referral farms where they openly ask for strangers to refer. These companies are so massive that they don't have the time to keep track of who's funneling in mediocre referrals.

> What would be considered a "bad" candidate? Let's say I refer a friend who passed the resume screen but failed the recruiter screen, would I be liable to sourcing a bad candidate?

It's hard to draw a line, but I think someone who can't pass the recruiter screen isn't great (of course, someone who fails the resume screen is even worse). I would want most people to make it to phone screen at least.

> Can you rank the scenarios in terms of what damages my reputation from most to least:

These are weird scenarios that are almost certainly never going to happen haha. Just refer good people you know and don't worry about this too much. I think #1 and #2 are fine. #3 is stupendously unlikely, but that's more of the hiring committee's fault, not yours.

> He mentions that many candidates would miss int overflow, but what if youre working in python? theres no int overflow or worrying about data types? I'm guessing you would just mention this?

Yep, you would just mention this, demonstrating a mastery of your language.

> Do you just literally list out the edge cases?

The interviewer will generally prompt you in some way to start talking about edge cases (the classic way is asking *"Now what ways can this possibly break?"*). From there, you start going through the edge cases and reacting to the interviewer's responses. Some edge cases are more practical and/or higher-signal to talk about, so a good interviewer will probe you on specific ones.

> Alex mentions Strong Yes candidates ask 80%(\~8+) clarifying questions and 80%(\~8+) edge cases. Wouldnt this take up so much time.

No as:

1. Communication is supposed to take up a lot of time to get signal
2. The coding should be fast
3. Some of the edge cases are just a 2 second mention (e.g. input can be empty, 0, or null)
4. If someone does a "Strong Yes" performance on Question #1, Question #2 is generally graded more lax (i.e. less expectations) so it balances out

> For current economy, is it same for MLEs as well or just SWEs ? This is an MLE role.\
> \
> I am curious how does the offer negotiation work here? I could be in the team-matching for 1 to 1.5 months & get another offer to better negotiate in the end no?

I'm unsure. I would spin this out into separate questions on the forum personally to get more signal.

> Do you know if its hard to switch teams internally at google?

Switching teams now in any company is just weird due to the economic climate, but I'm sure it'll be easier at Google compared to almost any other company in the industry. Historically, Meta and Google have had the best internal mobility cultures in all of Silicon Valley.

It also gets easier if you meet the following criteria:

1. Have been on your team for a while (2+ years)
2. Are a high performer
3. Are L5+ (senior or above)

> On [**levels.fyi**](http://levels.fyi), their Staff matches with other company's senior level. But it seems money-wise their staff-level is more. I am not sure how to match up levels here.

Money is the main measuring stick I use as it's universal. At most companies, their Staff level makes around the same as Meta's mid-level (E4). Levels are just strings next to your name at the end of the day, so I don't think it's worth your time and mental energy trying to "match up" levels.

Here's another good thread about this: ["How should I think about levels when it comes to evaluating jobs and in my career overall?"](https://www.jointaro.com/question/siBFn9WmU204N6D0IRHZ/how-should-i-think-about-levels-when-it-comes-to-evaluating-jobs-and-in-my-career-overall/)

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

You can, but you're taking a risk of staying in team matching hell, which I imagine is more likely given the current economy (too many good candidates, not enough jobs). If a team is semi-decent, I recommend joining. More thoughts here: ["How to navigate through team matching with Meta?"](https://www.jointaro.com/question/ctIpEokLUNbLiR86I1hd/how-to-navigate-through-team-matching-with-meta/)

> Is it like an interview? Do you have prepare for it?

Team match is usually a behavioral interview effectively (but not as intense as a standard one during the onsite), and it can get quite competitive. Google in particular is notorious for having a pool of candidates who have passed hiring committee that is way larger than the number of open roles. Many candidates who passed the interview for Google actually just drop out of contention as they're stuck in team match for 3+ months (this happened to my little brother).

So yeah, you should prepare for these rounds. Understand the hiring manager and their team, and take the time to craft a compelling narrative about why you would be a good fit: [Master The Behavioral Interview As A Software Engineer](https://www.jointaro.com/course/master-the-behavioral-interview-as-a-software-engineer/)

From reading this, I feel like you're working too hard. Your weekends should be yours (at least mostly), and working past midnight isn't great. It's tricky as you need to find the balance between getting more done by spending more time and [getting enough rest that you are functional and doing high-quality work](https://www.jointaro.com/course/maximize-your-productivity-as-a-software-engineer/get-good-sleep/). When spending more hours to get work done, you will eventually hit a point of diminishing returns that even goes into negative as you burn yourself out.

I would introspect on your task load and see what you can drop. Follow the framework here: <https://www.jointaro.com/course/maximize-your-productivity-as-a-software-engineer/finding-the-best-things-to-work-on/>

When it comes to personal life "overhead" tasks, here's what I do (and feel free to mirror if you have the resources):

- **Instacart for grocery delivery** - You can get a free membership for Instacart+ if you have the Chase Sapphire Preferred card. I almost always shop at Walmart in Instacart as they match the in-store prices. You can specify a 3-hour delivery window as well to save $2. Once you stack all of these, the price is very comparable to just going there yourself except you get to save a lot of time.
- **Cook in batches** - I almost always make 4-5 servings of food at once. My wife and I aren't too picky and are okay eating leftovers (i.e. don't need fresh food all the time).
- **Do chores during breaks** - When I can't keep doing work anymore and I need to rest my brain for a bit, I do a chore like vacuuming that is still personally productive but takes very little brainpower.

I imagine this never happens for Big Tech and unicorns unless you're like an L10 engineer at least (Fellow).

Juggling multiple tech stacks is *hard*. Your current array seems very disparate as well since AI development and game development are incredibly specific/niche, being quite different from "traditional" full-stack development.

My recommendation is to focus on the tech stacks where you make money doing them. The job always comes first, and [going deeper on the stack](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/focus-focus-focus/) will increase your quality of work (and hopefully your pay/level as well). When it comes to side projects, this is why I recommend for people to try and marry them together (i.e. if your job requires Stack A, build side projects with Stack A).

If you really need to do other sorts of development outside of your paid work, I would try to use AI to generate as much of the code as possible and then you police it with thorough testing. It's worth going through the code at a high-level to identify any large messy patterns, but I wouldn't spend the effort to understand it line-by-line.

Nobody leaves a job in less than 8 months to pursue greener pastures like entrepreneurship and "AI upskilling" (i.e. opportunistically looking for a positive). I think that response would sound really fishy and has a large chance of hurting you during the interview.

I would simply tell them that it wasn't a good fit (i.e. leaving due to a negative). Check out a similar thread here: ["How do I pursue recruiters if I was fired from my previous job?"](https://www.jointaro.com/question/epp8z0h1YAIPOwwWmWVG/how-do-i-pursue-recruiters-if-i-was-fired-from-my-previous-job/)

Oh my god, this thing is crazy expensive. There is absolutely no way raw content can be worth $1200. System design is also incredibly hard to tech with a standard resource as it varies a lot based on context (your company, tech stack, product space, etc). You can see me struggle to make something generic with [my version of a system design course](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/).

The course mentions that you get 1 on 1 time. I would figure out how many 1 on 1 meetings you get and with whom. That's the main thing you're paying money for I would guess. If you're talking with senior+ FAANG engineers, then I would value it at $250/hour, and you can do the math from there to see if you're getting your money's worth. The course itself is worth $500 max.

Claude has a pretty cool workspace feature that effectively acts as an AI second brain: <https://www.anthropic.com/news/research>

The thing is I really doubt Meta would let you use an LLM that's primarily funded by a core competitor.

My advice for Meta is to always be writing/documenting all the time across tasks, meetings, diff context sections, Workplace posts, etc. Check out this related thread: ["Tips for someone with poor working memory?"](https://www.jointaro.com/question/55fEwxKMxTLMyiurKdBH/tips-for-someone-with-poor-working-memory/)

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.

[Taro Top 10] Understanding Engineering Levels

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

[Taro Top 10] Getting Promoted Faster In Tech

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

[Taro Top 10] System Design

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