You can never ask *any* question (you obviously can't go to anybody and ask *"What's your deepest, darkest secret?"*), but if it makes sense, especially as a tactical question (e.g. *"Can someone explain this part of the codebase to me?"*), you should generally be able to ask it. That course covers tactics you can use to level up the quality of your question to minimize the chance of you losing reputation from it and maximize your chances of getting a good outcome.

Of course, some companies are incredibly toxic and see asking any question as a sign of weakness, and in those scenarios, the best course of action is often unfortunately to leave the company altogether.

Happy to provide more specific thoughts if you share more context - What kinds of questions are you looking to ask?

Tech Lead @ Robinhood, Meta, Course Hero

Alex Chiou

As an SDE 1, focus time and landing commits is super important. On the flip side, you are also not super important to the broader direction/politics in your organization (at least not yet). So can you hack RTO by just booking a solo meeting room for yourself for 2+ hours at a time? Then you just go in there and work. I did this a lot at Meta when my desk area was getting way too crazy.

Anyways, Amazon RTO is so dumb 🫠

Great question! The main factor to consider here is the *intensity* of the change. The thought process here is as follows:

- **Low intensity** - If it's a low intensity cleanup, then you should go ahead and make the change. Some obvious ones are unnecessary lines of code (Meta's codebase was full of these), bad variable/method names, lack of comments on complicated business logic, and flattening control-flows with early returns. These are very non-controversial small wins that don't fundamentally change how the code flows or reads. An example of a low intensity migration from my past is [lambdas from Java 8](https://www.w3schools.com/java/java_lambda.asp). After we added support for Java 8 in Instagram, there was a ton of verbose, old-school anonymous object style code lying around. Whenever I would see those while working on a task, I would migrate it to a lambda as it's a non-controversial change that preserves the overall flow/style of the code.
- **High intensity** - If it's a high intensity cleanup, you need to be wary and more thoughtful about your actions. As I mentioned in the course, if you are making a high intensity change, you should try to follow-through and propagate the change across the entire codebase for consistency's sake. An example of a high intensity change is migrating from [MVC](https://www.geeksforgeeks.org/mvc-model-view-controller-architecture-pattern-in-android-with-example/) to [MVVM](https://www.geeksforgeeks.org/mvvm-model-view-viewmodel-architecture-pattern-in-android/). These 2 coding architecture styles make the code read *entirely* differently as you have a different data flow, component structure, etc. It should be extremely annoying to have a codebase that is half/half as you need to gear your brain differently when reading code in each pattern. It would be like reading a book where the first 50 pages are in English, the next 50 are in Spanish, the next 50 are in English, and the final 50 are in Spanish. It's super disorienting.

I think you have already found the answer: *Remove as many helpers as possible.*

Instead of doing the standard strategy of copy-pasting a 90% similar code sample and then tweaking the parameters, try to write the code from scratch. Whenever your memory fails to produce something from scratch, then you can use some aid (AI, documentation, Googling, looking at another code sample) to unblock you just enough to get you to the next step where you then try again to write the code from scratch.

Another piece of advice I have is to be curious and dig deeper as necessary. Are you running into some bug which you know can be fixed with lines of code XYZ, but you don't actually know what's going on underneath with XYZ that makes it fix the issue? Then go find out! Command + click a bunch and read through the layers and how they harmonize with each other. The tricky part is making sure you don't go to deep and unwrap the entire abstraction (this is death at a company like Amazon). Follow the advice here on striking a balance: ["How to avoid going down the rabbit holes when learning new things?"](https://www.jointaro.com/question/4XLModnvZVwgQYbZEbDD/how-to-avoid-going-down-the-rabbit-holes-when-learning-new-things/)

Your teammates are also correct in that depth takes time and patience. You are just starting your career, so you shouldn't place too much pressure on yourself. It will take an engineer a minimum of 6 months to be regarded as an expert, often 12+, which is usually the case for an SDE 1.

How many years of experience do you have? [Mid-level is a wide-band](https://www.jointaro.com/course/grow-from-mid-level-to-senior-senior-l4-to-l5/how-this-course-works/), and many mid-level engineers have 6+ years of experience. If you're on the higher end of mid-level, I think Oracle Principal is actually fairly reasonable.

Oracle is weird as it doesn't have a Staff level. This means that Oracle Principal = Staff at most companies, and Staff is just 1 level above senior. If you have 6-8 YOE or something, Staff makes a lot of sense.

My inclination is to just go through the loop, and if you don't show Principal-level signals, hopefully they can do the level subtraction (we did this at Meta all the time). If you're on the earlier end of mid-level though, then I would reach out and ask them if they're certain your background is a match for their Principal level. It's indeed possible they simply made a mistake.

I think you've done more than enough - Nice job! You're way more prepared than I was back before I started my first job 🤣

> What should I ask my future teammates?

You can spend 5-10 minutes asking for any educational resources they recommend, but for these early chats before you even start, it's more about building the relationship more than anything. Make small talk, learn about who they are as people (i.e. outside of work), and share a bit about your personal background as well. More thoughts here: <https://www.jointaro.com/course/networking-guide-build-deep-relationships-quickly-in-tech/1-on-1-meetings/>

> My future manager is also a new recruit who’ll be joining in May (but they have 5+ YoE in management exp). What should I ask them if I get the chance to meet them?

It's similar to the teammates - Use these early chats as an ice-breaker. Something specific to managers though is that you can ask them how they prefer to work, specifically how they want their reports to "plug in". Show them that you're flexible and happy to adapt to their style to get the most from your relationship. Here's a great video about mindset: <https://www.jointaro.com/lesson/sIm7s54ILdBQmpCtKFtb/having-the-proper-mentality-for-manager-1-on-1s/>

Here's the unfortunate truth: *There is not much overlap between getting to Staff at Big Tech and making yourself more ready to become a founder.*

I generally recommend that engineers get to senior or at least high mid-level before pursuing a switch into entrepreneurship to have a core bedrock of skills to rely on during the founder journey (technical skills, social skills, fundamental skills, etc). *You are already there.* You'll definitely grow a lot going from LinkedIn senior -&gt; staff, but it's going to be more about navigating the politics behind a massive organization, not how to build your own thing from 0 to 1.

Every year you don't go down the founder path, it gets harder (there is a reason most tech founders are in their early to mid-20s). And every year you stay at Big Tech, it gets harder to leave as you get silver/gold handcuffs, especially as a high-performer. If you know in your soul that you want to become a founder someday and you have a decent financial cushion, you should go down the founder route ASAP.

December 2026 is almost 2 years away. That's a long time.

Here's a good playlist to go through: [\[Taro Top 10\] Entrepreneurship And Tech Startups](https://www.jointaro.com/playlist/ArtlSzF17v7cad1K6TJG/)

Best of luck!

Employment gaps primarily hurt you when you don't have another job lined up as you will be viewed at with skepticism about your rust. If you have an offer lined up, I think having even a 2-3 month gap is okay if you are really burnt out and need the time to unwind.

The main problem with having a big gap is the risk of your offer getting rescinded. It's way easier to cut off an employee before they start compared to after they start, so you should only have a big gap if you really trust the hiring manager and company you have an offer from.

> This data point from interviewing io suggests that meta is hiring aggressively right now...

Oh yeah, Meta is kind of an outlier as they're throwing the entire world at their ads organization 🤣

Gotta get more cash to set on fire for Metaverse and AI development.

It just has the overall time, but here's a data point: <https://www.jointaro.com/question/dIXdt7dq3hcBrMR8SLpm/my-meta-interview-experience-mid-level-e4-or-usa-or-reject-after-follow-up/>

From what I've seen, loops need to move pretty quickly, especially for junior (L3) and mid-level (L4) roles. Just a couple weeks between each round. You can ask for something later, but then you risk the headcount being filled.

For the future, I recommend sharing some data points of your own when starting threads like these, just to get the ball rolling.

An unfortunate angle is that I don't think a ton of people are getting into these FAANG-level loops nowadays. The economy is all weird right now, and in times of uncertainty, companies (especially large publicly traded ones) slash hiring while boosting firing.

Check out the #job-searchers-accountability-group in the Taro Premium Slack! If you're not in it, just shoot us an email at [help@jointaro.com](mailto:help@jointaro.com) and we'll set you up.

It's sort of expected for the product manager to be the face of the product as, well, that's their job. However, that doesn't mean they can just be unappreciative of you. When there are project milestones being announced as complete, is this PM @mentioning you and giving thanks? Or are they just showing the demo and acting like the work just magically appeared?

If they're not giving you any shoutouts, I definitely think you should talk to your manager about this.

Also, I don't know if Apple's culture allows this, but can you just post project wins and updates yourself? At Meta, I would do this all the time. I would polish up some video demo [from one of my test plans](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/have-a-test-plan/) and just share it in big channels.

Good health habits go a long way:

1. Consistent sleep
2. Regular exercise
3. Spending time with loved ones (mental health)

If you sacrifice these to go deeper on the job search (which is very tempting), it's extremely easy to fall into a doom spiral you can't pull out of.

> I do have people In the same boat as me but like surrounding yourself with people who are also struggling to get a job doesnt help because that just reinforces the doom cycle

This depends a lot on people's personality types. Solidarity is important, but you need some people with optimistic personalities to cancel out those who are more pessimistic. If everyone is doom and gloom, you are indeed right in that things just get worse.

I highly recommend this thread as well: ["How to stay motivated during the job search when facing rejections?"](https://www.jointaro.com/question/HerTMFnB5Gg5kUyVzDbe/how-to-stay-motivated-during-the-job-search-when-facing-rejections/?playlistId=SzIOYQ4Ib3lj61jjhX01)

Hang in there!

Unfortunately, a lot of team switches need to happen in secret. The logic is generally this:

- **If you have a good relationship with your manager** - You tell them you want to leave, and in your conversation, make it clear that you appreciate everything they've done for you and have a general *"It's not you, it's me"* vibe. They might even help you coordinate the move (this happened to me at Meta).
- **If you have a not good relationship with your manager** - You need to approach other hiring managers directly and work with them. You will probably have to go through a full interview loop. After you lock in an offer from another team, you just give your 2 weeks notice and vanish into the sunset.

Outside of Google, Meta, and Amazon, I've generally heard that internal team switching is quite hard (Google and Meta don't make you interview again). And in this economy, internal team switches are even harder to come by as companies are being very conservative right now.

The sucky part is that most managers will retaliate against a report they know is trying to leave them as it undermines their power. This is a crappy way of looking at the world, but that's just how it is.

Here's the L4 -&gt; L5 course (will be helpful for behavioral): [Grow From Mid-Level To Senior Engineer: L4 To L5](https://www.jointaro.com/course/grow-from-mid-level-to-senior-senior-l4-to-l5/)

I recommend the DSA course as well: [Master The Data Structures And Algorithms Interview](https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/)

Aside from those, I think you're good on courses as you already mentioned several that would be super helpful.

To go even deeper into behavioral, I recommend this thread about Meta culture: ["How does Meta's culture differ from that of other Big Tech companies?"](https://www.jointaro.com/question/poiwEbI2e6VRFG0xSUCA/how-does-metas-culture-differ-from-that-of-other-big-tech-companies/)

Sorry to hear about the toxicity of your organization - Many people are running into that nowadays unfortunately. There's a lot in your post, so I'll just share a bunch of thoughts:

- **It's okay to fail** - Unless you do something really bad like assault an interviewer, you don't really get hard punished for failing an interview badly. Most companies will have a 6 to 12 month cooldown window, but that's totally fair as you don't want candidates spamming interviews. The main thing on your end is to try and fail the interviews with weaker companies first: <https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/order-matters/>
- **Prioritize getting good reads in interviews** - Make sure to reverse interview folks, so you get signal on how toxic or not the organization is. This seems to be the part main of your post, finding a place where you won't get burned again. Follow the advice starting from here (and probably just take the entire course): <https://www.jointaro.com/course/master-the-behavioral-interview-as-a-software-engineer/interviews-are-a-2-way-street/>
- **Try to keep your job** - It's way better to have a job as a fallback, but I totally understand if you need to leave to focus more on interview prep and get away from a toxic environment. I'm also unsure what notice period means.

Best of luck!

It's easily going to be 2x better at the minimum. Of course, this doesn't mean that it'll become easy (especially in this market). It's important to remember that going from 1/100 to 2/100 is a 2x improvement that is genuinely meaningful (it's an extra dozen interviews after 1200 applications, and many new grads will need to send 1k+ applications).

Notion is one of the best companies out there right now, so you'll have a massive leg up on a huge portion of the competition. Congrats on getting such a great opportunity!

Of course, the ideal outcome is that you just don't need to interview at all due to getting a return offer from Notion. Follow the advice here to do that: [The Software Engineer Internship Survival Guide](https://www.jointaro.com/course/the-software-engineer-internship-survival-guide/)

> Are there any more you suggest?

How can the engineering culture be improved? 😄

> This isn't the tech lead on *my* team specifically.

Ooooh, this is more of a general networking call then. You can zoom out to higher-level and ask about the engineering culture overall.

Some other standard questions:

1. Is there anything I can help you with?
2. What are your favorite and least favorite things about working here?

Least favorite is more important as it ideally exposes a problem you can help fix or at least empathize with.

The main mechanism here to prevent this is [code review](https://www.jointaro.com/lesson/rhRFh49oouaUDhWUvkQb/masterclass-how-to-do-amazing-code-review/). For both of you, you should be submitting [clean pull requests](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/one-diff-one-thesis/) whenever you want to make a code change, and you can even review them together to share knowledge faster.

Another thing you should do is work with them *before* they write a single line of code. When they get a task, you can work with them to write up a detailed plan on how to implement it (i.e. what classes to make/modify, interface design, edge cases to account for, etc).

Overall, you want to take as collaborative a tone here as possible, especially since it seems like they are self-aware that their code has problems. The failure mode is it just feels like you're reprimanding them for bad code, and they shut themselves off from you.

I think your goal, especially as what I assume is an incoming new grad, is mainly to understand the codebase better so you can hit the ground running. Here's some questions I would ask:

1. What are the main components within the codebase and how do they interact with each other?
2. Can you give me some examples of high-quality PRs I can model mine off of?
3. What are the most common mistakes you see from engineers when modifying the codebase?
4. At a high level, what are the biggest problems and weaknesses of the codebase right now?
5. If I want to [share a technical plan with the team](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/lay-out-the-plan/), what's the best way to do so?

After you get answers to all those, you can ask about things like promotion culture and what it takes to become a TL, but I wouldn't worry about those for 2-3 months at least. Onboarding comes first.

A job's a job, and the economy is very rough right now unfortunately. I would try to [negotiate the offer](https://www.jointaro.com/course/the-insiders-guide-to-negotiating-your-tech-salary-and-compensation/), and I think you should be open to taking it if you don't have other offers/final round interviews.

Senior ML Research Engineer is also a great title to have given how the industry is shaping up.

Inbound is inbound. I think you should mute/block them and move on. It's annoying yes, but it's really hard to prevent the derps from reaching out to you without shutting off the funnel altogether.

LinkedIn is an unfortunate evil, because it's just so big and has a near monopoly on the job searching space. Due to its size, it's bound to have a lot of derpy people. I remember back when I was at Meta, I had recruiters reaching out to me asking if I wanted to make $100k - $150k working at Meta *as a contractor.* The sheer stupidity of these recruiters was absolutely mind-boggling (literally would have taken them just 10 seconds to realize it was a dumb idea), but that's just how LinkedIn is.

I really like this comment. Very empathetic 😊

Forgot to mention: I'm not a huge fan of React Native: [Android (Kotlin) vs. React Native](https://www.jointaro.com/question/KUeUaVRfcjrnjGDcFuZC/android-kotlin-vs-react-native/)

If your goal is to build something purely to get something out into the world, cross-platform makes sense. But if you want to parlay side project experience into a real job someday, native is better.

I have a different take in that I don't think specific technical realms are the way to go (everything you mentioned is just important all the time, especially at more senior levels and at higher-level companies).

When it comes to technical skills, there are 2 broad areas I think SWEs will need to get even better in:

1. **AI workflow integration** - If you aren't using AI in your workflow, you're going to get left behind. However, the big question is *how* you use it. When using AI poorly, you become a worse engineer as it makes you dumber and write crappier code. However, if you are thoughtful with AI, using it in the right places and carefully looking over its output, it will upgrade you from a good to great engineer. What I've seen is that AI is distinctly human here. If you are lazy and ask low quality questions, you tend to get a low quality answer. But if you ask a high-quality question that is loaded with rich context and you do the proper follow-ups (i.e. what I talk about for [2+ hours in my question asking course](https://www.jointaro.com/course/ask-great-questions-that-get-great-answers-quickly/)), AI can both make you do stuff faster and learn more while doing so.
2. **Debugging** - Debugging has always been an underrated skill as many engineers are frankly lazy and don't want to spend time digging, preferring to mindlessly hammer out new features instead. Debugging is especially important now for 2 reasons:
   1. **AI code is riddled with bugs** - A lot of the senior+ engineers' job will be to clean up the terrible, messy AI code of junior engineers.
   2. **AI sucks at debugging** - Of course, AI can debug, but only with relatively simple tasks. Whenever I throw a bug at it that is a Meta E4 equivalent (FAANG mid-level) in technical complexity, AI is completely useless, a time-waster even as it endlessly hallucinates. This is because debugging is fundamentally a deeper engineering skill that requires a broader contextual understanding of the entire codebase.

I *highly* recommend this thread: ["How to balance interview prep with a job?"](https://www.jointaro.com/question/fob1V9LjohGiwRIn8Uvd/how-to-balance-interview-prep-with-a-job/)

Some other thoughts from me:

1. **Try reducing to just 1 stack** - Can you go after just 1 of front-end or back-end instead? As a mid-level engineer, it's better to have focus.
2. **Don't study (yet)** - Are you drowning in interview opportunities? If not, I recommend playing it more by ear and focusing on applying. A common failure mode I've seen from engineers is they preemptively study a bunch of stuff they never actually use.

I recommend the overall job searching course too: [Ace Your Tech Interview And Get A Job As A Software Engineer](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/)

For creating the engineering plan, I recommend this: [System Design Masterclass: Shipping Real Features To Production](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)

If this is too heavy (likely given that you are E3), they are probably looking for the more local version which is having very detailed tasks. Here's an example from the code quality course: <https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/lay-out-the-plan/>

> Also, our team roadmapping is upcoming, how can I contribute to the team roadmap as an E4?

My expectation for an E4 in those meetings is to have *some* sort of opinion. I don't expect them to drive any part of those meetings, but if they are a leading voice on certain projects, that's obviously nice. 2 things to have an opinion on:

1. Project ideas to add to the roadmap
2. Arguments for or against a project already on the roadmap (presented diplomatically of course)

Meta has always paid more than the other FAANG companies. That being said, I really doubt this is happening today unless you are a rockstar intern (Greatly Exceeds) with 3+ other FAANG-level offers.

> I wonder if having successful side mobile apps projects could lead to mobile development related opportunities...

It definitely can as I'm living proof of it. I went to Course Hero as their Android lead with only side projects under my belt. Back at PayPal, I was a Java back-end developer.

However, your case is different from mine as you're a senior engineer already. I was still junior when I joined Course Hero (just did 1 year at PayPal as my sole work experience). I recommend sticking with web unless you don't like it and are looking for a switch.

Being front-end overall is better for side projects as you are closer to the user interface. On web, you also get the immense power of SEO, making your ceiling higher (though the floor is admittedly lower): <https://www.jointaro.com/course/build-side-projects-with-500k-users-shipping-and-growing/seo/>

And yes, just build stuff people love at the end of the day 😁

> Do you have any advice in particular regarding how to best work with a staff-level IM, as he is so many levels above me? I imagine many of the advice would be similar to what is mentioned in the Internship Success course, but anything in particular to keep in mind?

You absolutely need to [diversify your mentors](https://www.jointaro.com/course/the-software-engineer-internship-survival-guide/diversify-your-mentors/). A lot of Meta intern managers unfortunately leave the interns to fend for themselves, sometimes intentionally, often unintentionally. I would be very surprised if an E6 carved out a lot of time for you to review diffs quickly, answer questions, do project planning, etc.

Dang, you make $400k as a FAANG mid-level? Congrats.

> How would you recommend I find clients / contracting projects?

There's a lot of websites out there that pair talent with clients. Here's one I've gotten so many ads for: <https://gun.io/>

I'm surprised you have meaningful spare time outside of work though if you work at a FAANG-level company 😯.

It's true that most IMs are E4, but I wouldn't say the average is an E4 who's close to E5 promo. More in the middle and maybe even before E4.5. I actually call out why mid-level is a good sweet spot to take an intern here: <https://www.jointaro.com/course/grow-from-mid-level-to-senior-senior-l4-to-l5/mentorship/>

When it comes to levels, the dynamic is like this:

1. **E3** - Probably not strong enough to mentor another engineer yet. A strong E3 could probably do it though (i.e. an E3 who has already been operating at E4 for 2-3 months and [is waiting for lagging promo](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/underleveled-its-a-feature-not-a-bug/))
2. **E4** - Strong enough to mentor an intern, and the PSC credit is decent
3. **E5** - Can certainly raise an intern but PSC ROI is dubious
4. **E6+** - Intern raising credit is nothing by E6+ PSC standards. They would literally only do this out of the kindness of their heart. Ironically, they might be a terrible mentor anyways as they are so many levels above the intern

> ...I just received an email to schedule the next round of interviews.

Yooo, congrats!!!

> Maybe just keep the message short and simple...

Yep! The more general message still opens up room for them to share specifics if they're comfortable while not prying for them directly.

Meta is very paranoid about leaks and is going more and more towards a culture of secrecy nowadays.

> *If possible, could you share what technologies the team primarily works with? I understand that Meta’s technology is largely custom and internal, but if there is anything I can do to prepare for my internship, please let me know.*

You could, but adding more specifics just increases the cognitive load of your message and it just makes it more awkward as the IM is now worried about accidentally leaking something. I think you should just keep it simple.

Don't overthink this, and keep expectations low.

There are 2 main areas of growth:

1. Revenue (duh)
2. Traffic + growth (might be irrelevant if the company is pure B2B)

I would just ask about both. Headcount growth is a big signal for sure, but if they're hiring too aggressively and don't have the growth to back it up, that's actually an anti-signal. In 2025, it's probably better to have your growth be more sustainable overall. Unless you're a super hot AI startup, raising money is not a guarantee.

Here's some other good resources:

- ["How to evaluate a startup?"](https://www.jointaro.com/question/UCG4XxyEOTjjyg4pEuwY/how-to-evaluate-a-startup/)
- ["Best websites to help evaluate startup offers?"](https://www.jointaro.com/question/gqsJsWyd1c7DMp6pwucX/best-websites-to-help-evaluate-startup-offers/)

> What do I do if I meet my previous co-workers that know I was laid off in the future in a couple of years?

It's quite unlikely, so I wouldn't worry too much about it.

If it somehow does, hopefully you have leveled up so much that they won't even care about the person you once were.

Trump just announced a 90-day pause on the tariffs, so idk wtf is going on anymore...

Ugh, everything is so unpredictable now. One day it's this, one day it's that, another day it's potato.

This video perfectly sums up the economy right now: <https://www.youtube.com/watch?v=2hshkdneE8o>

What I do know is that companies tend go conservative turtle-mode in times of economic uncertainty, so expect a lot more layoffs, stack ranking, PIPs, constrained hiring, etc. Be an engineer [that does great work](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/), has a deep network [full of people willing to fight for them](https://www.jointaro.com/lesson/QYQHPiYqZvBzuQw1Vjnc/supercharge-your-professional-networking-by-leading-with-kindness/), and [takes care of their loved ones](https://www.jointaro.com/question/wpPPjI1gZtM5eNaCxlB0/how-to-keep-my-mental-health-while-working-in-a-competitive-team-and-having-kids/?playlistId=JNCZ1vbRF3NwsOQCqblt).

If you truly don't have anything tactical to talk about (i.e. you are crushing onboarding and you 100% understand the workflow now), you can use the 1 on 1s purely to build the relationship and further understand big picture.

Being a founder is really stressful, so it's probably valuable for them to talk through the challenges with you, both to think out loud and maybe vent a little. Just ask them how things are going and what's the biggest challenge they're facing right now. A fun UXR question that could work here is: *"What's the biggest thing keeping you up at night?"*

This can also be an opportunity where you flip the dynamic. Instead of having this be a meeting where you extract value (i.e. ask questions on how to do stuff), make it an opportunity for you to [proactively surface product/project ideas you came up with](https://www.jointaro.com/playlist/EWIo3USNcsgXbCs5PS0h/) that are relatively fleshed out, derived from your solid understanding of the company's product. This is the kind of stuff that you should be doing at startups that you can't really do at FAANG (it's possible there but just so, so, so hard). If you do this, you will be providing value instead of extracting value.

A good startup will value truly independent, proactive thinkers who are taking the initiative to bolster the company. That's how the best startups thrive.

> Is it appropriate to ask for more details about the intern project at this stage, or should my ask be limited to just the team's overall focus and what they do?

No, you don't work at the company yet, so it's risky for anybody to share anything internal with you. It's possible that you will reneg on the intern offer - Nothing is certain until you actually start working at the company. It's very unlikely you can specifically prepare for the intern project anyways as it's almost certainly going to be niche and specific to Meta.

The best outcome you can get here is *"Maybe go through this generic TypeScript tutorial to sharpen your fundamentals"*.

This email feels too fluffy and is asking for too much IMHO. I would tweak everything after the 2nd paragraph to look more like this:

> I'll cut straight to the chase: I want to be as impactful as possible for your team and hit the ground running. I understand that Meta's technology is largely custom and internal, but if there's anything I can do to prepare for my internship, please let me know.
>
> Thank you for your time, and I'm excited to build cool stuff with you!

When it comes to all communication overall, you should always be thinking about incentives. Intern managers get rewarded the more productive their interns are, and I think the above messaging cuts straight to that in a more plain + efficient way.

I'll talk more about incentive alignment in my upcoming networking course. Deep empathy solves many problems 😄

> Thinking aloud, what about potentially taking up some freelance work?

It's far better than nothing - This is a good thinking aloud thought 🙂.

If you can't get anything else, might as well. In general, it's good to always be coding, especially if you aren't getting interviews. When it comes to the job search, the prep is more time-intensive than the applying, and if the applying isn't working, you can't really prep. So might as well use the time building cool stuff.

> Do you have any advice on other approaches to get more interviews? (outside of warm referrals, as I am wanting to use those strategically)

Given this clusterf\*ck of an economy, it's just the same old advice but like... more:

1. 10x the size of your side project
2. Do more networking to meet people, produce additional warm referrals
3. Become an open-source hero
4. Get big on LinkedIn

Everything here is long-tail. All the short-tail stuff is exhausted as enough talented, laid-off engineers are also doing them.

Congrats on making it to the final round at Google! What level are you? The breakdown is:

- **L3/L4** - I think it's entirely LeetCode with 1 behavioral.
- **L5+** - 1 LeetCode gets swapped out with system design.

You can find all the interview related courses here: [Land Your Dream Job In Tech](https://www.jointaro.com/learning-paths/land-your-dream-job-in-tech/)

Your biggest ROI will probably come from focusing on data structures and algorithms (DSA). Go through this: [Master The Data Structures And Algorithms Interview](https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/)

Since you passed the screening round, I imagine you have some DSA expertise already, and now you just need to refine it so it meets the FAANG final bar (that's what the above course helps you with).

Argh, this is such an anti-pattern, sorry to hear that. For that small bit of automation, can you super highlight that and make it seem like it's most of your job?

You'll probably need to shrink your first work experience so the 2nd and 3rd shine through more and are likely even bigger blurbs. This is the opposite of what you should do ideally (i.e. get better jobs over time), but you don't have much optionality here.

Regardless, if you have done some automation, I recommend changing your branding with the suggestions above title-wise if you haven't already.

> Is there maybe a way I can list the project under work experience but kind of say that its not a paid gig?

This is awkward and slightly dishonest IMHO. I wouldn't do it.

Congrats on building such an impressive side project though! 4k MAU is solid, and with 800+ commits, you clearly put a lot of effort into it.

Another thing I recommend doing with this side project (especially since you have traction) is to build in public and talk about it on LinkedIn.

Work experience is king 👑, so it's better to optimize those. If I had to put a number on it, it's 2x - 5x more valuable than building a side project. This means that if your work made you build a feature with 100k users, it's 2 to 5 times more impressive than building a side project with 100k users. This is why side projects are particularly relevant for the many junior engineers who have effectively 0 work experience (and there will be even more of these folks in this market sadly).

Your situation is very different as you have 3 existing blurbs of work experience. Your time is best spent on how to optimize those. For your current job, can you spin it so it doesn't come off as too QA-ey?

QA is a huge spectrum:

- **Primitive** - Manual QA. Literally just getting spreadsheets of test cases and clicking through things manually. Not only is this draining work that doesn't teach you much, it's not respected by hiring managers. You can put "QA Engineer" on your resume, but most won't consider you an engineer.
- **Advanced** - Automation. You are writing infrastructure like CI/CD pipelines and integration testing frameworks, using code to assure the quality of a product at scale. At Meta, there are many engineers who do this, and they aren't called QA engineers. They are software engineers just like I was back at Meta, because they are building meaningful, complex, important software that just happens to be laser-focused on quality.

Many QA engineers fall somewhere in between. As long as you aren't entirely on the primitive, manual side, you can highlight the automation you did and make yourself seem more like a proper software engineer.

You can even change your job title:

> QA Engineer -&gt; Quality Infrastructure Engineer
>
> QA Engineer -&gt; Automation Engineer

I can chime in here having grown up in Silicon Valley, and my dad is literally a software engineer as well who retired around 60 who knows a *bunch* of other software engineers who are 50+.

> It seems like there aren’t a ton of older engineers (say, past their 50's) in hands-on SWE roles...

This is actually not the case from what I've seen. The reason you might perceive this is because older folks tend to work at companies that young people tend to avoid. Also, there are simply far more young software engineers than older software engineers as the tech boom really started in the early 2010s with the rise of FAANG. Before, we didn't have $1 trillion market cap companies and the dot-com bust also forced many older software engineers to leave the entire industry (many younger folks don't understand how bad 2000 was).

> I’d love to hear if anyone has seen or heard of successful transitions out of tech.

For the Bay Area in particular, a *very* common exit is to go into real estate. I know so many engineers like my dad who bought Bay Area homes after the 2008 recession and are now just property managers for a living.

Unfortunately, I don't think this can be really replicated now as Bay Area homes are stupidly expensive due to the software boom starting in the early 2010s and limited housing supply.

I'm going to be honest: I forget that Anduril exists sometimes 😅. I do think that the defense space is more niche.

I'm leaning towards Meta, especially given the market. But at the end of the day, it's hard to put a price on learning and fun. If you really connected with the hiring team at Anduril and think you'll have learning and fun in spades there, I think Anduril is a good call. It's not the hottest unicorn, but if you can get 2+ years in, I think you'll be decently positioned in the job market.

Sorry to hear about the layoff without PIP - That's a very Meta thing to happen. Getting GEE in your first PSC and speed-running the E5 promotion is extremely impressive: *You should be super proud of that!*

In short, don't let this experience get to you. It didn't happen because you were a bad engineer; it happened due to circumstances outside of your control. Check out this related thread: ["Success story after PIP?"](https://www.jointaro.com/question/RHzlgI5QE4JD6qUtBI00/success-story-after-pip/)

Meta E5 maps to Staff at the vast majority of companies as the Meta bar is so high. Put the past behind you and keep your head high - You are a new person now! I recommend following the advice from the senior to staff course: [Grow From Senior To Staff Engineer: L5 To L6](https://www.jointaro.com/course/grow-from-senior-to-staff-engineer-l5-to-l6/)

The mid-level to senior course is also a good refresher (again, FAANG senior maps to staff at most companies): [Grow From Mid-Level To Senior Engineer: L4 To L5](https://www.jointaro.com/course/grow-from-mid-level-to-senior-senior-l4-to-l5/)

As a new staff engineer, your priority is to show that you can build relationships and context quickly. Be the friendliest face in the office and talk to as many people as possible. See how you can help and think in terms of multiplicative impact.

Lastly, congrats on the 2 offers! Most engineers can't even get 1 offer in the current market.

Those seem... fine? It's hard to tell without additional context. With behavioral interviews, it's more about behavior than impact (though impact is important too). FAANG understands that many candidates haven't worked with gigantic impact as they have never worked for Big Tech before - In those cases, they are looking more for behavior.

In terms of what behavior to show, I recommend going through the project credit section of the promotion course: <https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/its-not-just-about-impact/>

Here are ways a bug can be more impressive outside of impact (largely expanding on what Helpful Tarodactyl said as they are correct):

- **Hard to repro** - Points for technical complexity
- **Outside of your team's immediate codebase** - Points for organizational complexity and expanding your scope
- **Low observability** - You need to make a lot of smart, educated guesses instead of simply following the logs
- **Performance related** - In other words, the bug isn't purely binary of feature clearly works or doesn't work and is more like *"The feature works, but it has 1 extra second of delay that is very noticeable"*

Helpful Tarodactyl's advice is spot-on, and their linked resources are very good.

In a nutshell, your goal is to talk to more people and write more stuff down. I need to modernize this course, but it still has a good example on what a good planning doc looks like: [System Design Masterclass: Shipping Real Features To Production](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)

> Also, how can I politely ask to schedule the interview further in advance to give myself more time to prepare, without making a bad impression?

I think you need a week max. New grad positions fill up *fast*. You don't need that much time to prepare for these rounds.

Once you pass this round, then you can think about spacing rounds out for preparation. But in the meantime, don't worry about this.

This is almost certainly a light behavioral-style round: <https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/recruiter-screen/>

It's possible that the call is purely tactical and all they do is rattle off the logistics over a call, but it's probably best to do some behavioral interview prep anyways. Go through the behavioral interview course: [Master The Behavioral Interview As A Software Engineer](https://www.jointaro.com/course/master-the-behavioral-interview-as-a-software-engineer/)

I think given your context, it's not likely you can fail this round, but I wouldn't count on that. I have seen a ton of engineers fail supposedly "freebie" recruiter screens. Play it safe and go through the course.

The EU is also considering a digital tariff where if a EU company buys Google search ads for instance, there would be a tax placed on it.

Almost certainly yes. In the past 1.5 months alone, Meta has shed around $500 billion in market cap, and it will likely keep shrinking alongside the rest of the US economy.

Make sure to really follow the advice from the intern course: [The Software Engineer Internship Survival Guide](https://www.jointaro.com/course/the-software-engineer-internship-survival-guide/)

Even in 2023, there were still some return offers. It was only for rockstar interns (Top 5%), but that's better than 0.

Zooming out outside of the internship, this is why it's still important (and more so now) to do things like networking (make a ton of friends during your internship!), side projects, open-source, etc. You need every possible advantage you can get.

First, try [Cursor](https://www.cursor.com/en) if you're a VSCode developer. What you mentioned about Copilot matches what I've heard. It can be helpful-ish here and there, but it struggles with a bunch of stuff. Cursor is a step function more powerful, lending far more assistance with higher accuracy. AI is woven in everywhere as they forked VSCode and rebuilt it from the ground up with AI in mind.

As for using AI to bolster your workflow, it's tricky. AI has a ton of nuance in how it should be applied, and I think a lot of an engineer's value nowadays is knowing when vs. when not to use it. I use ChatGPT a lot to expedite writing code I already mostly know how to write. However, I've learned that it's pretty terrible for any feature that's more niche with higher technical complexity and it's particularly terrible at debugging tough issues.

Check out this thread too: ["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/)

> Thank you for the thoughts. With this all in mind, would you recommend that I leave at all? Or would staying be better at this point?

Totally depends on you! The market is rough right now, so a job search would definitely be *very stressful*. So if you have the patience for that and want to take some risk, by all means, go for it.

But if you're looking to take it easy for a bit after a hard-fought promotion, just chilling (well, as much as you can in this economy) and waiting 6 months to see where your head is at then is also totally a valid option.

In general, if you are happy with your current team (good pay, supportive manager + teammates, fulfilling work), I recommend that people stay and squeeze as much juice from that fruit as possible. It's a bit grim, but 90%+ of teams get worse over time (awesome manager leaves, weird reorg, layoffs, etc). It is very, very, *very* rare for teams to get better over a long-term horizon.

Great question! If the company is reasonable, they shouldn't hold you responsible for impact since you're a junior engineer as I talk about in-depth here: <https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/impact/>

For junior engineers in particular, it's more about quality of execution as the onus is on your tech lead/engineering manager/product manager to give you projects with meaningful purpose.

> This example is a minor example as it only involved a few days. What if it was months instead?

Yeah... This is the painful one. Again, you shouldn't be punished for this as a junior engineer in performance review if the company is reasonable, but working on big projects that flopped has broader implications:

1. It means your entire team is probably struggling
2. It's rough for your resume if you worked on a bunch of stuff that died, especially if they never even launched (i.e. development hell)

This happened a lot at Meta, and the main way to get credit for it (very important at senior/staff and beyond) *is to extract and formalize as much learning as possible*. When we had a big workstream that failed, we would always write a long note (effectively an essay/paper) eloquently covering what we did, what we learned, and *how this should all affect our product direction going forward*. In other words, we needed to make a case that while this failed project obviously didn't have immediate impact, it will bring *delayed impact*.

3 YOE to get senior will be tough, especially at a top-tier company like Notion that will use FAANG standards for leveling. You can certainly try but keep expectations low. The cutoff for senior is usually 5 years, sometimes 4, as I talk about in my mid-level to senior course here: <https://www.jointaro.com/course/grow-from-mid-level-to-senior-senior-l4-to-l5/how-this-course-works/>

In terms of when to leave, I would actually try to leave earlier rather than later. The failure mode here is that you don't want to get 50%+ of the way to senior (very doable within 1 to 1.5 years) and then struggle to leave as you don't want to lose that progress. I think you can even start applying right now (it'll take you minimum 3 months to start a new job anyways, especially in this market).

Here's the job searching learning path: [Land Your Dream Job In Tech](https://www.jointaro.com/learning-paths/land-your-dream-job-in-tech/)

Lastly, congrats on the promo!

I lean towards keeping it simple and not bolding anything within my experience (I just use bold for section-ing).

If you were to bold things, I would keep it minimal. If I were to throw a number out there, I would do 5 bolds max across the entire resume.

In terms of what to bold, it's simply your most impressive pieces, ideally metrics.

I like the idea, but situations like these are *incredibly* rare. It's simply too complicated:

1. You need to keep track of the value added percentage dynamically as that's certainly going to change month-to-month, year-to-year
2. If you want to be exposed to upside, it's only fair to be exposed to downside as well. Let's say you cause a bug that loses the company $100k or even $1M (I saw this happen all the time at Meta). Would you be okay having your salary drop by 2% of that?
3. It's unfair to have these deals as many employees work on something that is more than 1-step away from direct revenue (e.g. infra, internal tools, process/culture improvements)

\#3 is a big one as that's how every company eventually functions where you have a core group that is directly connected to $$$ and a bunch of groups that support that group. At Instagram for example, I worked on ads. I shipped multiple products that made $10M+ per year, but I didn't get a $100k+ raise every time. That's because those ads wouldn't be able to make money without all the people working on the organic app, build infra, ad testing tools, UI framework, etc.

Anyways, good luck getting a great full-time offer! The negotiation course is here for easy access 😉: [The Insider's Guide To Negotiating Your Tech Salary And Compensation](https://www.jointaro.com/course/the-insiders-guide-to-negotiating-your-tech-salary-and-compensation/)

> I see for mid level roles they have a system design round, how would that be different from the ones for senior level. I find that system design is really wide. Wanted to understand for a mid level role interview how much is required

My bar for mid-level is if they can just do a non-embarrassing system design at all. It's tricky to quantify as system design is inherently quite fuzzy. This should shed some color on what senior looks like: ["What is the difference between a Senior and Staff engineer in a System Design Interview?"](https://www.jointaro.com/question/5TaZMBhgxvdsKMoQ7qWi/what-is-the-difference-between-a-senior-and-staff-engineer-in-a-system-design-interview/)

I recommend the technical part of the L4 -&gt; L5 course as well: [Grow From Mid-Level To Senior Engineer: L4 To L5](https://www.jointaro.com/course/grow-from-mid-level-to-senior-senior-l4-to-l5/)

Unfortunately, a lot of timeline crafting is trial-and-error. As an E3, you are going to mess this up *a lot*. In a vacuum, I recommend just blindly tacking on 50% to whatever initial deadline you come up, so 2 weeks would become 3 for example. I have mentored so many E3s and I have literally never seen them overestimate a task, only underestimate 😅

So to sum up all the tactics of getting better at estimations:

1. Learn from your mistakes
2. Get feedback from other people on your team (cc people on docs aggressively and hold technical review meetings as a forcing function)
3. Don't be afraid to go outside of your team as many projects, especially at Meta, span across multiple teams' services
4. *Write stuff down as detailed as you can.* Clarity brings accuracy. Try to make docs as high quality as these: [System Design Masterclass: Shipping Real Features To Production](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)
5. Really scope out the "extra stuff". This is including (but not limited to): [Edge cases](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/sweat-the-details-call-out-edge-cases/), analytics, experimentation details, XFN alignment, security, privacy, legal

Another thing: Yes, it sucks to miss a deadline, but there's layers to it, particularly with proactivity and earliness. If you have a 4 week project and realize after just 1 week that it's a 6 week project, that isn't too bad. However, if you realize in Week 3 that you're going to be late, that's awful. Break all your estimations down into as many milestones as possible, so you can quickly realize when things are off-track.

This is truly trial by fire, but one of the best things you can do (if you believe in the company) is convince the startup to hire another engineer. You can split your work into distinct categories of proposed ownership and then eloquently describe to your boss what another engineer would do for 40+ hours a week. From there, hope they make the budget for it.

fwiw, I would *never* expect an intern of all people to do this, so only try it if you're feeling incredibly bold haha. This is Staff Engineer behavior.

FAANG hiring has unfortunately always been *extremely* elitist. Even if you pass the interview, [they often brutally downlevel you](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/dont-get-downleveled/). If you don't have that existing prestigious background for junior/mid-level roles, you generally need to do some crazy heroics like [making a side project with 10k+ or even 100k+ users](https://www.jointaro.com/course/build-side-projects-with-500k-users-shipping-and-growing/) just to get their attention. However, given how much FAANG pays, this is all expected - This is how late-stage capitalism works.

> Thinking to quit the job and prepare for the BigTech is the worst idea your brain could ever give to you

Yep, 100%. In general, FAANG or Bust is a terrible mentality to have, yet so many engineers have it. I made an entire lesson about that here: <https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/faang-or-bust-and-why-its-dumb/>

The good news is that there are a lot of awesome, non-elitist companies to work for that aren't FAANG. It takes time to find them, but they do exist. Go there and do good work. From there, you'll be able to work your way up the company prestige list (if you choose to do so). Generally once you get to senior and especially staff, you can at least get a call from FAANG. But of course, there's nothing wrong with just avoiding FAANG forever as those companies are well past their prime when it comes to work culture and learning.

At the end of the day, do what makes you happy!

It's impossible to do an apple-to-apples comparison between a startup and a Big Tech company 99.9% of the time. The rare exception is when a startup is so mature and so guaranteed to go IPO that it's already giving RSUs (this is what Robinhood did when I joined pre-IPO).

For startups, you need to do the math to figure out what the value of the option is on paper. Ideally your recruiter/hiring manager are nice and just tell it to you (but this is rare). I recommend this playlist (we really need to refactor this into a course) to learn more about the math (find the lessons about equity): [\[Masterclass\] Understanding And Optimizing Your Pay In Tech](https://www.jointaro.com/playlist/Hdfdk7MewdupgeAsIE2y/)

I looked up Snorkel AI, and it seems like a hot AI unicorn. I generally prefer unicorns to Big Tech (especially if you have worked in Big Tech already like yourself) as you still have good financial upside (with some risk of course), but you don't need to deal with all the crappiness of FAANG (politics, lack of scope, red tape).

At the end of the day, it really comes down to your priorities. If you need consistently high TC, it's hard to turn down Meta which pays well even among FAANG. But if you want to learn more and have more excitement in your life, unicorn is obviously the way to go.

Last and certainly not least, team quality matters a ton as well. If one manager came across as far better and more supportive than the other, just join them. It's hard to go wrong following a truly stellar manager.

It's easier said than done, but here's the best way to find motivation to do great work: *Join a team full of people you respect and deeply enjoy working with.*

Performance review is also a big motivator (especially now with increased stank rank and PIP everywhere), but it definitely is relatively infrequent (hard reviews are every 12 months at most places, 6 months at others). This means that it's easy to sort of forget about it and be unproductive in your day-to-day.

That's why awesome teammates are so important as you will work with them every day and not want to let them down. Humans are biologically wired to adapt to social pressure, so this is the most natural way to motivate yourself to do great work fast.

In terms of finding great teammates, that's a big task. We should make a course about that. In the meantime, I recommend this (there's other useful links here too): ["How possible is it to spot red flags about toxic culture during the interview?"](https://www.jointaro.com/question/1JwmhC3Nh9Ku0fkDL1bq/how-possible-is-it-to-spot-red-flags-about-toxic-culture-during-the-interview/)

I straight up don't think it's a good time to come to the US right now as an immigrant. The current US administration is completely unpredictable, and we have 0 idea what they'll do with the immigrant community.

Outside of that, there is a very real chance the US descends into a recession over the next 1-2 years, and you don't want to be around for that. Immigrant engineers are very expensive to hire (good immigration lawyers cost *a lot*), and I have already seen anecdotally in the Bay Area that many companies are just immediately rejecting candidates who aren't citizens or have a green card.

If Microsoft can do some magic to transfer you internally to a US office, that would be great. But otherwise, I think it's just way too stressful and risky to do the standard path of coming to the US for a Master's and then trying to get a job after.

Here's some thoughts on getting a Master's in general here: ["Do I need to do masters in Computer Science to move ahead in career?"](https://www.jointaro.com/question/tKuUT3ELEa1uCGBuMykX/do-i-need-to-do-masters-in-computer-science-to-move-ahead-in-career/)

> will consistent open source contributions over the next 6–12 months actually help my resume stand out when applying to top-tier companies?

Yes! I'm really glad open-source works out for you. The nice thing about open-source is that you get to work off an existing core vs. building an entire thing yourself.

Even if the company behind the open-source repo isn't hiring, you still gain valuable technical skills (especially during code review), and the maintainers can get to know you overtime as well (which are valuable relationships to have).

Here's our open-source course if you haven't gone through it already: [Become An Open Source Master](https://www.jointaro.com/course/become-an-open-source-master/)

I Googled for "Workday jobs" (Google knows I'm a Bay Area SWE) and found several job postings, so I assume so? I think it's unlikely they'll have a lot of iOS positions though as I imagine Workday is web-first.

Even if a company is doing layoffs (like Workday recently did), they will generally still have some openings all the time to backfill attrition.

Okay, this is actually an easy question (unless I'm super out of the loop): *Junior engineers generally don't get system design rounds.*

If a company is giving a true, in-depth, rigorously graded system design round to a junior engineer, they are being cruel and have outrageous expectations.

You can go through my entire L3 -&gt; L4 course and see there's no mention of system design: [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/)

I was at Meta, and juniors \[E3\] at Meta are like mid-level engineers at other companies (they're paid like it too). Despite that, I would never expect an E3 to be able to do high-quality system design. That is so unreasonable.

So I worked at PayPal, and that sounds about right. Overall, PayPal is a successful company that pays above average, but it simply can't compete with Meta. Most E5s at Meta now are at minimum $450k TC (the stock has done quite well over the past 2 years), and it will be very hard for PayPal to beat that unless they dramatically uplevel you from senior.

Again, PayPal is a storied, incredible company overall, but I consider it a rung below Meta frankly having worked at both. I personally wouldn't go from Meta -&gt; PayPal unless you are really pushing for more work-life balance (and I don't know if PayPal can provide that either as they're also doing layoffs).

All that being said, I highly recommend the negotiation course: [The Insider's Guide To Negotiating Your Tech Salary And Compensation](https://www.jointaro.com/course/the-insiders-guide-to-negotiating-your-tech-salary-and-compensation/)

> And you're allowed to officially switch teams after a year of being at Meta.

To caveat this, you need a "Meets All" rating or above for the past 2 halves. It's effectively a hard requirement.

Exceptions can be made, but they're incredibly rare. Most managers (especially now) won't take risks with a low performer.

Some updates:

- **You should absolutely learn Jetpack Compose instead of XML** - Compose is now the industry standard and has stabilized quite a lot over the past few years. Declarative UI as a whole is the future of mobile.
- **Google Play rolled out a stupid testing requirement** - You need 20 people to test your app before you can even publish it, which is insane. The silver lining is that increased barriers to entry means that by merely qualifying, you are already above so much of the competition who couldn't even pass Step 1. Here's my advice on how to deal with this requirement: ["How to deal with Google Play’s new 20-person testing rule for publishing Android apps?"](https://www.jointaro.com/question/9n9CUFtq72yNZYNBf2Og/google-plays-new-20-person-testing-rule-for-publishing/)
- **AI is awesome at helping with Android** - Due to Android's more open-ended nature (especially when compared to iOS), AI tools are excellent with assisting beginner Android engineers. The massive resource pool for Android means that the AIs have a lot more juicy training data to feast on.

> What would you recommend I do in my case?

It's cliched but follow your passion. At the end of the day, being genuinely excited about your work is the biggest asset you need to grind things out long-term and earn those hard-fought promotions.

I wouldn't worry too much about the front-end web disrespect thing (it does exist but irrelevant), because you are already operating at a top company (FAANG). Once you get into that FAANG-level echelon, tech stack doesn't really matter as it's assumed that whatever stack you're working on, you have a world-class level of depth with it.

> The fact that you got 9 calls is AMAZING!

Adding some perspective here, this is very much true. Most engineers in this economy are struggling to get 9 technical screens, let alone 9 final rounds.

Sorry to hear about this (insinuating that missing the project will lead to PIP/firing is crass to say the least), but I just want to say that everyone's really stressed out right now and the amount of empathy in the workplace (and beyond) is at a low.

Unless your manager has been consistently terrible to you in the past, I imagine she's just frustrated something is behind deadline and probably perceives you two as [needing hand-holding](https://www.jointaro.com/question/5vEWajcZlSi7nlohTGtJ/what-does-it-mean-to-not-require-handholding-anymore/). It's important to have empathy in these situations.

Tactically speaking, getting blocked on code reviews is incredibly common. There's many things you can do here:

1. **Be a bit annoying** - Ping the blocking reviewers and remind them to do the review. Make sure to follow the advice from [the question asking course](https://www.jointaro.com/course/ask-great-questions-that-get-great-answers-quickly/) to make your requests graceful. I particularly recommend the lesson on explaining the impact: [Explain The Impact](https://www.jointaro.com/course/ask-great-questions-that-get-great-answers-quickly/explain-the-impact/)
2. **Escalate** - If they still aren't reviewing, rope in whoever their manager is to apply pressure. Maybe your manager will give you the power to self-merge as it's an emergency. The important thing is to bring visibility and urgency to the issue. It's easy for stuff like this to get lost in the fold.
3. **Make your commits easier to review** - This one is great as it's entirely under your control. Your goal as an engineer is to make your pull requests so high quality that your teammates can approve them with high-confidence while barely looking at it. Follow the advice from the code quality course starting from here: <https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/one-diff-one-thesis/>

> Should I consider switching to a different org, or is it time to leave the company?

If this is a repeated pattern from your manager, you should definitely consider switching, either to a different team or a different company. Given how rough the market is (especially for junior engineers like yourself), I would try a team switch first. Oracle is a good company, and the stock has done well over the past couple years.

This is actually very normal - I know it feels very ambiguous and you're just sort of floating in this weird void with no clear success criteria, but that's the entire point of a true Staff Engineer project. The expectation of a Staff Engineer (at least at Big Tech) [is to own the overall goal](https://www.jointaro.com/course/grow-from-senior-to-staff-engineer-l5-to-l6/own-the-goal/), and with just that, create concrete projects to advance the org towards that.

The first part of this process is need-finding, which is what you're currently doing. Platform / infra teams have to do this all the time - You are effectively a user researcher. Talk to a ton of people, figure out their pain points, and see if there's any overlap between their pain points and the solutions/systems your team owns. Here's a thread with some examples: ["How can I come up with big initiatives, especially those at a Staff level?"](https://www.jointaro.com/question/c3LcBDXEcxA85y9jlFjz/how-can-i-come-up-with-big-initiatives-especially-those-at-a-staff-level/?playlistId=YD8LMCSlE71VUGUbNAWM)

I recommend the overall senior to staff course as well: [Grow From Senior To Staff Engineer: L5 To L6](https://www.jointaro.com/course/grow-from-senior-to-staff-engineer-l5-to-l6/)

Applying to multiple positions at the same company is very common. At Meta, they encourage employees to attach 3 relevant roles for every referral.

Where things get weird though is when you apply to several roles across many different tech stacks/domains. It makes you seem desperate and lacking depth in any particular area (which is really painful as most companies want specialists nowadays).

For your situation, you should stick to just 1 stack (e.g. front-end web, mobile, ML, back-end) and apply to roles within that stack. As a junior engineer, your goal is just to convince employers that [you're good at 1 thing](https://www.jointaro.com/lesson/wUl3hc2wr1ms493bd23b/this-is-how-software-engineers-should-initially-learn/).

I'm not a recruiter, but I don't think that much weight is assigned to the LinkedIn summary section as it has similar problems to [resume summaries](https://www.jointaro.com/course/get-more-interviews-write-a-stellar-resume-as-a-software-engineer/intro-summaries/): They are usually all "tell", no "show". I imagine most recruiters just skip straight to the experience section.

> What kinds of keywords should go there if we want to be discoverable on LinkedIn by the right kind of recruiters and opportunities?

I think it's similar to resumes in that you want as many keywords (i.e. tech things) as possible. As for the "right kind" of recruiters and opportunities, that's much harder to control. I imagine most of that will come from the prestige of your background (companies worked for + school). *1 small tactical piece of advice I have is to not have the public #OpenToWork ring.* A lot of recruiters/hiring managers see that as desperate and a signal of a lower-quality candidate.

> **Logos and household names on LinkedIn Profile: Does it *really* matter if the first 3 positions I have on my LinkedIn profile don't have a company logo (these are stealth projects/startups).**

Unfortunately, I think it does 😓. The problem with stealth startups is that there's 2 buckets:

1. Actual stealth startups that raised lots of money and built products that got real traction but had to stay secret for whatever reason
2. Made up startups that were effectively just bad side projects and the candidate is desperate to manufacture some work experience

It can be hard for recruiters to differentiate. If you can fish out an old company logo and attach it on, that would be great. There's no reason you can't retroactively make the LinkedIn company page now. And of course, drop as many metrics as you can about the company traction.

Really sorry to hear about all this. Normally [I recommend that you don't quit to interview prep](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/interviewing-while-employed/), but it seems like your situation is really bad (is there not a way you can switch teams internally?).

Failing 9 onsites is rough, but that's how the market is right now. I know folks who have failed 10, 15, and even 20 onsites. In these situations, all you can do is get back up, dust yourself off, and try to learn from the experience (there are rarely interviews where your rejection was 100% the fault of the interviewer).

Keep in mind that hiring managers and recruiters discriminate heavily against employment gaps, especially now. I would try to stick it out at your current company as long as possible, putting in minimal effort to get by and mentally compartmentalizing away the work experience as much as possible.

Lastly, if you have a non-terrible manager, I would talk about this with them as well. Maybe they can put in some mitigation measures to boost your mental health a little bit.

Best of luck!

Sorry to hear about the lay off 😓. Meta is a brutal place to be right now.

I would try the self-study route first. Since you're ex-Meta with good experience (almost 5 years), you'll have a far easier time with interviews than most.

Engineer time (especially that of top engineers who can genuinely help you with interviews) is expensive. All the decent bootcamps will set you back around \~$5,000 minimum.

The main value of these bootcamps isn't the tactical advice from my experience (that's already online, [especially on Taro](https://www.jointaro.com/learning-paths/land-your-dream-job-in-tech/)), it's the accountability. If you need help having a consistent routine and maintaining motivation, these bootcamps provide you a fellow human to enforce that.

This is actually a big reason I went to Meta. Course Hero had some of the nicest people I've ever worked with, but the engineering bar frankly wasn't super high. It was absurd the kind of low-quality code engineers there could get away with. Outside of FAANG and FAANG-adjacent companies, the vast majority companies are like this.

In general, I've found that going to places that have FAANG/FAANG-adjacent talent leads to an environment that pushes you harder. You can either go to Big Tech itself (which most aspire to) or go to a startup that primarily hires these people (more fun IMHO and you'll learn more at the cost of consistent pay).

> **If I prepare for Pinterest, will I also be improving my chances with other similar, high-quality companies?**

Yes. Big Tech companies commonly share [the infamous data structures and algorithms (LeetCode) round](https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/why-does-faang-do-this/). On top of that, these companies push candidates to break down concepts more in-depth, and once you train your brain to handle that style of thinking, it'll carry over to all the interviews at the top companies.

If you haven't done the problems in a while, it's probably worth revisiting them.

From my experience (and hearing from others), the LeetCode Premium frequency chart is pretty accurate. If a problem is marked as fairly common, you should know it, even if it comes across as "weird".

You need to give feedback to your manager, so they can give feedback to the tech lead. If necessary, rally others on your team to also give feedback to make this a concerted effort and more likely to succeed. If this is truly a common problem, this should be possible.

Check out these related discussions as well:

- ["Really struggling with team/engineer"](https://www.jointaro.com/question/pZzSKRKoOyYqUSNRv3dW/really-struggling-with-teamengineer/)
- ["As a MLE, how should I communicate with a difficult backend engineering lead?"](https://www.jointaro.com/question/BQhuTbP5N2rA07Nflmm8/as-a-mle-how-should-i-communicate-with-a-difficult-backend-engineering-lead/)

As mentioned in the threads, empathy is important. This engineer seems extremely capable and invaluable to your time - It would be a shame to lose him. The onus isn't purely on him to help you, it's also on you to help him. There's a good chance he doesn't have the time or mental energy to unwrap his expertise and share it with you. Think of ways you and your teammates can alleviate some of his burden, so he's in a better position to help all of you.

Yes.

From what I've seen, interviewers will either do 1 LeetCode Hard or 2 LeetCode Mediums. LeetCode Hard is a spectrum too. Some of the problems labeled "Hard" feel like tough mediums honestly.

For the onsite, [just make sure to get LeetCode Premium](https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/the-1-tool-for-dsa-prep/) and do all the of the top 50-100 questions for the company you're targeting. This will include a mix of all difficulties.

> If I'm able to crack most mediums in under 30 minutes is that a decent place to be?

Decent, but try to get it faster, assuming your &lt;30 minutes is just the solution and [not all the other stuff I talk about in the course](https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/how-to-pass-faang-dsa-rounds/) (edge cases, alternate approach, big O analysis). For just coming up with the raw solution for a LeetCode Medium at the onsite level, I think you want to keep it to 15 minutes and below.

Normally I recommend that junior engineers [go to Big Tech first to build a foundation](https://www.jointaro.com/lesson/OcWRqQcx31VwIEV6tfWK/why-you-should-start-your-career-at-a-big-tech-company/?playlistId=Hdfdk7MewdupgeAsIE2y), but your brother's situation is different as he already knows he wants to become a founder someday.

Honestly, I'm leaning towards the Series A company. Series A companies generally have some semblance of product-market fit already, and the team seems very strong while also being a good fit for him.

Google's great, but I imagine working on ads is super stressful (source: I worked on ads at Meta which is also primarily a digital ads company). If you're going to be super stressed out and have poor work-life balance, might as well do it for an exciting product you're super passionate about. Google ads is so mature now that I can't imagine any reasonably sane person being genuinely passionate about it.

Anyways, on to the question in the title: *"When should you take risks in early career?"*

**My answer:** *Literally all the time when you can.* For 99% of people, their energy levels will go down as they get older while their personal life complexity goes up. It only gets harder and harder to take risks as you age. When you're in your 20s, just do as much fun crazy stuff as possible unless you have some hard blocker (health issue, actually need the high TC of FAANG to survive, etc).

First off, they would never assign an intern to someone who is fighting off PIP. It's possible they get put on PIP after, but that's not likely. Ignoring that though, there are many other reasons why your intern manager can disappear on you suddenly (illness, family issue, etc).

Situations like these are why you absolutely have to [diversify your mentor base](https://www.jointaro.com/course/ask-great-questions-that-get-great-answers-quickly/diversify-your-asks/). Build relationships with people besides your intern manager, so you can also ask them for help.

We'll be making a revamped internship course soon, and a broader networking course is my next course after I finish my current side projects one. Stay tuned!

> Fto the course isn’t opening in mobile and I don’t see a search option for courses 🥲YI

For iOS in particular, app links don't work 😭. Apple's own documentation about it is broken and outdated.

Search is also very broken, but that's under our control and it's in my backlog to fix it.

First of all, it's great that you have this instinct! Much better to be an engineer who cares about the edge cases than one who doesn't.

At a high-level, my main advice here (as with many things in tech and in life) [is to prioritize](https://www.jointaro.com/course/maximize-your-productivity-as-a-software-engineer/finding-the-best-things-to-work-on/). As I talk about in [my code quality course](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/the-myth-about-better-code/), there will always be an effectively infinite amount of edge cases and at some point you'll need to start making trade-offs. 

Concretely what happens is you tackle some amount of edge cases efficiently (so code quality trends up while still moving fast) but then you consciously decide to ignore/backlog the remaining ones as ROI isn't good (i.e. you hit diminishing returns on code quality while tanking velocity).

When it comes to edge cases, you need to grade them across 2 axes:

- **Commonality** - Is this edge case relatively big for an edge case, like a 10% possibility? Or is it tiny like 0.1% or less?
- **Severity** - How bad is it when this edge case occurs? Is it bad enough that the NYTimes will write a scathing article about how evil your company is? Or will it just make a user slightly inconvenienced?

So take all the edges you found and grade them on common/uncommon and severe/not severe. You will have 4 buckets:

- **Common, severe** - Obviously fix these
- **Common, not severe** - Probably fix these
- **Uncommon, severe** - Probably fix these
- **Uncommon, not severe** - A lot of edge cases will be here. Deprioritize unless they're low-hanging fruit (&lt;5 minutes to account for)

Once you have this structured table, you (and your teammates) will have clarity.

For what it's worth, engineers doing thoughtful writing and planning like this was a good sign that they were ready to grow from mid-level to senior from my experience.

Hope this helps!

It's rough as the current economy isn't one where companies are willing to take risks on employees 🙁

Sometimes you need to play the long con and switch to another (often bigger) company with your current tech stack and then do a switch there after establishing yourself as a high-performer across 1-2 years. Big Tech companies like Amazon, Google, and Meta are known for having good internal mobility (it's much weaker now but still industry-leading in relative terms).

One way to satisfy that learning itch immediately though is by building stuff outside of work (if you can find the time). The 2 main paths here are open-source and side projects:

- [Build Side Projects With 500k+ Users: Coming Up With An Idea](https://www.jointaro.com/course/build-side-projects-with-500k-users-coming-up-with-an-idea/)
- [Become An Open Source Master](https://www.jointaro.com/course/become-an-open-source-master/)

It's important to remember that being at Meta right now is very stressful, and as the company says, *"Assume good intent"*. Being extremely busy is a very valid reason a mentor is deprioritizing a mentee - That mentor could even be fighting off PIP right now.

All that being said, asking for another mentor seems fine (assuming it's a been a while since your current mentor was assigned). Just tell your manager that your current mentor is way too busy.

What I recommend doing though is flipping the mentality from *"I need to find a mentor"* to *"I'll make a mentor want to choose me as a mentee"*. Follow the advice here: ["How does one attract a sponsor who is invested in their growth?"](https://www.jointaro.com/question/pRX7I8QC5YPOEDNX5q87/how-does-one-attract-a-sponsor-who-is-invested-in-their-growth/)

I highly recommend the question asking course as well if you haven't taken it. For E3s in particular (understandably), I saw a lot of them struggle to get the support they needed as they weren't asking sharp enough questions. Here's the course: [Ask Great Questions That Get Great Answers Quickly](https://www.jointaro.com/course/ask-great-questions-that-get-great-answers-quickly/)

First, I recommend this course (it's Meta-specific, but a lot of the advice is generic): [Nail Your Return Offer As A Meta Software Engineer Intern](https://www.jointaro.com/course/nail-your-return-offer-as-a-meta-software-engineer-intern/)

We'll be making a more general intern course over the coming weeks as well, which will be much higher quality.

Your primary goal right now should be to lock in that return offer. Getting quality mentors within the company will help a lot with that, and I recommend following the advice here to make yourself attractive to mentors to pick up as a mentee: ["How does one attract a sponsor who is invested in their growth?"](https://www.jointaro.com/question/pRX7I8QC5YPOEDNX5q87/how-does-one-attract-a-sponsor-who-is-invested-in-their-growth/)

You can look for friendly coffee chats and mentorship from Taro Networking as well: <https://www.jointaro.com/networking/?selectedServices=Mentorship>

A late-stage career pivot is tough but definitely possible. Given how senior you are, [you should have a bunch of general technical fundamentals](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/focus-focus-focus/) that make it easier to pick up any new language/tech stack. Interestingly enough, a recent thread talks about this: ["How much does language-specific experience impact switching to other tech stacks?"](https://www.jointaro.com/question/O9zTAoXh2ktvqRmdzCDT/how-much-does-language-specific-experience-impact-switching-to-other-tech-stacks/)

What I will say is that you should do this pivot *through an internal team switch, not an external interview jump.* When you join a new company entirely, they are already taking a risk by not knowing if you'll be able to adapt to their culture. Very few hiring managers want to stack the extra risk of not knowing if they'll adapt to the new tech stack as well. More thoughts here: ["How to transition from back-end development to distributed systems?"](https://www.jointaro.com/question/zzb5xiaRVK1pOmeCzG97/how-to-transition-from-back-end-development-to-distributed-systems/)

It depends a lot on level.

When you're just starting out, you are focusing more on syntax and low-level mechanisms. When you build something, you are thinking more in terms of *"I need this specific code in X language to accomplish the task"* as opposed to *"I need these high-level components like classes, interfaces, etc to accomplish the task"*. That latter mentality comes up more as engineers reach senior, which we talk about in-depth here: [This Is How Software Engineers Should Initially Learn](https://www.jointaro.com/lesson/wUl3hc2wr1ms493bd23b/this-is-how-software-engineers-should-initially-learn/)

A resource that covers proper learning even more is the code quality course: [Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)

All that being said, job availability is a pragmatic angle you simply can't ignore. If there aren't a ton of Go jobs in your region and you want to stay, you probably shouldn't learn Go. You can almost never go wrong getting good at Java/JavaScript as they are literally everywhere.

It's on our roadmap! We took our first foray into this with the web dev course: [Become A Better Web Developer: Basic React Best Practices](https://www.jointaro.com/course/react-best-practices-javascript-framework-gotchas/)

The tricky part is making sure that the content is as evergreen as possible. We don't want to make a course where the content becomes irrelevant or even worse, actively wrong, just 1 year later. Our goal is to finish the more evergreen courses (e.g. effective 1 on 1 meetings) before tackling these.

**One last thing:** I don't think switching from FAANG to FAANG will solve the work-life balance issue. It certainly won't if you do it with an uplevel at the same time.

For the first 6 months, you'll need to deal with both a new company and a new level you've never had before. You could be working 80-100 weeks in the current stressful climate that's permeating all of Big Tech right now. It's important to remember that L4 in particular is a very wide band, and you need to compete with all of the L4s to avoid being at the bottom of stack rank.

> What should I say if the recruiter asks me for my current job level?

Follow the advice here: ["Recruiter asking what level I was"](https://www.jointaro.com/question/mkJTQwyNmvvLimhF5aiI/recruiter-asking-what-level-i-was/)

If they explicitly ask if you're L3 or L4, then you need to tell the truth but also say that you're a high performer on track for a fast L4 promo.

> What if a recruiter reaches out to my current company to ask about my level?

I don't think people do that. If your manager likes you, I doubt they would disclose that information, even when explicitly prompted.

> What parts of my experience can I highlight to show I'm performing at the L4 level?

Go through these 2 resources:

- [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/)
- [Master The Behavioral Interview As A Software Engineer](https://www.jointaro.com/course/master-the-behavioral-interview-as-a-software-engineer/)

There are many complex ways [to get to staff and beyond](https://www.jointaro.com/course/grow-from-senior-to-staff-engineer-l5-to-l6/why-have-archetypes/), but one of them is actually quite straightforward (at least at Meta): *Just write more code than everyone else by a **staggering** amount.*

That's exactly what [Michael Novati](https://www.linkedin.com/in/michaelnovati/) did to get to Staff \[E6\] at Meta and eventually Senior Staff \[E7\]. Since Michael was early Facebook, there actually wasn't a Staff Engineer archetype at the time to capture the way he was adding immense value to the company. So they added it! Thanks to Michael, there is now a formal "Code Machine" archetype in the official Meta internal wiki.

Michael will be breaking down:

- His story about how he became Meta's first incredibly senior "Code Machine" engineer
- The most impactful projects he worked on
- How he managed his time effectively to write so many diffs.

At the end, we'll have time for Q&A where you can ask Michael questions about topics like:

- How he grew so quickly and crafted such an extraordinary career
- What the early days at Meta were like
- Different ways to create a unique brand for yourself, your work, and your career

If you need extra help breaking into top tech companies like FAANG, [**Formation.dev**](https://formation.dev/partners/taro) is here to provide you hands-on, personalized support. Join Michael and the rest of the awesome team at Formation here: [**https://formation.dev/partners/taro**](https://formation.dev/partners/taro)

Co-Founder & CTO @ Formation.dev, Meta's First E7 Code Machine

Michael Novati

Tech Lead/Manager at Meta, Pinterest, Kosei

Rahul Pandey

Becoming A Legendary Meta Coder: The Story of the First E7 Code Machine

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.