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

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

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

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

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

Tech Lead @ Robinhood, Meta, Course Hero

Alex Chiou

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hope this helps!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

It depends a lot on level.

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

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

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

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

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

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

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

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

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

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

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

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

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

Go through these 2 resources:

- [Grow From Junior To Mid-Level Engineer: L3 To L4](https://www.jointaro.com/course/grow-from-junior-to-mid-level-engineer-l3-to-l4/)
- [Master The Behavioral Interview As A Software Engineer](https://www.jointaro.com/course/master-the-behavioral-interview-as-a-software-engineer/)

Really glad you like Taro and found it to be helpful!

> Is promo from L3 -&gt; L4 in FAANG by moving companies, even possible?

Uplevels happen all the time. Amazon in particular is common as many people get unfairly stuck at SDE 2 (mid-level) and then they go to another FAANG as senior. 

However, in your case it's tricky as the mid-level bar is usually 2 YOE and the market's not good right now for L3/L4. I think you'll need strong interview performance + multiple competing offers to make the L4 promo the likely outcome. More advice here: [Don't Get Downleveled](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/dont-get-downleveled/)

If you need to join the Taro Premium Slack, please email us at team@jointaro.com

*Yes. However, the grant doesn't vary in dollars but in the # of shares.*

For these big public companies, they have a *target comp* in mind for every employee. Let's say they have chosen $200k target comp for a Google L3 like yourself and your base salary is $150k. That means they want to give you *$50k worth of Google stock every year*:

- **Current price:** As of 3/22/25, Google is trading at \~$166/share, which means that they need to award *300 shares per year to get $50k*. For an offer (let's just assume they use $166 for simplicity's sake), they will give a 4-year grant of 1,200 shares with 300 vesting each year.
- **Surge:** Now let's say Google has surged back to all-time high levels and returned to $200/share. This means they only need to award *250 shares per year or 1,000 shares across a 4-year grant* to reach the target comp.

Tactically, this means you want to join the company when the stock is low so that it rises during your time at the company. Since the grant is locked to # of shares (it doesn't dynamically go up or down based on price), this scenario means you are getting a raise without having done anything.

On the flip side, if the company's stock drops while you're there, you have functionally gotten a pay cut due to your RSU grant losing value.

Many companies don't like this comp volatility, so they are shortening the grant duration from 4 years down to 2 or even 1 year. My former company Robinhood is on 1-year grants now. This caps both upside and downside so your floor and ceiling are closer to one another.

I recommend watching our comp masterclass as well: [\[Masterclass\] Understanding And Optimizing Your Pay In Tech](https://www.jointaro.com/lesson/gk408yBIV2fa5RjVR213/masterclass-understanding-and-optimizing-your-pay-in-tech/)

Your new manager seems great! The resource list you have crafted is also great - Those are all the exact things I would have linked you 😄

Once you understand the principles, the main thing is execution which can be surprisingly difficult. Embrace the [awkward 1 on 1](https://www.jointaro.com/lesson/xjeFRpp5YHxG9TTK8wjn/1-on-1s-are-the-time-to-be-awkward/), and don't be afraid to [probe for feedback](https://www.jointaro.com/lesson/aGuxjGbFjYb34ofhRxjs/this-is-how-you-get-feedback-making-the-process-smooth/). Micro-level, tactical feedback (e.g. *"How was the system design doc I made for the latest project?"*) should happen on a weekly basis as applicable. Macro-level, performance feedback (e.g. *"How do you feel about my leadership skill development?"*) should happen on a 1-2 month time scale.

The engineers who grow the fastest are those who establish a strong, transparent relationship with their manager and regularly get/process/implement feedback.

I recommend the overall mid-level to senior learning path as well: [Nail Your Promotion: Mid-Level To Senior (L4 -&gt; L5)](https://www.jointaro.com/learning-paths/nail-your-promotion-mid-level-to-senior-l4-to-l5/)

Don't worry about it too much - You are a new junior engineer, and your team seems cool with it. Stressing out over this will just hurt you over the long-term as you second-guess every single decision you make.

Your main goal now is to learn from the experience. Think about how you could have caught this error earlier and more proactively. Learn how do that here: ["How to turn a string of silly mistakes into a mature positive outcome?"](https://www.jointaro.com/question/JybGyc935lsYbM8dAo7Y/how-to-turn-a-string-of-silly-mistakes-into-a-mature-positive-outcome/)

As a tech lead, the making of the mistake didn't matter to me that much - We're all human after all and do dumb stuff all the time. What mattered is how the engineer responded to the mistake. If they feel bad about it and I can see them introspecting and trying to grow from it, I was happy. If they didn't care about it and just moved forward nonchalantly - That's when I got mad.

Tactically, follow the advice from the code quality course to plan better: [Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)

I highly recommend starting off with this course which will help you establish mindset and set up a preparation schedule: [Master The Data Structures And Algorithms Interview](https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/)

After that, I recommend going through this course which explains the major data structures and algorithms concepts in-depth: [Crash Course: Beginner Data Structures And Algorithms Concepts](https://www.jointaro.com/course/crash-course-data-structures-and-algorithms-concepts/)

Since you have limited time, I have 2 bigs pieces of advice:

1. **Make studying a habit** - As a parent, you will have a hard time finding huge focus blocks of 4+ hours. This means, you need to get value from random scattered 10-30 minute blocks throughout the day/week. Try to consume at least 1 course lesson or do 1 LeetCode problem every day, and it will add up incrementally over time.
2. **Parallelize** - If you are doing a chore that doesn't require high cognitive load (e.g. washing the dishes), you can treat a course as a podcast and listen to it in the meantime (Taro has mobile apps too to make this easier).

The good news is that 6 weeks is quite a lot of time. You mentioned 45 minutes, so I assume this is the initial round. I think this is very doable for you - A solid grasp of LeetCode Easy + Medium will give you a strong chance of passing this round.

I highly recommend our [behavioral interview course](https://www.jointaro.com/course/master-the-behavioral-interview-as-a-software-engineer/), specifically the part about levels: <https://www.jointaro.com/course/master-the-behavioral-interview-as-a-software-engineer/mid-level-engineer/>

I further recommend the junior to mid-level course to understand the delta even more deeply: [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/)

> But how can we get to know if the story is good enough for passing the interview round?

You can't unless you do a mock with someone from Amazon who is actively doing interviews there + leveling people. Even then, this isn't perfect signal as interviewers vary. Some interviewers will be having a good day and will be nice, others will be having a bad day (probably more common now at Amazon tbh) and will be mean.

Just make it your goal to tell a compelling story and give it your best shot. There's not much else you can do.

Just wanted to leave a comment saying that this is one of the best threads I've ever seen. Thank you for creating such a valuable resource 🫡

From Taro's experience working with LLMs, compute costs are *expensive*. I didn't realize so many companies out there are willing to take a loss to foster the next generation of AI builders. This is amazing!

I will add another amazing free AI tool here: <https://readdy.ai/>

Readdy isn't AI compute, but it should still be useful to anybody building anything as it's a very good AI designer with a generous free tier. Even if you're building a back-end REST API side project or something, you will need to expose some user interface at some point through a set of API docs. We've been using Readdy a lot for Taro, and it's been an absolute game changer.

Is this for comp? $300k - $400k is exactly correct. If you can get $375k+, that would be quite good.

At less prestigious companies, even Staff Engineers won't make that much. At my first company of PayPal (still a well known $50B+ tech giant), Staff \[MTS 1\] is only around $275k TC. Meta simply pays an absurd amount of money.

The main downside of being E4 IMHO is that you still [need to deal with 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/), which will be very stressful and annoying (especially given the current climate + harder promotions at Meta). However, with Taro and your wealth of experience, you are very well positioned to make the E4 -&gt; E5 promotion in 1 year by following the advice here: [Grow From Mid-Level To Senior Engineer: L4 To L5](https://www.jointaro.com/course/grow-from-mid-level-to-senior-senior-l4-to-l5/)

For mocks, I actually have a really awesome fresh tool for you: <https://readdy.ai/>

In short, Readdy is an AI designer. It's obviously rough around the edges, but if you prompt it well enough, it can crank out some really nice fairly high-fidelity stuff. This tool is effectively Taro's product designer now, and it's so fun and useful. The free tier goes quite a long way.

For project management, you don't need to be too fancy. A Notion or a Google doc with milestones is enough. If you really want to go all out, you could use Asana or something, but that feels like overkill.

Your team is quite small - I'm sure expectations are high then (if they aren't, the company won't survive).

Definitely talk to your manager to take expectations as clear as possible. When in doubt about your own performance, having an honest conversation with your manager is usually the right call.

Do your tasks have due dates? If not, ask your manager to put due dates on them.

> ...and I often need to ask my buddy or someone else for some help. Is this ok or am I underperforming?

If your team isn't super mean, this is perfectly normal. It's literally just your 3rd day. Your goal though is to make sure that your need for help drastically drops over time due to following the advice here: <https://www.jointaro.com/course/ask-great-questions-that-get-great-answers-quickly/learn-to-fish/>

Needing help isn't inherently a problem. Needing the same type of help in the same amount over and over again is.

> hope to get some advice on what’s considered normal so I know where I am at! I have 2+ YOE.

It really depends on the startup. If it's a tiny 5-engineer company, the expectation will be much higher for you to move fast and become independent. If it's a massive unicorn with 500+ engineers, the expectation will be much lower as companies at that point are more like Big Tech than tiny startups.

If I had to throw a number on it, I would say you should be operating at 90% productivity compared to a similar engineer of your level after 2-3 months. But again, I could be completely wrong based on what kind of startup you're working for.

What version of bootcamp are you in?

- **Traditional:** You aren't tied to a team, and you need to find one during bootcamp
- **Already matched:** You are already allocated to a team, and bootcamp is just training

Nowadays, the vast majority of engineers are in the 2nd bucket (I'm not even sure if the 1st exists anymore). In this case, your goal is just to go through the bootcamp tasks as fast as possible to familiarize yourself with Meta's codebase and overall engineering culture.

There's really no way to prepare for bootcamp if you haven't started at the company yet. Meta's culture and tech stack are so unique that you can't exactly train at home.

> How to make a good first impression?

Follow the advice 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/)
- [The Complete Onboarding Guide For Software Engineers](https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/)

It's possible that it's just bad luck - I would just keep applying and hopefully your luck evens itself out over time. Though maybe L3/early L4 hiring has gone off a cliff recently due to Trump doing... Trump things.

This is all the more reason to build a [side project with a meaningful amount of users](https://www.jointaro.com/course/build-side-projects-with-500k-users-coming-up-with-an-idea/how-this-course-works/) or [make a ton of meaty open-source contributions](https://www.jointaro.com/course/become-an-open-source-master/). If you're not even getting the interviews to begin with, you have a lot of spare time anyways. Might as well (and side projects are fun too if you're doing them right).

In this market, you're competing with those kids who do have those side projects with 10,000+ users or have merged 100+ high-quality PRs into React. I would know because I have several junior mentees doing this and still getting interviews (including at FAANG). That's what you need to do to become cracked in this market and genuinely stand out.

There are 3 core sources of time to pull from while working:

1. Nights
2. Weekends
3. PTO (should probably save these for final round interviews)

It's a struggle, but you need to pull from these sources and grind through if you are seriously interviewing. Follow the advice from the productivity course to maximize your performance at your current job with minimal time: [Maximize Your Productivity As A Software Engineer](https://www.jointaro.com/course/maximize-your-productivity-as-a-software-engineer/)

Another option is to interview extremely selectively. Literally only take 1-2 interviews for an entire month, so 5 hours of studying per week gives you a decent chance to pass.

People are indeed getting interviews right now, but the market is rough for people who meet the following criteria:

- Less than 4 years of experience
- Haven't worked at a FAANG or FAANG-adjacent company before

That's unfortunately a lot of people. I shared a lot of advice on overcoming that barrier here: ["How to get interviews?"](https://www.jointaro.com/question/yrrkhJNp2nL9pvPMwrhe/how-to-get-interviews/?playlistId=SzIOYQ4Ib3lj61jjhX01)

> Follow up Q: Do people open links on cold emails? I have seen people send like loom recordings to HMs of their side project. But im not sure if anyone would even open them.

Almost never. Too many candidates and not enough time, especially for junior/mid-level roles.

You would need an extremely solid lead-in like "I built [this project for fun and got 500,000+ users](https://www.jointaro.com/course/build-side-projects-with-500k-users-coming-up-with-an-idea/), check it out here: \[LINK\]" to even have a chance.

Based on what you just shared, Infra Platform seems like the best. Infra Systems is very low-level infra and honestly seems like a horrible place for an intern. The technical complexity there is very high, probably around E5, E4 minimum. The problems faced there, especially at Meta, will be so hard that AI is completely useless.

On top of the advice Jonathan and Rahul shared, I highly, *highly* recommend side projects: [Build Side Projects With 500k+ Users: Coming Up With An Idea](https://www.jointaro.com/course/build-side-projects-with-500k-users-coming-up-with-an-idea/)

At these big product-based companies, they want to know if you can build quality software at scale. For a lot of candidates, they demonstrate that through their prior work experience, and these are the "safe" candidates these companies prefer. If you are trying to get your first experience doing this, especially in this market, you will need to jump start this virtuous cycle yourself.

You don't need to work in a corporate environment to build software tons of people love. Take matters into your own hands (you'll also get awesome learning along the way).

Check out this thread as well: ["How to get interviews?"](https://www.jointaro.com/question/yrrkhJNp2nL9pvPMwrhe/how-to-get-interviews/?playlistId=SzIOYQ4Ib3lj61jjhX01)

I have never actually seen the Meta intern team match survey (though I have heard about it a lot obviously).

Can you attach the exact questions/options from the survey into your original post? That would be really helpful to me.

> Wow, really appreciate the detailed examples!!
>
> If I have significant experience working on backend/database of full stack applications, would Product Infra likely be a better fit?

Not really. Like I said, product infra can be any tech stack (at least based on how the term worked when I was at Meta).

If you have mainly worked on back-end, the main thing is to pick back-end (if that's possible).

> I got my MS in CS but with a focus on ML as my area of focus is MLE. I understand for SWE it doesnt count for anything, but curious if that changes for MLE/Data Science

It depends on how big the focus is. My wife got a GTech Master's with a focus on MLE, but it was just a couple extra shallow ML courses so ultimately it wasn't helpful.

If your MS was pure ML, ideally with research, it will certainly help. A lot of MLE roles require a deep MS minimum just to qualify (especially at FAANG).

MS counts for effectively 0 YOE at FAANG unless it's a longer, research-based MS. Most MS (largely just supplemental courses) aren't counted by the top tier companies at all.

For less prestigious companies, MS will get you from SW1 -&gt; SW2. That was the case at PayPal.

Just to put things into context: Rahul had an MS from Stanford and 3 YOE at startups/Pinterest when interviewing in 2017. [*He got an **L3** offer from Google.*](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/dont-get-downleveled/) This is when the economy was good.

Here's a good thread about the value of a Master's: ["Do I need to do masters in Computer Science to move ahead in career?"](https://www.jointaro.com/question/tKuUT3ELEa1uCGBuMykX/do-i-need-to-do-masters-in-computer-science-to-move-ahead-in-career/)

> What is the main difference between "Product Infra" and "Infra Platform"? Both seem to relate to backend API development, but is there anything specific I should be aware of?

"Product Infra" is infra that's closer to product, i.e. directly tied to a certain product. Here's an example:

- How ads work in Instagram is the mobile client requests a bunch of ads from the server
- The ads can be injected among the organic content in certain ways (every 1/2/3 organic content items, back-to-back, dynamic based on how long the user spends on an organic item, etc)
- This logic is very complicated (it can get even more so if you have ad load experiments), so it was abstracted away into an ads injector module built by the ads product infra team
- As you can see, this code doesn't relate to how the ads look directly (i.e. product work), but it is exclusively relevant to ads

I worked with those engineers. And this code was written on mobile (Android/iOS). So infra also doesn't automatically mean back-end.

An example of "Infra Platform" is you work on the core ImageView widget used to load any image across Instagram, and your goal is to make it as fast/reliable/observable as possible.

> Is "Web Product" mainly frontend development, or is there also some backend work with APIs?

Probably mostly front-dev dev. It's risky to have an intern go full-stack.

> Are there any specific orgs you would recommend I indicate preference (or avoid) as an intern?

Anything that doesn't sound interesting to you. There are good orgs and bad orgs, but the intern survey doesn't give you enough granularity to choose. Intern manager quality varies wildly.

> so the entire epic does have a deadline. but so many engineers work on an epic - it's more like we collectively as a team need to hit that deadline. It's just that no individual ticket deadlines are there

Okay, this is more of a planning thing for the tech lead then. Having only 1 broad deadline for the entire project is a recipe for disaster.

You should talk to your tech lead and see what sub-milestones make sense. As a new grad who is also new to the company, you will need this support initially. Over time, you will develop this intuition on decomposing + estimating over time.

I highly recommend [the code quality course](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/), especially the lessons starting from this one: <https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/break-it-down/>

> I really appreciate your advice! Following up, when would it be more appropriate to thank the person publicly instead of just sending them a personalized message?

There is unfortunately no math for this. You do this when they help you with a big thing. As for what is a big thing, that's up to your personal judgment to decide.

What I will say is that there's a fairly linear correlation between magnitude of help and time spent. If they spent several hours helping you (or even several days), that's probably something worth giving a bigger thanks too.

You cannot rely on your intern manager for everything - It's a hard expectation for Meta interns to get at least 1-2 glowing pieces of feedback *on top* of your intern manager's. I talk about this in the Meta intern course here: <https://www.jointaro.com/course/nail-your-return-offer-as-a-meta-software-engineer-intern/part-6-meta-intern-success-series-how-most-interns-fail/>

One of the first things you can do after joining is asking your intern manager for 1-2 other engineers on the team who are a good fit to help you (tactically, you can immediately start putting them on your diffs for review).

There's case studies in the mid-level to senior course. I highly recommend going through the entire course as it's very detailed and answers your question well: [Grow From Mid-Level To Senior Engineer: L4 To L5](https://www.jointaro.com/course/grow-from-mid-level-to-senior-senior-l4-to-l5/)

The senior to staff course doesn't have case studies embedded directly but does link a couple: [Grow From Senior To Staff Engineer: L5 To L6](https://www.jointaro.com/course/grow-from-senior-to-staff-engineer-l5-to-l6/)

The level of thanks will vary based on the level of help: It would be *very* weird (and awkward/annoying) if you sent someone a box chocolates or something for every little thing they helped you with.

What I will say though is that you should *always* write a personalized medium-effort message minimum for everything instead of the very lazy *"thanks"* or *"ty"* DM (that is a low bar that you should never stoop too).

Let's say someone helped you figure out some build issue where you simply mis-followed the onboarding wiki and missed a step. Even though the help was just 2-5 minutes of their time, you can send something like: *"Even though it was small, I've been stuck on this for 30+ minutes, so I really appreciate the help! You saved me from potentially hours more of going nowhere* 🤣".

There's a good lesson about Deep Thanks in the question asking course as well: <https://www.jointaro.com/lesson/UwFI0QisFWFRiOx30HiJ/asking-great-questions-part-23-deep-thanks/>

Your thought around public thanks is good. It makes the thanks more meaningful and gives the helping engineer more points in performance review.

Yeah, you simply need to escalate further here. However, this only solves the short-term problem of this particular project, not the long-term problem of this person not being in-sync with you at all. For advice on solving that, I highly recommend this very related thread and its linked resources: ["Really struggling with team/engineer"](https://www.jointaro.com/question/pZzSKRKoOyYqUSNRv3dW/really-struggling-with-teamengineer/)

If she never processes the feedback and you can't switch teams, your best bet is to engineer your workflow in a way where her approval is needed as little as possible, working with other sources of authority instead. I have had to do this before with certain tech leads at Meta who I didn't get along with - Sometimes the problem isn't solvable, and you just need to mitigate the damage instead.

I'm surprised that a top company doesn't have deadlines given the current economic climate.

At the end of the day, deadlines do exist *somewhere* (usually in the brain of some executive), they just might not be formalized. Your goal here is to formalize them.

You can solve this with some upfront, proactive, and clear communication:

*"Hey \[manager\], what's a good target date for this task? I was thinking 2 weeks is a good deadline but wanted to hear your thoughts."*

If your manager is being ultra-nice and giving you an answer like *"Oh, just finish it when you finish it"*, politely refuse that non-answer and push harder. Tell them that you appreciate flexibility but a target date (even if it's sort of conjured up) would be tremendously helpful to give you a forcing function + motivation.

We made an entire course about this - Check it out here: [Ask Great Questions That Get Great Answers Quickly](https://www.jointaro.com/course/ask-great-questions-that-get-great-answers-quickly/)

We have a networking/relationship building course in the works too which will give more advice on how to approach these conversations.

Another thing I'll say is that [there will always be people who just don't get along with you](https://www.jointaro.com/lesson/BPh3QbVvH1HaGV0bSszf/dont-be-naive-when-networking-understand-that-youll-get-burned/?playlistId=nvsMxZ9ZGIjlyaZbWqYS) (that's life). That percentage will be much higher at Meta now given the current climate. There will be many more senior+ engineers who are just so, so, so stressed out right now that they simply don't want to help the intern where if it was 2019 or something, they definitely would have.

The good news is that since you're a Meta intern, you by definition have at least **1** person that cares: Your intern manager. Use them as a gateway to unlock other mentors in the team since they can use their social capital to convince others to help you.

> Where is this problem on LeetCode?

I don't think this problem exists there. This is the closest one I think (which is harder as you need to return the list): <https://leetcode.com/problems/combination-sum/description/>

> If we wanted the different ways a target could be reached, how do we do that?

That's pretty much the Combination Sum problem I linked above (it even has the stipulation that you can reuse numbers). Here's a Python solution:

```
class Solution:
    def combinationSum(self, candidates: List[int], target: int) -> List[List[int]]:
        # This list will store all unique combinations that sum up to the target
        result = []

        # Helper function for backtracking
        def backtrack(start_index, current_combination, current_sum):
            # If the current sum matches the target, add the combination to the result
            if current_sum == target:
                result.append(list(current_combination))  # Make a copy before appending
                return
            
            # If the current sum exceeds the target, stop exploring this path
            if current_sum > target:
                return

            # Iterate through candidates starting from the current index
            for i in range(start_index, len(candidates)):
                # Add the current candidate to the combination
                current_combination.append(candidates[i])

                # Recursively call backtrack with the same index (allowing reuse of the same number)
                backtrack(i, current_combination, current_sum + candidates[i])

                # Remove the last added number to backtrack and explore other possibilities
                current_combination.pop()

        # Start the backtracking process from index 0, with an empty combination and a sum of 0
        backtrack(0, [], 0)

        # Return the list of all unique valid combinations
        return result
```

Find the highest number on levels.fyi for that company/level combo and give that.

> When considering 4 years at Amazon vs. 2.5 at Amazon and 1.5 at Meta, will one lead to better long term outcomes than the other if none of those led to senior promotion? Or does it not really make that much of a difference?

All things considered equal (you are mid-level at both and have a decent team that teaches you stuff), it really is about the same. I think Meta has more prestige than Amazon, but that will be cancelled out by the 1.5 year stint (recruiters will have concerns about loyalty).

The main thing that will really advance your prospects is getting an official FAANG senior title. That will open up a *lot* of doors. Companies can't get enough of engineers operating at that level.

Good question! There's a lot of things going on here:

1. Front-end vs. Back-end
2. Product vs. Infra (this is actually different from #1!)
3. Specialist vs. Generalist

For #2 in particular, I recommend this: ["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/)

For front-end vs. back-end, I think it really depends on your preference. As I mentioned in the list above, this isn't the same as product vs. infra as front-end infra engineers are a thing (we had a ton of mobile infra teams at Instagram). An example of front-end infra is you work on the core image loading component for Instagram, which is a common view used by every product team.

From my experience, front-end/back-end split isn't what makes the technical scope run out at senior, it's more product vs. infra. As long as you're in infra and your product has scale, there's generally tons of Staff+ level scope.

In terms of specialist vs. generalist, I don't think the market favors either one. I have seen both reach incredibly senior levels (L7+, $1M+ TC). What I will say though is that every engineer needs to start their career as a specialist as becoming *extremely* good at 1 thing provides the street cred and foundation to master other things (for me, this was Android product work): [This Is How Software Engineers Should Initially Learn](https://www.jointaro.com/lesson/wUl3hc2wr1ms493bd23b/this-is-how-software-engineers-should-initially-learn/)

I recommend going through Staff Engineer archetypes as well to understand how long-term career trajectories can play out: <https://www.jointaro.com/course/grow-from-senior-to-staff-engineer-l5-to-l6/why-have-archetypes/>

### **Work Culture & Work-Life Balance**

**Work Environment:** The workplace culture in the UAE is typically professional and dynamic, with a **multicultural workforce**. Since expatriates make up roughly 85–90% of the UAE’s population, and most tech teams are diverse and international. English is the primary business language in the tech industry, and teams often include colleagues from across Europe, Asia, the Middle East, and the Americas. This diversity fosters an inclusive environment but also means you’ll encounter a blend of work styles and cultural norms. In general, there is a strong emphasis on productivity and meeting targets, as the UAE is very business-driven. However, companies also respect local customs – for example, the work calendar accommodates Islamic holidays, and many offices adjust hours during **Ramadan** (with a legally mandated 2-hour daily reduction in working hours for all employees during the holy month). It’s also common to see company events and team gatherings celebrating both local traditions and international holidays, reflecting the mix of cultures.

**Working Hours:** The UAE officially moved to a **Monday–Friday work week** (with weekends on Saturday and Sunday) to align with global markets . Most tech companies follow a standard \~40-48 hour work week, typically around 8–9 hours per day. In practice, office hours might run roughly 9am to 6pm (with an hour lunch break), though this can vary by organization. **Work-life balance** can greatly depend on your employer and role. Some roles, especially in startups or fast-paced projects, may involve occasional late nights or weekend work to meet deadlines. Historically, the Gulf region has had a reputation for demanding workloads and longer hours in certain sectors , but this is not universal. Many multinational tech firms and well-established local companies are increasingly mindful of employee well-being. **Flexible work arrangements** are becoming common: post-pandemic, a number of companies (including big tech firms) have adopted flexible hours or hybrid remote-work policies to help employees balance personal and professional life . It’s not unusual for software engineers in Dubai or Abu Dhabi to have options to work from home a few days a week or adjust their schedule as long as targets are met .

**Work-Life Balance and Benefits:** Overall, UAE labor laws and company policies provide a solid foundation for work-life balance. Annual **paid leave** is quite generous – by law, employees get **around 30 calendar days of vacation per year** (after one year of service), in addition to around **10–15 public holidays** (exact number varies with the Islamic lunar calendar). This amount of leave is higher than what many Western countries offer, allowing expat workers ample time to travel or visit family. Employers also often organize team outings or provide on-site amenities (gyms, cafeterias, etc.) especially in larger tech firms, which helps create a more comfortable work environment. The culture in most tech workplaces encourages continuous learning and development – you’ll find opportunities for training, conferences, and certifications, which companies sometimes sponsor as part of professional growth initiatives.

In terms of daily life, expat software engineers generally enjoy a high quality of life in the UAE. Outside of work, there are plenty of options for recreation and socializing, and the country’s modern infrastructure makes day-to-day living convenient. With the combination of **tax-free income**, strong career opportunities, and a cosmopolitan lifestyle, the UAE remains a popular destination for software engineers looking to advance their careers abroad. Expats often cite the **competitive pay, sunny climate, and diverse community** as major positives. While the work culture expects dedication and results, more employers today recognize the importance of work-life balance, making it feasible to build a rewarding career without sacrificing personal life.

### Compensation

Software engineers in the UAE enjoy **competitive, tax-free salaries**, which make the compensation especially attractive to expats . Pay is usually quoted in **AED** (Emirati Dirhams) per month. Actual salaries vary with experience level, but approximate monthly ranges are as follows :

- **Entry-Level** (junior developer with limited experience): **AED 7,000 – 12,000** per month (approximately $1,900–$3,300).
- **Mid-Level** (a few years of experience): **AED 12,000 – 18,000** per month (\~$3,300–$4,900).
- **Senior-Level** (extensive experience or specialized skills): **AED 18,000 – 30,000** per month (\~$4,900–$8,200).
- **Lead/Manager** (team leads, engineering managers): **AED 25,000 – 45,000** per month for top-tier positions (up to around $12k).

These figures are **take-home** amounts since there is **no personal income tax** on salaries in the UAE . In addition to base pay, many companies provide performance bonuses and **generous benefits** that significantly enhance the overall package. For example, it’s common for employers to cover **private health insurance** and to provide an annual **airfare allowance** for expats to visit home, as well as **housing allowances** to offset rent costs . Some firms also offer **relocation assistance** (covering moving costs and initial accommodation) and even **education allowances** for employees with children .

**Factors influencing pay:** Salaries can vary by industry and company type. Tech professionals in high-paying sectors like **finance, banking, and healthcare** often earn at the upper end of the range due to the complexity and critical nature of their projects . Large multinational companies or established enterprises may offer higher base salaries (and more stability) compared to startups, which might offer slightly lower pay but other incentives like stock options . Company size and funding thus play a role: a well-funded tech firm or bank will generally pay more than a small startup, though the latter might compensate with equity and faster career growth. **In-demand skills** also boost compensation — engineers with expertise in areas such as cloud architecture, cybersecurity, artificial intelligence or big data can command premiums. Professionals with 5+ years experience and niche skills (e.g. AI/ML or blockchain) are often able to negotiate significantly higher salaries within the senior brackets . Lastly, benefits should be factored in: the **total remuneration** for expat engineers often includes perks like housing or transport allowances, end-of-service gratuity (a lump sum payout after completing your contract), and **paid leave** — all of which contribute to an attractive overall compensation package.

### Top Tech Companies

The UAE hosts a mix of multinational tech giants, regional firms, and innovative startups that hire software engineers. Notable companies include:

- **Amazon (Souq)** – The e-commerce and cloud services leader has a major presence after acquiring local marketplace [Souq.com](http://Souq.com), offering roles in software engineering, cloud computing, and IT solutions .
- **Microsoft** – The global software company’s Dubai hub focuses on cloud technologies and AI-driven business solutions, creating demand for developers and cloud specialists .
- **IBM** – A long-established tech firm in the region, hiring for cutting-edge roles in AI, cloud computing, and cybersecurity in its UAE offices .
- **Oracle & SAP** – Enterprise software leaders with regional offices that recruit for cloud services experts, database administrators, and solution engineers .
- **Huawei** – The Chinese telecom and electronics giant offers opportunities in telecom network engineering, 5G development, and digital innovation labs in the UAE .
- **Careem** – A homegrown success story (ride-hailing and delivery “super app,” now part of Uber) with large engineering and data science teams in Dubai .
- [**noon.com**](http://noon.com) – A fast-growing e-commerce platform founded in the region, hiring software developers, data scientists, and product managers to scale its online marketplace .
- **Anghami** – The Middle East’s popular music streaming startup (now a public company) with tech offices in the UAE, offering roles in app development and analytics .
- **Dubizzle (OLX Group)** – A leading online classifieds platform based in the UAE, employing web and mobile developers, UX/UI designers, and other tech talent to run its large-scale marketplace .
- [**Bayt.com**](http://Bayt.com) – The region’s top online job portal, which has an in-house tech team for its web platform and frequently hires software engineers and IT professionals .
- **Etisalat** – One of the world’s leading telecom groups, headquartered in the UAE, with extensive IT, network engineering, and digital services divisions employing software and system engineers .

*(Many other global players like **Google**, **Cisco**, **SAP**, and **Oracle** also have offices in the UAE, and emerging local startups in fintech, logistics, and ed-tech are continually entering the market. The tech ecosystem is diverse, giving expat engineers options in corporate, government, and startup environments.)*

I don't know any engineers in the UAE, so I tried out ChatGPT's relatively new Deep Research feature for this:

### Job Availability

The UAE’s tech sector is booming, creating a strong demand for software engineers across various domains . Government initiatives and a diversifying economy have positioned cities like Dubai and Abu Dhabi as emerging tech hubs, attracting companies and talent globally. Software development roles are **highly sought-after** and rank among the top in-demand jobs for the future in the region . Employers are hiring for numerous specializations – beyond general software engineering, there is growing need for **AI/ML engineers, data scientists, cloud specialists, and cybersecurity experts** to drive digital transformation. Tech talent is needed across many industries – from fintech and banking to healthcare, e-commerce, telecom, and even gaming and artificial intelligence . In fact, start-ups and local companies have become **very active in recruiting** tech talent (often even more than global tech giants at the regional level) . Common job roles include **software developers** (front-end, back-end or full-stack), **mobile app developers**, **DevOps and cloud engineers**, **data engineers**, and **project/product managers**. Recruitment experts note especially high demand currently for positions like cloud architects, cybersecurity specialists, project managers, software developers, and data engineers in the UAE .

***Visa Sponsorship*:** Nearly all employers hiring from abroad provide **visa sponsorship** for expatriate software engineers. Companies typically handle the work visa and residency paperwork, making the relocation process straightforward . Additionally, the UAE has introduced initiatives like a **Job Seeker Visa** (allowing professionals to enter the country to explore opportunities) and a **Golden Visa** program that grants up to 10-year residency to highly skilled tech professionals . These policies reflect the country’s push to attract and retain top global tech talent.

For the future, please negotiate your offer. Given the fact that you declined it, you were obviously willing to walk away - That is ***incredibly*** powerful. When you have nothing to lose, you can negotiate aggressively, and that confidence will show in how you communicate. Negotiating isn't just against competing offers, but against your current employment as well. Check out the negotiation course if you haven't already: [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/)

[**Mid-level to senior at Amazon is notoriously difficult**](https://www.jointaro.com/question/Tno7LGeINpsTPrljUTTT/how-to-navigate-the-difficult-sde-2-to-sde-3-promotion/), even with a good team. If you want to get to senior, Meta is definitely better, especially as it has the forcing function of [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/). Having an official senior title from a company at the level of FAANG does indeed open a lot of doors.

However, WLB is extremely important and is a rare resource in the current economy, especially at Big Tech. At the end of the day, you'll need to make a call on what you want to prioritize. There's nothing wrong with staying as an Amazon L5 for a long time - It's a terminal level after all.

A good proof of concept is defined by the name: *It can either prove or disprove a concept with a relatively high degree of certainty.*

Based on what you mentioned, it seems like you did a good job to me! Showing multiple approaches is good alongside demo-ing what you have (which is effectively the end result of a POC).

> Also I feel like something is missing because I haven't done any stress testing and haven't measured the difference of performance metrics between the "old ways" and the "new ways".

Is this required? Even though it's a POC doesn't mean you can't iterate on it. My advice is to move fast to deliver a POC showcasing the core improvements ASAP. If your teammates have feedback on additional information/demos they want, you can always quickly go back to the drawing board. Return for another demo after that and repeat as many times as necessary.

> Also, how long do you think POC should take?

Depends on the complexity of the project, but 1 week max IMHO, ideally even shorter.

genAI is great for POCs as they are often throwaway code. Your goal is just to demonstrate that an overall direction is feasible after all. The POC shouldn't be built on top of to deliver the final product.

Yes. However, the requirements are often malleable. I have a lot of [mentees who grew lightning fast at Meta](https://www.jointaro.com/lesson/EX9563YnxcJb62cCmetg/case-study-mentoring-junior-swes-e3-to-senior-e5-in-just-25-years-at-meta/), and for the most part, they aren't being downleveled (at least at the companies that matter). In the current market though, companies are enforcing these YOE walls more aggressively.

Level bars are roughly like this (these are bare minimums):

- **Junior:** At least 1 internship
- **Mid-level:** 2+ YOE
- **Senior:** 5+ YOE
- **Staff:** 8+ YOE

Many companies have a higher bar and are doing 3, 6, 10 for mid/senior/staff.

> But everyone i talk to tells me san jose is incredibly boring suburbia and not a fun place for early 20s.

Apologies to folks in San Jose, but this is mostly true. San Jose does have a decent downtown centered around SJSU, but it's surprisingly car-centric and not very large. San Jose was literally built to be a city that's just suburban sprawl.

San Jose was the original heart of Silicon Valley, but that crown has clearly gone to San Francisco over the past 15 years. If you are looking for a more innovative tech culture, vibrant social life, and more energy overall, SF clearly wins despite its *many* problems.

For what it's worth, I lived in San Jose for 4 years and grew up in the Bay Area. I have never lived in SF and never wanted to. Despite this, I can say as objectively as I can that SF is the undeniable cultural and tech center of the Bay Area region.

As I talk about in [my behavioral interview course](https://www.jointaro.com/course/master-the-behavioral-interview-as-a-software-engineer/), there's no such thing as a right answer for a behavioral question. What matters is your ability to present a narrative with conviction while defending your choices with an open mind.

If your team values quality over velocity, mention that. That's a good engineering cultural value that most top tech companies have. If your team really cares about quality, they should be making deadlines more conservative to match that anyways, so you aren't missing them.

It sounds harsh, but it's true: *Companies aren't willing to share feedback with you when they reject you, so why should you do it the other way around?*

Unless you **really** resonated with the folks in the interview loop and they were some of the nicest people you've ever met, just tell them you aren't comfortable sharing.

I have also heard "Man Jose", and I've read way too many horror stories on the San Jose subreddit from women who were on on terrible dating experiences with awkward San Jose tech workers 🤣

I haven't gone through it as I'm not an MLE, but ByteByteGo (the golden standard for system design stuff) seems to have machine learning material: <https://bytebytego.com/intro/machine-learning-system-design-interview>

As a Taro member, you can get ByteByteGo with a discount from the perks page: <https://www.jointaro.com/perks/>

First off, ask for help - You might as well. If you deliver a project late or with poor quality (or worse, both), you will lose reputation points anyways. Follow the advice from the question asking course to maximize the chances of you getting an answer while preserving your standing within the team: [Ask Great Questions That Get Great Answers Quickly](https://www.jointaro.com/course/ask-great-questions-that-get-great-answers-quickly/)

As Elliot mentioned, it's best in times like these to take a step back and clear your head. Go for a walk (ideally on a recurring basis), spend time with friends and family, get back into a hobby you've put on hold. Yes, surviving as an L3 at Big Tech is hard nowadays, but it's not *that* hard where taking the time to reset for a few days will tank you.

You mentioned that you're getting feedback regularly (or at least asking for it). That's a great start. If you're [probing for feedback well](https://www.jointaro.com/lesson/aGuxjGbFjYb34ofhRxjs/this-is-how-you-get-feedback-making-the-process-smooth/) and aren't getting any negative feedback, don't worry as everything outside of that isn't under your control anyways.

In terms of whether tech is right for you at all, that's a trickier question and I wouldn't spend too much time dwelling on that. If you want some answers though, check out this great thread: ["How do you know if software engineering is the right career for you?"](https://www.jointaro.com/question/JaceyBRDbpOc5F7OyVB6/how-do-you-know-if-software-engineering-is-the-right-career-for-you/)

It really depends on your risk tolerance as *any* decent startup at any stage will yield more technical/product learning compared to FAANG.

If you want to be safe, go to pre-IPO unicorn company like Notion, Perplexity, etc. Those companies are a sweet spot where there's still a lot of scope, but you'll get still top-of-market pay with potentially large financial upside. These companies generally match the salary bands of FAANG, and the equity has a very real chance of becoming valuable.

For example, Airbnb doubled its share price in its last round of funding. I know engineers who joined Airbnb as senior just 1-2 years before IPO and after IPO, their TC was over $ 1 million per year. They weren't some geniuses who spotted some diamond in the rough - Airbnb was already very mature by the time they joined.

> I personally dont recommend a super early stage startup (&lt;= series A) unless you personally know the founders.

I agree with this advice. If you join a very early startup without being very senior (senior/staff), it can easily be unproductive chaos where you're doing a lot, but a lot of it is random stuff like literally setting up furniture.

In terms of how to find the best startups, just browsing TechCrunch is a good start (and use Crunchbase to see funding/headcount trajectory). There's a lot more advice here too: ["How to evaluate a startup?"](https://www.jointaro.com/question/UCG4XxyEOTjjyg4pEuwY/how-to-evaluate-a-startup/)

Unfortunately you can't do a strict search right now from the job board - Radial search is tricky as you need very well-labeled geolocation data. It's on our backlog though!

The feature is only available on web, and it will likely never come to mobile sorry 😞

The complexity of starting a discussion is high due to the Markdown composer and very complicated identity logic. Even Markdown rendering on mobile is very tough and both the Android/iOS implementations have bugs due to shortcomings in the libraries they use. Given the relatively low volume of discussion (3-10 users start one per day), it's hard to commit the mobile resources to add this feature.

Mobile web is functional though, so if you want to do it on mobile, you can do that.

> Aside - If theres a better place to post about feature requests / bugs ? I don't want to take away from the career discussions taking place here.

I appreciate the thoughtfulness! There are a couple ways to share feedback:

- If you use the Taro Premium Slack space, post in #taro-app-discussion-and-feedback
- Just email us directly at team@jointaro.com

This is the classic bad manager scenario:

- Doesn't really people manage, is just a coder with a lot of power
- Micromanages
- Tramples over others

That being said, a lot of stuff you said about him seems quite positive like these:

> - He is direct, and use to give feedback about what we could improve in our ways of communicating things.
> - He shares the information we need in order to do our work.
> - He is very good when thinking analytical and provide answers when we need.

Because of these, I think the situation is salvageable. Given the market and the fact that you can't switch teams, I recommend trying to fix things. Check out this thread for ideas on how to proceed: ["My manager and I don't see eye-to-eye. How can I improve this relationship?"](https://www.jointaro.com/question/WWuU0HRpNu90J638iJPs/my-manager-and-i-dont-see-eye-to-eye-how-can-i-improve-this-relationship/)

This may be hard to believe, but I think your manager is at least average or maybe even a bit above. People often underestimate how bad engineering managers are. Most managers will embody the first 3 traits I mentioned and not the latter 3 I clipped from your list.

Best of luck!

Here's some notes on Android and iOS from both a US perspective and a platform perspective. I have worked on both with 10+ years of experience on Android and 3+ on iOS, so I have a lot to say:

### iOS

- There is more demand for iOS engineers as wealthier people (like Americans) tend to have iPhones. Businesses want to sell more to rich people instead of non-rich people, so you'll see way more American companies that only have an iOS app but not an Android app vs. the other way around
- *However*, there's a higher supply of iOS engineers than Android engineers because most American engineers have iPhones and they just pick iOS because of that. This greater supply actually cancels out the higher demand, maybe even more
- Because of this, I've actually seen iOS engineers get paid *less* than Android engineers from my experience. However, the gap isn't huge, maybe 5-10%
- As a platform, iOS is notoriously hard to work with as it's a closed ecosystem by Apple. You need to buy an expensive Mac and use Xcode. Because of this massive anti-competitive moat, Apple feels no pressure to make the SDK and development environment good
- However, iOS is the overall more polished platform. iOS users can only have iPhones, which are high-end phones. Apple bullies everyone into getting the latest OS version, so you only need to support the most recent 2 OS versions. This makes your life *so much easier* as a developer

### Android

- Android is unfortunately the "poor people's phone" in the eyes of many Americans, so the supply of Android engineers is actually quite low in the US
- Because of this and the fact that every big company needs an Android app eventually, Android engineers make *more* based on my Silicon Valley experience. It's probably exacerbated in the SF Bay Area as it's a very wealthy region where iPhones have a very large advantage over Android
- Android, unlike iOS, is open-source. This makes it easily extensible and debuggable. The Android open-source scene is 5x stronger than iOS's
- Android Studio is great since it's a fork of IntelliJ. IntelliJ-based IDEs are generally very good, and they can be easily extended with many plugins
- The Android user ecosystem though is a clusterf\*ck to say the least. Since Android is just an OS that any manufacturer can deploy, you need to account for 10,000+ different phone types, especially if you work at a big company like Duolingo
- On top of the physical devices being different, Android users are often slow to upgrade their OS, especially in developing markets outside of the US. Most bigs apps need to support 5+ or even 10+ (!!!) OS versions. WhatsApp supports **15** Android OS versions (21 -&gt; 35) 🤯. This will often lead to you writing a bunch of if-statements to make sure that your code works for everyone. It's not pretty and is quite frustrating

Zooming out, you should figure out if Duolingo values Android or iOS more. This is relatively easy to test: Try Duolingo on both an Android phone and an iPhone and see which app feels better. If the iOS app has more features and UI polish, it's clear the company values iOS more.

If I had to guess, Duolingo is more iOS-focused. Very few companies are Android focused with Meta being one of them (this is actually one of the reasons I joined Meta).

**Short answer:** Pick the one that matches your personal device.

**Longer answer:** You want to match your personal device for many reasons:

1. You'll be intrinsically familiar with the OS-level design patterns. Apple and Google want very different vibes to their products
2. It's much easier to dogfood (i.e. use your own company's product). Duolingo is one of the most successful consumer apps of all time, so it's perfect for dogfooding. Dogfooding is great for establishing end-user empathy, which will give you greater product sense. Once you become more senior, you can use that product sense to [create scope](https://www.jointaro.com/course/grow-from-mid-level-to-senior-senior-l4-to-l5/the-goggles/)
3. It's just more fun and motivating to see something you built on your own device instead of just an emulator running in your IDE sandbox

Here's a good thread about picking up Android: ["How can I get really good at Android?"](https://www.jointaro.com/question/r18MMuiBoRR0ugpxJ7bC/how-can-i-get-really-good-at-android/)

Here's a good thread about picking up iOS: ["Good resources to learn iOS app development?"](https://www.linkedin.com/company/duolingo/)

As Rahul mentioned, "research" is an incredibly broad term. Have you considered doing post-grad? PhDs in particular go deep on research.

If you have a competing offer that is higher than your current TC at Google (ideally from another Big Tech), I'm pretty sure that you can get a meaningful raise at Google.

However, Google's budget is tighter now I imagine given that the current tech economy is a complete mess, so be prepared to take that offer if they can't play ball. It's very awkward to have a bluff called out.

To put things into perspective, there's only 2 possible scenarios here:

1. **This E6 just hates everyone** - This problem will naturally solve itself over time. The manager will get feedback from everyone else, and something drastic will happen. Either the manager will give strong feedback to the E6 and fix them, or the E6 will be replaced in some way. Or maybe the manager prizes the E6 over everyone else and tells everyone who doesn't like that to leave.
2. **It's just you the E6 doesn't get along with** - In this case, the situation is under your control. Think back across all your interactions with them, and see if you could have rubbed them the wrong way unintentionally. Maybe you missed a thoughtful diff review comment a long time ago (this has been a *very* common reason I've gotten mad at engineers), had a messy system design document, or didn't do a thorough Deltoid analysis on an experiment. After that introspection, come up with a list of ways you can improve, share it with your manager, and execute.

Since Meta is all RTO now, a relatively simple action is to take them out for a coffee or afternoon snack or something. If you're in the Bay Area, maybe get them some Blue Bottle.

I recommend this as well: [\[Masterclass\] How To Build Deep Relationships Quickly In Tech](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/masterclass-how-to-build-deep-relationships-quickly-in-tech/)

It's important in this situation to have empathy and follow one of Meta's mantras: *"Assume good intent"*.

E6s are incredibly busy, stressed out, and overwhelmed. This is going to get even worse given the sharply negative direction Meta's culture has gone down recently. It's not likely that this engineer is purposefully out to get you as that's not in their best incentive to do that. E6s largely achieve impact by delegating through their E5s.

As Jonathan mentioned, think of ways you can improve the relationship. It's not a matter of who's right or wrong on what here. It's a matter of finding a way that you 2 can synergize better together, and the onus is frankly on you as you're both new and less senior than this person (i.e. you have far less leverage).

I have been the stressed out tech lead many times before shooting people down (often newbies like yourself), including at Meta. It's a hard job, and there were many times where I didn't communicate in the most polite way or execute in the smoothest fashion which I regret as someone who genuinely tries to be a nice person. However, looking back on those scenarios, there was never a case where the person I shot down *couldn't* have done a better job by creating more intricate planning documents, spending more time getting to know me and other gatekeepers, and communicating more proactively. You should look for those opportunities.

All that being said, definitely talk to your manager about this. It's their job to resolve these interpersonal disputes, and 16 hour days aren't healthy. It's in their best interest to make sure you don't burn out.

> Is it too early to switch teams? How quickly can this process occur?

Team switches generally require 1+ years on your current team with sustained "Meets All" or higher ratings. This means that it will be very hard for you to switch, especially given how Meta is now. However, it can be done in an emergency. You can try this if it's been over a month, and you and your manager still aren't able to solve this problem.

Here's a similar thread, which I highly recommend: ["As a MLE, how should I communicate with a difficult backend engineering lead?"](https://www.jointaro.com/question/BQhuTbP5N2rA07Nflmm8/as-a-mle-how-should-i-communicate-with-a-difficult-backend-engineering-lead/)

Based on what you've said, "Meets Expectations" seems low, but the market is quite rough right now and my perspective here is obviously limited.

I've been in this boat before, and the main thing to do (easier said than done of course) is to not dwell on the past. Focus on the future instead and figure out how you can get better. Make it your goal to become so ***obviously*** impactful and useful to your organization that they have to give you great ratings and a promotion.

The good news is that the feedback your manager gave you seems legitimate. This is a very, very common piece of feedback for engineers at senior to start developing staff behaviors and level up. Think about how you can expand scope of existing workstreams and what relationships you can build outside of your team.

Rahul already linked the Senior to Staff course, so I'll link a case study of a good example of a Staff-level project: [\[Case Study\] Revamping Oncall For 20 Instagram Engineers - Senior to Staff Project](https://www.jointaro.com/lesson/esVxIGXYC5BdgxXUkO6H/case-study-revamping-oncall-for-20-instagram-engineers-senior-to-staff-project/)

I don't know exactly how Google works, but I imagine it's similar to Meta where everything is very formulaic and derived from your rating + level. I can't imagine you have a lot of room to negotiate or learn any actionable information.

That being said, I do know that Google does respect competing offers, especially from Meta (lol). I know Google L4s who get a competing offer from Meta, took it to their manager/director, and got a $100k+ pay bump to $400k+ TC.

In contrast, Meta doesn't respect competing offers at all. They just tell you to take it or stay.

Congrats on getting the great feedback! That's a great way to start your journey at Airbnb, which I personally consider one of the best tech companies out there.

Creating Staff scope is obviously difficult - If it wasn't, then far more people would be Staff and the title would lose most of its meaning. There isn't exactly a playbook to create scope as it varies wildly based on company, team, and tech stack, but there's a bunch of ideas here: ["How do I come up with innovative, impactful ideas and bring them to my team?"](https://www.jointaro.com/question/3QIJhAT4loA7n1hSfCuw/how-do-i-come-up-with-innovative-impactful-ideas-and-bring-them-to-my-team/)

At a very high-level, I recommend:

1. **Look for problems** - From there, work backwards from them to create the opportunity as that's why any of us do anything, to solve genuine problems that real people have, either teammates or end-users.
2. **Talking to a bunch of people and listening to their complaints** - Engineers love to complain, so it's not too hard extracting this feedback from them once you have a decent relationship.
3. **For anything you work on, think about how you can expand its benefit** - Expanding scope is way, way easier than creating scope from scratch. It's a much more organic action, and you'll face less opposition.

I also highly recommend our Senior -&gt; Staff course which has case studies for inspiration on how to find that scope: [Grow From Senior To Staff Engineer: L5 To L6](https://www.jointaro.com/course/grow-from-senior-to-staff-engineer-l5-to-l6/)

Mentality takes time to fix, and the journey is largely self-driven. What I can do right now though is give you some pointers and perspective to help out:

1. **You are currently employed** - You are already doing better than hundreds of thousands of engineers who have been laid off. The market continues to be rough, especially after the recent US election. Take comfort in the fact that you always have this cushion to fall back on.
2. **You have a lot of experience** - With 6.6 years of experience, you are firmly out of the "early-in-career" bucket. The market isn't the best for mid-level engineers, but it's doable, unlike for junior and early mid-level engineers. If you play your cards right, you could probably land a senior offer as well.
3. **Stop caring** - This is the big unlock that I've seen drastically change the vast majority of folks struggling on their job search. Ironically, the more you care, the worse you'll do. The less you care, the better you'll do. And the cool thing here is that you have the tools to not care as you still have a job right now. I break this down in depth here: <https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/having-the-right-mentality/>

I recommend going through the entire job search course. I think it'll help a lot: [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/)

I like Garry Tan, but he has some... weird takes sometimes. Remember that he literally runs the biggest startup accelerator on the planet, so it's in his best interest to drive the AI narrative.

That being said, I wouldn't be surprised if these numbers were true (i.e. not cherry-picked/stretched/distorted). YC focuses on very early-stage startups, and when you're just starting out, it makes sense to quickly generate a bunch of throwaway prototype code.

As Rahul mentioned though, generating 95% of your code with AI won't fly in any larger company. Even at Series A, you're generally going to have some sort of technical debt and certain contextual roadblocks that AI will struggle to work around. You will also have some amount of traction at that stage, so you can't just hit full send on risky AI-generated code. It's been 2+ years since ChatGPT came out, and I still 100% believe that the skills in this course (skills that AI are absolutely terrible at) are extremely valuable: [Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)

Here's another fun thread about AI coding: ["ZUCK will replace mid level engineers with AI"](https://www.jointaro.com/question/gFUVPNsu03uHFmshuuTF/zuck-will-replace-mid-level-engineers-with-ai/)

> Thank you Alex! Can you share a sample google doc of the system design you created for a project you drove at Meta or any other project?

Follow the doc linked in that course (check out the video description of any lesson that's the 3rd or beyond). The format is literally exactly the same.

I couldn't port anything from Meta externally for obvious reasons.

My team used Quip, so if you look me up in Quip, you can probably find my old docs. Another way is to look me up in Workplace and look at my most popular posts.

Being new on a team is like puberty: It's awkward, and it happens to everyone, even very senior people. Unlike puberty though, you have more control over it:

1. **Your mindset** - Use your cluelessness as an asset instead of treating it as a weakness
2. **Your urgency** - Accelerate the time table by aggressively asking questions, being extremely nice/friendly/enthusiastic, and winning with quality

All of this is covered in 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/)

For something more specific, I gave a case study on how I quickly adapted after switching from Meta to Robinhood: [\[Case Study\] Becoming A Tech Lead Again In Just 1 Month After Joining Robinhood From Meta](https://www.jointaro.com/lesson/X8vpfJooDpsX915ouC00/case-study-becoming-a-tech-lead-again-in-just-1-month-after-joining-robinhood-from-meta/)

I like this thread as well: ["How do you learn "on the job"?"](https://www.jointaro.com/question/kv2KAIr16TuvRKPs7sY2/how-do-you-learn-on-the-job/)

I assume the company you're working for now is a good one that you're proud to be at. If this is the case, that means that their interview process is very fine-tuned, engineered to only let in the best people. The fact that you passed means that you belong there! Keep your head high.

A domain switch will definitely hit your productivity and performance in the short term. However, I do think general software engineering has a big benefit over security engineering in the market: *Flexibility*

- Startups don't really care about security as they're just trying to get users on their product to begin in
- The lack of security can go surprisingly far. Even when I was at Course Hero at a Series B stage (50+ engineers, $10M+ yearly revenue), their security was terrible. I found massive security flaws as a regular SWE
- This means security engineers are largely relegated to larger companies

All that being said, the biggest factor here is you and your passion. Do you genuinely love security engineering? Then I think you should stick with it. Are you maybe getting tired of it and are open to trying new things? Maybe give SWE a shot. As a Staff Engineer, you have options. Junior engineers on the other hand need to pragmatically stick with what they already know just to survive.

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

First, there's nothing wrong with copy-paste. I feel like a rite of passage for most engineers is realizing that seeing the same code twice (or more) isn't the end of the world. The problem with abstracting away logic into common areas is as you mentioned:

1. Use-case 1 wants to modify A, B, C, and D
2. Use-case 2 wants to modify just A, B, and C
3. If the 2 use-cases share some method like processPipelines() that touches A, B, C, and D, you break Use-case 2

When moving code into common places, it's a spectrum of granularity:

1. **Most granular** - Moving tiny pieces like hard-coded strings into constants
2. **Medium granularity** - Taking specific slices of business logic and putting them into methods like processPipelineA()
3. **Low granularity** - Moving almost all business logic into a common class/method like processAllPipelines()

Figure out what level you can take on that balances reusability and scalability (without breaking things and needing to write a bunch of if-statements).

Also, you will often need to write specific business logic.

I don't have the full context of your code and I'm not an ETL specialist, so I made guesses where I could. Hopefully at least some of this made sense.

Lastly, AI can be helpful with this if given enough context. It will rarely give you a great answer off the bat, but it's useful for bouncing ideas off of and then molding what inspiration they give you.

All of the things you mentioned are good - I have seen AI struggle with all of those. It can be pretty decent at debugging though as the success criteria there is more clear.

For technical things, I would also add code review. Code review is an extremely contextual process that depends a lot on the engineering cultural and legacy historical decisions of the team (i.e. [code quality means different things in different teams](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/case-study-instagram-vs-robinhood/)). I have tried a couple code review AI bots, and they're all *terrible*. I can only imagine how terrible it would have been reviewing code on my Instagram team.

Here's another good thread about the topic: ["What are product skills and how to develop them in the age of ChatGpt and CopilotX?"](https://www.jointaro.com/question/n2qq0tGjSTDu982KL3nL/what-are-product-skills-and-how-to-develop-them-in-the-age-of-chatgpt-and-copilotx/?playlistId=qeFEXCDpfUiogN6iJI4f)

The good news is that you don't need to do anything particularly different in the age of AI. The growth path engineers were already following before ChatGPT took the world by storm, particularly at top tech companies, is still the same. It's just that the pace is accelerated and junior engineers are pressured to advance on that path much faster. Start off with this: <https://www.jointaro.com/learning-paths/nail-your-promotion-junior-to-mid-level-l3-to-l4/>

I recommend going through these lessons in the promotion course:

- <https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/sell-yourself-claim-your-wins/>
- <https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/brag-journal/>

It is hard to come up with a step-by-step guide as this will vary by company. At a very, very broad level, the process is:

1. Define success (and failure) metrics for a project before working on it
2. If you need additional logging to get those metrics, add it while developing the project
3. Ship the project
4. Keep an eye on analytics and see how they're trending vs. your success criteria

At Big Tech, this process will be super complicated as you'll need to set up an A/B test, dashboards, and a bunch of other stuff to measure the impact with extremely high granularity.

At startups, you might not even have to do this at all. A lot of startups will just ship stuff with minimal or even 0 logging. At early-stage startups where they're just building prototypes, the feedback can be purely qualitative/anecdotal.

Talk to your manager and tech lead about what success looks like in your team and how to measure it.

It is common for all engineers at Meta to work 50+ hour weeks, and this is even more true now. For interns where Meta is their first FAANG-level company, this is often the case as they need to adjust rapidly to the high engineering bar.

In terms of hours to work:

- Work whatever hours you need to get stuff done
- Overlap with your team as much as possible
- Prioritize being in sync with your intern manager and other engineers who review your diffs + answer your questions

I recommend these 2 courses:

- [Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)
- [Maximize Your Productivity As A Software Engineer](https://www.jointaro.com/course/maximize-your-productivity-as-a-software-engineer/)

Lastly, I just want to mention that if you play your cards right ([use your 1 on 1s effectively](https://www.jointaro.com/lesson/bgfN3YVJc82YrZSjOXgq/the-1-thing-to-remember-with-meetings/?playlistId=RJ2r6sC85xqtIDvBt1fF), [add value to people](https://www.jointaro.com/lesson/QYQHPiYqZvBzuQw1Vjnc/supercharge-your-professional-networking-by-leading-with-kindness/?playlistId=nvsMxZ9ZGIjlyaZbWqYS), [communicate with empathy and enthusiasm](https://www.jointaro.com/course/effective-communication-for-engineers/effective-communication-guide-part-1-core-high-level-principles/)), the ceiling on what you can share with your manager is effectively infinite.

I have had 11 managers. For the first 5+, I was pretty terrible about managing this relationship and getting the most from it. By the end, I got pretty good at it, which is a large reason behind my career success.

How good? Well, I told my manager at Robinhood that I was exiting Robinhood to start my own company *2 months* before I was going to leave. That's how much I trusted her, because we got along really well. She was sad that I was leaving but supported my decision. And when Taro launched on Hacker News many, many months after I left, she even reached out to me personally to congratulate me! That's how powerful you can make this relationship.

Just because they're your boss doesn't mean you can't turn them into a friend.

This is a good question, but it's a tricky one. In a nutshell, the answer is *"Share more if your manager likes you, less if they don't"*. However, you need to do the work to figure out how healthy that bond between your manager and you really is. This will require some amount of social intuition from you alongside careful observation and plenty of meetings (obviously).

It will also require some amount of a leap of faith as humans misjudge the depth of their relationships all the time - I'm sure we've all had a situation where we thought this person really deserved our trust but sadly didn't. Keep this in mind, but don't let you stop you from opening up.

Going back to your particular scenario, I think you should share your feelings of anxiety and imposter syndrome with your manager (assuming your relationship is good). This was actually how I conquered my imposter syndrome back when I started at Meta (thankfully my 1st manager there was extremely empathetic).

Here's another good thread to check out: ["What's the boundary between what's okay to share with your manager vs. what's not? Are some things simply too deep?"](https://www.jointaro.com/question/3L4B8iqM7D5GYsYy6xWx/whats-the-boundary-between-whats-okay-to-share-with-your-manager-vs-whats-not-are-some-things-simply-too-deep/)

I like this one about imposter syndrome as well: ["I've felt imposter syndrome from seeing super talented peers - How do I deal with this?"](https://www.jointaro.com/question/MPUkGXFDaBixmxfjOg9i/ive-felt-imposter-syndrome-from-seeing-super-talented-peers-how-do-i-deal-with-this/)

Back in my day, interns could still get a return offer with very few Workplace posts, non-proactive communication, and weak question asking. Meeting the Meta technical bar is already hard enough, so expectations aren't super high here.

> what strategies do you use to come up with test cases and edge cases?

On top of the exception covering I mentioned before:

- Role-playing as a malicious user
- Role-playing as an incredibly dumb use
- Talking to other engineers who are more familiar with the space
- Pattern recognition from raw experience
- Asking genAI for some ideas

Here's another thread about general DSA edge cases as well which is still applicable: ["How do you find edge cases in DSA problems for FAANG?"](https://www.jointaro.com/question/JbK5LlJsKk9SW7sKc5Cc/how-do-you-find-edge-cases-in-dsa-problems-for-faang/)

> I played Devil’s Advocate against myself today, and the meeting went much more smoothly than previous ones.

That's awesome! Well done 😊

You should *always* use AI where you can as it is part of the modern day engineering workflow, and it will only grow in importance over time. The tricky part though is using it to bolster your velocity and learning instead of having it be a crutch for them, which I break down here: ["How Can Junior/Mid-level Engineers Effectively Integrate AI into Their Coding Workflow?"](https://www.jointaro.com/question/dlsuqOZpW9O2zOjdCUIl/how-can-juniormid-level-engineers-effectively-integrate-ai-into-their-coding-workflow/)

That being said, it's important to remember that with side projects, you want to set them up in a way where even if they don't get users, you still come out a winner. This is especially important in the beginning as chances are that your initial side projects won't get users as you're learning the ropes.

One of the main ways to always be a winner is make sure that you emerge with learning and genuinely sharper skills. You will get more of that if you lean more towards struggling in the code organically and trying to piece things together yourself vs. having the AI generate everything for you. Similar to how I study LeetCode, my approach is as follows:

1. Do things myself until I hit a roadblock
2. Have AI unblock me on that particular piece
3. Make sure that the AI deeply explains what it's doing and why (just tweak the prompt as Sai mentioned)
4. Repeat this process

That seems like a reasonable middle ground to me.

So as you have figured out by now, contractors get way less credit then full-time engineers do when it comes to hiring. [That's because contractors are largely 2nd class citizens at the companies they work at.](https://www.jointaro.com/question/KM6mWpwwCZHRwh2WF4LI/faang-contracting-is-it-worth-it/)

In general, I'm a big proponent of honesty - I think you should tell them. However, I don't blame you if you don't as the market sucks right now. If you switch the label to contractor on your resume and go to getting 0 callbacks, well, that's not exactly great.

What I will say though is that finding out that you were a contractor at a prior role is generally not too hard. When companies dig deep into references, there's a very, very high chance they'll find that information, especially Big Tech companies who have access to literally all the information in the world. If they find out that you hid this information from them all along, it will probably lead to instant rejection and potentially even blacklisting as well. Be careful.

Payments overall are a basket case of potential edge cases and failures:

- Insufficient balance to issue the payment
- Payment just fails for some reason
- Duplicate payments
- Payment is a fraud (not authentically created by relevant parties)
- Payment is money laundering
- One of the payment parties is an illegal organization (terrorists, drug cartels)

There are also a ton of laws governing what you need to do with payments, and that opens up even more edge cases. For example, payments usually need to be logged so you can construct a ledger. That has edge cases like the log not being created, the log being created but malformed, the log being created correctly initially but then getting corrupted later, etc...

Modern coding languages generally help with this process as code that can fail will return an exception. Understand why and what kind of exception it is. From there, seriously think about the user implications and how to react if that error were to occur.

I think you might have seen this already, but this particular case study lesson from my code quality course can help get the test case juices flowing: [Case Study: Signup Form Edge Cases](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/case-study-signup-form-edge-cases/)

GenAI tools are pretty lacking here, but they're surprisingly semi-decent. If you give a detailed enough prompt and tell it general edge case areas to think about, it can give you some good ideas to get started. I've tried it a couple times and have been impressed.

This is a classic communication conundrum, and the particular stacks you're on don't super matter here as the solutions are the same across all backgrounds.

Before I go into more details, I first recommend going through this lesson in my [communication course](https://www.jointaro.com/course/effective-communication-for-engineers/): [Resolving Disagreements](https://www.jointaro.com/course/effective-communication-for-engineers/effective-communication-guide-part-4-resolving-disagreements/)

With that out of the way, there are many, many ways to tackle this problem:

1. **Lay out your case more pragmatically** \- In particular, I recommend creating a [system design document](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/) that lays out the pros and cons in detail of your approach vs. theirs. Make sure that you work backwards from first principles by identifying the engineering cultural values your org cherishes most and using that to anchor the discussion. *On top of that, attach as much cold, hard, data as possible.* Your approach leads to higher CTR? - Prove it. From what I can see here, the database approach is simpler but less performant/harder to scale while your search engine approach has more complexity but more general power underneath. This isn't a clear case of right or wrong - Different orgs would make different decisions here.
2. **Introspect and be a Devil's Advocate against yourself** - As I talk about in that "Resolving Disagreements" lesson, this is a critical step. Stepping back and looking for flaws in your own approach objectively makes you have a lot more empathy for the other side. Assuming you didn't change your mind on your approach, that empathy can help you convince them better.
3. **Assemble backers** - It's much harder for this tech lead to turn you down if there are 10 other engineers on your team who support your strategy vs. if you were just vouching for it on your own. Talk to others on your team and see what they think, ideally after you made that super detailed system design doc.
4. **Disagree and commit** - I'm stealing from an Amazon LP here, because it's a good one. You can't win every possible battle. I've done detailed proposals for engineering solutions I deeply believed in countless times and gotten shot down. It's a part of life. When this happens, it's important to be graceful in loss so that you can earn some social capital that hopefully lets you pass future decisions.
5. **Escalate** - This is a nuclear option, but if the tech lead continues giving you a hard time, talk to your manager. It's their job to resolve internal politics like these.

It's important in situations like these to assume good intent because it's frankly easier to work with a tech lead who likes you vs. one who doesn't.

Your goal isn't to prove that their database idea is wrong, it's to make better engineering decisions as a team.

Your goal isn't to call out their gaps with machine learning knowledge, it's to deepen the team's collective understanding of machine learning.

Similar to that other post, I recommend going through the L3 to L4 learning path which breaks down the evolution of junior engineers in great detail: [Nail Your Promotion: Junior To Mid-Level (L3 -&gt; L4)](https://www.jointaro.com/learning-paths/nail-your-promotion-junior-to-mid-level-l3-to-l4/)

Here's how it works in broad strokes:

### Meets All

- Solid coding velocity
- Decent code quality that comes together in the last 3-4 weeks of the internship. Will still put out diffs that get roasted pretty bad occasionally
- Can solve tasks independently but needs a little hand-holding sometimes
- Lackluster communication

### Exceeds Expectations

- High code velocity
- Good code quality that starts coming together around the midway point of the internship. Rarely puts out low quality diffs
- Solves tasks very independently, rarely needs hand-holding
- Good communication

### Greatly Exceeds

- Extremely high code velocity
- Stellar code quality that comes together astonishingly early in the internship (like week 3). Almost never puts out a diff that gets a major amount of comments
- Solves tasks extremely independently, even those with high technical complexity and ambiguity
- Great communication with many well-written project updates
- Takes the initiative, creates some small scope here and there for themselves

IDEs have a ton of buttons, so don't feel free if you can't immediately find something that a mentor points you too. *"It's in the menu at the top right"* can often times mean like 8 different things 🤣

There's 2 simple things you can do:

1. **Use the tools outside of work** - Getting used to common dev tools like command line and certain IDEs is just building muscle memory. [Do some side projects](https://www.jointaro.com/course/build-side-projects-with-500k-users-coming-up-with-an-idea/how-this-course-works/) to make your hands and eyes familiar with common workflows like building a project, navigating to a certain file, adding break points, etc.
2. **Just ask for help** - There's nothing wrong with asking questions, especially as an intern and if you ask [high-quality questions](https://www.jointaro.com/course/ask-great-questions-that-get-great-answers-quickly/). You can always lighten the mood by prefacing your questions with something like, *"Sorry, my eyes don't work...* 😅".

With outside people (e.g. regular engineers you're looking to get a referral from), yes, I think it's good to be open about it. It will get you sympathy which hopefully leads to a higher willingness to help.

With the hiring loop (recruiter, hiring manager), *I don't think you should be open about it*. If they ask why exactly you left your previous company, you can mention that you were part of a reduction in force, ***but definitely don't volunteer that information upfront***.

My answer has changed a lot since 2 years ago. Back then, the layoffs were much bigger and random. The economy was worse. If you were laid off back then, people generally thought that the cut was necessary for the company to survive and it wasn't your fault.

Nowadays, layoffs are tinged with stack rank, PIP, and low performance energy. We saw this recently with the Meta layoff and the Intuit one before. Even if you were a high performer at the company, the hiring loop will assume that there's some chance you're a bad engineer and were laid off because of that.

The truth doesn't matter when it comes to discrimination, and that's what a lot of surviving (and getting) interviews is - Avoiding discrimination.

Here's another similar thread, relevant even if performance-related reasons aren't applicable to you (just covers generally good communication techniques to shield yourself): ["How do I pursue recruiters if I was fired from my previous job?"](https://www.jointaro.com/question/epp8z0h1YAIPOwwWmWVG/how-do-i-pursue-recruiters-if-i-was-fired-from-my-previous-job/)

> And what org to join?

I remember when my intern showed me exactly what he got in team matching, and it wasn't much. That makes sense as interns are the most expendable, and there's so many of them. So my broader point here is to not worry about this too much as you don't have a lot of control anyways.

*My main advice here is to pick whatever tech stack you're best at*, which is ideally the one you're the most passionate about. The tech stack was the one meaningful thing my intern showed me that he was allowed to put input in for (he chose mobile as an interest). The type of org doesn't matter as you are just an intern (i.e. you aren't held responsible for scope). Every org will have some internal tool that an intern can work on for 3 months. What matters is the quality of intern manager, but you don't have a choice there as an intern anyways. Every org will have terrible intern managers, great intern managers, and intern managers in between.

If you want to get a head start, [use side projects](https://www.jointaro.com/course/build-side-projects-with-500k-users-coming-up-with-an-idea/how-this-course-works/) to bolster your raw technical mastery of that tech stack. Use AI as little as possible to actually learn the concepts and maximize your chances of impressing your Meta teammates.

Your goal as a Meta intern is to function as a fully-fledged E3 by the end. That means the ratings are roughly the same (just drop a third of a band):

- Intern Meets All Expectations (MA) = E3 MA- to E3 MA
- Intern Exceeds Expectations (EE) = E3 MA+ to E3 EE
- Intern Greatly Exceeds Expectations (GE) = E3 EE+ to E3 GE

When an E3 starts performing at very high Exceeds or Greatly Exceeds level, they are now functioning as an E4 or 85%+ of the way there. To understand E4 expectations, go through the learning path: [Nail Your Promotion: Junior To Mid-Level (L3 -&gt; L4)](https://www.jointaro.com/learning-paths/nail-your-promotion-junior-to-mid-level-l3-to-l4/)

I've worked with a few GE interns, and here's the traits they had:

- Very high diff count (around double the average intern or more). This velocity should translate to you not only getting your entire intern project done on time but early as well. If your intern project has any bonus features, you've done them all
- [Very high diff quality](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/one-diff-one-thesis/) (starting from Week 3-4, your diffs rarely get rejected)
- [Asks very high-quality questions](https://www.jointaro.com/course/ask-great-questions-that-get-great-answers-quickly/)
- Can disambiguate tasks on their own (particularly the decomposition bit)
- Communicates project progress very well (interns only need to write 1-2 Workplace posts to get an offer, but GE interns will write 5+)
- Starts helping other people on the team (other interns alongside E3s)
- If working on product, has some product and design sense
- Shows some initiative, taking on tasks without people asking them too (fixing some bugs in the backlog, adding test coverage, etc)

This is an incredibly high bar to clear, so don't feel bad if you don't hit it. Only 5% of interns can go into this bucket. The vast majority of Meta interns spend most of the 3 months learning how to code at a FAANG level and developing basic communication skills.

As I have mentioned many times, you don't want to write down word-for-word (or anything close to it) what you're going to say as that encourages your brain to just memorize.

I think the detail you have is good. It's enough that the shape of your narrative is clear but also sparse enough that it forces your brain to be nimble and fill in the gaps organically during the interview.

This is around the same level of thoroughness I had with my behavioral interview notes.

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

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

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

Michael will be breaking down his story about how he became Meta's first incredibly senior "Code Machine" engineer in this event. He'll cover the most impactful projects he worked on and how he managed his time effectively to write so many diffs. At the end, we'll have time for Q&A where you can ask Michael questions about how he grew so quickly and crafted such an extraordinary career.

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

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

Michael Novati

Tech Lead/Manager at Meta, Pinterest, Kosei

Rahul Pandey

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

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

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

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

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

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

[Course] Master The Data Structures And Algorithms Interview

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

[Course] Break Into Tech And Become A Software Engineer

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

[Course] How Engineering Managers Hire Great Engineers

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

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

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

[Course] The Top Ways People Fail System Design Interviews

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

[Course] Clear Communication For Software Engineers

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

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

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

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

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

[Course] Ask Great Questions That Get Great Answers Quickly

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

[Course] Maximize Your Productivity As A Software Engineer

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

[Course] How To Be An Effective Tech Lead

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

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

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

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

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

[Course] Master The Behavioral Interview As A Software Engineer

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

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

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

[Course] Nail Your Promotion As A Software Engineer

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

Taro Book Club: Designing Data Intensive Applications

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

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

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

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

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

Underrated Engineering Discussions

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

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

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

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

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

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

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

[Taro Top 10] Effective Mentorship And Growing Others

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

[Masterclass] How To Work Better With Your Engineering Manager

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

[Masterclass] How To Learn Quickly In Tech

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

[Masterclass] How To Do Amazing Code Review

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

[Masterclass] How To Survive Tech Industry Layoffs

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

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

Your career lives or dies on the quality of your professional network. Whether it's finding a job or getting promoted, you always need a large bench of people willing to go to bat for you.

[Masterclass] How To Build Deep Relationships Quickly In Tech

Promotion, not job switching, is the true foundation for any software engineering career. However, you don't get promoted by just doing good work and hoping for the best - You have to be much more deliberate about it.

[Masterclass] How To Get Promoted Faster In Tech

The 1 on 1 meeting is one of the important mechanisms within the workplace, especially in the fast-moving tech industry. How you leverage this time will make or break your career, especially when it's with your engineering manager.

[Masterclass] How To Have Impactful 1 on 1 Meetings

The absolute 1st step towards a successful job search is to have an effective, polished resume. Despite this, so many engineers mess this up, missing a lot of low-hanging fruit to improve their resumes.

[Masterclass] How To Write A Stellar Tech Resume That Gets You More Job Opportunities

As a software engineer, you are going to work across many, many different teams and companies across your career. This means that it's vital for you to get good at onboarding, so you can hit the ground running at any new job.

[Masterclass] How To Succeed At A New Team Or Company As A Software Engineer

Money. It's what makes the world go round, and it's especially true for the tech industry. Software engineers are paid more than 95% of the population, but tech compensation is... complicated to say the least. There's far more to it than base salary.

[Masterclass] Understanding And Optimizing Your Pay In Tech

We all have the same 24 hours in a day, from the new grad engineer to the veteran principal engineer. 1 common theme that separates the rockstar engineers from the rest is that they're able to get far more done (up to 100x more) from those 1440 daily minutes.

[Masterclass] How To Manage Your Time Optimally In Tech And Achieve More Results

It doesn't matter how talented you are as a software engineer: If you don't have a good engineering manager supporting you, your career growth is dead in the water.

[Masterclass] What Software Engineers Should Look For In Their Engineering Manager

Data structures and algorithms (otherwise known as "DSA") are an infamous part of SWE interviews, especially those of Big Tech companies. They're agonizing, but they can truly be mastered by anybody.

[Masterclass] How To Ace Your Big Tech Interview - Data Structures And Algorithms

As software engineers, we all start off writing code. However, a mindset shift is needed as we become more senior: We need to review more code than we write to positively influence others' technical direction.

[Taro Top 10] Code Review

It doesn't matter how talented you are as an engineer: When a talented developer is pitted against a crappy team, the crappy team wins 99.9% of the team. In order to grow in your career, you must find a supportive team first.

[Masterclass] How To Choose A Good Company And Team As A Software Engineer

As a software engineer, you are more than just your code. As the person bringing the product to life, you are uniquely positioned to have a strong influence on its direction. In fact, it's extremely important for very senior engineers to get to know their PM and develop strong product intuition.

[Taro Top 10] Product Management For Engineers

No matter what, there will always be bugs. As a software engineer, it's crucial for you to master this often underrated skill.

[Taro Top 10] Debugging

Engineers are surprisingly terrible at taking care of themselves. Never forget: A healthy personal life is the foundation for a successful career, not the other way around.

[Taro Top 10] Work-Life Balance

This is one of most important interview rounds, especially for engineers targeting more senior levels. However, so many engineers struggle in these interviews due to poor communication skills.