There is a huge difference between 10k and 1k both in terms of learning (more users = more issues to handle) and the attractiveness to employers. 1k users is at a point where it's rare but could be fluke (e.g. you wrote 1 social media thing that did well and drove a bunch of registered users). 10k is at the point where there's almost certainly something special happening and 99.9% of engineers overall won't have a side project that large.

That being said, going from 1k to 10k is incredibly hard. You can definitely try sending out more applications and doing interview prep with your current 1k side project resume and see where it lands you.

I recommend sharing some LinkedIn posts as well about the achievement. I know many engineers who've done that and had employers take notice.

Tech Lead @ Robinhood, Meta, Course Hero

Alex Chiou

As a heads up, backlinks aren't that important. It must be a vestige of what used to work for SEO. We have tried for years (and mostly failed) to get meaningful SEO traffic to Taro, and we found out that backlinks don't matter the hard way.

The true way to get Google SEO relatively quickly is to generate a lot of high-quality, content-rich pages. It doesn't matter if your DR (domain reputation) is tiny. Most side projects won't be able to do this unfortunately.

*There is a pretty linear correlation between company prestige/pay and code quality.* Code quality is a defining trait of top engineers, and the more prestigious a tech company, the more top engineers it'll have. It's not some mystery why FAANG towers above everyone else - Because they pay more than 90% of the market, they'll get the top 10% engineers.

My advice is to reverse interview engineers while you're job searching. [In behavioral interviews in particular](https://www.jointaro.com/course/master-the-behavioral-interview-as-a-software-engineer/interviews-are-a-2-way-street/), you'll generally get an opportunity to ask them some questions. You can ask some pretty pointed ones about code quality:

1. **How fast do engineers review code in your team?** - Code review culture is one of the top indicators of code quality. Teams with low code quality don't care about it and therefore review code slowly. 1 day turnaround is the baseline for a top company IMHO.
2. **Hypothetically, what does your team do if it hits a deadline but needs more time for polish?** - This explicitly frames velocity vs. quality. See which one they pick - Ideally they give a nuanced response balancing the two.

I talk more about the incredibly intricate mechanics behind code quality in my course: [Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)

You can also see how much they care about code quality from how well they proctor the interview, [even data structures and algorithms (LeetCode) ones](https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/clean-code/). If they're pushing you for edge case coverage and detailed solution analyses (trade-offs), that's a good sign they truly care about code quality.

In this market, I think contracting is a solid option for the reasons you mentioned. The economy is still quite rough (2024 had *way* more layoffs than I expected), so the bar for FAANG FTE is skill-high. The bar will definitely be lower for contracting roles, and I know several great engineers in the Taro community who are trying the contract -&gt; FTE conversion strategy right now. The tradeoff with a contract of course is [the lower pay (no RSUs), less stability, and being treated not as well as the FTEs](https://www.jointaro.com/question/KM6mWpwwCZHRwh2WF4LI/faang-contracting-is-it-worth-it/).

In terms of how long to do the contract, I think you just want it to be as short as possible. Ideally you can just contract at FAANG and convert it after 6 months, but that's not likely (earliest conversion is generally 12 months). Once you're on the contract, treat it like a promotion. [Establish yourself as a high-performer and then figure out that conversion dialogue with your manager](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/step-0-establish-yourself/).

I also recommend just asking upfront (both to the recruiter and during the interview) for contract opportunities on what the pathway to FTE conversion is.

I don't expect full-on L4 to become the bar (at least not within 5 years), especially as L4s do have meaningful expectations around people skills, mentoring/teaching, and other non-single-player things that AI can't really solve on its own.

L4s also have expectations around code quality, which is something AI really struggles with. AI is overwhelmingly trained on online code samples which are almost always centered on just getting the thing working as opposed to writing the cleanest code.

What I do know is that L2 engineers (i.e. engineers who can't really code, pretty much intern by FAANG standards) will be useless. Most engineers graduate school operating at L2, and that's what most companies hire at (in the official Meta leveling guide for example, PayPal SW1 is considered a Meta intern). If you haven't done 1-3 FAANG internships (or interned at a company of a comparable level), it's not likely you are operating as a solid L3.

> What is this sort of topic called? Claude is saying System Design or Control Flow, I'm thinking it's a turing machine of some sort but don't know the software design term.

System design feels too high-level for this and control flow specifically refers to branching logic due to conditionals (i.e. if-statements). There really isn't a good term for this. I would use one of these terms:

- Code structure
- Code flow
- Code design

If you're using an OOP language, this can also fall under OOP design.

> What if the actions need to be modified or cancelled? e.g. For the chain X-&gt;Y-&gt;Z, Action X runs and the loop goes to the next iteration. After Action Y runs it then decides Action X needs to be ran again instead of Z.

You can create some sort of ActionProcessor class that takes in a queue of Action objects. *Make the queue mutable, so the execution logic can change the contents of it (push/pop certain actions) if necessary.* In your case, it looks like you may need to push certain things based on action outcomes.

> The loop runs and then ActionY errors out. I need some way of knowing which actions were successful, which ones errored, which ones failed etc. Or even a count on how many actions took place in the sequence. Perhaps, if it errors, then the chain is dumped and actionE runs instead or something like that.

Make your processActions() method return some sort of results object like ActionResults. It can have fields like:

- FailedActions
- SucceededActions
- NumActions

Congrats on the offer! I'm also glad PayPal is currently going well for you - That certainly wasn't the case for me back when I was there 🤣

First off, I consider Amazon far higher than PayPal on the totem pole. It's a FAANG company at the end of the day, and having the name on your resume will help you quite a lot for future job searching, especially when compared to PayPal.

The thing is that Amazon, similar to PayPal, is a huge tech company. There will be great teams, average teams, and terrible teams. The same goes for PayPal. It is very possible to go from a great team at PayPal to a terrible team at Amazon and be in a worse position. For you right now as a junior engineer, the most important thing to optimize for is learning.

In a vacuum, I recommend going to Amazon and trying to stay there for 2+ years to "cancel out" the short PayPal stint. You also generally need to stay at Amazon for a little more than 2 years anyways to get the backloaded RSU grants. But you still need to make the judgment call on how good your team is and how excited you are about the new team at Amazon. Happy to give more thoughts if you can share details there.

First off, ignore Blind. Blind is overwhelmingly toxic and negative: It's a place people go to complain and vent. According to Blind, every company is the worst company ever. In general, people are more willing to go to the effort of publicly sharing feedback on the internet when they have something negative to say.

Glassdoor is a bit trickier as even though it leans negative from the inherent aforementioned nature of the internet, it's not as purely negative as Blind. Personally, I would be super wary joining a company with a Glassdoor average of 3.5 stars or less.

> I don't know how to get a more "well-rounded" view of a company, and I'm wondering if there are any tips on how to get a more unbiased take?

You really just have to talk to people, and this comes from building a strong network. The deeper the relationship you have with someone, the more likely they are to be truly honest with you. There's a judgment call for you as well as you need to figure out which of your friends have higher emotional intelligence and are able to see past the Kool-aid.

When it comes to people giving you a truly unbiased, fair take, the chances of this go up with the following:

- **Tenure at the company** - Systemic problems usually take a while to realize. I wouldn't trust the opinion of someone who's been at the company for just 6 months or less. They are likely to be still on the Kool-aid at that point.
- **Seniority** - Junior engineers in particular are often just happy to have a job. It generally takes them far longer to figure out that they're actually drinking the Kool-aid. Senior engineers are more grizzled with real-world experience. They have the pragmatism and holistic viewpoint to see the true culture of a company faster.

Congrats on the new job! For onboarding, I recommend our course here: [The Complete Onboarding Guide For Software Engineers](https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/)

If I were to distill down that entire course to what I personally think is the most important, my advice would be to *"Win with quality"*. It is almost impossible for a newbie to win with velocity and quantity as they're trying to understand how the heck the codebase and overall engineering culture work. What you can do though is to spend an extra couple minutes here and there really polishing your pull requests and going out of your way to make social interactions pleasant (social quality).

After the onboarding course, I highly recommend the mid-level to senior course to understand exact level expectations for a senior engineer: [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/)

Commit count has a *ton* of nuance to it. Meta in particular is unique as it's very metrics-oriented, and its culture is built to let engineers write a lot of code. Even at Meta though, there are many very senior engineers who will have super low commit counts like the [Product Hybrid Staff Engineers](https://www.jointaro.com/course/grow-from-senior-to-staff-engineer-l5-to-l6/product-hybrid/).

When it comes to commit, here's how you should think about it.

### Quality Comes First

It doesn't matter how many commits you spam if the quality is poor. If you're known for poor code quality at a company like FAANG, you're probably 80% of the way there to a PIP. The good news is that if you're truly prioritizing quality, the quantity should come naturally. That was my strategy at Meta as I talk about in-depth in my 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/)

### It's All About Impact

It also doesn't matter how much code you're writing if all your commits are for low-impact projects that add 0 (or even negative) business value. Learn how to evaluate projects and ruthlessly prioritize the best ones. I talk about this in my productivity course: [Maximize Your Productivity As A Software Engineer](https://www.jointaro.com/course/maximize-your-productivity-as-a-software-engineer/)

### Think Comparatively

Code volume will vary a lot based on its company and its culture. For example, the average commit count per half for a Meta engineer was around 125 commits. This makes a commit count of 250+ pretty impressive (double). At Google though, I know that the average commit count is far lower per half, more like 50-75. This makes sense as Google is a bigger, older, and slower company that also has to care far more about quality (there's a lot more government scrutiny around Google nowadays).

If you want to be known as a code machine, learn about the average benchmark numbers across your organization/company and beat that by a lot.

Oh wow, congrats on getting 1,000 users! 99% of junior engineers can't even come close to what you've accomplished, so you should be incredibly proud.

You can grow a product with raw marketing, but as you've probably figured out, that's not super fun and it also defeats one of the core purposes of a side project: *Technical learning*

Instead of spending a bunch of time on content marketing, think about how you can organically multiply that 1k to 10k with word of mouth. Go through your email feedback and reviews (if you have them). If you don't have much, you can even email users to do a user research call to figure out what they like/don't like.

> **TL;DR: side project has 1000 users. should I leetcode in free time or market my side project?**

It depends on what your job search currently looks like. If you have 3 FAANG interviews lined up, you obviously should spend 75%+ of your free time on [LeetCode grinding](https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/). But if you're in a position where you just need to get the interviews to begin with, the side project makes more sense [to beef up your resume](https://www.jointaro.com/course/get-more-interviews-write-a-stellar-resume-as-a-software-engineer/the-real-secret-for-a-top-tier-resume/). I talk about this all incredibly in-depth in my job searching course: [Ace Your Tech Interview And Get A Job As A Software Engineer](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/)

Just don't do it:

- IQ tests are notoriously a poor barometer for intelligence
- If you don't do well, it's a huge ego hit
- Your time as a Senior Software Engineer is valuable and time spent on an IQ test could be spent on doing something actually productive instead

On top of that, raw intellect is far from a great predictor of how you'll do in a tech career. A clear example is leveraging social/emotional intelligence. I know many engineers (including those at FAANG) who were kind of slow at grasping complex technical concepts. However, they were a genius with relationships and communication, being very likable overall. This allowed them to build a dense network around them who could provide mentorship and quality teaching to greatly overcome their lack of raw intellect.

There are many ways to succeed in tech besides just being purely smarter than everyone else. In fact, it's much healthier to rely on more fundamental skills for your success in tech compared to raw intellect as many engineers have the raw intellect but not the fundamental skills (i.e. they are very awkward with poor communication).

HFTs will pay far more than Big Tech, but your work-life balance will be 50% worse (like even worse than what you can achieve at FAANG which already has poor WLB): ["What's the reputation of quant firms from the lens of big tech?"](https://www.jointaro.com/question/TyPoHYv5k1tpcfwKszaw/whats-the-reputation-of-quant-firms-from-the-lens-of-big-tech/)

If you want to become rich, I think it's way better to target a hot unicorn like Notion, Brex, and of course, OpenAI.

My brother got into pre-IPO Robinhood and has grown very well there. He's making well over $1 million per year now and works 40 hours/week.

This feels like an obvious team switch to me. I think your good ratings are coming more from you building up raw skills as opposed to deepening certain relationships given how chaotic your prior team was (no manager until 3 months ago is... wow).

All of this means that I don't think you'll lost that much momentum for your Staff promotion. Momentum is lost [when you have a bunch of built-up social capital and deep relationships that you're leaving behind](https://www.jointaro.com/course/grow-from-senior-to-staff-engineer-l5-to-l6/you-need-tenure/), but since your prior team didn't have a manager for so long and there were so many loans, you shouldn't have too much of that to lose.

Sorry to hear about all this, particularly your reputation hit. I firmly believe that you should be both (focused on shipping great products efficiently to users *while also* caring about code quality), but there's definitely a balance to be struck here which seems to have been missed.

That being said, the best way to approach any solution like this is to *have empathy*. Genuinely try to see the world from their shoes and play a bit of Devil's Advocate - It's always far better to build a bridge instead of burning whatever you currently have and trying to find another way around. Ask yourself these questions:

1. **Is this engineer stretched super thin?** - They might be slow and angry because they're the only senior or staff engineer on a team of 15+. Even at FAANG, I have seen teams like this where 1 person is the gatekeeper for everyone, which leads to them getting burnt out and taking this out on everyone else with their grumpiness.
2. **Does this engineer make efforts to leave feedback proactively?** - Proactively = before the code is written and the pull request is out. If you see them commenting on tasks and system design docs before code is written, that's good on them and is a sign that the team can figure out a way to plug in better. If you don't, this engineer really needs to learn how to channel their feedback more productively.
3. **How is your relationship with this engineer overall?** - Do you eat together at lunch? If you've ever talked to them 1 on 1, how's the vibe? Have you done anything in the past that might have offended them before and you didn't realize it? Have they done anything in the past that was actually quite nice for you? (i.e. there is a softer side to them you've seen before)

All of these questions are just important food for thought - I'm an outsider without enough information, so I'm not really here to "pick sides". My goal here is to encourage introspection and figure out how all of you can find a graceful path forward together. For example, I don't see this engineer getting fired as a win - That feels too acrimonious.

All that being said, here's my tactical advice to improve the situation

1. **Talk to your manager!** - Given that this is a team-wide problem, you absolutely need to tell your manager. Better yet, talk to your teammates who you also know are unhappy with the situation and all of you can talk to the manager together as a united front, either in a group chat or a meeting (or both). The ideal path is that the manager delivers all of your feedback in a way where this engineer is receptive and betters themselves.
2. **Act super proactively** - Scope out your coding tasks in detail beforehand and share it with this engineer. Follow the advice from the code quality course starting from this lesson here: <https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/sweat-the-details-call-out-edge-cases/>
3. **Time-box decisions** - I have been rug-pulled so many times on all sorts of decisions. You simply need to put your foot down to really solve this. If there's an open discussion point on your technical approach for a project, say *"Hey everyone, we need to make a decision on this by **X** day in order to hit the deadline. Whatever we have by **X** day, we are going with that, and it cannot be changed"*. And of course, you make this easier for everyone by outlining pros/cons in great detail and suggesting a default course of action.

Meta is a great company that I think is financially well-positioned (I imagine your initial RSU grant has grown considerably). I do think it's worth giving it a shot across the next 2-3 months and see if you can hang in there. In terms of what to do:

1. **Talk to your manager** - If you have a good relationship with your manager, you should definitely have that [awkward conversation](https://www.jointaro.com/lesson/xjeFRpp5YHxG9TTK8wjn/1-on-1s-are-the-time-to-be-awkward/) and really lay this out on the table. There are things that your manager should be able to help with like optimizing processes, fine-tuning oncall load, etc.
2. **Optimize your productivity** - In particular, prioritize ruthlessly and see if you can stack your schedule so you can isolate focus blocks and dedicate certain time as "chaos time" where you're peppered with meetings and random pings. I highly recommend going through my entire productivity course: [Maximize Your Productivity As A Software Engineer](https://www.jointaro.com/course/maximize-your-productivity-as-a-software-engineer/)
3. **Switch teams (if all else fails)** - Assuming you've gotten decent PSC ratings, you should be pretty mobile as an E5. Meta as a whole is definitely approaching what you described (both chaotic and with a lot of process), but there are certainly teams where it's more "chill". The beauty of being E5 is that ["up-or-out"](https://www.jointaro.com/question/X3ccTVVCpuS1T76HI5fX/how-does-up-or-out-work-and-whats-the-transition-generally-like-for-e3-greater-e4-greater-e5/) doesn't apply to you, so you don't need to think about promotion timelines. Most teams can support an additional E5 if they're strong (i.e. [able to create scope themselves](https://www.jointaro.com/course/grow-from-mid-level-to-senior-senior-l4-to-l5/the-goggles/)).

Here's another good thread I recommend (from another burnt out Meta engineer): ["How can I have less burnout and better work-life balance?"](https://www.jointaro.com/question/yvEFVA9n1wEcBU3fHNKU/how-can-i-have-less-burnout-and-better-work-life-balance/)

Worst case, you can look outwards (Meta is admittedly a terrible place for someone with ADHD), but let's not think too much about that yet. The PSC rating in particular is an important piece of info.

Best of luck and if you need more help, please share more in the forum and I'll be around to support you with more advice!

You pretty much nailed it! Practically, the interviewer will be mentally "running" the APIs you've made in their head, pretending that your architecture lives in production and they are the consumers of it. That's the beauty of OOP - It reflects what you actually do in the real world, so the interviewers will evaluate you against that.

I *highly* recommend going through my DSA course which covers this topic and the FAANG hiring bar in general in-depth: [Master The Data Structures And Algorithms Interview](https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/)

In general, you should always strive for the optimal solution in terms of run-time unless the interviewer tells you not to. In most cases, this is 65%+ of the battle.

However, there are several branching scenarios from just getting the optimal solution in terms of run-time, one of which is super common at Meta:

1. **You are pushed for an alternate solution** - Meta does this all the time. All 3 people I shadowed for interviewing training at Meta did this. The interviewers on my own panel back when I interviewed to get into Meta also did this. If a question is of lower difficulty (e.g. LeetCode easy on phone screen or LeetCode medium on onsite), there is a good chance the interviewer is expecting an alternate solution with an in-depth explanation in order to pass you. That's what I did.
2. **You aren't allowed to get stuff "for free"** - In your min heap example, it is trivial to write that solution if you can use a built-in heap. If the interviewer feels like you got the solution too fast with a poor explanation, they might make you explain the heap in-depth or even have you code up the heap. *One of the primary goals of the interviewer (especially at Meta and FAANG in general) is to make sure the candidate didn't merely memorize the problems and that they actually understand the underlying concepts*. When I saw this as a Meta interviewer, I would make sure to push the candidates much harder. You don't get much signal when the engineer is just recanting memorized knowledge.

This is a very broad topic, but I would start off with these 2 courses:

- [Tech Lead Blueprint: Role, Skills, and Strategies](https://www.jointaro.com/course/tech-lead-blueprint-role-skills-and-strategies/)
- [Effective Communication For Engineers](https://www.jointaro.com/course/effective-communication-for-engineers/)

For your particular scenario (and many, *many* others), the cure is *constant communication.* This is especially true given that you work at Meta where over-communication is the glue that is furiously working overtime to keep the engineering org and culture together.

Just because a team gave you alignment in the past doesn't mean they'll continue  giving you alignment in the future. As a senior engineer and tech lead, it is your responsibility to check in on them regularly (at least once a week) and continue building the relationship so they are less inclined to rug pull you.

There's also a social reading component to it. It's possible that a team will say in a meeting that they're aligned, but there's a slight hesitation in their voice and/or body language. As an E5, you should be adept at picking up these small cues and noting down that this alignment is risky and not stable. The action item from there is to check in on that partner more aggressively so that if they end up flaking out, you can catch it ASAP.

The system design bar isn't that high for L4, but it is there. You should have some basic instincts about what's scalable and what's not - A classic example is knowing the differences between a polling solution and a listening solution like a web socket.

The system design interview is sort of like a behavioral interview in that it's very open-ended and more about the quality of the conversation, but it is distinctly different. It's still a very technical exercise despite you not having to write any code.

I recommend the other system design course we have as well: [The Top Ways People Fail System Design Interviews](https://www.jointaro.com/course/the-top-ways-people-fail-system-design-interviews/)

30 minutes is really not a lot of time - It definitely won't be enough for an in-depth knowledge transfer. Your goals here should be primarily two-fold:

1. **Leave the relationship on a good note** - If you liked the TL, thank them for their work and at the very least, connect on LinkedIn if you haven't already. If you had a really good relationship, try to connect on something like Facebook/WhatsApp.
2. **Get high-level wisdom** - Ask broad strokes questions like *"What do you think is the biggest problem facing the team?".* These kinds of insights are both critical to grow from L4 to L5 while also being uniquely suited to be presented by very senior engineers (L6+).

Don't ask stuff like *"Hey do I debug XYZ issues in service ABC which you owned?"* as 30 minutes isn't enough to go sufficiently deep into nitty-gritty. Hopefully the L7 left behind a wealth of documentation to help the team absorb his offboarding. If he hasn't, then well, it's too late (good luck in this case).

At the end of the day, you need to prioritize. I'm a perfectionist, so I try to fix every bug. Unfortunately, that is simply not possible, *especially* for Android and its extremely fragmented nature.

Fixing a bug as soon as it comes in is ideal *but only if it's worth it*. In terms of whether it's worth it, that's a tricky calculation but what I will say is that since you work in an early-stage startup, ROI will be much better working on new flashy features instead of trying to patch up every single issue. In terms of whether an issue is worth fixing, ask yourself the following questions:

1. **How many users does it affect?** (breadth)
2. **How severe is the issue when it happens?** (depth) Is it a slight inconvenience (e.g. a user needs to click a button an extra time) or a major violation of the user experience (e.g. a user is billed twice on accident)?

If possible, strive to figure out the impact, similar to feature work. Let's say you have a bug where your Google Pay integration can't take American Express cards. Figure out what percentage of users fall into that specific flow and what their average order size is. From there, you can roughly deduce revenue unlock by fixing the bug.

I recommend going over the lessons in my productivity course about prioritization: <https://www.jointaro.com/course/maximize-your-productivity-as-a-software-engineer/the-productivity-giant-you-are-missing/>

> I would say that It's good, even preferable, to reassign the bug to the person who worked on it because they'll probably have the most context on it, so they'll be able to fix it faster.

I agree with Charlie here - In a startup, it's just best to do the naive model where people fix stuff for the areas they've worked on.

Zooming out, if you're feeling swamped with random bugs and are being forced to work on them, talk to your manager. Talk about how it's affecting your roadmap work and the opportunity cost of being distracted with bugs.

> - Additionally, would this potentially slow down my first promotion to mid-level by quite a bit?

I imagine it would slow down that first promotion by at least 3 months, haha.

Overall, delaying the start date to do the internship makes this pretty awkward. I'm now leaning against it, especially as you really like your Amazon team.

If you can share more about your goals here, that would be really helpful. As is, it seems like you should follow up with that introduction to be nice to the person who made it and have some sort of initial call. After that, it's not likely you'll talk ever again.

These sorts of connections are awkward, but it's a natural part of networking. Some are hits, but most are misses. But if you play your cards right, your hits are extremely huge. We talk about this all in-depth here: [\[Masterclass\] How To Build Deep Relationships Quickly In Tech](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/masterclass-how-to-build-deep-relationships-quickly-in-tech/)

I don't know the exact specifics as in my day, everyone went through bootcamp, but bootcamp culture is unfortunately dying off and being replaced with the Google-style team match. If I were to guess, the offer is probably contingent on a team wanting you. I imagine Meta just wants everything on the hiring side to be a lot cleaner now and putting more pressure on the candidate to convince a team to take them in will do that.

Getting into Meta now is 100% better than getting into Meta later. The problem is getting in.

I have a different opinion to Rahul in that waiting until January seems like a good option, and I think I'm leaning towards it (but not by much). Here's why:

- The Meta interview is extremely hard, especially for E5. 60% prepared still has a 40% gap. Keep in mind that the Meta bar is substantially higher now with "year of efficiency". Back when I was a Meta interview, I saw people with "Weak Yes" (and even that is hard to get as a score) get an offer. This isn't happening anymore
- Team matching will be way better in January as most teams are effectively half brain-dead in late November and most of December
- Meta does E5 hiring perennially, so headcount will definitely still be open by January 2025. Meta is unique here, similar to Google, [in that it does central hiring](https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/why-does-faang-do-this/)

I don't think there's a competition angle. The bar will not be lower in November/December. If anything, it could be higher as if you interview during the holidays, the people remaining at the office could be super hardcore. I had a workaholic teammate at Instagram who stayed around during the holidays, and he was pretty brutal in interviews (I never saw him pass anybody and he gave a ton of hard "No's").

That being said, Meta recruiting (like all recruiting) can be kind of derpy and leaving a thread open for 2 months is risky. The energy will die down, and your packet could be lost in the shuffle.

Anyways, I hope these help:

- [\[Course\] Master The Behavioral Interview As A Software Engineer](https://www.jointaro.com/course/master-the-behavioral-interview-as-a-software-engineer/)
- [\[Course\] Master The Data Structures And Algorithms Interview](https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/)
- ["How does the Meta interview work?"](https://www.jointaro.com/question/Ne8lv2jCMZGuSGkr8wp9/how-does-the-meta-interview-work/)

Ah, the elevator OOP question is such a classic.

Unlike LeetCode, OOP is real and is something software engineers actually do and should know. If a company does Java for example (my primary language historically), then it should do OOP, that's the main point of the language.

This makes preparation quite straightforward. Just write OOP code: <https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/object-oriented-programming-oop/>

Side projects are great for this if you can connect an OOP use-case to an actual product, but OOP is something that can be done in isolation on Replit or something.

> On the scale of abstraction, it's not nitty gritty like Leetcode questions where you need to write the logic for every part of your code and actually run code...

You often don't need to run the code in an OOP interview, but to really practice, I think you ideally should. For example with the elevator problem, you can write APIs like elevator.takeInPeople(people: List&lt;People&gt;) and then call them. After the APIs are called, you can print out state like number of people in the elevator and make sure that the state is correct.

The closer something is to real life, the better the practice is. This is why I haven't studied for an OOP interview for 8+ years. I just got really good at OOP writing Java for my jobs and side projects that solving an OOP problem feels natural.

This feels like a micro-optimization. The opinion of a newbie won't hold too much weight for a referral. Also, your friend needs to do the following:

1. Get the offer
2. Accept the offer
3. Start the job

1-3 is not guaranteed and it could take a long time. I think you can just apply and mention that your friend is also in the loop and supposedly doing well.

You could wait if the company is smaller and you think headcount will still be open in 1-2 months. Otherwise it feels risky. For juniors, you just need to apply often and apply early in this market.

Good question! Unfortunately, the answers are quite tricky and vary a lot based on company 😅

> What are some quantifiable metrics that engineers can use to demonstrate the efficacy and cost-effectiveness of their technical proposals?

Well, there's only 1, which is money $$$. The tricky part is how do you calculate the $$$ saved?

The process here is to calculate a metric that's 1 layer removed with a known conversion to $$$. For example, if you know that storing 1TB of user data costs you $1000 and you optimize a flow via data compression to generate 50TB of data per month instead of 100TB per month, you can say that you're saving $50,000 per month or $600,000 per year.

In terms of the conversion, it will vary based on the SaaS infrastructure products you use or how your own software is built if you're doing things in-house.

At Meta, we had all of this tooling built in-house where you could run an A/B test and just see the savings. If the thing you were measuring against didn't have the collection, you would need to talk to someone on the infra side like an SRE, data engineer, etc.

> What are some quantifiable metrics that engineers can use to demonstrate the efficacy and cost-effectiveness of their technical proposals?

I really doubt there's standard tools besides general A/B testing frameworks where you would still need to add the custom logging. Again, this varies a ton based on the type of bug and product it affects.

For a concrete example, check this out: [\[Case Study\] Solving A Multi-Million $$ Instagram Bug](https://www.jointaro.com/lesson/WYk4J05iBqOuPtD0CYKX/case-study-solving-a-multi-million-dollardollar-instagram-bug/)

> What approaches can I use to measure and present reductions in coding and discovery time? Any suggestions on metrics or tools that can help quantify these time savings in terms of cost?

For projects that make the codebase better, it is really hard to holistically measure. You need more anecdotal evidence. You could also run a survey. More thoughts here: ["How do you measure the impact of refactoring your codebase to use a new pattern?"](https://www.jointaro.com/question/reItyrYxp8rMCyC03v2u/how-do-you-measure-the-impact-of-refactoring-your-codebase-to-use-a-new-pattern/)

> How can I illustrate the cost benefits of implementing scalable solutions that accommodate future changes without additional coding? Are there ways to forecast and present these long-term savings?

You would need to calculate dev time and multiply it by an average cost of an engineering hour. So if the average engineer gets paid $100/hour in your org, and you take a 40 hour coding task and reduce it to 0, every instance is worth $4000.

> Are there recommended tools, methodologies, or frameworks that assist in gathering and presenting these metrics effectively to a cost-focused audience?

I recommend making a slide deck with as many charts as possible. Executives can't read code anymore, and people in general don't like walls of text. Be visual and show deltas.

I was an intern manager at Meta, mentored other interns directly, and even mentored other intern managers, so I can share some advice here. I'm glad you're interested in raising an intern - It's a very fulfilling experience!

### Intern Project Constraints

It's important to remember that interns are effectively clueless children, especially if it's their 1st internship. Because of this, make sure that the project is:

1. **Well-defined** - The requirements, designs, and technical architecture should be crystal clear. They are largely expected to just be able to code things out.
2. **Doesn't involve cross-functional (XFN) partners** - The definition of XFN is either someone outside of engineering (e.g. legal, design, product) or an engineer that reports to a different director of engineering (sister team isn't too bad).
3. **Is low technical complexity** - It should be something that you can code up in your sleep as a fully-fledged full-time engineer.
4. **Is self-contained** - The project should just be 1 big thing on its own, not a bunch of smaller disconnected projects or tasks awkwardly bundled up. At worst, give your intern 2 medium-sized projects (1.25 months each). Very junior engineers are extremely bad at context switching.

When it comes to projects that meet all of these requirements, especially at Big Tech, internal tools are great. I feel like most Meta interns worked on internal tools - By the time I was an intern manager, the stakes for Meta were too high to give mission-critical pieces to interns (don't want an intern causing a massive security leak or something and leading to another wave of bad press for Meta 😅). I made my intern build an internal tool (I talk about it in-depth [in my L4 -&gt; L5 course here](https://www.jointaro.com/course/grow-from-mid-level-to-senior-senior-l4-to-l5/instagram-ads-testing-tool/)), and all the other interns I mentored also worked on internal tools.

### How To Find Intern Projects

The absolute best way to come up with an intern project is to look at your workload and see if you can cleanly partition off some non-complex piece to give to someone else. One way to do that is to look at the problems you're facing - Is there a pain point you have that can be solved with code? If so, congrats - You might have discovered a great internal tool opportunity!

If there isn't scope that you can carve off from your own, look at your team's overall backlog. Just sift through projects until you find something that meets all the requirements.

### Deliverable

Your end goal is to create a master spec for the proposed project. It should be very similar to the one I made for this course here: [System Design Masterclass: Shipping Real Features To Production](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)

The doc doesn't have to be as insanely detailed as mine though. An intern project will be way lower complexity, both on the technical side and the people side.

Got it - That makes a lot of sense to me.

What I will say is that the ownership and learning at a top startup (like Applied Intuition) will almost *always* be superior to what you can find at FAANG. When you are deciding between a unicorn and FAANG, the main benefit of FAANG is the name brand. Meta in particular complicates things as I do think it's the most prestigious among FAANG as its youngest member (i.e. highest reputation for talent).

Going to Applied Intuition seems like a good choice, and it's not a 1-way door. You seem like a smart person who could get into Meta again if Applied didn't work out for whatever reason.

Good luck!

Okay, this seems like an internal-facing team, but I wouldn't let that hurt your perception of the role. At the scale of an Nvidia, Meta, Google, etc, there are so many engineers that teams like these can easily have senior/staff/principal scope. There were many E7s/E8s at Meta (senior staff/principal) who literally only worked on internal tools. Being customer-facing isn't pure upside either as interfacing with them can be incredibly annoying. More thoughts here: ["Between platform (serving developers) and product teams (serving end customers), what should be one's preference based on level?"](https://www.jointaro.com/question/zyEImoKWObsSm8YymzvT/between-platform-serving-developers-and-product-teams-serving-end-customers-what-should-be-ones-preference-based-on-level/)

> However, before getting to that stage, I want to be confident about the growth opportunities this role provides.

Growth opportunities are far less dependent on the role/space and far more dependent on the quality of manager. I've seen great managers take relatively dry areas and create lots of scope. Conversely, I've seen terrible managers take scope-rich areas and have their teams land 0 impact within it.

My advice is to really pay attention when talking to the hiring manager and do a good job [reverse interviewing them](https://www.jointaro.com/course/master-the-behavioral-interview-as-a-software-engineer/interviews-are-a-2-way-street/). People don't leave companies or orgs, they leave managers 😉

Thank you for the kind words about the courses! I'm really glad they were helpful 😊

> Do the Google interview, and if I get the offer, go to Google for an internship before joining Amazon full time

How feasible is this? If you can just sort of get an Google internship along the way to your Amazon role without any real friction, that seems good (it's just more experience and you can potentially unlock Google FTE).

Amazon's a great company of course, but I do put Google above it. I'm unsure how the comps are different in Canada though. In some markets, the difference is real wide (usually in Google's favor).

That being said, a bird in hand is worth 2 in the bush (arguably more). Just make sure not to jeopardize your Amazon return offer. Yes, Amazon promotions are slow, [especially for SDE 2 -&gt; SDE 3](https://www.jointaro.com/question/Tno7LGeINpsTPrljUTTT/how-to-navigate-the-difficult-sde-2-to-sde-3-promotion/), but I'm sure you could do SDE 1 -&gt; SDE 2 pretty quickly, especially with the help of this: [\[Course\] 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/)

From what I've seen, junior to mid-level promotion speed at Amazon is more inline with peer companies. Mid-level to senior is what makes Amazon particularly brutal.

Honestly, I would just say that you're a software engineer. It is tricky though if you work at a Big Tech company though with clear, known levels and they specifically ask something like if you're Amazon SDE 1 or Amazon SDE 2.

There's some nice communication tricks here too: ["Recruiter asking what my current level is when applying for new roles - how to answer?"](https://www.jointaro.com/question/2fK71r3NhIuhLzq07atk/recruiter-asking-what-my-current-level-is-when-applying-for-new-roles-how-to-answer/)

> What other type of value can I add in this market when people are not really looking to hire?

Off the top of my head:

1. Contributing to their open-source
2. Building a side project with them
3. Engaging with their content if they post to social media

Those are standard tech things - It's hard to fully "playbook" a relationship. Just be genuinely interested in them and see how you can help. It doesn't have to be an engineering thing either. Maybe they're looking for a gym buddy, and you realize that it makes sense for you to start working out as well.

> At what point do I ask for a favour which is a referral to a job position?

It's hard to quantify, but the main things are:

1. The relationship has some amount of age on it (&gt;3 months IMHO)
2. You have actually worked on something together
3. You have done something of substantial value for them (even the gym buddy example is pretty valuable IMHO, accountability is important)

Holy smokes, congrats on the offers! Seems like you crushed it.

I'm biased, but I personally recommend Meta as it looks like this is for your first full-time job? On top of [all the standard benefits of working at Big Tech](https://www.jointaro.com/lesson/JnEnRphdi5TaPZl1Zrl8/masterclass-should-you-work-at-faang-what-big-tech-is-like-for-software-engineers/) and getting the name brand on your resume, Meta has some unique benefits among FAANG:

- It's the most "startup-ey" among them and moves quite fast
- It gives engineers a huge amount of autonomy, especially when it comes to product direction. It's the main company with a [formal product hybrid Staff Engineer archetype](https://www.jointaro.com/lesson/8XCtYTOZD4GJm9rcKuAL/grow-from-senior-to-staff-engineer-part-18-product-hybrid/)
- It's a great place to find cofounders as it's huge, has good talent, and the most "startup-ey" vibe among Big Tech

That being said, there are many unicorns I would personally recommend over Meta. If you don't mind sharing, I can give a more detailed opinion.

This course has a detailed technical design doc which I personally wrote: [System Design Masterclass: Shipping Real Features To Production](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)

It's old but the content still mostly holds up. It's on my roadmap to redo it and modernize it, but there are a lot of projects ahead of it 😅

> I don't understand the difference between a Software Architecture document and a RFC. Are they the same?

It really depends on the company - Some places can be super finicky about lingo. From my perspective, RFC = request for comment, and like the name suggests, it's anything requesting a comment from a design doc to a pull request. So a software architecture document will RFC by default but not all RFCs are software architecture documents if that makes sense.

Software architecture documents go by many, many names depending on where you've worked:

- Tech docs
- Tech specs
- Design docs
- Technical design doc
- System design doc

This feels both fairly specific and vague: What have you been able to get from Glassdoor, Blind, the JD, and the recruiter?

> Given my background in backend and distributed systems, would a non-revenue-generating role like this offer good growth opportunities at Nvidia?

You seem infra-adjacent, so I think you'll be fine. [If you're operating comfortably at senior](https://www.jointaro.com/course/grow-from-mid-level-to-senior-senior-l4-to-l5/), the differences shouldn't be too meaningful as you should be able to pick up new stuff on the fly.

Also, it's hard for an infrastructure role *not* to be revenue-generating or just 1-2 layers removed. A classic infrastructure workstream is to make optimizations to remove costs, especially in this economy where every Big Tech company is trying to do "year of efficiency".

It's complicated as companies don't standardize leveling. At Cisco for example, tech lead is an official rank. After SW4, there is Tech 1 and Tech Lead 2, which will translate to senior and staff at top companies like FAANG.

At Big Tech, tech lead is usually not a level in and of itself but rather a role. You can be on the later end of L4 (mid-level) and be functioning as a tech lead (and referred to as one). You can be L6 (staff) and not functioning as a tech lead as you're a more individual archetype like code machine or fixer.

> Damn that sounds interesting. Could you give an example of what you mean by 'tactical' here?

Stuff explaining what a binary search tree is, how depth-first search works, etc

I have heard that Apple in particular will require certain languages for interviews often. Since you have been asked to interview in C, you should definitely do everything in C. As Rahul mentioned, you should leverage the interviewer to sidestep boilerplate DSA coding - There isn't much signal on them having you create the HashSet data structure from scratch.

I talk about this all more in-depth in this lesson of my DSA course: <https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/missing-what-matters/>

Coaching can be worth it if you meet these criteria:

1. You struggle substantially with self-accountability
2. You have a big time crunch
3. You have lots of $$$ (selling human time is expensive, especially in tech)

Most people don't meet all the requirements, so I generally recommend people avoid coaching options, pushing them to self-learn first with resources like Taro. There are definitely people where coaching makes sense though, so I would do some introspection and figure that out for yourself.

\#1 is often the biggest reason people seek coaching, but the thing is you need to fix that problem after you get the job anyways. If you can't do quality self-studying for interviews and then you break into a company like Meta, it's not likely you will survive there.

Overall, my mentality here is similar to what I say about [Formation.dev](http://Formation.dev): ["Experience with formation dev"](https://www.jointaro.com/question/dHwWkp5C76fqnFyQr1H4/experience-with-formation-dev/)

That's a great idea! I think it could be a good focused 45-60 minute course - The tricky part is giving good high-level advice that can be applied to any codebase. The caveat is that having deep dives on large codebases is tricky as those belong to companies, and companies keep their code strictly confidential.

We'll do more thinking on this - Rahul has written some viral social media content about it, so he'll share more thoughts.

Yeah, that should more or less do it. Past 1 month seems a bit short, so I would recommend just starting off with past 3 months to normalize the sample unless you are very stretched for time and can only do 1 month's worth of problems.

If you haven't already, I highly recommend my DSA/LeetCode course here: [Master The Data Structures And Algorithms Interview](https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/)

The solution here is straightforward: *You need to get on those meetings.*

Unfortunately, what your tech lead is doing is very common where they restrict access to information. This can be done due to a more closed-off company culture, them being more selfish (you are technically more valuable if you are the only one with critical information), or a mix of the 2 reasons.

No matter the reason, you need to fix this. You should go to your manager and use them as an intermediary to deliver feedback to your lead to get you on those meetings. *Make sure to provide clear examples of how missing key information led to you struggling to land impact efficiently on the project.* Your goal is to provide a well-thought out case with evidence, so it doesn't seem like you're just complaining.

I know a lot of people at Cisco, so I'm fairly familiar with Cisco leveling. Assuming Meraki uses the same system as core Cisco, Tech Lead 1/2 should map to the higher-end of Meta E5 and Meta E6. I recommend going through the senior to staff course to further understand these levels: [Grow From Senior To Staff Engineer: L5 To L6](https://www.jointaro.com/course/grow-from-senior-to-staff-engineer-l5-to-l6/)

If you go to L5 properly, L6 should largely feel like you're doing L5 things but better and with larger scope. If I were to guess, this is why this promotion doesn't feel transformational.

I recommend this tech lead course as well: [Tech Lead Blueprint: Role, Skills, and Strategies](https://www.jointaro.com/course/tech-lead-blueprint-role-skills-and-strategies/)

Congrats on getting to Technical Leader!

Wow, this is super weird. 2 directors and 1 senior EM is also strange as M-track folks usually only do system design and behavioral interviews, so you should have 2 max.

Regardless, this doesn't change anything. Good luck on your interview and follow the advice here: ["How does the Meta interview work?"](https://www.jointaro.com/question/Ne8lv2jCMZGuSGkr8wp9/how-does-the-meta-interview-work/)

At Big Tech, it's not super common for senior engineers to have regular meetings with their skip, that's more of a staff-level thing. Regardless, you can try as it certainly wouldn't hurt to talk to them and establish yourself as a friendly face. Here's a good video to prepare for it: [How To Effectively Leverage Skip Level 1:1s](https://www.jointaro.com/lesson/TToehFEc738PBhJcALwL/how-to-effectively-leverage-skip-level-11s/)

> 2\. Should I tell my manager I'm talking to my skip level ie his manager?

It's not a requirement to tell your manager, but you might as well since your manager would be the most effective "broker" to help you set up that meeting. Just tell your manager that you're interested in talking to the skip and see if they can help. If you have already started off on a good foot with your manager, they can put in a good word for you with the skip to make the meeting more productive.

On top of all this, I highly recommend the onboarding course: [The Complete Onboarding Guide For Software Engineers](https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/)

Oof, 1 day is not a ton of time. I would do this:

1. Binge the new data structures and algorithms course: [\[Course\] Master The Data Structures And Algorithms Interview](https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/)
2. Try to do 5-10 LeetCode problems in the next 24 hours. Make sure to follow the advice from the course to learn them properly
3. Get great sleep the night before and listen to some peaceful music 30 minutes before the interview. This will [maximize your dynamic state](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/dynamic-state-vs-prepared-state/), which you'll 200% need given minimal prep

Good luck!

I don't think it's fair to use layoffs as a measuring stick - Virtually every company (including FAANG) had massive layoffs from late 2022 to now.

Brex is definitely overvalued right now (like almost every other tech unicorn), but the tech industry tends to recover faster than people think, and Brex is filled with incredibly talented people to make that happen.

> How would you recommend thinking about layoffs and a bad year in the context of evaluating a late stage startup?

For layoffs, it's tricky as you need to differentiate between them being a necessary obstacle to overcome on the path to thriving (Robinhood had 3 waves of layoffs but is doing great now, look at the stock price) and them being a sign of the company's inevitable downward spiral and death (e.g. if AMC did a huge wave of layoffs, it's because of that). I believe that Brex is in the first camp, but I'm obviously biased as I'm YC and I love their product.

More thoughts on evaluating a company's quality here:

- ["Thoughts on breakout/rocket ship startups vs big tech"](https://www.jointaro.com/question/1DNzxUjy0w8uLLwWGIXZ/thoughts-on-breakoutrocket-ship-startups-vs-big-tech/)
- ["How do you assess company’s market position (especially startups)?"](https://www.jointaro.com/question/a7FnIiTBwfMHm4V72W7q/how-do-you-assess-companys-market-position-especially-startups/)

I assume you're a machine learning engineer in your Big Tech ML org? If you feel like you're not getting the depth you need, you should switch teams. Open-source can help, but hands-on business experience, especially at a top company, reigns supreme. Availability of options is one of the biggest benefits of working at a Big Tech company.

Another thing you can do is just apply to a bunch of ML roles and see what happens. Maybe your lack of knowledge isn't as bad as you think. I have seen so many engineers underestimate themselves 😛

In general, you want to take multiple approaches for solving any problem. If you have the resources, you can try applying to a green card yourself. On top of that, apply to jobs that offer visa sponsorship alongside big international companies (e.g. FAANG) that have a presence in your region (if you get into these, you can go for the internal transfer route).

What I will say is that green card depends on your country of origin with there being a quota for each one. It's a dumb system IMHO, but that's how it is. This makes China and India in particular really rough as you can easily be waiting for 10+ years to get your green card. Filing for green card is very resource-intensive, so most engineers come to the US on a visa (usually OPT or H-1B) and then have their company submit a green card application for them.

Yes!

Brex is *easily* one of the hottest unicorns, coming in at a $12.3 billion valuation. It's one of the breakout stars of YC and is often shared as a success story to emulate. Almost every recent YC company uses Brex for their banking, including us! It's an extremely good product, and I'm very confident they will go public within 5 years.

If the package on paper beats your current compensation by 50% or more, I think Brex would be a good option. There is risk in the equity, but as I mentioned before, it's smaller compared to most startups as Brex is pretty far along. Fintech is also an incredible place to be as it's very scalable, and you can't go wrong holding billions to trillions of dollars of other people's assets (I worked at Robinhood so I would know).

As usual, it looks like the recruiter is playing the negotiation game with you. If you remotely like your current job in any way, make sure to play it up. Make it seem like they need to pry you away from your current role, so they're pressured to give you a high number. Once you get that initial number, you can have more concrete negotiations and get more detailed feedback from the community. If you're more risk-averse, you can also let the recruiter know that you would prefer more cash instead of equity.

Check out the negotiation course if you haven't already: [\[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/)

Congrats on the offer!

**Final note:** There are non-tactical reasons for a sub-par memory. In particular, if your overall well-being isn't in tip-top shape, it is easy for your brain to fall behind, *especially* if it's super stressed out. Make sure to take care of yourself outside of work:

1. Get a consistent 8 hours of sleep
2. Stay hydrated
3. Exercise regularly
4. Maintain a thriving social life

More thoughts here: ["How do you make sure you stay healthy as an office worker?"](https://www.jointaro.com/question/yzSAlrCeJwoKeD3pPI7w/how-do-you-make-sure-you-stay-healthy-as-an-office-worker/)

I dig into all this more in-depth in my productivity course too: [\[Course\] Maximize Your Productivity As A Software Engineer](https://www.jointaro.com/course/maximize-your-productivity-as-a-software-engineer/)

When it comes to advice, here's my biggest one: **Write stuff down.**

This manifests across 3 stages:

1. **Before the code** - Make sure that the task is crystal clear. In particular, you should understand the full feature set that stakeholders want you to build out. After that, outline your approach (including the edge cases) and get feedback.
2. **During the code** - Submit a clean, well-documented PR. Keep doing the self-review that you're already doing. When people comment on your PRs, push them for more detailed explanations if you don't both fully understand their feedback *and how they got to it.* Every PR is essentially a valuable artifact of documentation.
3. **After the code** - If a PR didn't go well because you missed a lot of stuff, *write it down.* This one is the most important; you need to ensure that you're learning as much stuff from your mistakes as possible. Over time, you will assemble a giant *"Stuff I've Missed"* journal. Look over that journal before you submit any future PRs.

Here's 2 more threads that I highly, highly recommend:

- ["Tips for someone with poor working memory?"](https://www.jointaro.com/question/55fEwxKMxTLMyiurKdBH/tips-for-someone-with-poor-working-memory/)
- ["How to ensure mistakes do not repeat?"](https://www.jointaro.com/question/dEgyk5swYBwPLO1lws22/how-to-ensure-mistakes-do-not-repeat/)

Zooming out, most engineers severely underestimate the amount of non-code writing they need to do. If you work at a good, fast-moving, modern company in particular stuff will move fast. Only the most brilliant geniuses will be able to keep up through sheer perfect memory - More "normal" people like us need to rigorously and constantly leave behind a trail of high-quality documentation to keep up. Writing is one of the most important skills for any human to develop though, so it's not a waste!

After you go through the related discussions, I highly recommend the code quality course too: [\[Course\] Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)

Before I give any concrete advice, I just want to say that it feels like you're beating yourself up too much over this and you seem like a good engineer with good instincts 😊

For what it's worth, it's common for engineers around your level to keep missing stuff. Most of my E3 (junior) Meta mentees were still making basic mistakes 6-9 months in, and you're in that range for your current job. I did have some mentees that stopped making basic mistakes 3 months in, but they had a natural talent 99% of engineers don't have, myself included. It's not reasonable to compare yourself too stringently against those people - It's not realistic.

You've gotten good reviews, even getting "Exceeds" sometimes, so I don't think this is a huge cause for concern. Make sure to follow [the advice in Taro around avoiding a PIP ](https://www.jointaro.com/course/the-ultimate-performance-improvement-plan-pip-guide/how-to-avoid-a-pip/)(maintain a transparent dialog with your manager, probe for feedback, be humble), and you should be okay!

> I agree with your assessment, but what I’m trying to understand is *how much worse* is Applied compared to DB and Notion.

It's to the point where it's a no-brainer to take Databricks/Notion over it. As you mentioned, it's hard to quantify.

> If the gap is super huge, what companies would you put in between them (to get a sense of scale)?

The gap is substantial, but I don't want to put companies in between them or create any remotely concrete tier list in general as it oversimplifies the topic and will offend people at those companies (people don't want to be shown lower on a tier list 😜).

Just know that Applied Intuition is a solid company. Yes, you could do better, but you could easily, easily do worse. In this market, junior folks tend to not have much of a choice anyways - Interview and see what you get. I imagine Applied Intuition's rejection rate is insanely high right now. No need to worry about this hypothetical too much.

It's half-baked (the descriptions are placeholders or empty), but you can watch it here: [\[Course\] Master The Data Structures And Algorithms Interview](https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/)

If you know it's DSA, your path forward is exactly the same. Obviously giving an E6 performance would be great for an E5 loop, haha.

Good luck!

*A follow-up is requested when a candidate is borderline.*

If you interviewed for E6, this is somewhat common (still rare overall but common relative to other levels). This is because E6 hires are very valuable and Meta doesn't want to let go of a potentially good E6 if there's a chance.

The most common case for follow-up E6 interviews *is another DSA round*. I literally presided over this exact case before and was the one who triggered the follow-up. It is very common for E6s to have rusty coding skills as many Staff+ engineers (especially outside of FAANG) are more of a traditional "architect" role that Meta is allergic too (making high-level decisions but not coding).

Luckily for you, I just released my new DSA course! If it is a DSA round and you follow all the advice from the course (you'll need it as the E6 bar is super high), you'll surely ace the interview: [\[Course\] Master The Data Structures And Algorithms Interview](https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/)

However, make extra sure what round it is first. It might be some form of system design (not likely if they said it was coding in particular, but I would check anyways).

So if you have large clients, definitely mention them by name. Don't be afraid to use ballparks.

For example, let's say you're building an app to help Home Depot's warehouse workers and there are 475,000 of them (this is a super rough number I pulled from Google for the sake of the example). You can say something like *"Delivered an inventory solution for Home Depot's 475,000 warehouse workers"*. You have 0 idea of how many workers among that pool are actually using your software, but this statement is also technically true as it is for that general group overall.

If you can't do that for any of your prior projects, make sure to add basic logging to your future projects so you stop this lack of numbers bleeding. I imagine your clients would want to know metrics too, so that's a win-win. Of course, the overall business wants to know as well - There's no point writing software with 0 users. This is classic senior+ engineer behavior and building a logging instinct was a huge part of my growth from mid-level to senior at Meta. Check out this thread: ["How do you measure the impact of an initiative you are leading?"](https://www.jointaro.com/question/DpEnhErWq3fZ5eICaP19/how-do-you-measure-the-impact-of-an-initiative-you-are-leading/)

I have heard of Applied Intuition, but I personally would put it below Databricks and Notion. It's a name I know but don't feel like it's constantly in the zeitgeist like Databricks/Notion (and certainly not at the level of OpenAI or Anthropic). I feel like self-driving cars have been mostly a failure (tons of layoffs and botched betas), but Waymo has admittedly gained a *ton* of traction recently. If it wasn't for Waymo's recent smash success, I would actually have leaned away from it (unless it was your only offer of course).

Overall, it seems like a solid company, and I'm sure there's talent there. Probably a solid place to start your career. Check out this thread as well: ["How do you assess company’s market position (especially startups)?"](https://www.jointaro.com/question/a7FnIiTBwfMHm4V72W7q/how-do-you-assess-companys-market-position-especially-startups/)

Great questions!

> ...that a candidate asks more **clarifying questions** and **edge cases**. Aren't these pretty much the same thing?

They are deeply connected, but not the same thing. Clarifying questions tee up your ability to find edge cases. For example, take this clarifying question:

> What is the type of the input parameters? Int or Float?

You need to ask this question as it will literally affect your code, and the answer will help you come up with edge cases after the solution is written. However, I don't think you would ask *all* the specific follow-up questions afterwards of whether ints can be huge (INT_MAX), you can get a bunch of duplicates, etc. If you do that, you would be directly and fully merging the clarifying questions and the edge cases together, and you would spend like 10-15 minutes just asking questions before coding (i.e. way too long). Something else to keep in mind is you need to be careful on the follow-up; the failure mode is that you spend 5-10 minutes discussing a single tricky edge case instead of actually writing code.

Another example of a good clarifying question to ask for the k-closest points example I worked through is the tie-break one. If the interviewer wants some strange algorithm, that will directly affect your implementation in a major way, so you need to catch it ASAP. Looking back at the course, I do think I could have phrased the clarifying questions section better as a lot of the questions are sort of sub-questions that can be merged together into 1 grand question. For example, with the tiebreak question, you can quickly iterate through the options to show how forward thinking you are but still ask it in 1 big question.

In a nutshell, you want to ask the main questions that will affect the core implementation engine of your code. Anything that can be handled with an if-statement (e.g. null input) isn't that important.

The overall process should be:

1. Ask sharp clarifying questions to mold the code and *set up the **foundation** to dig deep into edge cases later*
2. Write clean code that handles the happy flow very well. If you can account for edge cases proactively by writing good code, do it. Otherwise, don't it (i.e. you need to write some super narrow if-statement)
3. Talk about the solution, which will include edge cases if the interviewer is pushing you hard as many FAANG interviewers do. If they force you to account for an edge case in code, do it

Hopefully this makes sense - Your question definitely isn't a ramble, and if you need more clarification, just respond to this 😊

Pre-Big Tech constraints:

- $5B+ valuation (this is an unscientific number, but it definitely needs to be at least a unicorn)
- Pay packages on paper are the same as FAANG (usually higher). Most Tier 1 unicorns will have their on paper packages be 25% - 75% higher than FAANG as you still are taking some risk joining a pre-IPO
- Growing super fast valuation-wise, usually just having 1-2 year gaps (maybe even smaller) between blockbuster funding rounds
- Has raised a *ton* of capital, $250M+
- Hires a ton of people from FAANG and FAANG-adjacent companies (Airbnb, Uber, DoorDash)
- Lots of top-tier press attention, largely from their blockbuster funding rounds (TechCrunch, The Verge)

Number of people will vary a lot among these companies. Some companies are more aggressive than others. For example, Robinhood was pretty conservative with hiring up until their Series D. Other companies will start trying to 3x - 5x headcount year over year after raising a large Series A. This is why some companies with $5B valuation will only have like 100 people while others will already have 500+ people. It's less about the current state and more about the momentum and future trajectory.

I unfortunately don't know much about Flutter vs. React Native as I've literally never interacted with Flutter before. I've never written React Native code either, but I have helped with big efforts to rip it out of Instagram hehe.

If you're 100% sure you want to do cross-platform, I recommend sticking to your strengths. If you have written JavaScript/TypeScript before, React Native makes more sense. I think Flutter is written in Dart, so if you already have Dart experience somehow, do that. Another angle to consider is your network: If you have a ton of engineering friends who are Flutter masters, that's a great argument to just do Flutter.

> How fast are native mobile apps when compared to react native/flutter apps?

This is a hard question as it depends on scale. If you are building a relatively basic CRUD app (i.e. many startups), the performance difference is negligible. If you are FAANG, the difference is huge; it can be up to 1-2 seconds latency delta when loading pages (this is the impact I saw when migrating React Native to native at Instagram). At that scale, that is easily a $50M+ improvement when it comes to revenue (I worked on ads).

> Do native mobile apps inherently support some more features (like running ML models on-device?) that react native/flutter apps can't support?

Yes. Anything that's more performance-sensitive and complicated is much better suited for native development. Video is a great example here - There are so many OS-specific gotchas and it's so complicated that doing it in cross-platform is hell.

If you care about performance (like Big Tech) but are doing cross-platform, you have to do native bridging here. Either that or be content with shipping a very messy version (bad latency, more random errors, reliability issues) using the cross-platform video player widget.

You can read more in-depth about the tradeoffs between native mobile and cross-platform here: ["Android (Kotlin) vs. React Native"](https://www.jointaro.com/question/KUeUaVRfcjrnjGDcFuZC/android-kotlin-vs-react-native/)

> Is it preferrable to use react native/flutter until the app reaches a certain scale and then switch to native mobile development?

That's a very, very painful migration. Engineering orgs and companies should make the right call upfront. For example, Robinhood knew from the get-go they wanted to deliver a world-class mobile experience (amazing perf, tight reliability, beautiful animations), so they started off with native and never looked back. However, there are counterexamples - Airbnb famously started off with React Native and then migrated over. However, these top-tier company examples of successful migrations from cross-platform to native are *extremely* rare. I literally don't know of any other examples besides Airbnb.

> A question I have is how big is the difference in the brand value between your average breakout startup and a big tech? Is it negligible?

This is a tricky question as a "breakout" implies non-average. So I looked through the first \~35 companies on your linked spreadsheet and used that as an average.

*If we're using that as the measuring stick, I do think there's a big gap in Big Tech's favor.* For example, I have never heard of ClickHouse (which is on that list), and if I haven't heard of it (it's literally my job to keep tabs on the overall tech scene and I'm a Silicon Valley native), there's a good chance many recruiters haven't either.

That spreadsheet is pretty wild as it has companies like Notion (probably 2x stronger brand value than FAANG) and then stuff like ClickHouse. **Huge** variance, haha.

> Funnily enough Sam Altman laments that someone picked big tech over a breakout startup.

Sam Altman is one of the most biased and privileged people to say this LOL. Dude literally runs OpenAI. The second ChatGPT launched, the brand value of getting an OpenAI offer instantly jumped to 5x that of a traditional FAANG offer. OpenAI is the most exciting company to work for right now, and it's not even close. It's reflected in their compensation too as OpenAI pays 50%+ more than Meta and Meta is already known as a company that pays top-of-market *even within FAANG*. That combination is just so incredibly potent. Literally nobody in Silicon Valley thinks that a Google/Meta offer is better than an OpenAI one due to them being more stable/traditional.

I feel like this question is bit off as companies like OpenAI and Databricks are *clearly* not really startups anymore. OpenAI in particular isn't as it's going to raise at a $150 billion valuation, bigger than 95% of large tech companies (literally 2x bigger than PayPal which is a storied, legendary, huge tech company). I had a coworker who described these companies well: These companies are *"pre-Big Tech"* as everyone knows they're going to reach that $10B+ scale someday with similar pay/prestige.

You would **obviously** go to these companies over FAANG - They will almost certainly pay more in the medium/long-term, and you'll have way more scope. I would recommend the same thing in the past if an engineer had a Google offer vs. a Series D Robinhood offer or something. Same with pre-IPO Uber, DoorDash, Pinterest, Airbnb, etc. Notion is another great example of a unicorn that is almost certainly going to succeed - Definitely take that over Amazon/Google/Meta if you have a Notion offer as a new grad.

Where it gets tricky is when you're outside the super, super top tier with hot Series A/B/C companies that haven't raised at a +$1 billion valuation yet. So they clearly have a lot of potential, but they're not as proven as something like OpenAI. At that point it really go either way, but I would recommend Big Tech. Even among Big Tech, there are layers: I personally consider Meta the best FAANG compay and it's a considerable amount better for early career growth compared to something like Microsoft.

The beautiful thing about mobile is that it's the absolute best when it comes to side projects. Keep on building, and my recommendation is to publish apps and *maintain them over a long period of time*. You don't learn that much publishing new app after new app, never taking them past a v1.

I need to make a dedicated side project course at some point, but in the meantime, I recommend the resources here (particularly the masterclasses): [\[Taro Top 10\] Building Impressive Side Projects](https://www.jointaro.com/playlist/vKUWMgmmaEvzcYUXZs4B/)

Side projects literally made my career: I have published 30 apps with 5+ of them getting 100k+ users. To this day, I still get dozens of interviews from top companies due to my side projects. I genuinely believe that anybody else can do the same.

I'm glad to hear that there's a lot of job opportunities in Hungary! In the US, it honestly feels like everyone is thirsty but is walking around in a desert 🥹

If you really need a job fast, I think you should be pragmatic. At the end of the day, paychecks are extremely important, especially if you are supporting people besides yourself. Here's my advice:

- **Apply to back-end roles as well** - *However, apply to back-end roles at product-based companies where there is a mobile component.* In the US, it's very common to have "wide" product teams where all types of engineers blend together (i.e. Android, iOS, back-end all report to the same manager). This is contrast to a more "vertical" team where it's only back-end engineers, only ML engineers, etc. Anyways, you should be open to taking a back-end role in a team where you can dabble in mobile on the side and hopefully transition into mobile full-time once you have earned enough trust.
- **Understand your mobile market** - There are many ways to do mobile, and it will vary depending on company type, region, etc. You should look through all the mobile job postings and see which mobile engineer type is the most common. Here are the Top 4 types:
  - Native iOS (Swift)
  - Native Android (Kotlin)
  - React Native (cross-platform)
  - Flutter (cross-platform)

The feeling of mobile will be around the same overall, so divorce yourself from the technology. Don't be afraid to pivot off of React Native if it is not in-demand in your area. My final note on this topic is that [I generally prefer native over cross-platform](https://www.jointaro.com/question/KUeUaVRfcjrnjGDcFuZC/android-kotlin-vs-react-native/), especially if your ultimate goal is FAANG/Big Tech.

Companies are risk-averse, especially in this economy. It's important to follow your passion, but you need to blend in some pragmatism and patience as well. It will be tough to convince a reputable company to hire you as a mobile engineer, especially at a senior level matching your years of experience. So be open to continuing with back-end development for a bit more but with a clear plan to transition (you should mention this to hiring managers as well that you are interested in switching).

*Treat the contract -&gt; full-time conversion as a promotion.*

Similar to a promotion, you need to do:

1. [Earn the trust of your manager](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/step-0-establish-yourself/)
2. [Have the dialogue making it clear that you want this level up](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/talk-to-your-manager/)
3. [Create a plan outlining the delta between where you are now and what it takes to reach the desired destination](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/create-an-expectations-plan/)

If you feel like you've done Step #1 by doing good work consistently over a decently long period of time, move on to Step #2. You don't have a ton of time left - You should have this honest conversation sooner rather than later.

Lastly, don't worry too much about the competition aspect. That's not something you can really control. Just take your best shot and hope 🤞

My recommendation is to look at *adjacent teams* (often called "sister teams"). These are teams where they report to the same Director of Engineering that you do.

In general, you don't want to completely switch teams (i.e. change companies or go to a completely different VP) unless you absolutely have to, especially as a Senior/Staff engineer. The relationships and understanding of org culture are super important. This is why the most graceful move is to go to a sister team working on areas that you're interested in, brokering that transition with your manager and their team (and if it's a sister team, these 2 managers will probably know each other).

Senior engineers will often have good relationships with sister teams as well due to the cross-functional nature of your work, so you won't be starting from 0.

All that being said, *you absolutely need to talk with your manager to figure out a move like this.* These career transitions are so, so, so much harder when your manager is on your side vs. not. If you have at least a decent relationship with your manager, I highly recommend bringing this up in your next 1 on 1. It will feel awkward, [but that's actually what 1 on 1 meetings are supposed to feel like - It's sort of the point](https://www.jointaro.com/lesson/xjeFRpp5YHxG9TTK8wjn/1-on-1s-are-the-time-to-be-awkward/) 😉

Here's another great thread on how to pivot to a new tech domain: ["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/)

> Just wanna make sure this is not a typo. Skills above trivial coding will become more important or less important?

Far, far more important.

This is probably a good sign, though I am surprised at the speed (interview feedback can take a long time to crunch, especially for E6 candidates). I wonder if this is something they do for everyone...?

As Rahul mentioned, Meta references aren't necessary so don't try to game them or stress out too much about it.

Best of luck!

> Is Tech Career coming to an end?

No.

AI fearmongering just gets clicks, that's why people do it. ChatGPT has been out for 2 years now, and I don't see companies replacing millions of engineers with autonomous robots running ChatGPT. The supposed "fully independent" coder AI was a sham.

In terms of how the tech industry will evolve, skills above trivial coding will become more important. That was already the case at top companies like FAANG, and now it'll spread across the industry.

Check these out as well:

- ["The AI frenzy is really making me rethink my career - What direction should I take?"](https://www.jointaro.com/question/z4yxcV50SBaCLea3dBMA/the-ai-frenzy-is-really-making-me-rethink-my-career-what-direction-should-i-take/)
- ["How to AI-proof your career?"](https://www.jointaro.com/question/3xg5SvXnyTQ0mhNLfbK1/how-to-ai-proof-your-career/)

Unfortunately, I don't know anything about the Enterprise Systems Engineer role. Even after Googling for it and looking on [levels.fyi](http://levels.fyi), I don't fully understand what it does and how the career path is different from SWE.

So my main concern is how this engineering vertical relates to "traditional" Meta SWE. At Meta, there are roles that have "Engineer" in them but are on a different path/pay grade compared to SWE. For example, there is a "Solutions Engineer" role that is effectively a support engineer for big advertisers (I knew people on that track). The salary is around the same, *but the stock is like 50% - 75% lower*. As you get to E5, RSUs become most of your TC, so this really hurts over time. Since this engineering track is "lower" than SWE, Meta Solutions Engineers effectively need to go through the entire interview loop to transition into SWE.

> If I plan to transition to a Software Engineer or Machine Learning Engineer role at Meta after a few years, is that possible internally?

It definitely is (Meta has good internal mobility), but you need to figure out how "close" it is to those roles. I would ask your recruiter what the difference is between Enterprise Systems Engineer and SWE/MLE, specifically about compensation. If the pay bands are around the same, it should be considered level to the "traditional" engineering roles at Meta and transitioning should be far easier.

Also, MLE will be trickier as it's a narrower domain with higher barrier to entry concerning expertise. You might need to switch to SWE first, work in an ML-specific domain, and then switch to MLE. Check out my advice here on domain switches: ["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/)

I wouldn't say competition is necessary to maintain motivation, but it certainly helps if you have the **right** type of competition. Here's the difference between wrong and right competition:

- **Right:** *"I want to be the most helpful and beloved person on the team. The main metric I care about is how many people I can empower."*
- **Wrong:** *"I want all the best opportunities for myself. I will tear down others to get them."*

I'm a very competitive person, but I've always made sure to channel the spirit of morally right, friendly competition. If you're smart and don't join a team of sharks, this mentality will carry you a long way. I've built a career off of [building people up](https://www.jointaro.com/lesson/EX9563YnxcJb62cCmetg/case-study-mentoring-junior-swes-e3-to-senior-e5-in-just-25-years-at-meta/) instead of [tearing them down](https://www.jointaro.com/question/wDZ2LC0AzujhbOOBs43m/how-do-you-deal-with-zero-sum-situations-where-ones-success-comes-at-the-expense-of-another/).

That being said, you should be deliberate with your promotion, especially at Amazon due to SDE 2 -&gt; SDE 3 being notoriously difficult. I highly recommend going through the following thread and its attached course: ["How to navigate the difficult SDE 2 to SDE 3 promotion?"](https://www.jointaro.com/question/Tno7LGeINpsTPrljUTTT/how-to-navigate-the-difficult-sde-2-to-sde-3-promotion/)

Sorry to hear about the downlevel - This is classic Google. And in this economy, it will happen more often. 😢

Your manager will know if you're downleveled, and if they're a good, sympathetic manager, they will fast-track you to promotion (it's in their best incentive to do that because if you're downleveled for too long, you will just leave). However, this won't come for free obviously. You need to follow the advice in Taro of:

1. [Building a great relationship with your manager](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/step-0-establish-yourself/)
2. [Working with them to create a clear growth plan](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/create-an-expectations-plan/)
3. Actually doing the work (landing impact, showing L4 behaviors deeply and consistently, [particularly with code quality](https://www.jointaro.com/course/grow-from-junior-to-mid-level-engineer-l3-to-l4/code-quality/))

On top of the L3 -&gt; L4 course, I highly recommend the overall promotion course: [\[Course\] Nail Your Promotion As A Software Engineer](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/)

*Show that you care.*

This is what makes small startups in particular unique: *If their early employees don't care, they die.*

This is in contrast to Google where even if all their engineers are super jaded and just there for the paycheck, the company can still thrive and print billions of dollars from their incredibly established competitive moat.

Spent at least 15-20 minutes going through their website and the founder profiles. If the product is consumer-facing or has some sort of demo, spend another 15-20 minutes checking it out and playing around with it. Spend 10-15 minutes crafting a [human, resonant cold message](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/cold-messages/) or cover letter showing that you actually took the time to thoroughly research them and their product. Prove to them that they aren't just 1 of 1,000 applications you're blasting out.

I highly recommend checking out this thread as well (there's a great story about how a Taro community member got into early Airtable): ["How to find and connect with scrappy startups?"](https://www.jointaro.com/question/9jFuRj3UymeHsaKIzXia/how-to-find-and-connect-with-scrappy-startups/)

For B2B, it's definitely much harder as you can't dogfood the product. At that point, you're relying more on [crafting an effective cold message](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/cold-messages/) showing how you're passionate about the space.

YC isn't representative of all startups though, and even if 80% of startups are purely enterprise SaaS, 20% of 100,000+ startups is still a ton of companies to apply to.

I think that's a great idea! *Learning to be a great software engineer is all about the struggle.* If you are constantly copy-pasting code from ChatGPT, you will not learn the underlying material, which will be seriously damaging both in interviews and on the job itself.

Just relying on Google and core documentation/videos is how people did it in the "good ol' days", and it's a time-tested method. That is how I built my entire Android foundation.

My code quality course talks about this all in-depth as well: [\[Course\] Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)

As a reminder for folks, the Slack invite is unfortunately manual - Automating it would cost us around $200,000/year. 😭

We usually get the invites out within 24 hours (unless it's a weekend).

Looks like things are going great for you, congratulations! A lot of companies are being super stingy right now when it comes to bonuses, raises, and promotions, even with surging stock price, so I'm glad those gains are being distributed to you and other employees. Meta/Google interviews certainly don't hurt either 😉

Honestly, I think you can try to have it all. Continue doing what you're doing to lock in that promotion - I recommend taking the [productivity course to get more from your time](https://www.jointaro.com/course/maximize-your-productivity-as-a-software-engineer/how-this-course-works/) and following the advice in the promotion course about [disambiguating the delta](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/create-an-expectations-plan/). Promotions are generally valuable (especially at big publicly traded tech companies) as they add buffer to prevent you from being downleveled too much ([which Google in particular is notorious for](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/dont-get-downleveled/)). On top of that, carve out some time on the side to tackle the Meta/Google interviews.

I'm working on the DSA course literally right now, but in the meantime, I recommend these:

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

As Thoughtful Tarodactyl mentioned, here's how quant firms work:

- They pay an *insane* amount of money, far more than FAANG (often double). A new grad quant can easily make $350k - $400k, which is what a senior Big Tech engineer would make
- The main downside is that work-life balance is ***awful***. The quants I know work 80 hour weeks *minimum*. They are all single workaholic types
- Quant skills aren't super transferrable to a traditional product-based tech company like FAANG, but you will probably be given an interview anyways as they will assume you're just a generally smart person who can learn quickly (which most quants probably are). The prestige is there, and it's harder to become a quant than a FAANG engineer (there's far more competition for those roles)

Personally, I would work for something like Databricks over a quant firm. You can still get a huge financial outcome at a pre-IPO (often double top-of-market comp), but your work-life balance won't be complete garbage. Quants rarely have any semblance of a personal life, so if your goal is to date/get married/start a family eventually, being a quant effectively delays that for whatever amount of time you are a quant.

This is effectively a weirdly formatted behavioral interview, so I highly recommend checking out the behavioral interviewing course (in particular, go through the 3 keys): [\[Course\] Master The Behavioral Interview As A Software Engineer](https://www.jointaro.com/course/master-the-behavioral-interview-as-a-software-engineer/)

I think your overall strategy is good. Right now, you are covering 2 of the 3 keys:

- Why you're excited about the technical/product space
- Why you're excited about the company

Now you're missing the 3rd key of showing that you're passionate about working in a synergistic, supportive team. If one of your experiences is an example of stellar teamwork, you will demonstrate that.

Lastly, 10 experience is way, way, waaaaay too much for 9 minutes. I would trim it down to 2-3. Heck, you can literally do just 1 if you talk about it with enough depth and charisma (e.g. *"This is my favorite robotics experience which made me truly fall in love with the space"*).

Just to clarify: *Are you asking about signaling that you're open to work privately, i.e. only recruiters searching for you will know that you're looking, not the general LinkedIn public?*

If that's the case, I think this is the best thing to do. The alternative is to have the green #OpenToWork ring about your LinkedIn profile photo so that everyone knows that you're looking. I don't think that helps as it doesn't communicate any extra information to the people that matter, and *I've actually heard from Taro community members/recruiters that can **hurt** you with some recruiters as it makes you look desperate*.

There is a stigma around engineers who broadcast that and have been looking for a while, and to be 100% honest, the candidates who have that green ring do tend to be lower quality.

That being said, I don't have a ton of evidence/supporting data around the green #OpenToWork ring, so if anybody has any insights there, would love to hear it.

I recommend checking out this course for an excellent example of a project spec document: [System Design Masterclass: Shipping Real Features To Production](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)

This document will both help you understand how to best lay out and execute the project while helping others understand what you're doing (and provide feedback).

What I don't recommend is writing some sort of wiki explaining how your code works. Those get outdated super quickly and take a lot of effort to write/maintain, which is why Meta was extremely against that kind of documentation.

If you are performing well as a software engineer, you should naturally be creating documentation as you go through the workflow (system design doc, detailed pull requests, meeting notes, etc).

First, if you have any tactical needs (e.g. prioritization isn't clear or a timeline is falling behind), bring those up first. They will be responsible for making decisions around which product efforts come first, how to reduce scope, etc.

Aside from that, use the meetings to clarify direction. As with any form of communication, [your goal is to empathize with them as much as possible](https://www.jointaro.com/course/effective-communication-for-engineers/effective-communication-guide-part-1-core-high-level-principles/). Strive to understand what they care about and the North Star they're trying to establish for your organization.

> Having said that, what are some of the questions we engineers can ask leadership/product to hold them accountable for some of the requirements?

Can you clarify this more? As Rahul mentioned, this feels a bit antagonistic, at least for me. Leadership is there to set vision and priorities, not to actually deliver anything. Maybe you're referring to how the requirements they hand down are uncleaR?

I need to convert this into a course, but I still recommend this: [\[Masterclass\] How To Choose A Good Company And Team As A Software Engineer](https://www.jointaro.com/lesson/0WEmTNZOMIh8xAdfO3JH/masterclass-how-to-choose-a-good-company-and-team-as-a-software-engineer/)

In short, it depends on your priorities. While a startup will have more velocity, scope, and learning, Big Tech brings compensation, stability, and credibility. Since you're a senior engineer, it can easily go both ways as that's when you have the most optionality (in contrast, I recommend [junior engineers start off at a Big Tech company if they can](https://www.jointaro.com/lesson/OcWRqQcx31VwIEV6tfWK/why-you-should-start-your-career-at-a-big-tech-company/?playlistId=Hdfdk7MewdupgeAsIE2y)).

Check this out too: ["What's the difference between Big Tech and startups in terms of learning and growth?"](https://www.jointaro.com/question/KWXIrFIR1EIJsvdOdo7u/whats-the-difference-between-big-tech-and-startups-in-terms-of-learning-and-growth/)

Unfortunately, these decisions are often made at the executive level (VP and above), so you often won't even have a choice, even if you're the team's highest performer and are delivering massively positive ROI to the company. Executives are often grossly out-of-touch and overpaid, so they'll foolishly assume that you can magically transfer all your genius when you train your replacement.

In terms of what you can control though, you pretty much hit the nail on the head. Follow the advice in Taro to:

1. Be a high performer and deliver impact
2. Become a [specialist/domain expert](https://www.jointaro.com/course/become-the-go-to-expert-as-a-software-engineer/)
3. [Build relationships](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/masterclass-how-to-build-deep-relationships-quickly-in-tech/), particularly with your manager/skip - This one is more important than all the others

If you do this, you'll have the highest chance of survival when it's a partial layoff which happens a lot (i.e. an executive goes to your manager/director and tells them they can keep 30% of their staff in the US and the rest go to India/Brazil/etc).

Overall, the entire issue is similar to layoffs in that you just want to be a good engineer with a strong network so that no matter what happens to you, you'll be best positioned to bounce back: ["How to survive potential layoffs?"](https://www.jointaro.com/question/ydZFpJz0x8wKUIfd8E1r/how-to-survive-potential-layoffs/)

fwiw, Meta is one of very few companies that doesn't really outsource its development to much lower-cost countries, particularly India. The tricky part is that you need to get into Meta first, and engineers are cut pretty aggressively in other ways (mainly tough performance review + stack rank).

Unless your manager is weird about people not attending meetings, I would just not go. If you are marked as required though, I would at least attach a note when you turn down the meeting series (you can just say that you're super busy and will catch up via the meeting notes).

I recommend going through this lesson in the productivity course too: <https://www.jointaro.com/course/maximize-your-productivity-as-a-software-engineer/not-every-meeting-needs-you/>

Wow, if *"Tell me about a time you worked on a team"* is exactly how they phrased the question, that's kind of bad 🤣. I know the spirit behind the question, but engineers are literally always working on a team in a corporate setting, so it's a weird phrasing. Personally I would have asked it this way: *"Describe a time where you demonstrated stellar teamwork."*

Anyways, I think your story is good! It would definitely clear the bar for a junior engineer. If I were to give this question, the main signal I would look out for is the engineer working with other engineers (especially those who they're unfamiliar with) and demonstrating strong communication/empathy. Having some semblance of a problem/obstacle to overcome together is great too.

I wouldn't worry too much about IP right now - Just focus on getting a good job, stabilize within it (work 2-3 years), and figure out your next steps from there.

Meta, Google, and Apple are all amazing companies with tough interviews. I would go through all those loops and see what offers you can get. From there, you can make a choice (assuming you get multiple offers). It's also tricky as those are big companies with many, many teams, and Meta/Google have a team-matching component. That will play a bigger role in which offer you take more than the company overall.

In this market, it's unfortunately one where it's less about the engineer choosing the job and more about the job choosing the engineer. Many engineers are only getting 1 offer in this market, especially among the Big Tech interviews they take on.

Oh wow, this is a *very* egregious downlevel then. Definitely mention all the things you just shared here:

1. You were Meta E5
2. You have TikTok and Amazon offers (both Tier 1 Big Tech companies)

Given this, I think you have a good shot of getting an L5 offer. And if you don't, take TikTok or Amazon (assuming they are senior offers). Don't let Google insult you this badly - It's not a company anymore where it's worth getting downleveled (that era passed like 10 years ago).

Was the job posting specifically for a senior role? If not, then this makes sense.

Unfortunately Google is the undisputed king of downleveling, especially if you have never worked for FAANG before at an equivalent level (this is why [I specifically call them out in my job searching course](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/dont-get-downleveled/)). Even if you have, you can still get downleveled. They will only budge if you have a competing offer or work at a competitor like Meta as an E5.

If you are going to try negotiating hard, be prepared to walk away. In this market, there's no shortage of candidates that are willing to take a mediocre offer from Google. Google is still Google at the end of the day, and I personally think the stock is undervalued.

When it comes to communication tactics and reach outs, I recommend these:

- The "Favors" section of my question asking course: <https://www.jointaro.com/course/ask-great-questions-that-get-great-answers-quickly/put-them-on-a-pedestal/>
- ["How to have more impactful/deeper Taro 1:1 member match convos?"](https://www.jointaro.com/question/NUW8bsmcHjm8RXCQLv9k/how-to-have-more-impactfuldeeper-taro-11-member-match-convos/)

Be polite and always show that you're striving to add value to others. If you do that, networking will come naturally.

I highly recommend the overall job searching course as well to familiarize yourself with the US market: [\[Course\] Ace Your Tech Interview And Get A Job As A Software Engineer](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/)

Welcome to America! I totally understand the anxiety here, but I 100% believe that if you communicate well and treat people with respect, you have nothing to lose but everything to gain.

When it comes to connecting with folks, Charlie already pointed out a lot of great avenues to meet people. In particular, I recommend going to events like these: <https://www.jointaro.com/event/jobsearchers-coffee-chat-d1bdb/>

There's a lot of job seeking related events, and you can find all Taro events here: <https://www.jointaro.com/events/>

Lastly, if you're in the Seattle area in particular of Washington, make sure to keep an eye out for in-person events there. Seattle is Taro Premium's 2nd most represented region, and there's an in-person meetup every 2 months or so. Networking and earning trust in general are best done in real life (IRL).

Senior after 9 YOE is pretty normal, and I don't think it would be held against you. I do think having "Senior Software Engineer" for both blurbs makes sense as well.

Given the senior title and your 9 YOE, you will probably be mostly considered for senior loops, even at FAANG.

5-8 seem like the same thing, but I think that overall bundle would be the most interesting/applicable, especially if we workshopped the title well.

I personally like 9 and 10 as well. That's sort of my "2nd tier" of preference.

**Short answer:** No.

**Longer answer:** No 99% of the time. There is that 1% of cases where a job will hard-require certain certifications, but those are generally pretty rare. I've been on 1,000+ hiring loops across my career across top companies like Meta, Robinhood, and more, and I have literally never seen a certification make a difference in whether we gave a candidate an interview.

A much better use of your time would be [doing side projects](https://www.jointaro.com/playlist/vKUWMgmmaEvzcYUXZs4B/), [contributing to open-source](https://www.jointaro.com/course/become-an-open-source-master/), and of course, following the advice in Taro 😛

Once the numbers start coming in, I think 2 is the max. For a lot of companies, it'll be one. Let's say they increase the number from $150k to $175k - It will likely just stop there.

If you give the number in particular, it's done after 1 round. Let's say it starts at $150k and *you* are the person who says *"$175k would be great"*. If they give you that $175k and you go back asking for more for whatever reason, there is a very high chance the offer will be rescinded.

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

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

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

Can't make the event? No worries, just ask your question anonymously in the Taro forum: <https://www.jointaro.com/questions/create/>

Group Office Hours With Alex - Get Personalized Career Advice Privately

Since there isn't a big Palo Alto meetup for the remainder of the year due to the holidays, I'm ([Jonathan](https://www.linkedin.com/in/were-no-strangers-to-love-you-know-the-rules-and-so-do-i/)) holding a smaller scale Fremont meetup to serve in its place. I heard a special guest might show up as well? 🤔

**Transit**

- The pizzeria is a long walk/short drive from Fremont BART
- The area around it is effectively a massive parking lot: there is lots of free parking in the area (if you can't park in the core downtown, just go a 1-2 streets over)

**Dietary**

- The pizzeria is 100% vegetarian with gluten free and vegan options. We will order at least 1 pizza that is both vegan and gluten-free

Engineer @ Robinhood

Jonathan C

Meet Alex - Taro Fremont 🍕 Meetup

The relationship you have with your manager is the most important one in your professional life. So why do so many tech workers **make obvious mistakes** when dealing with their manager?

In this session, Ethan will share strategies and tips to:

1. Build trust with your manager, even if you've had challenges in the past

2. Drive your professional development and earn investment

3. Navigate difficult conversations and manage up effectively.

[Ethan Evans](https://www.linkedin.com/in/ethanevansvp/) managed teams of 800+ while a Vice President (VP) at Amazon. Across 15 years, he grew from manager to Vice President, providing executive leadership for multiple $500M+ businesses. In that process, he's managed hundreds of people directly across dozens of changes in his own management chain.

Ethan is now a career development expert and teacher. Watch his courses on Taro:

1. [Managing Up: Build Effective Relationships With Your Boss](https://www.jointaro.com/course/managing-up-build-effective-relationships-with-your-boss/)

2. [The Growth And Promotion Recipe - Magic Loop](https://www.jointaro.com/course/the-growth-and-promotion-recipe-magic-loop/)

3. [Make The Most Of A Layoff: Maximize Your Severance Package](https://www.jointaro.com/course/maximizing-a-severance-package/)

Learn more: 

- Watch the [interview series with Ethan about eng management on YouTube](https://www.youtube.com/watch?v=V8McoEVUiYQ&list=PLMrAfqhZjqfIkD-0p0tJ_zqvPnBdYsixT&index=4).
- Ethan's live cohort-based course "Stuck at Senior Manager" is open for enrollment now: <https://maven.com/ethan-evans/break-through-to-executive>
- Taro members get a discount to join [Ethan's Level Up community](https://levelupwithethanevans.substack.com/taro25)

Ex-Amazon VP, Leadership Coach

Ethan Evans

Tech Lead/Manager at Meta, Pinterest, Kosei

Rahul Pandey

How To Build A Strong Manager Relationship (From An Ex-Amazon VP)

For over a decade, *Cracking the Coding Interview* has been hailed as the "bible" of interview prep. Now, its high-anticipated sequel, [Beyond Cracking the Coding Interview](https://www.amazon.com/dp/195570600X), is out. While the original delved deeply into coding problems, the sequel shifts its focus to teaching you how to think—both in the context of technical interviews and throughout the job search process.

In this event, the authors of [Beyond Cracking the Coding Interview](https://www.amazon.com/dp/195570600X) will share how tech hiring has changed in the last decade. Ask them anything about interview prep, job stuff, negotiation, or algorithms and data structures. The authors are:

- [Gayle Laakmann McDowell](https://www.gayle.com/), the original author of CtCI
- [Michael Mroczka](https://www.linkedin.com/in/mike-mroczka/), Google engineer and top interview coach on [interviewing.io](http://interviewing.io)
- [Aline Lerner](https://www.linkedin.com/in/alinelerner/), founder of [interviewing.io](https://interviewing.io/?c=taroama)
- [Nil Mamano](https://www.linkedin.com/in/nilmamano/), Google engineer and algorithm researcher

Get $100 credit toward a mock interview using the link <https://interviewing.io/?c=taroama>

Author of Beyond Cracking the Coding Interview. Founder of interviewing.io

Aline Lerner

Primary author of Beyond Cracking the Coding Interview, Ex-Google

Michael Mroczka

CS PhD, Senior Software Engineer. Wrote 'Beyond Cracking the Coding Interview'

Nil Mamano

Author, Cracking the * Interview Series

Gayle Laakmann McDowell

Beyond 'Cracking the Coding Interview': 10+ Years Of Tech Interview Evolution

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.